Bài giảng Kiểm thử và đảm bảo chất lượng phần mềm: Chương 3

Bài giảng Kiểm thử và đảm bảo chất lượng phần mềm: Chương 3 cung cấp cho người học những kiến thức như: Tổng quan về lỗi phần mềm; Thực hành kiểm thử; Kiểm thử tĩnh; Tổng quan về thiết kế trường hợp kiểm thử. Mời các bạn cùng tham khảo!

KỸ THUẬT KIỂM THỬ

1 Các nguyên lý 2 Vòng đời

4 Kiểm thử chức năng

3 Kỹ thuật kiểm thử

5 Kiểm thử cấu trúc 6 Quản lý chất lượng

KIỂM THỬ VÀ ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM Chương 3

Nội dung

Tổng quan về lỗi phần mềm

Thực hành kiểm thử

Kiểm thử tĩnh Tổng quan về thiết kế trường hợp kiểm thử

Một lỗi phần mềm là sự không trùng khớp

giữa chương trình và đặc tả của nó, nếu đặc tả phần mềm tồn tại và được cho là đúng Đặc tả sai  phần mềm sai

Một lồi phần mềm hiện diện khi chương trình không làm cái mà người sử dụng đầu cuối

1) Lỗi giao diện người dùng - User interface errors

2) Lỗi xử lý - Error handling

3) Lỗi liên quan tới ranh giới/biên - Boundary-related errors

4) Lỗi tính toán - Calculation errors

5) Lỗi các trạng thái đầu và sau - Initial and later states

6) Lỗi luồn kiểm soát - Control flow errors

7) Lỗi trong xử lý hoặc dịch dữ liệu - Errors in handling or interpreting data 8) Tranh đoạt điều khiển - Race conditions

9) Điều kiện tải - Load conditions

10) Phần cứng – Hardware

11) Kiểm soát phiên bản và mã nguồn – Source and version control

12) Tài liệu – Document

13) Các lỗi kiểm thử – Testing errors

4

Có nhiều cách để làm cho chương trình làm việc một cách khó khăn, người ta quy chúng vào một nhóm lỗi có tên là “Lỗi giao diện người dùng”

Lỗi giao diện người dùng chia thành nhiều nhóm nhỏ

­ Functionality: chFunctionality: chươ ươ ng tri nh không la m nh ng th  nh  no  nên la m, hoăc la m ng tri nh không la m nh ng th  nh  no  nên la m, hoăc la m ̀ ̀ ̀ ̀ ư ư ̃ ̃ ư ư ́ ́ ư ư ́ ́ ̀ ̀ ̣ ̣ ̀ ̀ môt ca ch khô s  hay không hoa n chinh ̣ ́ ̉ ở ̀ ̉

môt ca ch khô s  hay không hoa n chinh ̣ ́ ̉ ở ̀ ̉

­ Communication: La m thê  na o đê ti m ra ca ch s  dung chCommunication: La m thê  na o đê ti m ra ca ch s  dung ch̀ ̀ ́ ́ ̀ ̀ ̉ ̉ ̀ ̀ ́ ́ ử ử ̣ ̣ ươ ươ ng tri nh? No  co  ng tri nh? No  co  ̀ ̀ ́ ́ ́ ́ chi nh xa c không? Co  gi  đo  nhâ m lâ n, sai lêch không? ́ ́ ́ ̀ ́ ̀ ̃ ̣

chi nh xa c không? Co  gi  đo  nhâ m lâ n, sai lêch không? ́ ́ ́ ̀ ́ ̀ ̃ ̣

­ Command structure: Co  dê  bi lac trong chCommand structure: Co  dê  bi lac trong ch́ ́ ̃ ̃ ̣ ̣ ̣ ̣ ươ ươ ng tri nh không? Co  lênh na o dê  bi ng tri nh không? Co  lênh na o dê  bi ̀ ̀ ́ ́ ̣ ̣ ̀ ̀ ̃ ̃ ̣ ̣ nhâ m lâ n không? Co  lô i na o la m ban la ng phi  th i gian không? Vi  sao? ̀ ̃ ́ ̃ ̀ ̀ ̣ ̃ ́ ơ ̀ ̀

nhâ m lâ n không? Co  lô i na o la m ban la ng phi  th i gian không? Vi  sao? ̀ ̃ ́ ̃ ̀ ̀ ̣ ̃ ́ ơ ̀ ̀

