Bài giảng Kiểm tra phần mềm - Chương 5: Kỹ thuật kiểm thử hộp đen

Đối tượng ₫ược kiểm thử là 1 thành phần phần mềm (TPPM).
TPPM có thể là 1 hàm chức năng, 1 module chức năng, 1 phân hệ
chức năng… Nói chung, chiến lược kiểm thử hộp ₫en thích hợp
cho mọi cấp ₫ộ kiểm thử từ kiểm thử ₫ơn vị, kiểm thử tích hợp,
kiểm thử hệ thống, kiếm thử ₫ộ chấp nhận của người dùng. 
pdf 18 trang xuanthi 28/12/2022 2280
Bạn đang xem tài liệu "Bài giảng Kiểm tra phần mềm - Chương 5: Kỹ thuật kiểm thử hộp đen", để tải tài liệu gốc về máy hãy click vào nút Download ở trên.

File đính kèm:

  • pdfbai_giang_kiem_tra_phan_mem_chuong_5_ky_thuat_kiem_thu_hop_d.pdf

Nội dung text: Bài giảng Kiểm tra phần mềm - Chương 5: Kỹ thuật kiểm thử hộp đen

  1. Vì chiến lược kiểm thử hộp ₫en thích hợp cho mọi mức ₫ộ kiểm thử nên nhiều người ₫ã nghiên cứu tìm hiểu và ₫ưa ra nhiều kỹ thuật kiểm thử khác nhau, chúng ta sẽ chọn ra 8 kỹ thuật có nhiều ưu ₫iểm nhất và ₫ược dùng phổ biến nhất, ₫ó là : 1. Kỹ thuật phân lớp tương ₫ương (Equivalence Class Partitioning). 2. Kỹ thuật phân tích các giá trị biên (Boundary value analysis). 3. Kỹ thuật dùng các bảng quyết ₫ịnh (Decision Tables) 4. Kỹ thuật kiểm thử các bộ n thần kỳ (Pairwise) 5. Kỹ thuật dùng bảng chuyển trạng thái (State Transition) 6. Kỹ thật phân tích vùng miền (domain analysis) 7. Kỹ thuật dựa trên ₫ặc tả Use Case (Use case) 8. Kỹ thuật dùng lược ₫ồ quan hệ nhân quả (Cause-Effect Diagram) 5.2 Kỹ thuật phân lớp tương ₫ương Tinh thần của kỹ thuật này là cố gắng phân các testcase ra thành nhiều nhóm (họ) khác nhau : các testcase trong mỗi họ sẽ kích hoạt TPPM thực hiện cùng 1 hành vi. Mỗi nhóm testcase thỏa mãn tiêu chuẩn trên ₫ược gọi là 1 lớp tương ₫ương, ta chỉ cần xác ₫ịnh 1 testcase ₫ại diện cho nhóm và dùng testcase này ₫ể kiểm thử TPPM. Như vậy ta ₫ã giảm rất nhiều testcase cần ₫ịnh nghĩa và kiểm thử, nhưng chất lượng kiểm thử không bị giảm sút bao nhiêu so với vét cạn. Điều này là dựa vào kỳ vọng rất hợp lý sau ₫ây : ƒ Nếu 1 testcase trong lớp tương ₫ương nào ₫ó gây lỗi TPPM thì các testcase trong lớp này cũng sẽ gây lỗi như vậy.
  2. Ứng với mỗi lớp tương ₫ương, ta ₫ịnh nghĩa 1 testcase ₫ại diện, thí dụ ta chọn 4 testcase sau : 1. Testcase 1 : {Input : 2 tuổi, Output : không thuê} 2. Testcase 2 : {Input : 17 tuổi, Output : thuê bán thời gian} 3. Testcase 3 : {Input : 35 tuổi, Output : thuê toàn thời gian} 4. Testcase 4 : {Input : 90 tuổi, Output : không thuê} Trong thí dụ trên, thay vì phải kiểm thử vét cạn 100 testcase, ta chỉ kiểm thử 4 testcase → chí phí giảm rất lớn, nhưng chất lượng kiểm thử hy vọng không bị giảm sút là bao. Tại sao chúng ta hy vọng chất lượng kiểm thử dùng lớp tương ₫ương không giảm sút nhiều ? Hãy xét ₫oạn code mà những người lập trình bình thường sẽ viết khi xử lý TPPM cần kiểm thử của slide trước : if (applicantAge >= 0 && applicantAge = 16 && applicantAge = 18 && applicantAge = 55 && applicantAge <=99) qd ="NO"; Ở góc nhìn kiểm thử hộp trắng, nếu dùng 4 testcase ₫ại diện của 4 lớp tương ₫ương, ta sẽ kiểm thử ₫ược ở phủ cấp 3, cấp phủ rất tốt vì ₫ã kiểm thử 100% các lệnh mã nguồn, 100% các nhánh quyết ₫ịnh. Tuy nhiên nếu người lập trình hiện thực như sau (rất cá biệt vì ₫ây là người lập trình rất yếu tay nghề) : if (applicantAge == 0) qd ="NO"; if (applicantAge == 16) qd ="PART"; if (applicantAge == 53) qd ="FULL"; if (applicantAge == 99) qd ="NO";
  3. 2. Nếu lớp tương ₫ương ₫ược xác ₫ịnh bởi các dữ liệu nhập là số nguyên liên tục, trong trường hợp này ta chọn 1 testcase ₫ại diện có giá trị nhập hợp lệ nằm trong khoảng liên tục các giá trị hợp lệ, và nếu muốn, 2 testcase miêu tả giá trị không hợp lệ nằm phía dưới và phía trên khoảng trị hợp lệ (số testcase cho mỗi lớp tương ₫ương là từ 1 tới 3). -101 2 3 4 56 78 3. Nếu lớp tương ₫ương ₫ược xác ₫ịnh bởi các dữ liệu dạng liệt kê rời rạc và không có mối quan hệ lẫn nhau gồm 1 trị hợp lệ và nhiều trị không hợp lệ. Trong trường hợp này ta chọn 1 testcase có giá trị nhập hợp lệ và nếu muốn, 2 testcase miêu tả 2 giá trị không hợp lệ nào ₫ó, nhưng cho dù chọn 2 testcase nào cũng không ₫ại diện tốt cho các trường hợp không hợp lệ còn lại (số testcase cho mỗi lớp tương ₫ương là từ 1 tới 3). 4. Nếu lớp tương ₫ương ₫ược xác ₫ịnh bởi các dữ liệu dạng liệt kê rời rạc và không có mối quan hệ lẫn nhau gồm n trị hợp lệ và m trị không hợp lệ. Trong trường hợp này ta chọn 1 testcase có giá trị nhập hợp lệ nào ₫ó và nếu muốn, 2 testcase miêu tả 2 giá trị không hợp lệ nào ₫ó, nhưng cho dù chọn các testcase nào cũng
  4. 1.342 0 Person Condo Invalid 5.432 3 Corporation Townhouse Invalid 10.000 2 Person Treehouse Invalid 5.3 Kỹ thuật phân tích các giá trị ở biên Kỹ thuật kiểm thử phân lớp tương ₫ương là kỹ thuật cơ bản nhất, nó còn gợi ý chúng ta ₫ến 1 kỹ thuật kiểm thử khác : phân tích các giá trị ở biên. Kinh nghiệm trong cuộc sống ₫ời thường cũng như trong lập trình các giải thuật lặp cho chúng ta biết rằng lỗi thường nằm ở biên (₫ầu hay cuối) của 1 khoảng liên tục nào ₫ó (lớp tương ₫ương). Do ₫ó ta sẽ tập trung tạo các testcase ứng với những giá trị ở biên này. Thí dụ xét ₫ặc tả TPPM “quản lý nguồn nhân lực” ở slide 8, ta thấy ₫ặc tả các luật ₫ều bị lỗi ở các biên, thí dụ luật 1 qui ₫ịnh không thuê những người có tuổi từ 0 — 16, còn luật 2 qui ₫ịnh sẽ thuê bán thời gian những người từ 16-18 tuổi. Vậy người 16 tuổi ₫ược xử lý như thế nào bởi hệ thống ? Đã có nhặp nhằng và mâu thuẩn trong các luật. Lỗi này do nắm bắt yêu cầu phần mềm sai. Giả sử ta ₫ã chỉnh sửa lại yêu cầu phần mềm như sau : Tuổi ứng viên Kết quả 0-15 Không thuê 16-17 Thuê dạng bán thời gian 18-54 Thuê toàn thời gian 55-99 Không thuê Và ₫oạn code hiện thực sau : if (0 < applicantAge && applicantAge < 15) kq ="NO"; if (16 < applicantAge && applicantAge <17) kq ="PART"; if (18 < applicantAge && applicantAge <54) kq ="FULL"; if (55 < applicantAge && applicantAge <99) kq ="NO";
  5. - nếu ₫ơn vị là $ thì ngay dưới của 5$ là 4$, ngay trên 5$ là 6$. Thí dụ dựa vào ₫ặc tả của TPPM “quản lý nguồn nhân lực” : Tuổi ứng viên Kết quả 0-15 Không thuê 16-17 Thuê dạng bán thời gian 18-54 Thuê toàn thời gian 55-99 Không thuê Ta sẽ ₫ịnh nghĩa các testcase tương ứng với các tuổi sau : {- 1,0,1}, {14,15,16}, {15,16,17}, {16,17,18}, {17,18,19}, {53,54,55}, {54,55,56}, {98,99,100}. Có nhiều testcase trùng nhau, nếu loại bỏ các testcase trùng nhau, ta còn : -1, 0, 1, 14, 15, 16, 17, 18, 19, 53, 54, 55, 56, 98, 99, 100 (16 testcase so với hàng trăm testcase nếu vẹt cạn). Khi TPPM cần kiểm thử nhận nhiều dữ liệu nhập (thí dụ TPPM xét ₫ơn cầm cố nhà ở slide trước có 4 loại dữ liệu nhập), ta ₫ịnh nghĩa các testcase ₫ộc lập cho các dữ liệu hay testcase dựa trên tổng hợp các dữ liệu nhập ? Nếu ₫ịnh nghĩa các testcase ₫ộc lập trên từng loại dữ liệu nhập, số lượng testcase cần kiểm thử sẽ nhiều. Trong TPPM xét ₫ơn cầm cố nhà, ta phải xử lý ít nhất là 6 testcase cho từng loại dữ liệu * 4 loại dữ liệu = 24 testcase. Để giảm thiểu số lượng testcase nhưng vẫn ₫ảm bảo chất lượng kiểm thử, người ta ₫ề nghị chọn tescase như sau : ƒ 1 số testcase cho các tổ hợp các giá trị biên. ƒ 1 số testcase cho các tổ hợp các giá trị ngay dưới và ngay trên biên. TPPM xét ₫ơn cầm cố nhà ở slide trước có 2 dữ liệu nhập liên tục là thu nhập hàng tháng và số lượng nhà. Tổng hợp 2 loại dữ liệu này theo góc nhìn ₫ồ họa trực quan, ta thấy cần ₫ịnh nghĩa các testcase cho các trường hợp sau :
  6. Actions Action-1 Action-n Condition-1 tới Condition-m miêu tả m ₫iều kiện dữ liệu nhập khác nhau có thể có. Action-1 tới Action-n miêu tả n hoạt ₫ộng khác nhau mà hệ thống có thể thực hiện phụ thuộc vào tổ hợp ₫iều kiện dữ liệu nhập nào. Mỗi cột miêu tả 1 luật cụ thể : tổ hợp ₫iều kiện nhập cụ thể và các hoạt ₫ộng cụ thể cần thực hiện. Lưu ý các hoạt ₫ộng cần thực hiện không phụ thuộc vào thứ tự các ₫iều kiện nhập, nó chỉ phụ thuộc vào giá trị các ₫iều kiện nhập. Tương tự, các hoạt ₫ộng cần thực hiện không phụ thuộc vào trạng thái hiện hành của TPPM, chúng cũng không phụ thuộc vào các ₫iều kiện nhập ₫ã có trước ₫ó. Chúng ta sẽ lấy 1 thí dụ cụ thể ₫ể làm rõ bảng quyết ₫ịnh. Giả sử TPPM cần kiểm thử là phân hệ chức năng nhỏ của công ty bảo hiểm : nó sẽ khuyến mãi cho những chủ xe (cũng là tài xế) nếu họ thỏa ít nhất 1 trong 2 ₫iều kiện : ₫ã lập gia ₫ình / là sinh viên giỏi. Mỗi dữ liệu nhập là 1 giá trị luận lý, nên bảng quyết ₫ịnh chỉ cần có 4 cột, miêu tả 4 luật khác nhau : Rule 1 Rule 2 Rule 3 Rule 4 Conditions Married? Yes Yes No No Good Student? Yes No Yes No Actions Discount ($) 60 25 50 0 Qui trình cụ thể ₫ể thực hiện kiểm thử dùng bảng quyết ₫ịnh : 1. Tìm bảng quyết ₫ịnh từ ₫ặc tả về yêu cầu chức năng của TPPM hay từ bảng thiết kế TPPM. Nếu chưa có thì xây dựng nó dựa vào ₫ặc tả về yêu cầu chức năng hay dựa vào bảng thiết kế TPPM.
  7. TC1 TC2 TC3 TC4 Conditions Cond 1 0 5 50 500 Cond 2 3 5 7 10 Actions Action-1 Do X Do Y Do X Do Z 5.5 Kỹ thuật kiểm thử các bộ n thần kỳ (pairwise) Chúng ta hãy kiểm thử 1 website với ₫ặc tả yêu cầu như sau : 1. Phải chạy tốt trên 8 trình duyệt khác nhau : Internet Explorer 5.0, 5.5, and 6.0, Netscape 6.0, 6.1, and 7.0, Mozilla 1.1, and Opera 7. 2. Phải chạy tốt ở 3 chế ₫ộ plug-ins : RealPlayer, MediaPlayer, none. 3. Phải chạy tốt trên 6 HĐH máy client : Windows 95, 98, ME, NT, 2000, and XP. 4. Phải chạy tốt trên 3 web server khác nhau : IIS, Apache, and WebLogic. 5. Phải chạy tốt trên 3 HĐH máy server : Windows NT, 2000, and Linux. Như vậy ₫ể kiểm thử ₫ầy ₫ủ ₫ặc tả yêu cầu, ta phải kiểm thử website trên 8*3*6*3*3 = 1296 cấu hình khác nhau. Một thí dụ khác : hãy kiểm thử 1 hệ thống xử lý dữ liệu ngân hàng có ₫ặc tả yêu cầu như sau : 1. Phải xử lý tốt 4 loại khách hàng là consumers, very important consumers, businesses, and non-profits. 2. Phải xử lý tốt 5 loại tài khoản : checking, savings, mortgages, consumer loans, and commercial loans.
  8. 6. Tạo tất cả bộ n và chọn 1 ít bộ n ₫ầu tiên trong danh sách. 7. Tạo tất cả bộ n và chọn 1 ít bộ n theo cơ chế ngẫu nhiên. 8. Chọn 1 tập con ₫ủ nhỏ bộ n mà tạo ₫ược ₫iều kỳ diệu là chất lượng kiểm thử không bị giảm sút. Bằng cách nào, nếu có ? Có 2 phương pháp xác ₫ịnh ₫ược tập con các bộ n thần kỳ cần kiểm thử : 1. Dùng ma trận trực giao (orthogonal array). 2. Dùng tiện ích Allpairs. Ma trận trực giao là 1 bảng 2 chiều gồm n hàng * m cột các giá trị số nguyên với 1 ₫ặc tính rất ₫ặc biệt là : 2 cột bất kỳ trong ma trận ₫ều chứa ₫úng các bộ ₫ôi xác ₫ịnh trước. Thí dụ, xét ma trận trực giao sau 4 hàng * 3 cột sau : 1 2 3 1 1 1 1 2 1 2 2 3 2 1 2 4 2 2 1 Ta thấy 2 cột bất kỳ trong ma trận ₫ều chứa ₫úng 4 bộ ₫ôi sau ₫ây (1,1), (1,2), (2,1), (2,2). Ta miêu tả 1 ma trận trực giao như sau :
  9. Thay vì dùng ma trận trực giao ₫ể nhận dạng các testcase, ta có thể dùng 1 thuật giải ₫ể sinh tự ₫ộng các testcase. Thí dụ James Bach ₫ã cung cấp 1 tool tạo tự ₫ộng tất cả các tổ hợp bộ n, bạn có thể download tool này từ ₫ịa chỉ và cái tiện ích này vào máy. Để chuẩn bị dữ liệu nhập cho tiện ích, ta có thể Excel ₫ịnh nghĩa các biến dữ liệu cùng tập các giá trị nhập có thể có của từng biến theo dạng cột/hàng, sau ₫ó lưu kết quả dạng văn bản thô *.txt. Chạy tiện ích theo dạng hàng lệnh như sau : Allpairs input.txt > output.txt Dùng 1 trình soạn trhảo văn bản mở file output.txt và xem kết quả. 5.6 Kết chương Chương này ₫ã giới thiệu những vấn ₫ề tổng quát về kiểm thử hộp ₫en 1 TPPM. Chúng ta ₫ã giới thiệu chi tiết cụ thể về 4 kỹ thuật kiểm thử hộp ₫en ₫ược dùng phổ biến là kỹ thuật phân lớp tương ₫ương, kỹ thuật phân tích các giá trị ở biên, kỹ thuật dùng bảng quyết ₫ịnh, và kỹ thuật kiểm thử các bộ n thần kỳ. Ứng với mỗi kỹ thuật kiểm thử, chúng ta cũng ₫ã giới thiệu 1 thí dụ cụ thể ₫ể demo qui trình thực hiện kỹ thuật kiểm thử tương ứng.