›

Bài giảng Công nghệ Phần mềm - Chương 5: Kiểm chứng phần mềm - Trần Anh Dũng

ppt 115 trang huongle 1960
Download
Bạn đang xem 20 trang mẫu của tài liệu "Bài giảng Công nghệ Phần mềm - Chương 5: Kiểm chứng phần mềm - Trần Anh Dũng", để tải tài liệu gốc về máy bạn click vào nút DOWNLOAD ở trên

Tài liệu đính kèm:

  • pptbai_giang_cong_nghe_phan_mem_chuong_5_kiem_chung_phan_mem_tr.ppt

Nội dung text: Bài giảng Công nghệ Phần mềm - Chương 5: Kiểm chứng phần mềm - Trần Anh Dũng

  1. Chương 5. Kiểm chứng Phần mềm (Software Testing) GVLT: Trần Anh Dũng 1
  2. Nội dung ❖ Giới thiệu ❖ Khái niệm kiểm thử phần mềm ❖ Tại sao phải kiểm thử phần mềm ❖ Các nguyên lý trong kiểm thử phần mềm ❖ Các mức độ kiểm thử ❖ Các kỹ thuật kiểm thử  Kiểm thử hộp đen  Kiểm thử hộp trắng 2
  3. Giới thiệu A person makes an error that creates a fault (bug, defect) in the software that can cause a failure in operation 3
  4. Khái niệm kiểm thử phần mềm ❖ Kiểm thử phần mềm là quá trình thực thi phần mềm với mục tiêu tìm ra lỗi Glen Myers, 1979 → Khẳng định được chất lượng của phần mềm đang xây dựng Hetzel, 1988 4
  5. Một số đặc điểm kiểm thử PM ❖ Kiểm thử phần mềm giúp tìm ra được sự hiện diện của lỗi nhưng không thể chỉ ra sự vắng mặt của lỗi Dijkstra ❖ Mọi phương pháp được dùng để ngăn ngừa hoặc tìm ra lỗi đều sót lại những lỗi khó phát hiện hơn Beizer ❖ Điều gì xảy ra nếu việc kiểm thử không tìm được lỗi trong phần mềm hoặc phát hiện quá ít lỗi 5
  6. Tại sao kiểm thử lại cần thiết? ❖ Nhằm tăng độ tin cậy cũng như chất lượng của phần mềm. ❖ Giảm chi phí trong quá trình phát triển, nâng cấp, bảo trì phần mềm ❖ Ví dụ:  Website công ty có nhiều lỗi chính tả trong câu chữ →Khách hàng có thể lãng tránh công ty với lý do công ty trông có vẻ không chuyên nghiệp.  Một phần mềm tính toán lượng thuốc trừ sâu dùng cho cây trồng, vì lý do tính sai số lượng lên gấp 10 lần →Nông dân phải bỏ nhiều tiền mua, cây trồng hư hại, môi trường sống, nguồn nước bị ảnh hưởng, 6
  7. Lỗi tăng lên khi nào? 7
  8. Lỗi tăng lên khi nào? ❖ Chi phí cho việc tìm thấy và sửa lỗi tăng dần trong suốt chu kỳ sống của phần mềm. Lỗi tìm thấy càng sớm thì chi phí để sửa càng thấp và ngược lại. 8
  9. Các nguyên lý trong kiểm thử PM ❖ Lập trình viên không nên thực hiện kiểm thử trên phần mềm mà mình đã viết ❖ Cần phải kiểm tra các chức năng mà phần mềm không thực hiện ❖ Tránh việc kiểm thử phần mềm với giả định rằng sẽ không có lỗi nào được tìm thấy ❖ Test case phải định nghĩa kết quả đầu ra rõ ràng ❖ Test case phải được lưu trữ và thực thi lại mỗi khi có sự thay đổi xảy ra trong hệ thống 9
  10. Vai trò kiểm thử ❖ Vai trò kiểm thử trong suốt quy trình sống của phần mềm  Kiểm thử không tồn tại độc lập.  Các hoạt động của kiểm thử luôn gắn liền với các hoạt động phát triển phần mềm.  Các mô hình phát triển phần mềm khác nhau cần các cách tiếp cận kiểm thử khác nhau.
  11. Các mức độ kiểm thử (Test levels) Acceptance System Integration Component 11
  12. Các mức độ kiểm thử (Test levels) ❖ Component testing (unit testing):  Tìm lỗi trong các component của phần mềm như: modules, objects, classes,  Do có kích thước nhỏ nên việc tổ chức, kiểm tra, ghi nhận và phân tích kết quả trên Unit test có thể thực hiện dễ dàng  Tiết kiệm thời gian, chi phí trong việc dò tìm và sửa lỗi trong các mức kiểm tra sau 12
  13. Các mức độ kiểm thử (Test levels) ❖ Integration testing:  Test sự kết hợp của các component, sự tác động của các phần khác nhau trong một hệ thống, sự kết hợp của các hệ thống với nhau, 13
  14. Các mức độ kiểm thử (Test levels) ❖ System testing:  Đảm bảo rằng hệ thống (sau khi tích hợp) thỏa mãn tất cả các yêu cầu của người sử dụng  Tập trung vào việc phát hiện các lỗi xảy ra trên toàn hệ thống ❖ Acceptance testing:  Test phần mềm đứng dưới góc độ người dùng để xác định phần mềm có được chấp nhận hay không. 14
  15. Các kỹ thuật kiểm thử ❖ Test tĩnh (Static Verification)  Thực hiện kiểm chứng mà không cần thực thi chương trình  Kiểm tra tính đúng đắn của các tài liệu có liên quan được tạo ra trong quá trình xây dựng ứng dụng  Đạt được sự nhất quán và hiểu rõ hơn về hệ thống  Giảm thời gian lập trình, thời gian và chi phí test, ❖ Test động (Dynamic Testing)  Thực hiện kiểm thử dựa trên việc thực thi chương trình 15
  16. Dynamic Testing - Kiểm thử động Dynamic Specification-based Structure-based Equivalence Experience-based Partitioning Basis Path Boundary Value Error Analysis Control-flow Guessing Decision Tables Cause-Effect Data-flow Exploratory Testing Graphing 16
  17. Các phương pháp kiểm thử (1) ❖ Funtional Testing (Black Box Testing):  Test dựa trên mô tả, chúng ta xem xét phần mềm với các dữ liệu đầu vào và đầu ra mà không cần biết cấu trúc của phần mềm ra sao. Nghĩa là tester sẽ tập trung vào những gì mà phần mềm làm, không cần biết phần mềm làm như thế nào.  Ưu điểm: ▪ Không phụ thuộc vào việc thực hiện phần mềm ▪ Việc phát triển test case có thể diễn ra song song với quá trình thực hiện phần mềm → Rút ngắn thời gian thực hiện dự án 17
  18. Các kỹ thuật kiểm thử hộp đen ❖ Kỹ thuật phân lớp tương đương (Equivalence Class Testing) ❖ Kỹ thuật dựa trên giá trị biên (Boundary Value Testing) ❖ Kỹ thuật dựa trên bảng quyết định (Decision Table- Based Testing) ❖ Kỹ thuật dựa trên đồ thị nguyên nhân – kết quả (causes- effects) ❖ 18
  19. Các phương pháp kiểm thử (2) ❖ Structural Testing (White Box Testing):  Test dựa trên cấu trúc còn được gọi là white-box hay glass-box bởi vì nó đòi hỏi sự hiểu biết về cấu trúc của phần mềm, nghĩa là phần mềm hoạt động như thế nào. 19
  20. Các kỹ thuật kiểm thử hộp trắng ❖ Basis Path Testing ❖ Control-flow/Coverage Testing ❖ Data-flow Testing 20
  21. Các phương pháp kiểm thử (3) ❖ Experience Testing (Test dựa trên kinh nghiệm)  Kỹ thuật này đỏi hỏi sự hiểu biết, kỹ năng và kinh nghiệm của người test.  Dựa vào những kinh nghiệm thu thập được từ những hệ thống trước đó, tester có thể dễ dàng nhìn thấy được những điểm sai trong chương trình. 21
  22. Các kỹ thuật kiểm thử hộp đen (1) ❖ Kỹ thuật phân lớp tương đương (Equivalence Class Testing) ❖ Kỹ thuật dựa trên giá trị biên (Boundary Value Testing) ❖ Kỹ thuật dựa trên bảng quyết định (Decision Table- Based Testing) ❖ Kỹ thuật dựa trên đồ thị nguyên nhân – kết quả (causes- effects) ❖ 22
  23. Kỹ thuật phân lớp tương đương ❖ Ví dụ: Một textbox chỉ cho phép nhập số nguyên từ 1 đến 100 → Ta không thể nhập tất cả các giá trị từ 1 đến 100 ❖ Ý tưởng của kỹ thuật này: Chia (partition) đầu vào thành những nhóm tương đương nhau (equivalence). ❖ Giảm đáng kể số lượng test case cần phải thiết kế vì với mỗi lớp tương đương ta chỉ cần test trên các phần tử đại diện Kiểm thử hộp đen (Black Box Testing) 23
  24. Kỹ thuật phân lớp tương đương ❖ Có hai yếu tố ảnh hưởng đến việc thiết kế test case  Dựa trên giả định (Assumption) ▪ Single fault assumption → Weak ECT (Equivalence Class Testing) ▪ Multiple fault assumption → Strong ECT  Dựa trên loại dữ liệu inputs ▪ Kiểm thử trên dữ liệu hợp lệ → Normal ECT ▪ Kiểm thử trên dữ liệu không hợp lệ → Robust ECT Assumption Single Fault Multiple Faults Data Valid Weak Normal Strong Normal Invalid Weak Robust Strong Robust 24
  25. Kỹ thuật phân lớp tương đương ❖ Weak Normal Equivalence Class Testing ❖ Strong Normal Equivalence Class Testing ❖ Weak Robust Equivalence Class Testing ❖ Strong Robust Equivalence Class Testing Kiểm thử hộp đen (Black Box Testing) 25
  26. Weak Normal Equivalence Class Testing ❖ Dựa trên Single Fault Assumption  Một failure ít khi nào là kết quả của 2 hay nhiều faults xảy ra cùng 1 lúc ❖ Ví dụ:  e ≤ x1 ≤ g, x1 có 2 lớp tương đương [e, f) [f, g]  a ≤ x2 ≤ d, x2 có 3 lớp tương đương [a, b) [b, c), [c, d] Kỹ thuật phân lớp tương tương 26
  27. Weak Normal Equivalence Class Testing X1 Weak normal equivalence class test cases for a function of 2 variables g P2 f P1 P3 e X2 a b c d Kỹ thuật phân lớp tương tương 27
  28. Strong Normal Equivalence Class Testing ❖ Dựa trên Multiple Fault Assumption  Một failure có thể là kết quả của 2 hay nhiều faults xảy ra cùng 1 lúc X1 Strong normal equivalence class test cases for a function of 2 variables g f e X2 a b c d 28
  29. Weak Robust Equivalence Class Testing ❖ Tương tự Weak Equivalence Class Testing, tuy nhiên test thêm trường hợp 1 biến với giá trị không hợp lệ X1 Weak robust equivalence class test cases for a function of 2 variables g For valid input: 1 value/ equivalence class. Invalid f input: a test case will have one invalid value and the e remaining values will all be valid. a b c d X2 Kỹ thuật phân lớp tương tương 29
  30. Strong Robust Equivalence Class Testing Strong robust equivalence X1 class test cases for a function of 2 variables g f e X2 a b c d Kỹ thuật phân lớp tương tương 30
  31. Các kỹ thuật kiểm thử hộp đen (2) ❖ Kỹ thuật phân lớp tương đương (Equivalence Class Testing) ❖ Kỹ thuật dựa trên giá trị biên (Boundary Value Testing) ❖ Kỹ thuật dựa trên bảng quyết định (Decision Table- Based Testing) ❖ Kỹ thuật dựa trên đồ thị nguyên nhân – kết quả (causes- effects) ❖ 31
  32. Kỹ thuật phân tích giá trị biên ❖ Phân tích giá trị biên - Boundary Value Analysis ❖ Thường được áp dụng đối với các đối số của một phương thức ❖ Tập trung vào việc kiểm thử các giá trị biên của miền giá trị inputs để thiết kế test case do “lỗi thường tiềm ẩn lại các ngõ ngách và tập hợp tại biên” ( Beizer ) ❖ BVA hiệu quả nhất trong trường hợp “các đối số đầu vào (input variables) độc lập với nhau và mỗi đối số đều có một miền giá trị hữu hạn” 32
  33. Kỹ thuật phân tích giá trị biên ❖ Giả sử hàm F có hai biến X1, X2 như sau:  a ≤ X1 ≤ b  c ≤ X2 ≤ d ❖ Input domain of a function of two variables: X2 d Set of legitimate inputs for function F c a b X1 33
  34. Một số kỹ thuật kiểm thử giá trị biên ❖ Standard BVA ( Boundary Value Analysis ) ❖ Robustness testing ❖ Worst-case testing ❖ Robust worst-case testing Kỹ thuật phân tích giá trị biên 34
  35. Standard BVA ❖ Giả sử biến x có miền giá trị [min,max] → Các giá trị được chọn để kiểm tra  Min - Minimal  Min+ - Just above Minimal  Nom - Average  Max- - Just below Maximum  Max - Maximum Kỹ thuật phân tích giá trị biên 35
  36. Kỹ thuật phân tích trên giá trị biên ❖ Số test case là 4n+1, với n là số lượng biến x2 Boundary value analysis test cases for a function of two variables d c x1 a b Kỹ thuật phân tích giá trị biên 36
  37. Robustness Testing ❖ Mở rộng của Standard BVA ❖ Kiểm thử cả hai trường hợp:  Input variable hợp lệ (clean test cases) → Kiểm thử tương tự như Standard BVA trên các giá trị (min, min+, average, max-, max)  Input variable không hợp lệ (dirty test cases) → Kiểm thử trên 2 giá trị: min-, max+ (nằm ngoài miền giá trị hợp lệ) Kỹ thuật phân tích giá trị biên 37
  38. Robustness Testing ❖ Số lượng test case là 6n + 1, với n là số lượng biến x2 Robustness testing test cases for a function of d two variables c x1 a b ❖ Tập trung vào việc kiểm thử trên các giá trị không hợp lệ và đòi hỏi ứng dụng phải xử lý ngoại lệ một cách đầy đủ Kỹ thuật phân tích giá trị biên 38
  39. Worst-case testing ❖ Dựa trên Multiple Fault Assumption để thiết kế test case ❖ Các biến sẽ được kiểm tra đồng thời tại biên để dò lỗi ❖ Chúng ta không kiểm thử tại các giá trị không hợp lệ Kỹ thuật phân tích giá trị biên 39
  40. Worst-case testing ❖ Số lượng test case là 5n, với n là số biến x2 “Worst case” test cases for a function of two d variables c x1 b Kỹ thuật phân tích giá trị biên 40
  41. Robust worst-case testing ❖ Tương tự Worst-case Testing nhưng kiểm tra thêm tại các giá trị không hợp lệ của input variables (min-, max+) ❖ Số lượng test case là 7n, với n là số biến Robust “Worst case” test x2 cases for a function of two variables d c x1 a b Kỹ thuật phân tích giá trị biên 41
  42. Ví dụ hàm kiểm tra tam giác ❖ Ràng buộc: 1 ≤ a, b, c ≤ 200. ❖ Áp dụng Standard BVA (số test case 4*3 + 1 = 13)  min = 1  min+ = 2  nom = 100  max- = 199  max = 200 Kỹ thuật phân tích giá trị biên 42
  43. Ví dụ hàm kiểm tra tam giác ❖ Áp dụng Worst-case testing Kỹ thuật phân tích giá trị biên 43
  44. Ví dụ hàm tìm ngày kế tiếp ❖ Bài toán tìm ngày kế tiếp với các ràng buộc:  1 ≤ Day ≤ 31.  1 ≤ month ≤ 12.  1812 ≤ Year ≤ 2012 ❖ Áp dụng Standard BVA (số test case 4*3 + 1 = 13) Kỹ thuật phân tích giá trị biên 44
  45. Ví dụ hàm tìm ngày kế tiếp Kỹ thuật phân tích giá trị biên 45
  46. Ví dụ hàm tìm ngày kế tiếp ❖ Áp dụng Worst-case testing, Số lượng test case: 53 Kỹ thuật phân tích giá trị biên 46
  47. Các kỹ thuật kiểm thử hộp đen (3) ❖ Kỹ thuật dựa trên giá trị biên (Boundary Value Testing) ❖ Kỹ thuật phân lớp tương đương (Equivalence Class Testing) ❖ Kỹ thuật dựa trên bảng quyết định (Decision Table- Based Testing) ❖ Kỹ thuật dựa trên đồ thị nguyên nhân – kết quả (cause- effect graghing) ❖ 47
  48. Bảng quyết định ❖ Là kỹ thuật được áp dụng trong nhiều lĩnh vực:  Phân tích logic trong các hoạt động nghiệp vụ  Lập trình  Kiểm thử  ❖ Làm giảm số lượng test case không cần thiết so với 2 kỹ thuật Equivalence Class và Boundary Value Analysis vì nó loại trừ các phép kết hợp không cần thiết giữa các input variables Decision Table-Based Testing 48
  49. Bảng quyết định ❖ Liệt kê các nguyên nhân (cause) – kết quả (effect) trong 1 ma trận. Mỗi cột trong ma trận đại diện cho 1 phép kết hợp giữa các cause trong việc tạo ra 1 effect Combinations Causes Values 1 2 3 4 5 6 7 8 Cause 1 Y, N Y Y Y Y N N N N Cause 2 Y, N Y Y N N Y Y N N Cause 3 Y, N Y N Y N Y N Y N Effects Effect 1 X X X Effect 2 X X X Cause = Condition Effect = Actions = Expected Results Decision Table-Based Testing 49
  50. Các bước để tạo ra Bảng quyết định ❖ Liệt kê tất cả các nguyên nhân (causes) trong bảng quyết định ❖ Tính tổng số lượng kết hợp giữa các cause ❖ Điền vào các cột với tất cả các kết hợp có thể có ❖ Rút bớt số lượng các phép kết hợp dư thừa ❖ Kiểm tra các phép kết hợp có bao phủ hết mọi trường hợp hay không ❖ Bổ sung kết quả (effects) vào bảng quyết định Decision Table-Based Testing 50
  51. B1: Liệt kê tất cả các nguyên nhân Combinations Causes Values 1 2 3 4 5 6 7 8 Cause 1 Y, N Y Y Y Y N N N N Cause 2 Y, N Y Y N N Y Y N N Cause 3 Y, N Y N Y N Y N Y N Effects Effect 1 X X X Effect 2 X X X ❖ Điền vào các giá trị trong từng causes ❖ Gom nhóm các causes có liên quan với nhau ❖ Sắp xếp các cause theo thứ tự giảm dần theo độ ưu tiên Ví dụ: xét bài toán kiểm tra loại của 1 tam giác dựa vào chiều dài 3 cạnh a, b, c. Decision Table-Based Testing 51
  52. B2: Tính tổng số kết hợp giữa các causes ❖ Tổng số phép kết hợp = (số lượng values của cause 1) * * (số lượng values của cause n) Mỗi cause có 2 giá trị true, false → Tổng số phép kết hợp = 26 = 64 Decision Table-Based Testing 52
  53. B3: Điền giá trị các cột trong bảng Combinations Causes Values 1 2 3 4 5 6 7 8 Cause 1 Y, N Y Y Y Y N N N N Cause 2 Y, N Y Y N N Y Y N N Cause 3 Y, N Y N Y N Y N Y N Effects Effect 1 X X X Effect 2 X X X ❖ Thuật toán:  Xác định số lần lặp lại (RF) trong từng giá trị của cause bằng cách lấy tổng số phép kết hợp còn lại chia cho số values mà cause có thể nhận  Điền dữ liệu cho dòng thứ i: điền RF lần giá trị đầu tiên của cause i, tiếp theo RF lần giá trị tiếp theo của cause i cho đến khi dòng đầy  Chuyển sang dòng kế tiếp, quay lại bước 1 và tiếp tục thực hiện Decision Table-Based Testing 53
  54. B3: Điền giá trị các cột trong bảng ❖ Ví dụ: RF = 64 / 2 = 32 RF = 32 / 2 = 16 RF = 16 / 2 = 8 Decision Table-Based Testing 54
  55. B4: Giảm số phép kết hợp ❖ Duyệt qua tất cả các ô trong từng cột, ô nào mà kết quả của nó không ảnh hưởng đến effect thì đặt giá trị trên ô này là “-” (don’t care entry) ❖ Ghép các cột với nội dung giống nhau thành 1 cột Decision Table-Based Testing 55
  56. B5: Kiểm tra độ bao phủ các phép kết hợp ❖ Tính rule-count trên từng cột (số lượng phép kết hợp) mà cột này có thể thực hiện ❖ Với các dòng có giá trị là ‘-’ thì luỹ thừa 2 ❖ Nếu tổng của các rule-count bằng với tổng số kết hợp giữa các cause trong bước 2 thì bảng quyết định là đầy đủ Decision Table-Based Testing 56
  57. B6: Bổ sung kết quả (effect) vào trong bảng ❖ Duyệt qua từng cột và check vào kết quả (effect) ❖ Nhiều cột khác nhau có thể cho ra cùng 1 kết quả giống nhau Decision Table-Based Testing 57
  58. Ví dụ ❖ Bảng quyết định hoàn chỉnh Decision Table-Based Testing 58
  59. Các kỹ thuật kiểm thử hộp đen (4) ❖ Kỹ thuật dựa trên giá trị biên (Boundary Value Testing) ❖ Kỹ thuật phân lớp tương đương (Equivalence Class Testing) ❖ Kỹ thuật dựa trên bảng quyết định (Decision Table- Based Testing) ❖ Kỹ thuật dựa trên đồ thị nguyên nhân – kết quả (causes- effects) ❖ 59
  60. Đồ thị nguyên nhân – kết quả ❖ Là kỹ thuật thiết kế test case dựa trên đồ thị ❖ Tập trung vào việc xác định các mối kết hợp giữa các conditions và kết quả mà các mối kết hợp này mang lại Đồ thị nguyên nhân – Kết quả 60
  61. Các bước xây dựng đồ thị ❖ Bước 1: Phân chia hệ thống thành các vùng hoạt động ❖ Bước 2: Xác định các nguyên nhân (causes), kết quả (effects) ❖ Bước 3: Chuyển nội dung ngữ nghĩa trong đặc tả thành đồ thị liên kết các cause và effects ❖ Bước 4: Chuyển đổi đồ thị thành bảng quyết định ❖ Bước 5: Thiết lập danh sách test case từ bảng quyết định. Mỗi test case tương ứng với một cột trong bảng quyết định Đồ thị nguyên nhân – Kết quả 61
  62. Bước 1 ❖ Phân chia hệ thống thành các vùng hoạt động  Phân rã các yêu cầu chức năng thành danh sách các functions hay sub-functions Đồ thị nguyên nhân – Kết quả 62
  63. Bước 2 ❖ B 2.1: Dựa vào đặc tả, xác định các causes và chỉ định mỗi causes này 1 định danh ID  Một cause có thể được xem như là 1 input conditions hoặc là đại diện của 1 lớp tương đương input conditions ❖ B 2.2: Dựa vào đặc tả, xác định effects hoặc sự thay đổi trạng thái của hệ thống và chỉ định mỗi effect 1 định danh ID  Effect có thể là output action, output condition hay là đại diện của 1 lớp tương đương output conditions Đồ thị nguyên nhân – Kết quả 63
  64. Xác định các causes, effects ❖ Ví dụ: Xét đặc tả hệ thống tính phí bảo hiểm xe hơi  Đối với nữ < 65 tuổi, phí bảo hiểm là: 500$  Đối với nam < 25 tuổi, phí bảo hiểm là: 3000$  Đối với nam từ 25 đến 64, phí bảo hiểm là: 1000$  Nếu tuổi từ 65 trở lên, phí bảo hiểm là: 1500$ → Có 2 yếu tố xác định phí bảo hiểm: giới tính và tuổi Đồ thị nguyên nhân – Kết quả 64
  65. Bước 3 ❖ Chuyển nội dung ngữ nghĩa trong đặc tả thành đồ thị liên kết các cause và effects  CEG #1: Đối với nam từ 25 đến 64, phí bảo hiểm là 1000$  CEG #2: Đối với nam < 25 tuổi, phí bảo hiểm là 3000$ Đồ thị nguyên nhân – Kết quả 65
  66. Bước 3 ❖ CEG #3: Nếu tuổi từ 65 trở lên, phí bảo hiểm là: 1500$ ❖ CEG #4: Đối với nữ < 65 tuổi, phí bảo hiểm là: 500$ Đồ thị nguyên nhân – Kết quả 66
  67. Bước 4: Chuyển đổi đồ thị thành Bảng quyết định Đồ thị nguyên nhân – Kết quả 67
  68. Bước 5: Lập danh sách test case từ Bảng quyết định Đồ thị nguyên nhân – Kết quả 68
  69. Chiến lược kiểm thử hộp trắng ❖ Thiết kế test case dựa vào cấu trúc nội tại bên trong của đối tượng cần kiểm thử ❖ Đảm bảo tất cả các câu lệnh, các biểu thức điều kiện bên trong chương trình đều được thực hiện ít nhất một lần 69
  70. Các kỹ thuật kiểm thử hộp trắng ❖ Basis Path Testing ❖ Control-flow/Coverage Testing ❖ Data-flow Testing 70
  71. Basis Path Testing ❖ Được McCabe đưa ra vào năm 1976 ❖ Là phương pháp thiết kế test case đảm bảo rằng tất cả các independent path trong một code module đều được thực thi ít nhất một lần ❖ Independent path: là bất kỳ path nào trong code mà bổ sung vào ít nhất một tập các lệnh xử lý hay một biểu thức điều kiện (Pressman 2001) ❖ Cho biết số lượng test case tối thiểu cần phải thiết kế khi kiểm thử một code module 71
  72. Các bước thực hiện ❖ Xây dựng đồ thị luồng điều khiển ❖ Tính toán độ phức tạp Cyclomatic ❖ Chọn ra tập path cơ sở cần test ❖ Phát sinh test case thực hiện kiểm tra từng path trong tập path cơ sở 72
  73. Xây dựng đồ thị luồng điều khiển ❖ Edge: đại diện cho một luồng điều khiển ❖ Node: đại diện cho một hoặc nhiều câu lệnh xử lý ❖ Predicate node: đại diện cho một biểu thức điều kiện 73
  74. Xây dựng đồ thị luồng điều khiển ❖ Một số cấu trúc luồng điều khiển cơ bản 74
  75. Xây dựng đồ thị luồng điều khiển ❖ Đồ thị luồng điều khiển từ một đoạn chương trình 75
  76. Tính toán độ phức tạp Cyclomatic ❖ Cách 1: Dựa trên công thức của McCabe  V(G) = edges - nodes + 2p  p = number of unconnected parts of the graph V(G) = 1 - 2 +2x1 = 1 V(G) = 4 - 4 +2x1 = 2 76
  77. Tính toán độ phức tạp Cyclomatic 77
  78. Tính toán độ phức tạp Cyclomatic ❖ Cách 2: Dựa vào số lượng Predicate Node  V(G) = Number of Predicate Nodes + 1 McCabe: V(G) = 6-5+2(1) = 3 78
  79. Tính toán độ phức tạp Cyclomatic 79
  80. Chọn ra tập path cơ sở cần test 80
  81. Phát sinh test case Test case 1 Path 1: 1,2,5 Test case 2 Path 2: 1,2,3,4,2,5 Test case 3 Path 3: 1,2,3,6,7,4,2,5 Test case 4 Path 4: 1,2,3,6,8,7,4,2,5 81
  82. Control-flow/Coverage Testing ❖ Là kỹ thuật thiết kế test case đảm bảo “cover” được tất cả các câu lệnh, biểu thức điều kiện trong code module cần test ❖ Có bốn tiêu chí đánh giá độ bao phủ  Method Coverage (phương thức)  Statement Coverage (câu lệnh)  Decision/Branch Coverage (biểu thức điều kiện)  Condition Coverage (biểu thức điều kiện đơn) 82
  83. Method Coverage ❖ Tỷ lệ phần trăm các phương thức trong chương trình được gọi thực hiện bởi các test case ❖ Test case cần phải đạt được 100% method coverage 83
  84. Ví dụ - Method Coverage ❖ Xét đoạn chương trình ❖ Test case 1: foo (0,0,0,0,0) ❖ 100% method coverage 84
  85. Statement Coverage ❖ Tỷ lệ phần trăm các câu lệnh trong chương trình được gọi thực hiện bởi các test case ❖ Test case 1 thực hiện các lệnh từ 1→5 trong 12 câu lệnh đạt 42% Statement Coverage ❖ Để đạt 100% Statement Coverage →Test case 2: foo (1,1,1,1,1) 85
  86. Decision/Branch Coverage ❖ Tỷ lệ phần trăm các biểu thức điều kiện trong chương trình được ước lượng giá trị trả về (true, false) khi thực thi các test case ❖ Một biểu thức điều kiện (cho dù là single hay complex) phải được kiểm tra trong cả hai trường hợp giá trị của biểu thức là true hay false ❖ Đối với các hệ thống lớn, thường chỉ đạt từ 75% → 85% độ bao phủ 86
  87. Decision/Branch Coverage → Đạt 75% coverage → Test case 3: foo (1,2,1,2,1) → 100% coverage 87
  88. Condition Coverage ❖ Tỷ lệ phần trăm các biểu thức điều kiện đơn trong biểu thức điều kiện phức của chương trình được ước lượng giá trị trả về (true, false) khi thực thi các test case ❖ Ví dụ: 50% coverage 88
  89. Condition Coverage ❖ Thiết kế thêm Test case 4, 5 để đạt 100% coverage 89
  90. Data-flow Testing ❖ Là kỹ thuật thiết kế test case dựa vào việc khảo sát sự thay đổi trạng thái trong chu kỳ sống của các biến trong chương trình ❖ Ví dụ: Một số pattern lỗi thường gặp  Sử dụng biến mà chưa khai báo  Sử dụng biến đã hủy trước đó  90
  91. Hệ thống ký hiệu trạng thái dữ liệu Hệ thống ký hiệu d defined, created, initialized k killed, terminated, undefined u used c – used in a computation (sử dụng trong biểu thức tính toán) p – used in a predicate (sử dụng trong các biểu thức điều kiện) ~x Cho biết trước khi tất cả hành động liên quan đến x x~ Cho biết tất cả hành động không có thông báo liên quan đến x 91
  92. Một số ví dụ ❖ v = expression → c – use của các biến trong biểu thức → definition của v ❖ read (v1, v2, , vn) → definitions của v1, , vn ❖ write (v1, v2, , vn) → c - uses của v1, , vn ❖ method call: P (c1, , cn) → definition của mỗi tham số ❖ While B do S → p – use của mỗi biến trong biểu thức điều kiện 92
  93. Ví dụ 93
  94. Các chiến lược thiết kế test case ❖ All-du paths (ADUP) ❖ All-Uses (AU) ❖ All-p-uses (APU) ❖ All-c-uses (ACU) ❖ All-p-uses / Some-c-uses (APU+C) ❖ All-c-uses / Some-p-uses (ACU+P) ❖ All-definition (AD) 94
  95. Ví dụ 95
  96. Xét biến “Bill” 96
  97. Bảng mô tả biến “Bill” 97
  98. Xét biến “Usage” 98
  99. Bảng mô tả biến “Usage” 99
  100. Data-flow testing paths for each variable 100
  101. Mối quan hệ giữa các chiến lược data-flow test 101
  102. Các công cụ hỗ trợ kiểm thử ❖ Các công cụ hỗ trợ quản lý quá trình kiểm thử ❖ Các công cụ hỗ trợ thực hiện các kỹ thuật kiểm thử  Công cụ kiểm thử hiệu năng (Performance)  Công cụ kiểm thử chức năng (Functional)  Công cụ kiểm thử bảo mật (Security)  Công cụ kiểm thử đơn vị (UnitTesting)  102
  103. Các công cụ hỗ trợ quản lý quy trình kiểm thử phần mềm (1) ❖ Các đối tượng cần quản lý của 1 công cụ kiểm thử PM  Project  User  User Role  Requirement  Release: Phiên bản của project.  Test Plan: Kế hoạch test.  Test types: Các loại test.  Test cases: Các trường hợp test  Teststep: Các bước thực hiện cho mỗi test case  Result: Kết quả thực thi test.  Bug: Lỗi  Reports: Các thông báo về tình trạng của tiến trình: Tình trạng lỗi, tiến triển của công việc:  Các tài liệu hướng dẫn sử dụng chương trình (Help) 103
  104. Các công cụ hỗ trợ quản lý quy trình kiểm thử phần mềm (2) ❖ Các chức năng cần phải có  Quản lý project.  Quản lý User.  Phân quyền User.  Quản lý requirement theo phiên bản.  Quản lý release.  Quản lý các thành phần của release: build, component,  Quản lý testplan.  Quản lý testcase.  Cập nhật kết quả cho test case.  Cập nhật tình trạng lỗi.  Thống kê lỗi cho mỗi release hoặc mỗi thành phần của release.  Tự động cập nhật kết quả kiểm thử 104
  105. Các công cụ hỗ trợ quản lý quy trình kiểm thử phần mềm (3) No Name Desc REq Download 1 TestLink Apache, MySQL, PHP 48797 2 Fitnesse Mac, Wnidows, POSIX 24475 Windows, BSD, Linux, 3 QATraq 21992 SunOS/Solaris 4 Bugzilla Test Runner Bugzilla 2.16.3 or above 17291 All 32-bit MS Windows (95/98/NT/2000/XP), All POSIX 5 rth 9563 (Linux/BSD/UNIX-like OSes), IBM AIX 6 TestMaster Linux, Apache, PostgreSQL 6728 7 TCW Any (PHP/SQL/Apache) 4488 8 Tesly OS Independent 3327 9 qaProjectManager Platform Independent 3133 10 Testitool Apache, PHP, MySQL 701 www.opensourcetestingtools.org 105
  106. Công cụ kiểm thử hiệu năng ❖ Là một dạng kiểm tra tự động nhằm tìm ra những điểm “thắt cổ chai” của phần mềm, giúp cho người phát triển có những thay đổi thích hợp để tăng khả năng thực thi, tốc độ xử lý của phần mềm ❖ Giúp người kiểm tra xác định được những thông số ngưỡng của phần mềm, đề ra tiêu chuẩn cho những lần kiểm tra sau ❖ Thường được áp dụng đối với các PM được triển khai trên môi trường nhiều người dùng ( ví dụ: ứng dụng web ) ❖ Kết quả mong đợi của việc kiểm thử hiệu năng phải được định nghĩa một cách rõ ràng ❖ Ví dụ:  Số kết nối (session) đồng thời mà server có thể phục vụ  Thời gian (bao nhiêu phút/giây) mà trình duyệt nhận được kết quả từ server  . 106
  107. Công cụ kiểm thử hiệu năng No Name Requirements Download 1 OpenSTA Windows 2000, NT4 and XP 251965 2 Grinder OS Independent 156458 3 TPTEST MacOS/Carbon and Win32 108036 Database Opensource 4 Linux, POSIX 103484 Test Suite 5 Sipp Linux/Unix/Win32-Cygwin 102111 32-bit MS Windows (NT/2000/XP), Linux, 6 WebLOAD 39401 Windows Server 2003 7 OpenWebLoad Linux, DOS 31204 Hammerhead 2 - Web Hammerhead has been used with Linux, 8 24814 Testing Tool Solaris and FreeBSD. 9 Dieseltest Windows 14618 10 DBMonster OS Independent 13710 www.opensourcetestingtools.org 107
  108. Các công cụ hỗ trợ kiểm thử đơn vị ❖ Có rất nhiều công cụ kiểm thử đơn vị được viết bằng nhiều ngôn ngữ khác nhau  ADA  C++  HTML  Java  .NET  Pert  PHP  SQL  XML  Ruby  108
  109. Các công cụ hỗ trợ kiểm thử đơn vị No Name Requirements Download 1 JUnit OS Independent 2151874 2 Findbugs JRE (or JDK) 1.4.0 or later 379779 3 PMD JDK 1.3 or higher 344688 4 Checkstyle OS Independent 216780 5 EclEmma Eclipse 209153 6 Dbunit JUnit 129300 7 StrutsTestCase for JUnit v1.9.5 OS Independent 106860 8 Emma Java 59435 9 MockObjects OS independent 55457 10 JUnitEE JUnit 54618 www.opensourcetestingtools.org 109
  110. Các công cụ hỗ trợ kiểm thử đơn vị No Name Requirements Download 1 NUnit Windows NT/2000 1061875 2 NUnitAsp Windows NT/2000 72724 NUnit Addin for 3 Windows 58588 Visual Studio.NET 4 NUnitForms Windows NT/2000 46880 csUnit has been tested using the Microsoft .NET 5 csUnit framework 1.0 Service Pack 2 runtime on an 31483 Intel-compatible platform. 6 NCover All 32-bit MS Windows (95/98/NT/2000/XP) 14264 7 VSNUnit All 32-bit MS Windows (95/98/NT/2000/XP) 8763 8 dotUnit All 32-bit MS Windows (95/98/NT/2000/XP) 6230 OS Independent (Written in an interpreted 9 .NETUnit 5558 language) 10 ASPUnit Microsoft Internet Information Server 5.0 or 5.1 5197 www.opensourcetestingtools.org 110
  111. Một sô công cụ hỗ trợ kiểm thử chức năng No Name Desc Req Download Software Testing Automation Framework Windows, Linux, Solaris, 1 212018 (STAF) AS/400, AIX, HP-UX, Irix 2 soapui Java 1.5 178985 3 Linux Test Project Linux 103484 4 jWebUnit OS Independent 56526 5 Abbot Java GUI Test Framework TBC 56118 All 32-bit MS Windows 6 Software Automation Framework Support 43735 (95/98/NT/2000/XP) OS Independent, JDK 1.4 7 Jameleon 43507 or higher Windows, OS 8 WebInject 40891 Independent, Linux 9 Marathon Java 1.3 or later 30328 10 Solex Eclipse 2.1 or above 29591 www.opensourcetestingtools.org 111
  112. Các công cụ kiểm thử thương mại Vendor Tool Name of testing suite or companion tools Compuware TestPartner QACenter Enterprise Edition+ Empirix e-Tester e-TEST suite Test Manager, Manual Tester, IBM Rational Functional Tester Performance Tester QuickTest Mercury Quality Center Professional RadView WebFT TestView Suite Seapine QA Wizard TestTrack Pro Segue SilkTest SilkCentral, SilkPerformer 112
  113. Các công cụ kiểm thử thương mại Technical and nontechnical users Mercury QuickTest Pro Compuware TestPartner Technical users Nontechnical users IBM Rational Functional Tester Empirix e-Tester Segue SilkTest Seapine QA Wizard RadView WebFT 113
  114. Tài liệu tham khảo ❖ Software Testing, A Craftsman’s Approach, Paul C.Jorgensen ❖ Practical Software Testing, EleneBurnstein ❖ Slides: Software Testing ISEB Foundation Certificate Course ❖ Slides: Software Testing, Dr. Balla Katalin ❖ Slide: Equivalence Class Testing, Prof. Schlingloff & Dr. M Roggenbach ❖ Slide: Decision Table Based Testing, Neelam Gupta, The University of Arizona Tucson, Arizona, USA ❖ Object Oriented Testing, Ali Kamandi, Sharif University of Technology 114