­ Missing commands: chMissing commands: chươ ươ ng tri nh thiê u lênh, c ng nhă c va  kho  điê u chinh đê  ng tri nh thiê u lênh, c ng nhă c va  kho  điê u chinh đê  ̀ ̀ ́ ́ ̣ ̣ ư ư ́ ́ ́ ́ ̀ ̀ ́ ́ ̀ ̀ ̉ ̉ ̀ ̀ phu  h p v i t ng đô i t ̀ ợ ơ ư ́ ̀ ́ ượ ng ng ươ ̀ i s  dung. VD phi m tă t ử ̣ ́ ́

phu  h p v i t ng đô i t ̀ ợ ơ ư ́ ̀ ́ ượ ng ng ươ ̀ i s  dung. VD phi m tă t ử ̣ ́ ́

1) User interface errors

Không lường trước hết các sai sót của chương trình và bảo vệ chương trình trước các sai sót này

Thiếu thông báo lỗi hoặc điều kiện sinh ra lỗi.

Giải quyết lỗi được phát hiện không hợp lý

Vd trong việc bảo vệ chống lại dữ liệu bị corrupt, kiểm tra dữ liệu đầu vào người dùng, kiểm soát phiên bản,

bỏ qua lỗi tràn bộ nhớ, so sánh dữ liệu, không phục lỗi, phục hồi khi có lỗi phần cứng

6

Bất kỳ thành phần nào của chương trình được mô tả có sự xuất hiện của miền giá trị: từ nhiều hơn đến ít hơn, từ lớn nhất tới nhỏ nhất, từ sớm nhất tới muộn nhất, đầu tiên tới cuối cùng, ngắn nhất tới dài

nhất đều cần kiểm tra ranh giới miền giá trị Chương trình thường chạy đúng và ổn định với các giá trị nằm trong miền xác định và hay bị gặp lỗi/ sự cố tại các giá trị nằm ngoài biên của miền xác định

Tìm kiếm lỗi ranh giới: vòng lặp, không gian bộ nhớ, thời gian, xử lý sai các trường hợp nằm ngoài ranh giới

VD

­ Sô  lSô  ĺ ́ ượ ượ ng sinh viên tô i thiêu cua 1 l p ti n chi la  15 tô i đa la  40 sinh viênng sinh viên tô i thiêu cua 1 l p ti n chi la  15 tô i đa la  40 sinh viêń ́ ̉ ̉ ̉ ̉ ơ ơ ́ ́ ́ ́ ̉ ̉ ̀ ̀ ́ ́ ̀ ̀

Hiểu sai công thức

Sai số tính toán

Tính toán sai do sai thuật toán

Sử dụng sai công thức

Sử dụng sai kiểu dữ liệu cho công thức tính toán

8

Nhiều chương trình chỉ sai ở lần chạy đầu tiên, ở

những lần chạy sau các thông tin khởi tạo đã được lưu trữ lại nên việc chạy chương trình không gặp lại lỗi này nữa.

Tìm kiếm lỗi: thiết lập chỉ mục dữ liệu bằng không,

khởi tạo biến kiểm soát vòng lặp, khởi tạo lại 1 con trỏ, …

5) Initial and later states

Luồng kiểm soát của một chương trình miêu tả cái mà chương trình sẽ làm tiếp theo trong những hoàn cảnh cụ thể Lỗi luồng kiểm soát xẩy ra khi chương trình thực hiện sai việc làm tiếp

theo.

Lỗi này thường xuất hiện do giả định trạng thái trả ra sai, xử lý ngoại lệ dựa trên cách thoát, tràn trên tràn dưới bộ đệm, thất bại trong việc chặn và bỏ chặn ngắt, các so sánh, lỗi kiểu dữ liệu, thiếu hoặc sai các mặc định - default

Vd Lỗi luồng kiểm soát xẩy ra do câu lệnh rẽ nhánh.

10

Một modun có thể truyền dữ liệu tới modun hoặc chương trình khác Một tập dữ liệu có

thể được truyền đi và nhận lại nhiều lần

Trong quá trình này tập dữ liệu có thể bị

corrupt (hỏng) hoặc dịch sai Những thay đổi cuối cùng tới dữ liệu có thể bị mất hoặc thất lạc tới một vài phần khác của hệ thống.

7) Errors in handling or interpreting data

Khi làm việc với dữ liệu chia sẻ, dù ở dạng tệp, cơ sở dữ liệu, các kết nối mạng, bộ nhớ dùng chung hay ở những dạng khác của truyền

