TRƯỜNG ĐẠI HỌC CÔNG NGHIỆP TP.HCM MÔN HỌC CÔNG NGHỆ PHẦN MỀM Chương 8 Kiểm thử phần mềm CNPM/NN 1

Bản ghi

1 TRƯỜNG ĐẠI HỌC CÔNG NGHIỆP TP.HCM MÔN HỌC CÔNG NGHỆ PHẦN MỀM Chương 8 Kiểm thử phần mềm 1

2 Nội dung 1. Kiểm thử (Testing)? 2. Chiến lược kiểm thử (Testing Strategy) 1. Kiểm thử đơn vị (unit test) 2. Kiểm thử tích hợp (intergration test) 3. Kiểm thử thẩm tra chức năng (validation test) 4. Kiểm thử hệ thống (system test) 5. Một số loại kiểm thử khác 3. Kỹ Kiểm thử hộp trắng (White Box) 1. Thiết kế test case 2. Kiểm thử hộp trắng (white-box) 3. Kiểm thử các đường cơ bản 4. Kiểm thử cấu trúc lặp 5. Phủ trong kiểm thử 6. Kiểm thử luồng dữ liệuthuật kiểm thử phần mềm 2

3 Nội dung 3. Kiểm thử hộp đen (Black Box) 3. Kiểm thử hộp đen? 4. Kiểm thử giá trị biên (Boundary Value Analysis) 5. Kiểm thử lớp tương đương (Equivalence Class Testing) 6. Kiểm thử dựa vào bảng quyết định (Decision Table Base Testing) 7. Kiểm thử giá trị đặc biệt 4. Các vấn đề khác 1. Kiểm thử hướng đối tượng (OOT) 2. Tự động kiểm thử 3. Gỡ lỗi (Debugging) 3

4 4

5 Các hoạt động 5

6 1. Kiểm thử phần mềm Testing is the process of exercising a program with the specific intent of finding errors prior to (trước khi) delivery to the end user. 6

7 What is... Kiểm thử (Testing): Bằng kinh nghiệm find errors in software (Myers, 1979) establish quality of software (Hetzel, 1988) Một test thành công: finds at least one error test-to-fail passes (software works correctly) test-to-pass 7

8 Kiểm chứng và thẩm định (V&V)??? Kiểm chứng và thẩm định bao gồm kiểm thử phần mềm Kiểm chứng (Verification): Chúng ta đang xây dựng sản phẩm theo đúng cách" Phần mềm phải phù hợp với đặc tả của nó Thẩm định (Validation): Chúng ta đang xây dựng sản phẩm đúng" Phần mềm phải thực hiện những gì người dùng thật sự cần 8

9 Kiểm chứng và thẩm định 9

10 Ai kiểm thử phần mềm? developer Understands the system but, will test "gently" and, is driven by "delivery" independent tester Must learn about the system, but, will attempt to break it and, is driven by quality 10

11 2. Chiến lược kiểm thử (Testing Strategy) 1. Kiểm thử đơn vị (unit test) 2. Kiểm thử tích hợp (intergration test) 3. Kiểm thử hệ thống (system test) 4. Các thuật ngữ kiểm thử. 11

12 3 mức kiểm thử 12

13 2.1 Kiểm thử đơn vị module to be tested results software engineer test cases 13

14 Các mục cần kiểm tra module to be tested interface local data structures boundary conditions independent paths error handling paths test cases 14

15 2.2 kiểm thử tích hợp Chọn lựa chiến luợc: Hướng tiếp cận big bang Chiến lược xây dựng gia tăng 15

16 Kiểm thử top down driver interface local data structures Module boundary conditions independent paths error handling paths stub stub test cases RESULTS 16

17 Driver 17

18 Tích hợp Top Down A top module is tested with stubs (nhánh) B F G C stubs are replaced one at a time, "depth first" D E as new modules are integrated, some subset of tests is re-run 18

