Bài giảng Đảm bảo chất lượng phần mềm: Kiểm chứng sản phẩm - Nguyễn Anh Hào

SW Quality Assurance

1

05. Validation
(kiểm chứng sản phẩm)


Nguyễn Anh Hào
Khoa CNTT2
Học viện CNBCVT – Cs Tp.HCM


Validation

2
1.

Là hành động để bảo đảm rằng đặc tả yêu
cầu cho phần mềm là đúng và đầy đủ so với
mong đợi
Ví dụ: hiện thực hố những hiểu biết về PM thành
mẫu thử để đối chiếu với mong muốn.

2.

Là hành động để bảo đảm rằng PM được làm
ra sẽ hoặc đã thỏa mãn mọi yêu cầu đã được
cam kết.
 Thường được hiểu là hết lỗi, ie, khơng tìm được
chứng cứ của lỗi trong PM. Vd: Định nghĩa và

thực hiện hết các testcase trong unit-test,
system test, acceptance test,..


3

1.Dùng mẫu thử

Mẫu thử
Mẫu thử được dùng để sửa hoặc thêm yêu cầu


4

Prototype


2. Software errors

5

ANALISYS
DESIGN
CODE
DEBUG


Lỗi phần mềm

6

1.

Tình huống nào thì phần mềm được cho là có
lỗi ?





Thực hiện sai u cầu
Khơng thực hiện được chức năng
Khơng thỏa mãn u cầu về tính năng
…


Lỗi phần mềm : ngôn từ

7
 Error:

là “sự hư hỏng” trong bản thân chương
trình (vd: logic bị sai).
 Fault: là “sự hư hỏng” trong chức năng xử lý
của chương trình do error gây ra.
 Failure : là “sự hư hỏng” nhận biết được, khi
phần mềm đang chạy đụng đến fault.
Không chắc là fault sẽ luôn luôn gây ra failure.
 Defect:

là khiếm khuyết của chương trình theo

cách đánh giá của người dùng (không hẳn là do
failures).


Lỗi phần mềm: vài nguyên nhân

8
1.
2.
3.
4.
5.
6.
7.
8.
9.

Người yêu cầu (khách hàng) định nghĩa sai
yêu cầu cho phần mềm.
Hiểu lầm giữa khách hàng và người phát triễn.
Người phát triễn pm hiểu sai yêu cầu
Sai thiết kế luận lý (sai thiết kế về mặt ý niệm)
Sai mã lệnh.
Chương trình thực thi khơng đúng với yêu cầu
Thiếu kiểm thử
Lỗi sai trong thủ tục vận hành
Lỗi sai trong các tài liệu hướng dẫn sử dụng.


Kiểm thử phần mềm : quan điểm

9

Phần mềm có chất lượng tốt là phần mềm khơng có
failure => kiễm thử mọi test case ?
 Dijkstra: kiểm thử chỉ khẳng định PM có lỗi, khơng
thể khẳng định PM hết lỗi, do tổ hợp input-output quá
lớn, điều khiển phức tạp hoặc môi trường sử dụng đa
dạng (SW Testting & QA from theory to practice,
P13)
2. Phát hiện để sửa lỗi trên các ấn phẩm ban đầu (đặc
tả yêu cầu, bản thiết kế) trước khi sử dụng là rất
cần thiết, để tránh phải làm lại.
1.

 Chứng minh cho cách làm và kiễm thử sản phẩm là 2
hành động hổ trợ lẫn nhau; ie ta cần chọn lựa hành
động cho phù hợp.
3.
4.

Ngăn ngừa lỗi vẫn tốt hơn là sửa lỗi.
Tự động hoá kiễm thử là cần thiết


Testing

10


Là hành động tìm chổ sai trong các ấn phẩm
của PM so với yêu cầu, bằng cách thực thi SP
PM hoặc mẫu thử của ấn phẩm.
 Có 4 mức: Unit, integration, system &
Acceptance test






Regression test : tìm hiệu ứng lề khi cập nhật
ấn phẩm; nó là một phần trong 4 loại test trên
Testing cịn gọi là kiểm thử có thực thi ≠ kiểm
thử phi thực thi (verification) : code inspection,
code walk-through,…
Testing ≠ Debug: để hiểu cách thực thi của PM

SW testing and quality assurance from theory to practice.pdf P16


Testing levels

11
1.

Kiểm thử trên từng mơ đun (unit)

 Mơ-đun có được thực thi đúng ?
2.

Kiểm thử tích hợp nhiều mơ đun (integration)

 Các mơ-đun có kết hợp được thành hệ thống ?
 Giao tiếp giữa các mơ-đun có đúng ?
3.

Kiểm thử hệ thống (system)

 Xem xét mức độ thỏa mãn yêu cầu của PM trong
môi trường chạy (functionality, performance,
reliability, security,…)
4.

Kiểm thử chấp nhận (acceptance)

 Chạy PM trong môi trường sử dụng của users
 PM có thoả yêu cầu ? (peak workload performance,
response-time, human factors test, procedures,
backup & recovery)


12

Testing Levels

SW testing and quality assurance from theory to practice.pdf P16


13

Black box & White box testing
 Black

box testing = functional testing: khơng
cần biết cách thực thi chương trình, chỉ cần biết
logic của chức năng để định nghĩa dữ liệu test
(inputs, expected outcome)
 White box testing = structural testing: xem xét
source code (data flow & control flow) để đưa ra
các testcase


14

Test case design

Thiết kế test-case: verification
Thực thi test-case: validation


15

Thiết kế testcase : test case gì cần ?

3.

Từ usecase & tương tác trong usecase
(requirements)
Xem xét các trạng thái chấp nhận được và

không chấp nhận được từ mỗi hành động xử
lý của usecase trong lược đồ hoạt động, tuần
tự, trạng thái
Lập ra các test-case

4.

Lập test procedures/scripts theo UI design

5.

Lập ra test plan

1.
2.


Test plan

16







Test cases, dựa trên chức năng của PM
Test scripts, dựa trên cách xử lý của chức
năng

Test data (inputs, expected outcome) dựa trên
logic của chức năng
Thủ tục lưu trữ & sử dụng kết quả test (pass,
fail, inconclusive, reports)
Trình tự các bước thực hiện (schedule)
Yêu cầu về phần cứng, phần mềm và các
ràng buộc trong khi test (thiết lập môi trường
test)


Bao nhiêu cái test-case thì đủ ?

17




Nếu một chương trình đã được test và sửa
lỗi thì có phải là nó khơng cịn lỗi, hay bộ
testcase chưa đủ để phát hiện các lỗi còn
lại ?
Nguyên lý McCabe: chỉ ra số test-case tối
thiểu cho một function (→coverage)


18

Control flow graph (CFG)

Basis_Path_Testing.pdf

SW testing & QA theory & practice.pdf (trang 89)


19

Control flow graph (CFG)


20

Control flow graph: example 1


21

Cyclomatic complexity (McCabe,1976)


22

Cyclomatic complexity


23

Cyclomatic complexity


24

Basis set of paths from example 1


25

Generate test cases