thông liên tiến trình, có một số lỗi dễ tạo ra làm tổn thương tới tính bảo mật của hệ thống, đặc biệt là trong các hệ thống đa xử lý.

Ví dụ, nếu bạn mở một tệp và sau đó đọc nó, mặc dù ứng dụng của bạn không làm gì giữa hai hoạt động, vài quy trình khác có thể thay thế tệp sau khi tệp đã được mở và trước khi được đọc Nếu hai tiến trình khác nhau (trong cùng hoặc khác ứng dụng) đang ghi lên chung một tệp, sẽ không có cách nào để biết cái nào ghi trước, cái nào sẽ ghi đè lên dữ liệu được ghi bởi tiến trình kia Tình huống này gây ra

lỗ hổng về bảo mật

12

Chương trình có thể hoạt động sai khi bị quá tải, nó có thể bị lỗi khi chạy trong một thời gian quá dài hoặc thực thi

quá trọng tải cho phép, chiếm dụng quá vùng nhớ cho

phép, thất bại khi cố chia sẻ vùng nhớ hoặc thời gian sử dụng CPU với chương trình khác hoặc giữa hai tiến trình con của nó

Ghi nhớ rằng tất cả mọi chương trình đều có giới hạn Vấn đề là nó có đáp ứng được các giới hạn đã đề ra hoặc cách xử lý thất bại khi vượt quá giới hạn cho phép

Vd chương trình gửi dữ liệu tới các thiết bị

rồì lờ đi các mã lỗi phản hồi lại, và cố gắng sử dụng thiết bị phần cứng đang bận hoặc không tồn tại gây ra lỗi về phần cứng.

Hoặc trong trường hợp khác, nếu phần cứng hỏng, phần mềm cũng bị hỏng nếu nó không nhận ra và khôi phục lại từ phần cứng hỏng.

14

Cần kiểm soát phiên bản và toàn vẹn mã

nguồn, tránh trường hợp kiểm thử đi kiểm thử lại một phần mã nguồn phiên bản cũ

QA đưa ra những quy định chặt chẽ về toàn

vẹn mã nguồn và kiểm soát phiên bản mã

nguồn

Có thể dùng công cụ hỗ trợ để kiểm soát, vd GitHub, SVN,

Các tài liệu cũng là một phần của sản phẩm phần mềm Tài liệu nghèo nàn, kém chất

lượng có thể làm người sử dụng tin là sản

phẩm làm việc không chính xác

16

Các lỗi được tạo ra bởi kiểm thử viên là một

trong các lỗi phổ biến nhất được pha kiểm thử, chẳng qua là do người kiểm thử không báo cáo lại chi tiết các ca kiểm thử đó Nhưng kiểm thử viên nên ghi nhớ một số lỗi trong những lỗi bạn mắc phải khi sử dụng chương trình hoặc việc

bạn gặp quá nhiều lỗi kiểm thử khi kiểm thử có thể phản ánh các vấn đề trong giao diện người sử dụng  đây có thể tiềm ẩn lỗi trong thiết kế Khi đó các lỗi của bạn chính là các dữ liệu kiểm thử cho chương trình

Khi có lỗi/ vấn đề được tìm thấy qua hoạt động kiểm thử, nó cần được báo cáo lại một cách rõ ràng, dễ hiểu để người

khác có thể đọc và fix nó  viết bug report

Làm thế nào để viết bug report hiệu quả

- Mô tả làm thế nào để sinh ra vấn đề Các lập trình viên bỏ

qua các báo cáo của các vấn đề mà bản thân họ không thể nhìn thấy

- Phân tích lỗi để có thể miêu tả nó bên trong một số lượng

bước tối thiểu, bỏ qua các bước không cần thiết

- Viết một báo cáo hoàn chỉnh, dễ hiểu sao cho lập trình viên

không bị hiểu lầm hay bực mình

Vòng đời của bug và nội dung bug

report

Vo ng  ̀

đ i cua  ơ ̀ ̉

bug

Program, release,

version: thông tin về

chương trình, phiên bản

code hay bản phát hành

Severity - mức độ

nghiêm trọng của lỗi:

Bó buộc mạnh bạo Lật ngược

Loại bỏnguyên nhân

Cách tiếp cận gỡ lỗi

lượng lớn thông tin đưa ra

VẤN ĐỀ: chương trình có lỗi nhưng kết quả cuối cùng có thể không lỗi

