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ù”.
