Ưu nhược điểm của phương pháp kiểm thử hộp đen

I. Giới thiệu kiểm thử hộp đen (Blackbox tesing)

-          Một trong những chiến lược kiểm thử quan trọng là kiểm thử hộp đen, hướng dữ liệu, hay hướng vào/ra. Kiểm thử hộp đen xem chương trình như là một “hộp đen”. Mục đích của bạn là hoàn toàn không quan tâm về cách cư xử và cấu trúc bên trong của chương trình. Thay vào đó, tập trung vào tìm các trường hợp mà chương trình không thực hiện theo các đặc tả của nó.

-          Theo hướng tiếp cận này, dữ liệu kiểm tra được lấy chỉ từ các đặc tả.

-          Đây là kỹ thuật test mà công ty mình đang áp dụng ở các dự án: CĐT, NL, Ebay, Adnet …

II. Các phương pháp kiểm thử hộp đen (Blackbox testing method)

Ø  Phân lớp tương đương – Equivalence partitioning.

Ø  Phân tích giá trị biên – Boundary value analysis.

Ø  Kiểm thử mọi cặp – All-pairs testing.

Ø  Kiểm thử fuzz – Fuzz testing.

Ø  Kiểm thử dựa trên mô hình – Model-based testing.

Ø  Ma trận dấu vết – Traceability matrix.

Ø  Kiểm thử thăm dò – Exploratory testing.

Ø  Kiểm thử dựa trên đặc tả – Specification-base testing.

Ø  Đồ thị nguyên nhân – kết quả - Cause & Effect Graphing

Ø  Đoán lỗi – Error Guessing

Kiểm thử dựa trên đặc tả tập trung vào kiểm tra tính thiết thực của phần mềm theo những yêu cầu thích hợp. Do đó, kiểm thử viên nhập dữ liệu vào, và chỉ thấy dữ liệu ra từ đối tượng kiểm thử. Mức kiểm thử này thường yêu cầu các ca kiểm thử triệt để được cung cấp cho kiểm thử viên mà khi đó có thể xác minh là đối với dữ liệu đầu vào đã cho, giá trị đầu ra (hay cách thức hoạt động) có giống với giá trị mong muốn đã được xác định trong ca kiểm thử đó hay không. Kiểm thử dựa trên đặc tả là cần thiết, nhưng không đủ để để ngăn chặn những rủi ro chắc chắn.

III. Ưu nhược điểm

Kiểm thử hộp đen không có mối liên quan nào tới mã lệnh, và kiểm thử viên chỉ rất đơn giản tâm niệm là: một mã lệnh phải có lỗi. Sử dụng nguyên tắc “ Hãy đòi hỏi và bạn sẽ được nhận”, những kiểm thử viên hộp đen tìm ra lỗi mà những lập trình viên đã không tìm ra. Nhưng, mặt khác, người ta cũng nói kiểm thử hộp đen “giống như là đi trong bóng tối mà không có đèn vậy”, bởi vì kiểm thử viên không biết các phần mềm được kiểm tra thực sự được xây dựng như thế nào. Đó là lý do mà có nhiều trường hợp mà một kiểm thử viên hộp đen viết rất nhiều ca kiểm thử để kiểm tra một thứ gì đó mà đáng lẽ có thể chỉ cần kiểm tra bằng 1 ca kiểm thử duy nhất, và/hoặc một số phần của chương trình không được kiểm tra chút nào.

            Do vậy, kiểm thử hộp đen có ưu điểm của “một sự đánh giá khách quan”, mặt khác nó lại có nhược điểm của “thăm dò mù”.