Có thể lãng phí thời gian và công sức

Lo i b  nguyên nhân ạ ỏ

Quy nạp hay diễn dịch và đưa vào khái niệm về phân

hoạch nhị phân

Dữ liệu có liên quan tới việc xuất hiện lỗi được tổ chức để

cô lập ra các nguyên nhân tiềm năng

Một “giả thiết nguyên nhân” được nêu ra và dữ liệu trên được dùng để chứng minh hay bác bỏ giả thiết đó

Một cách khác, xây dựng ra một danh sách mọi nguyên

nhân đặc biệt có nhiều hứa hẹn thì dữ liệu sẽ được làm mịn thêm để cố gắng cô lập ra lỗi

Nội dung

Tổng quan về lỗi phần mềm

Thực hành kiểm thử

Kiểm thử tĩnh Tổng quan về thiết kế trường hợp kiểm thử

Kỹ thuật kiểm thử

1 2 3

4 5 6

Kiểm thử phần mềm

Vai trò con ng ườ i trong vi c ki m  ệ ể

thử

Quy trình ki m th  t ng quát ể ử ổ

Thi t k  tr ế ế ườ ng h p ki m th   ợ ể ử d a  ự

Thi t k  ki m th  d a trên phân  ế ế ể ử ự

Xác định các phân hoạch đầu vào và phân

hoạch đầu ra và thiết kể thử nghiệm

Hệ thống thực hiện với đầu vào từ tất cả các phân hoạch và sinh ra đầu ra trong tất cả các phân hoạch

Các phân hoạch là các nhóm dữ liệu có chung đặc tính như tất cả các số đều âm, tất cả tên đều có đều có độ dài nhỏ hơn 30 ký tự, tất cả các sự kiện phát sinh từ việc chọn các mục

Thi t k  ki m th  d a trên c u  ế ế ể ử ự ấ

Các ph ươ ng pháp ki m th ể ử

Phân loại dựa vào việc chạy chương trình:

kiểm thử tĩnh là các kỹ thuật đánh giá, định

hướng kiểm tra các tài liệu và mã nguồn mà không cần chạy chương trình Kiểm thử động

là phương pháp thông qua việc chạy chương trình để kiểm tra đánh giá

Phân loại theo cách tiếp cận hộp: kiểm thử

hộp trắng và kiểm thử hộp đen, kiểm thử hộp xám

Các k  thu t ki m th ỹ ậ ể ử

Kiểm thử tĩnh (Không thực thi chương trình)

• Danh sách các ki m tra tài li u, đ c t ,  Danh sách các ki m tra tài li u, đ c t ,  ể ể ệ ệ ặ ả ặ ả

    mã ngu n, vv mã ngu n, vv ồ ồ

Kiểm thử chức năng (Hộp đen)

• D a trên hành vi/ ch c năng ph n m m D a trên hành vi/ ch c năng ph n m m ự ự ứ ứ ầ ầ ề ề

Kiểm thử cấu trúc (Hộp trắng)

• D a trên c u trúc ph n m m D a trên c u trúc ph n m m ự ự ấ ấ ầ ầ ề ề

M t vài k  thu t ki m th ộ ỹ ậ ể ử

Structural

Behavioural

Functional Non-functional

Reviews

Walkthroughs

Desk-checking

Data Flow

Data Flow

Equivalence Partitioning

Boundary Value Analysis

Boundary Value Analysis

Cause-Effect Graphing Random

Usability

Usability

Performance

Static Analysis Inspection

Control Flow

Control Flow

Ph ươ ng pháp ki m th  tĩnh ể ử

Xem xét đặc tả

Xem xét mã nguồn

Duy t đ c t  m c cao ệ ặ ả ứ

Đối chiếu chuẩn mực hiện hành

­ Thu t ng , qui  Thu t ng , qui  ậ ậ ữ ữ ướ ướ c c

­ Chu n m c qu c t , Chu n m c qu c t , ẩ ẩ ự ự ố ế ố ế

­ Chu n do đ a ph Chu n do đ a ph ẩ ẩ ị ị ươ ươ ng ban hành ng ban hành

­ Chu n v  an ninh Chu n v  an ninh ẩ ẩ ề ề

­ Chu n v  d  s  d ng Chu n v  d  s  d ng ẩ ẩ ề ễ ử ụ ề ễ ử ụ

­

­ Ph  bi n thông tin Ph  bi n thông tin ổ ế ổ ế

