Các phương pháp kiểm thử

1. White box testing

Khi thiết kế test case và test, các tester truy cập thẳng vào bên trong source code, cấu trúc và thuật toán của chương trình và thực thi nó được gọi là White box testing.

Có các loại white box testing đang tồn tại như sau:
* API testing (application programming interface) – Kiểm thử ứng dụng bằng cách sử dụng các hàm API public và private
* Code coverage – Là việc tạo các trường hợp test để thỏa mãn một số điều kiện bao phủ code - code coverage (ví dụ như, người thiết kế test có thể tạo ra các trường hợp test sao cho tất cả các câu lệnh của chương trình đều được thực thi ít nhất 1 lần)
* Fault injection methods – cải tiến bao phủ một trường hợp bằng cách đưa một số lỗi vào để test các đường dẫn code.
* Mutation testing methods
* Static testing - White box testing bao gồm tất cả các phương pháp kiểm thử tĩnh (ví dụ review code).

Kiểm thử độ bao phủ
Phương pháp kiểm thử white box cũng có thể được sử dụng để ước lượng tính trọn vẹn đầy đủ của các tập hợp kiểm thử (test suit) đã được tạo ra bằng phương pháp kiểm thử black box. Điều này cho phép nhóm sản xuất phần mềm xem xét lại các phần của hệ thống ít được test nhất và để chắc chắn rằng các chức năng quan trọng nhất đã được tập trung test kỹ.

Hai hình thức chung của kiểm thử độ bao phủ code:
* Bao phủ chức năng - Function coverage, dựa trên việc thực thi các chức năng.
* Bao phủ câu lệnh - Statement coverage, dựa trên số lượng các dòng lệnh đã được thực thi để hoàn thành kiểm thử.

Cả hai hình thức trên đề trả về một cách đo độ bao phủ code, sự đo lường được tính bằng phần trăm %.

Tham khảo thêm white box testing

2. Black box testing

Phương pháp kiểm thử Black box là nghiên cứu xem phần mềm như là một “hộp đen” – không biết gì về hoạt động bên trong của nó. Các phương pháp kiểm thử Black box bao gồm: equivalence partitioning (phân vùng tương đương), boundary value analysis (phân tích giá trị biên), all-pairs testing (kiểm thử tất cả các cặp), fuzz testing (cách test: nhập vào các điều kiện sai hoặc data một cách ngẫu nhiên), model-based testing (Kiểm thử dựa trên model), traceability matrix (các chức năng của chương trình được tạo thành một ma trận, các trường hợp test là sự kết hợp các dòng hoặc các cột có liên quan), exploratory testing (kiểm thử chủ yếu dựa vào kinh nghiệm và khả năng focus vào việc test các chức năng của tester) và specification-based testing (kiểm thử dựa vào chức năng).

Phương pháp kiểm thử dựa vào chức năng - Specification-based testing: Việc kiểm thử được tiến hành dựa vào việc kiểm thử chức năng của phần mềm xem nó có phù hợp với yêu cầu của người dùng hay không. Vì vậy, các tester nhập data vào phần mềm và chỉ cần xem kết quả của phần mềm và các mục tiêu test. Mức test này thường yêu cầu các tester phải viết test case đầy đủ trước khi test, khi test, đơn giản chỉ cần thực hiện theo các bước mô tả trong test case thao tác và nhập data vào, sau đó xem kết quả trả về hoặc hành vi của phần mềm, rồi so sánh với kết quả mong đợi đã được viết trong test case, điền kết quả test vào test case là OK (OK = is – chương trình làm đúng theo mong đợi) hay NG (not good = is not – chương trình không làm đúng theo mong đợi).

Specification-based testing là cần thiết, nhưng nó không đủ để bảo đảm chắc chắn các rủi ro xảy ra (nó chỉ là điều điện cần chứ không phải là điều kiện đủ).

Ưu điểm và nhược điểm: Các tester kiểm thử theo phương pháp black box không có “mối ràng buộc” nào với code, và nhận thức của một tester rất đơn giản: một source code có nhiều lỗi. Sử dụng nguyên tắc, "Hỏi và bạn sẽ nhận" các tester black box tìm được nhiều bug ở nơi mà các DEV không tìm thấy. Mặt khác, việc kiểm thử black box được xem như "là bước đi trong mê cung tối đen mà không mang đèn pin” bởi vì tester không biết phần mềm đang test đã được xây dựng như thế nào. Như là một kết quả, ở đây có nhiều trường hợp khi một tester viết rất nhiều trường hợp test để kiểm tra một số thứ có thể chỉ được test bằng một trường hợp test (1), và/hoặc một vài phần cuối cùng không được test hết.

Vì vậy, black box testing có ưu điểm là "an unaffiliated opinion" (một quan điểm độc lập), mặt khác, nó có nhược điểm là "blind exploring" (khám phá mù).

3. Grey box testing

Grey box testing (Viết theo Tiếng Mỹ: gray box testing) bao gồm các kiến thức về các thuật toán, cấu trúc bên trong của chương trình để thực hiện mục đích việc thiết kế các trường hợp test, nhưng việc test phải thực hiện như là người dùng (suy nghĩ theo cách nghĩ của người dùng cuối), hoặc thiết kế ở mức black-box. Việc vận dụng dữ liệu đầu vào và xác định qui cách đầu ra không được gọi là grey box, bởi vì điều kiện input và output là ở bên ngoài rõ ràng là của "black-box" trên hệ thống chúng ta đang test. Sự phân biệt này đặc biệt quan trọng khi tiến hành thử nghiệm tích hợp giữa hai module đã được viết bởi hai DEV khác nhau, ở đó chỉ có các interface (giao tiếp giữa 2 module) được đưa ra để kiểm thử. Tuy nhiên, việc chỉnh sửa ngân hàng data test không được xem là grey box, như người dùng bình thường thì sẽ không thể thay đổi data bên ngoài hệ thống đang test. Grey box testing cũng có thể bao gồm kỹ thuật đảo ngược để xác định, ví dụ, các giá trị biên hoặc thông báo lỗi.

Ghi chú:

- Trường hợp kiểm thử = test case
- Các trường hợp kiểm thử = test cases