Black Box Testing
Cách kiểm thử chỉ dựa vào đầu vào và đầu ra theo yêu cầu, không cần biết bên trong code viết thế nào. Đây là kiểu test mà QC và người dùng nghiệp vụ làm hằng ngày.
Định nghĩa
Bạn không cần đọc một dòng code nào vẫn test được. Nhập vào cái này, mong đợi ra cái kia, so với tài liệu. Đó là kiểm thử hộp đen, và nó chiếm phần lớn công việc test ở mọi dự án phần mềm nghiệp vụ.
Hộp đen nghĩa là chỉ nhìn hành vi bên ngoài: đầu vào, đầu ra, và quy tắc nghiệp vụ, không quan tâm cách hiện thực.
So sánh với hộp trắng và hộp xám
| Tiêu chí | Black box | White box | Grey box |
|---|---|---|---|
| Biết gì về code | Không | Biết cấu trúc bên trong | Biết một phần, ví dụ cấu trúc dữ liệu |
| Ai làm | QC, người dùng nghiệp vụ | Dev | QC có nền kỹ thuật |
| Căn cứ | Tài liệu yêu cầu | Mã nguồn, nhánh điều kiện | Yêu cầu cộng hiểu biết về database, API |
| Ví dụ | Test màn tạo đơn hàng | Unit test cho hàm tính phí | Test API kèm kiểm bản ghi trong DB |
Trong thực tế ba kiểu này bổ trợ nhau. Dev viết unit test cho phần lõi, QC test hộp đen theo nghiệp vụ, và một QC biết đọc database sẽ bắt được những thứ nhìn màn hình không thấy — ví dụ giao diện hiện đúng nhưng bản ghi lưu thiếu trường.
Kỹ thuật thiết kế ca test hay dùng
Test hộp đen không có nghĩa là bấm loạn xạ. ISTQB có sẵn mấy kỹ thuật, học một buổi dùng được cả đời:
- Phân vùng tương đương: chia đầu vào thành các nhóm cho cùng kết quả. Số tiền chuyển khoản chia thành dưới hạn mức, bằng hạn mức, trên hạn mức, số âm, để trống. Mỗi nhóm một đại diện.
- Giá trị biên: lỗi hay nằm ở mép. Hạn mức 20 triệu thì test 19.999.999đ, 20.000.000đ và 20.000.001đ.
- Bảng quyết định: khi kết quả phụ thuộc mấy điều kiện chồng nhau, kiểu còn hạn bảo hành hay không, lỗi do người dùng hay do máy, có hoá đơn gốc hay không.
- Chuyển trạng thái: một hồ sơ bảo hành đi từ Tiếp nhận sang Đang sửa sang Trả khách — và cái nhánh ít ai test là khách đổi ý giữa chừng, đòi lấy máy về khi đang sửa dở.
Kỹ thuật thứ năm hay đi kèm là đoán lỗi, nhưng ISTQB xếp nó vào nhóm dựa trên kinh nghiệm chứ không phải nhóm hộp đen dựa trên đặc tả. Nó nhắm thẳng vào chỗ hay hỏng theo trực giác của người từng làm. Không thay thế được bốn kỹ thuật trên, mà bổ sung thì rất tốt.
Ví dụ thực tế
Chức năng tính phí giao hàng cho một sàn thương mại nội địa. Quy tắc: dưới 2kg tính 20.000đ, từ 2kg tới 5kg tính 35.000đ, trên 5kg cộng thêm 8.000đ mỗi kg, đơn từ 500.000đ được miễn phí trong nội thành.
Nếu chỉ test đại vài giá trị thì rất dễ bỏ sót. Áp phân vùng và biên vào thì ra danh sách rõ ràng: 1,9kg / 2kg / 2,1kg / 4,9kg / 5kg / 5,1kg / 7kg — mỗi biên đủ ba giá trị, cộng một giá trị nằm giữa vùng trên 5kg — nhân với hai mốc giá trị đơn 499.000đ và 500.000đ, nhân với hai trường hợp nội thành và ngoại thành. Ra 28 tổ hợp, cắt bớt tổ hợp vô nghĩa còn 20 case.
Kết quả đợt test đó: hai defect, cả hai đều ở mốc chính xác 2kg và 500.000đ — đúng chỗ mà quy tắc dùng từ "từ" hay "trên" mà tài liệu viết mập mờ.
BA lấy được gì từ đây
Mấy kỹ thuật này dùng ngược lại lúc viết tài liệu cũng rất tốt. Khi mô tả một quy tắc có ngưỡng, tự hỏi ngay: đúng bằng ngưỡng thì thuộc bên nào. Khi mô tả một quy tắc có nhiều điều kiện, vẽ luôn bảng quyết định vào FRD thay vì viết ba đoạn văn chồng chéo.
Bảng quyết định trong tài liệu có thêm một cái lợi: QC bê thẳng nó ra thành test case, và khách hàng đọc cũng hiểu. Ba bên nhìn cùng một bảng thì ít cãi nhau hơn ba bên đọc cùng một đoạn văn.