­ Tăng tính t  giác  Tăng tính t  giác  ự ự

­ Tăng tính đ ng đ i Tăng tính đ ng đ i ồ ồ ộ ộ

­ Phát hi n các c i ti n h u ích Phát hi n các c i ti n h u ích ệ ệ ả ế ả ế ữ ữ

40

Ph n bi n chéo ả ệ

Kiểm tra lẫn nhau, phi hình thức

Qui trình tương tự phản biện hình thức,

nhưng đơn giản hóa bớt

­ Ng Ng ườ ườ i trình bày không ph i là tác gi  nói và nh n  i trình bày không ph i là tác gi  nói và nh n  ả ả ả ả ậ ậ

Đảm bảo tính nhất quán, dễ hiểu của mã

nguồn do nhiều người cùng viết, sửa

42

Danh sách ki m tra mã ngu n ể ồ

Kiểm tra theo danh sách để không bỏ sót

­ L i tham chi u d  li u L i tham chi u d  li u ỗ ỗ ế ế ữ ệ ữ ệ

­ L i mô t  d  li u L i mô t  d  li u ỗ ỗ ả ữ ệ ả ữ ệ

­ L i tính toán L i tính toán ỗ ỗ

­ L i đi u khi n L i đi u khi n ỗ ỗ ề ề ể ể

­ L i truy n tham s L i truy n tham s ỗ ỗ ề ề ố ố

­

­ ❏ ❏   Are there any blocks of repeated code that could be condensed into a single  procedure?

­ ❏ ❏   Is storage use efficient?

­ ❏ ❏   Are symbolic used rather than “magic number” constants or string constants?

­ ❏ ❏   Are any modules excessively complex and should be restructured or split into  multiple routines?

44

Ví d  danh sách ki m tra ụ ể

Documentation

­ ❏ ❏   Is the code clearly and adequately documented with an easy­to­maintain  commenting style?

­ ❏ ❏   Are all comments consistent with the code?

Variables

­ ❏ ❏   Are all variables properly defined with meaningful, consistent, and clear  names?

­

Nội dung

Tổng quan về lỗi phần mềm

Quy trình kiểm thử Kiểm thử tĩnh Tổng quan về thiết kế trường hợp kiểm thử

Kỹ thuật kiểm thử

1 2 3

4 5 6

Kiểm thử phần mềm

Những tài liệu tester cần đọc hiểu

Định hướng test của tester

Quy trình test

Sự cần thiết của test case

Các thành phần của test case

Kỹ thuật thiết kế test case

50

T ng quan v  thi t k  tr ổ ề ế ế ườ ng h p  ợ

ki m th ể ử

Requirement documents : Những yêu cầu, mong muốn, suy

nghĩ của khách hàng về phần mềm mà họ muốn

Specification documents : Những ý tưởng, dự định của chúng

ta để hiện thực hóa những yêu cầu, mong muốn của khách

Design documents : phải có 2 textfield username, password,

Functional Requirement ( yêu cầu chức năng ) : test theo những chức năng chính mà phần mềm cần phải có.

Non-functional Requirement ( yêu cầu phi chức năng ) : test

những chức năng mà phần mềm nên có hoặc nên giống như thế Gồm 3 loại non-functional: Look and feel , Boundary, Negative

52

Non-functional Requirement

­ Look and feel (c m giác ng(c m giác ngảả ườười dùng ) : theo c m giác c a ngi dùng ) : theo c m giác c a ngảả ủủ ườ ửườ ửi s  i s  

­ Boundary (biên) : ki m tra nh ng gi i h n có th  có c a  ph n m m. (biên) : ki m tra nh ng gi i h n có th  có c a  ph n m m. ểể ữữ ớ ạớ ạ ểể ủủ ầầ ềề

­ Negative (b t th(b t thấấ ườường): ki m tra chuy n gì x y ra khi không đi theo ng): ki m tra chuy n gì x y ra khi không đi theo ểể ệệ ảả

Minh họa với Form login gồm có 2 fields

username, password và một nút submit

login.

Functional: Chức năng chính là login thành

công với valid account

Look and feel: Theo cảm giác của user thì

button nên highlight khi con trỏ đi qua nó

Boundary: giới hạn biên tối đa là 20 ký tự

đươc phép nhập

Negative: khoảng trắng là ký tự bất thường

mà ít người nghĩ tới và có thể gây nên lỗi

54

Ví dụ