19 Sử dụng stub Stub: calender() có gọi đến module tính ngày calc_day() chưa được phát triển String calc_day (Date d) { } return "Sunday"; Driver là một chương trình chính có nhiệm vụ nhận dữ liệu kiểm thử, chuyển dữ liệu đó xuống cho các module bên dười rồi nhận kết quả và xuất ra 19

20 Test drive void calc_day_test_drive() { Date d; String s; } while (1) { } cout << Enter date: ; cin >> d; s = calc_day(d); cout << s << endl; 20

21 Tích hợp Bottom-Up A B F G C drivers are replaced one at a time, "depth first" D E worker modules are grouped into builds and integrated cluster 21

22 Kiểm thử Sandwich A Top modules are tested with stubs (nhánh) B F G C D E Worker modules are grouped into builds and integrated cluster 22

23 2.3. Kiểm thử hệ thống (System testing) 23

24 Kiểm thử hệ thống. 24

25 Kiểm thử tính năng. 2.4 Các thuật ngữ kiểm thử Kiểm thử chấp nhận, Kiểm thử thẩm tra: Kiểm thử Anpha, Beta... Kiểm thử hồi quy (regression). Kiểm thử kiến trúc, môi trường và ứng dụng đặc trưng. Mô hình chữ V. Kiểm thử Smoke. Kiểm thử so sánh. Kiểm thử phục hồi (Recovery testing). Kiểm thử an ninh (Security testing. Kiểm thử áp lực (Stress testing) 25

26 Kiểm thử tính năng Kiểm tra đúng với đặc tả yêu cầu. Hướng dẫn. Dùng nhóm kiểm thử độc lập. Biết những hoạt động mong đợi và output. Kiểm thử cả valid và invalid. Không được biến đổi hệ thống. Có một tiêu chuẩn dừng. 26

27 Kiểm thử chấp nhận (Acceptance testing) Nhằm kiểm tra sự chấp nhận của người dùng. Kiểm thử chấp nhận có thể dựa vào hợp đồng. Nếu không có hợp đồng thì có thể dùng kiểm thử Alpha hay Beta. 27

28 Kiểm thử Alpha: Kiểm thử thẩm tra Được tiến hành ngay tại nơi sản xuất phần mềm. Nhà phát triển phần mềm sẽ quan sát người sử dụng dùng sản phẩm và ghi nhận lại những lỗi phát sinh để sửa chữa. Kiểm thử Beta: Phần mềm được kiểm tra bên ngoài phạm vi của đơn vị sản xuất. Khách hành trực tiếp sử dụng và ghi nhận lỗi để báo lại cho nhà phát triển sửa chữa. 28

29 Kiểm thử hồi quy (regression) 1. Việc kết hợp các module lại với nhau có thể ảnh hưởng đến vòng lặp điều khiển, cấu trúc dữ liệu hay I/O chia sẻ trong một số module 2. Điều đó làm lộ ra một số lỗi không thể phát hiện được khi tiến hành kiểm nghiệm theo đơn vị 3. Kiểm nghiệm hồi quy có thể được tiến hành thủ công bằng cách thực hiện lại các test-case đã tạo ra. Hoặc có thể dùng một công cụ capture-playback để thực hiện tự động 29

30 Kiểm thử kiến trúc, môi trường và ứng dụng đặc trưng Kiểm thử GUI: thường dùng công cụ kiểm thử tự động Kiểm thử client/server: Kiểm thử chức năng ứng dụng Kiểm thử server Kiểm thử cơ sở dữ liệu Kiểm thử truyền thông mạng Kiểm thử tài liệu và trợ giúp Kiểm thử hệ thống thời gian thực Kiểm thử công việc (task) Kiểm thử hành vi Kiểm thử liên tác vụ (inter task) Kiểm thử hệ thống: interrupt với độ ưu tiên, xử lý interrrupt, số lượng interrrupt xuất hiện trong một khoảng thời gian 30

31 Kiểm thử giao diện 31

32 Mô hình kiểm thử V Hệ thống Kiểm thử toàn bộ hệ thống Yêu cầu Kiểm thử tính năng Thiết kế Kiểm thử tích hợp Mã hóa Kiểm Thử đơn vị (module) 32

33 Phương pháp kiểm thử white-box methods black-box methods Methods Strategies 33

34 2. Kiểm thử hộp trắng (White Box) 1. Thiết kế test case. 2. Kiểm thử hộp trắng (white-box). 3. Kiểm thử các đường cơ bản. 4. Kiểm thử cấu trúc lặp. 5. Phủ trong kiểm thử. 6. Kiểm thử luồng dữ liệu. 34

35 Một test tốt? Có khả năng tìm lỗi cao Không dư thừa và tốn quá nhiều công sức để thực hiện Phải tinh chế để là test tốt nhất Không quá đơn giản và quá phức tạp 35

36 3.1 Thiết kế Test Case "Bugs lurk in corners and congregate at boundaries..." Boris Beizer Mục tiêu Tiêu chuẩn Ràng buộc Khám phá lỗi Toàn diện Ít tốn công sức và thời gian 36

37 Test case 37

38 Hướng dẫn thiết kế Test case Kiểm tra cẩn thận những kết quả từ test case trước đó Test case phải viết cho giá trị hợp lệ (valid) và không hợp lệ cũng như điều kiện, input, kết quả mong đợi, không mong đợi (tìm thấy và không tìm thấy ) Phải kiểm thử từ nhỏ tới lớn, không thể kiểm thử tất cả các trường hợp Khi một phần có nhiều lỗi được tìm nó có khả năng có nhiều lỗi hơn 38

39 Ví dụ về định hướng kiểm thử Lựa chọn các đầu vào sao cho hệ thống có thể đưa ra tất cả các thông báo lỗi. Thiết kế đầu vào sao cho vùng nhớ đệm bị tràn. Lặp lại nhiều lần cùng một đầu vào hoặc một chuỗi các đầu vào. Ép hệ thống tạo ra những kết quả không hợp lệ. Buộc cho các kết quả tính phải quá lớn hoặc quá nhỏ. 39

40 Kiểm thử vét cạn (Exhaustive) loop < 20 X 14 There are 10 possible paths! If we execute one test per millisecond, it would take 3,170 years to test this program!! 40

41 2.2 Kiểm thử White-Box... our goal is to ensure that all statements and conditions have been executed at least once... 41

42 Kiểm thử dựa vào cấu trúc? Dựa vào mã nguồn. Kiểm tra cấu trúc nội của chương trình. Test case được đưa từ việc kiểm tra cấu trúc chương trình. Xác định số test case để đảm bảo mức phủ đòi hỏi. 42

43 2.3 Kiểm thử đường cơ bản Path 1: 1,2,3,6,7,8 Path 2: 1,2,3,5,7,8 Path 3: 1,2,4,7,8 Path 4: 1,2,4,7,2,4,...7,

44 Biểu đồ luồng cơ bản 44

45 Kiểm thử các đường cơ bản Kiểm thử các đường cơ bản là một trong những phương cách kiểm nghiệm white-box Bảo đảm số phép thử là ít nhất đủ để phát hiện các lỗi Tất cả các đường cơ bản được thử qua ít nhất một lần Thử các điều kiện rẽ nhánh ở cả 2 nhánh true và false Thử qua vòng lặp tại biên cũng như bên trong Thử qua cấu trúc dữ liệu để đảm bảo tính toàn vẹn của nó Kiểm thử đường cơ bản áp dụng cho những module có tính nghiêm ngặt 45

46 Độ phức tạp lộ trình Cyclomatic Complexity V(G) Complexity V(G): Số rẽ nhánh đơn + 1 V(G) = 4 V(G) = E - N + 2, trong đó E là số cung, N là số nút của đồ thị. V(G) = P + 1, nếu đồ thị chỉ chứa các nút quyết định luận lý (chỉ có 2 cung 46

47 Đưa ra đường cơ bản 1 Since V(G) = 4, Path 1: 1,2,3,6,7,8 Path 2: 1,2,3,5,7,8 Path 3: 1,2,4,7,8 Path 4: 1,2,4,7,2,4,...7,

48 Quy trình xác định các đường cơ bản 1. Xác định đường cơ bản, đường này nên là đường thi hành phổ biến nhất. 2. Để chọn đường thứ 2, thay đổi cung xuất của nút quyết định đầu tiên và cố gắng giữ lại maximum phần còn lại. 3. Để chọn đường thứ 3, dùng đường cơ bản nhưng thay đổi cung xuất của nút quyết định thứ 2 và cố gắng giữ lại maximum phần còn lại. 4. Tiếp tục thay đổi cung xuất cho từng nút quyết định trên đường cơ bản để xác định đường thứ 4, 5,... cho đến khi không còn nút quyết định nào trong đường cơ bản nữa. 5. Lặp dùng tuần tự các đường tìm được làm đường cơ bản để xác định các đường mới xung quanh nó y như các bước 2, 3, 4 cho đến khi không tìm được đường tuyến tính độc lập nào nữa (khi đủ số C). Tom McCabe 48

49 49

50 50

51 Ví dụ với AnalyzeTriangle Đối với chương trình con AnalyzeTriangle Tổng số đường: a<b+ V = = 7 c 2 Đường 1: c > 0 Đường 2: Đường 3: Đường 4: Đường 5: Đường 6: Đường 7: a = c 4 6 a = b 3 8 b = c 7 10 a 2 =b 2 +c

52 Sample Test Cases Assuming Integer Greater than 0 and less than or equal to 200 Test Case X Y Z Expected Output Isosceles Isosceles Not a triangle Isosceles Equilateral Not a triangle Scalene Scalene Not a triangle Isosceles Scalene Isosceles 52

53 2.4 Kiểm thử cấu trúc lặp (Loop) Simple loop Nested Loops Concatenated Loops Unstructured Loops 53

54 Vòng lặp đơn 1. Bỏ qua vòng lặp Simple loop 2. Qua vòng lặp 1 lần 3. Qua vòng lặp 2 lần 4. loop m < n 5. (n-1), n, and (n+1) where n is the maximum number of allowable passes 54

55 Vòng lặp lồng nhau Nested Loops 1. Bắt đầu ở vòng lặp trong cùng, thiết lập tất cả các vòng lặp ngoài có giá trị tham số lặp nhỏ nhất (giá trị bộ đếm) 2. Test vòng lặp trong cùng (test vòng lặp đơn) 3. Di chuyển ra vòng lặp ngoài rồi thực hiện với bước 2 với giá trị của vòng lặp bên trong ở giá trị tùy ý 4. Tiếp tục cho hết vòng lặp 55

56 Vòng lặp nối tiếp Nếu phụ thuộc, chẳng hạn giá trị biến đếm của vòng lặp 1 dùng để khởi động vòng lặp 2 thì xem như 2 vòng lặp lồng nhau Concatenated Loops 56

57 2.5 Phủ trong kiểm thử Phủ cấp 0: kiểm thử những gì có thể kiểm thử được, phần còn lại để người dùng phát hiện và báo lại sau. Đây là mức độ kiểm thử không thực sự có trách nhiệm. Phủ cấp 1: kiểm thử sao cho mỗi lệnh được thực thi ít nhất 1 lần. Với hàm foo bệnh cạnh, ta chỉ cần 2 test case sau đây là đạt 100% phủ cấp 1 : 1. foo(0,0,0,0), trả về 0 2. foo(1,1,1,1), trả về 1 nhưng không phát hiện lỗi chia 0 ở hàng lệnh 8 1 float foo(int a, int b, int c, int d) { 2 float e; 3 if (a==0) 4 return 0; 5 int x = 0; 6 if ((a==b) ((c==d) && bug(a))) 7 x = 1; 8 e = 1/x; 9 return e; 10 } 57

58 Phủ cấp 2 Phủ cấp 2: kiểm thử sao cho mỗi điểm quyết định đều được thực hiện ít nhất 1 lần cho trường hợp TRUE lẫn FALSE. Ta gọi mức kiểm thử này là phủ các nhánh (Branch coverage). Phủ các nhánh đảm bảo phủ các lệnh. Line Predicate True False 3 (a == 0) Test Case 1 foo(0, 0, 0, 0) return 0 6 ((a==b) OR ((c == d) AND bug(a) )) Test Case 2 foo(1, 1, 1, 1) return 1 Test Case 2 foo(1, 1, 1, 1) return 1 Test Case 3 foo(1, 2, 1, 2) return 1 Với 2 test case xác định trong slide trước, ta chỉ đạt được 3/4 x 75% phủ các nhánh. Nếu thêm test case 3 : 3. foo(1,2,1,2), thì mới đạt 100% phủ các nhánh.

59 Phủ cấp 3 Phủ cấp 3: kiểm thử sao cho mỗi điều kiện luận lý con (subcondition) của từng điểm quyết định đều được thực hiện ít nhất 1 lần cho trường hợp TRUE lẫn FALSE. Ta gọi mức kiểm thử này là phủ các điều kiện con (subcondition coverage). Phủ các điều kiện con chưa chắc đảm bảo phủ các nhánh. Predicate True False a ==0 Test Case 1 foo(0, 0, 0, 0) return 0 (a==b) Test Case 2 foo(1, 1, 1, 1) return value 0 Test Case 2 foo(1, 1, 1, 1) return 1 Test Case 3 foo(1, 2, 1, 2) division by zero! (c==d) Test Case 3 foo(1, 2, 1, 2) division by zero! bug(a)

60 Phủ cấp 4 Phủ cấp 4: kiểm thử sao cho mỗi điều kiện luận lý con (subcondition) của từng điểm quyết định đều được thực hiện ít nhất 1 lần cho trường hợp TRUE lẫn FALSE & điểm quyết định cũng được kiểm thử cho cả 2 nhánh. Ta gọi mức kiểm thử này là phủ các nhánh & điều kiện con (branch & subcondition coverage). 60

61 61

62 2.6. Kiểm thử luồng dữ liệu 62

63 Kiểm thử hộp đen. 3. Kiểm thử Black-Box Kiểm thử giá trị biên (Boundary Value Analysis). Kiểm thử lớp tương đương (Equivalence Class Testing). Kiểm thử dựa vào bảng quyết định (Decision Table Base Testing). Kiểm thử giá trị đặc biệt. 63

64 Kiểm thử Black-Box requirements output input events 64

65 Kiểm thử Black-Box 65

66 Kiểm thử Black-Box Hệ thống xem như một hộp kín không cần biết bên trong chỉ cần tạo ra output đúng với chức năng từ input Cần quan tâm về dữ liệu của test case Những lớp input nào sẽ tạo ra những test case tốt? Hệ thống thường nhạy cảm với những giá trị input xác định nào? Biên của những lớp dữ liệu được cô lập như thế nào? Tỷ lệ và độ lớn của dữ liệu mà hệ thống có thể chịu đựng? Các dữ liệu đặc biệt sẽ ảnh hưởng gì đến hệ thống? 66

67 Boundary Value Testing 3.2. Kiểm thử giá trị biên Person s Age Rule 0-16 Don t hire Can hire on a part-time basis only Can hire as a full-time employee Don t hire {-1, 0, 1}, {15, 16, 17}, {17, 18, 19}, {54, 55, 56}, and {98, 99, 100}. 67

68 Xác định giá trị biên 68

69 TestCase Monthly Income Number of Dwellings Result Description $1,000 1 Valid Min income, min dwellings $83,333 1 Valid Max income, min dwellings $1,000 5 Valid Min income, max dwellings $83,333 5 Valid Max income, max dwellings $1,000 0 Invalid Min income, below min dwellings $1,000 6 Invalid Min income, above max dwellings $83,333 0 Invalid Max income, below min dwellings $83,333 6 Invalid Max income, above max dwellings $999 1 Invalid Below min income, min dwellings $83,334 1 Invalid Above max income, min dwellings $999 5 Invalid Below min income, max dwellings $83,334 5 Invalid Above max income, max dwellings 69

70 Kiểm thử lớp tương đương Phân hoạch tương đương (Equivalence partitions) Nhằm giảm các test case Equivalence partitions 70

71 Input trong khoảng [a..b] Ví dụ Chọn một mẫu nhỏ hơn a một mẫu giữa a và b và một mẫu lớn hơn b Input là một tập hợp V Chọn một mẫu trong V và một mẫu ngoài V 71

72 Cách phân hoạch theo input Nếu input là một dãy giá trị, chia thành 1 lớp valid và 2 lớp invalid Nếu input là một giá trị đặc biệt, chia thành 1 lớp valid và 2 lớp invalid Nếu input là một thành viên của tập hợp, chia thành 1 lớp valid và 1 lớp invalid Nếu input là một giá trị boolean, chia thành 1 lớp valid và 1 lớp invalid 72

73 Phân hoạch tương đương 73

74 Testcase cho tìm kiếm nhị phân Số phần tử của mảng: 0, 1 Lớn hơn 1 Khóa tìm kiếm: Không có trong mảng Nhỏ hơn, lớn hơn Xen kẽ Có trong mảng Phần tử đầu tiên, cuối cùng Phần tử ở vị trí bất kỳ 74

75 Testcase 75

76 3.4. Kiểm thử dựa vào bảng quyết định 76

77 Vd: Chương trình xác định tam giác 77

78 3.5. Kiểm thử giá trị đặc biệt (Ad Hoc Testing) Người kiểm tra dựa vào trực giác, kinh nghiệm và kỹ năng để đưa ra test case. Phụ thuộc vào khả năng của người kiểm thử. Thuật ngữ khác: hacking, out-of-box testing. 78

79 Loại kiểm thử và kỹ thuật áp dụng Testing type Unit Testing Integration Testing System Testing Techniques Used White Box White Box Black Box Black Box Accceptance Testing Black Box 79

80 4. Các vấn đề khác 1. Kiểm thử hướng đối tượng (OOT) 2. Tự động kiểm thử 3. Gỡ lỗi (Debugging) 80

81 4.1 Kiểm thử hướng đối tượng Bắt đầu bằng cách đánh giá sự đúng đắn và toàn vẹn của mô hình OOA và OOD Những khác biệt Khái niệm lớp unit Việc tích hợp tập trung vào tích hợp các lớp và dựa vào kịch bản Việc thẩm định sử dụng phương pháp blackbox Thiết kế test case theo phương pháp cũ nhưng phải bao gồm thêm những đặc trưng mới của hướng đối tượng Kiểm thử dựa theo mô hình CRC (lớp-nhiệm vụ-công tác) 81

82 Chiến lược trong OOT Kiểm thử lớp (unit testing) Kiểm thử tác vụ Kiểm tra hành vi, trạng thái của lớp Kiểm thử tích hợp thread-based testing (kiểm thử dựa vào dữ liệu vào) dựa vào đáp ứng của sự kiện hay input use-based testing (kiểm thử dựa vào chức năng) dựa vào chức năng (use case) cluster testing (kiểm thử dựa vào cộng tác) dưa vào sự cộng tác giữa các lớp 82

83 Các loại OOT Kiểm thử hướng lỗi (Fault-based testing) Thiết kế test case dựa vào dự đoán những lỗi có khả năng xảy ra Kiểm thử lớp và phân cấp của lớp (Class Testing and the Class Hierarchy) Thiết kế test dựa vào kịch bản (Scenario - Based Test Design) Dựa vào những gì người dùng làm (use-case) Kiểm thử tương tác (Inter-class) 83

84 Kiểm thử OOT Kiểm thử hành vi (Behavior) Test được thiết kế để duyệt qua tất cả các trạng thái và dịch chuyển trạng thái 84

85 Kiểm thử dịch chuyển trạng thái 85

86 4.2 Tự động kiểm thử Kiểm thử là công việc tốn nhiều công sức. Những hệ thống kiểm thử cung cấp những công cụ cho phép giảm thời gian và chi phí Phần lớn hệ thống kiểm thử là những hệ thống mở Có thể dùng kịch bản để tạo dữ liệu test Output có thể dùng để so sánh một cách thủ công. Có thể phát triển những hệ thống so sánh file 86

87 4.3 Gỡ lỗi (Debugging) 87

88 test cases Quy trình gỡ lỗi regression tests corrections new test cases suspected causes identified causes Debugging results 88

89 Dấu hiệu và nguyên nhân Dấu hiệu và nguyên nhân có thể khác biệt về nơi Dấu hiệu có thể biến mất khi một vấn để khác đã được sửa Nguyên nhân có thể do sự kết hợp của yếu tố không thực sự là lỗi Nguyên nhân có thể là do lỗi của hệ thống hay của bộ biên dịch symptom cause Nguyên nhân có thể là những giả định mà mọi người tin tưởng Dấu hiệu có thể lúc có lúc không 89

90 Kỹ thuật gỡ lỗi Brute force Backtracking Loại trừ nguyên nhân (cause elimination) Kiểm thử 90

91 BRUTE FORCE Áp dụng phương pháp này khi tất cả các phương pháp khác đều thất bại. Là phương pháp phổ biến nhất nhưng lại ít hiệu quả nhất cho việc phát hiện nguyên nhân gây lỗi phần mềm. Triết lý của phương pháp này là: Hãy để máy tính tìm ra lỗi. Cách thực hiện: Lấy dữ liệu trong bộ nhớ để xem xét. Dùng run-time trace để tìm lỗi. Dùng lệnh WRITE để xuất dữ liệu cần kiểm tra ra màn hình. 91

92 LẦN VẾT NGƯỢC (Backtracking) Cách thực hiện: bắt đầu tại dòng mã nguồn có triệu chứng lỗi thực hiện lần ngược trở lại từng dòng mã nguồn cho đến khi tìm thấy dòng gây ra lỗi. Là một phương pháp gỡ lỗi khá phổ biến có thể dùng thành công trong các chương trình nhỏ nhưng khó áp dụng cho đối với các chương trình rất lớn. 92

93 Cách thực hiện: LOẠI TRỪ NGUYÊN NHÂN Khi một lỗi được phát hiện, cố gắng đưa ra một danh sách các nguyên nhân có thể gây ra lỗi (các giả thiết) Danh sách này được xem xét lại để loại bỏ dần các nguyên nhân không đúng cho đến khi tìm thấy một nguyên nhân khả nghi nhất (dùng dữ liệu liên quan) Khi đó dữ liệu kiểm thử sẽ được tinh chế lại để tiếp tục tìm lỗi. 93

94 Gỡ lỗi bằng kiểm thử Dùng Test case. Dùng cùng với phương pháp quy nạp. 94

95 Các lưu ý Đừng vội vã hãy suy xét đến những dấu hiệu mà bạn thấy Dùng công cụ hỗ trợ (dynamic debugger ) Khi bế tắc nên nhờ người khác trợ giúp Khi gỡ lỗi cần phải thực hiện kiểm thử hồi qui (regression tests) 95