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

Bài giảng Đảm bảo chất lượng phần mềm: Kiểm chứng sản phẩm giới thiệu nội dung về dùng mẫu thử, lỗi phần mềm, kiểm thử phần mềm, thiết kế testcase, các kỹ thuật debuging. mời các bạn tham khảo nội dung chi tiết.

Nguyễn Anh Hào Khoa CNTT2

 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,

2

1.Dùng mẫu thử

3

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

4

2 Software errors

DEBUG CODE

DESIGN ANALISYS

5

Lỗi phần mềm

1. Tình huống nào thì phần mềm được cho là có

lỗi ?

 Thực hiện sai yêu cầu

 Không thực hiện được chức năng

 Không thỏa mãn yêu cầu về tính năng

6

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

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)

7

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

1. Người yêu cầu (khách hàng) định nghĩa sai

yêu cầu cho phần mềm

2. Hiểu lầm giữa khách hàng và người phát triễn

3. Người phát triễn pm hiểu sai yêu cầu

4. Sai thiết kế luận lý (sai thiết kế về mặt ý niệm)

5. Sai mã lệnh

6. Chương trình thực thi không đúng với yêu cầu

7. Thiếu kiểm thử

8. Lỗi sai trong thủ tục vận hành

9. Lỗi sai trong các tài liệu hướng dẫn sử dụng

8

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

1 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.

 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 Ngăn ngừa lỗi vẫn tốt hơn là sửa lỗi.

4 Tự động hoá kiễm thử là cần thiết

9

 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

10

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)

Testing Levels

12

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

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

13

Test case design

14

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

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

1. Từ usecase & tương tác trong usecase

(requirements)

2. 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

Test plan

 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)

16

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

 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)

17

Control flow graph (CFG)

18

Basis_Path_Testing.pdf

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

Control flow graph (CFG)

19

Control flow graph: example 1

20

Cyclomatic complexity (McCabe,1976)

21

Cyclomatic complexity

22

Cyclomatic complexity

23

Basis set of paths from example 1

24

Generate test cases

25

2. CFG hổ trợ phân hoạch miền giá trị của dữ liệu

đầu vào cho từng path, dựa trên data flow và các điều kiện rẽ nhánh

 Mỗi miền giá trị được phân hoạch của một input

(một biến) là một lớp tương đương.

- Lớp tương đương (equivalence class)

27

 2 inputs cùng thuộc 1 lớp tương đương nếu

chúng được hệ thống xử lý như nhau

◦ Nếu miền giá trị hợp lệ của trường dữ liệu trong khoảng 1-50 thì các giá trị 20, 38, 1, 47 đều cùng thuộc 1 lớp tương đương.

◦ Nếu trường dữ liệu có 2 miền giá trị (true và false) → nó

có 2 lớp tương đương.

 =>Chỉ cần kiểm thử bằng 1 giá trị đại diện trong lớp thay vì kiểm thử mọi trường hợp

 Kiểm thử thêm các trường hợp không thuộc lớp

để kiểm tra khả năng ứng xử với dữ liệu input sai của PM

- Ốc đảo (dependency islands)

28

Giả sử P có 6 inputs I1, I6 và 3 outputs O1,O2,O3

Nếu mỗi input có 5 lớp tương đương thì để test cho 6 inputs cần thực hiện khoảng 5 6 = 15.625 test cases ! Giả sử:

O1 chỉ phụ thuộc I1, I2, I3 → {I1, I2, I3 } là ốc đảo của O1

O2 chỉ phụ thuộc I4, I5 → {I4, I5 } là ốc đảo của O2

O3 chỉ phụ thuộc I6 → {I6 } là ốc đảo của O3

Như vậy:

Đối với O1: chỉ cần test bộ I1, I2, I3 : 5 3 test cases Đối với O2: chỉ cần test bộ I4, I5 : 5 2 test cases Đối với O3: chỉ test I6 : 5 test cases

Theo cách này, tổng số test cases cần thực hiện là

5 3 +5 2 +5 = 155 (thay vì 15.626) test cases.

Integration test

29

Type of unit integration

30

Integration basic path test: example

31

Complexity = 5

Top-down approach

33

Stubs: là các mô-đun “rỗng” (b, c, d) thay thế cho mô-đun thật (B, C, D) để xem mô-đun mức cao (A) có hoạt động đúng không Các stubs chỉ được cài

đặt các giao tiếp (inputs, outputs) và các bảng chuyển đổi inputs-outputs tính sẵn cho các testcases chứ không được cài đặt code chính thức.

Bottom-up vs Top-down

Top-Down: các mô-đun chính được viết và test trước (đối chiếu với chức năng) - như vậy tính logic được nâng cao khi các mô-đun

được kiểm thử xong

Bottom-Up: không có chương trình chạy được cho tới khi mô-đun cuối cùng được test và

tích hợp – lúc này các lỗi thiết kế mới có thể phát hiện và có thể phải làm lại các mô-đun

đã qua kiểm thử !

34

- Nguyên lý Paretto ( luật 20/80 )

35

Những lỗi nghiêm trọng (có tần suất xuất hiện cao) được ưu tiên kiễm thử và sửa trước, để giảm tối đa khả năng gây lỗi của PM

- Gieo lỗi

 Gieo lỗi để ước tính số lỗi có trong phần mềm 

đếm cá trong ao:

1 Bắt N con cá trong hồ nuôi cá Đánh dấu hết toàn

bộ và thả lại vào ao (vậy trong ao có đúng N con

cá có đánh dấu)

2 Quăng 1 mẽ lưới để bắt M con cá trong ao; trong

đó có n con có đánh dấu, và M-n con không đánh dấu.

3 Gọi X là tổng số cá trong ao, thì:

Nếu 1 - Cf không đáng kể thì không cần test nữa

Các kỹ thuật debuging

chương trình bằng cách đặt lệnh in ra màn hình các câu lệnh và giá trị của biến

trên các biểu hiện của lỗi để giới hạn phạm vi gây ra lỗi

đến câu lệnh gây lỗi

37

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

Unit testing framework

jUnit, CPPUnit, Nunit, PyUnit,… gọi chung là xUnit Hàm assert?() thực thi lệnh / hàm và đối chiếu với kết quả được mong đợi để đánh giá

 assertTrue(Boolean condition)

 assertEquals(Object expected, Object actual)

 assertEquals(int expected, int actual)

 assertSame(Object expected, Object actual)

 …

38

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