Decision Table Testing, State Transition Testing và Error Guessing đều giúp tester tìm ra những test case dễ bị bỏ sót. Tuy nhiên, mỗi kỹ thuật phù hợp với một loại bài toán khác nhau: tổ hợp điều kiện, hành vi phụ thuộc trạng thái và rủi ro dựa trên kinh nghiệm.
Decision Table Testing
Decision Table dùng để kiểm tra requirement trong đó nhiều tổ hợp điều kiện dẫn đến các kết quả khác nhau. Đây là cách biểu diễn business rules có hệ thống, giúp phát hiện combination bị bỏ quên, requirement thiếu hoặc mâu thuẫn.
| Điều kiện / Hành động | Rule 1 | Rule 2 | Rule 3 | Rule 4 |
|---|---|---|---|---|
| Khách VIP? | T | T | F | F |
| Đơn ≥ 500.000? | T | F | T | F |
| Miễn phí vận chuyển | X | X | X | |
| Tính phí vận chuyển | X |
Mỗi cột là một decision rule và có thể tạo thành ít nhất một test case. Để đạt 100% decision table coverage, test cases phải exercise tất cả cột chứa tổ hợp khả thi.
- T: điều kiện đúng.
- F: điều kiện sai.
- –: điều kiện không ảnh hưởng đến kết quả của rule.
- N/A: tổ hợp điều kiện không khả thi.
- X: hành động phải xảy ra.
State Transition Testing
State Transition Testing phù hợp khi phản ứng của hệ thống không chỉ phụ thuộc input hiện tại mà còn phụ thuộc vào state trước đó và chuỗi sự kiện đã xảy ra.
Một mô hình state transition thường có:
- State: trạng thái hiện tại của hệ thống.
- Event: sự kiện kích hoạt transition.
- Guard condition: điều kiện bổ sung để transition xảy ra.
- Action: hành động hệ thống thực hiện khi chuyển trạng thái.
| State hiện tại | Event | State tiếp theo | Action |
|---|---|---|---|
| Active | Nhập đúng mật khẩu | Logged in | Cho phép truy cập |
| Active | Nhập sai lần thứ ba | Locked | Khóa tài khoản |
| Locked | Nhập đúng mật khẩu | Locked | Từ chối truy cập |
| Locked | Admin mở khóa | Active | Đặt lại số lần sai |
Các mức coverage trong CTFL
- All states coverage: đi qua tất cả states ít nhất một lần.
- Valid transitions coverage: exercise tất cả transition hợp lệ. Mức này mạnh hơn all states và được dùng phổ biến nhất.
- All transitions coverage: exercise transition hợp lệ và thử cả transition không hợp lệ.
Error Guessing
Error Guessing dựa vào kiến thức và kinh nghiệm của tester để dự đoán nơi có thể xuất hiện error, defect hoặc failure. Nguồn kinh nghiệm thường đến từ:
- Cách ứng dụng từng hoạt động và những lỗi đã xảy ra trước đây.
- Những lỗi developer trong team thường mắc.
- Failure từng gặp ở các sản phẩm tương tự.
- Dữ liệu defect, production incident và bài học từ dự án cũ.
Ví dụ tester có thể đoán và thử:
- Bấm nút thanh toán hai lần liên tiếp.
- Để session hết hạn ngay trước khi submit.
- Gửi request thiếu parameter hoặc sai kiểu dữ liệu.
- Nhập emoji, ký tự Unicode hoặc chuỗi rất dài.
- Thử ngày 29/2, cuối tháng hoặc chuyển năm.
Một cách triển khai Error Guessing có hệ thống hơn là fault attack: team lập danh sách error, defect và failure có khả năng xảy ra, sau đó thiết kế test nhằm làm lộ chúng.
Khi nào chọn kỹ thuật nào?
| Dấu hiệu của bài toán | Kỹ thuật phù hợp |
|---|---|
| Nhiều điều kiện kết hợp thành business rules | Decision Table |
| Hành vi phụ thuộc trạng thái và thứ tự sự kiện | State Transition |
| Muốn khai thác lỗi quen thuộc, rủi ro thực tế và kinh nghiệm tester | Error Guessing |
| Business rule thay đổi theo state | Kết hợp Decision Table và State Transition |
| Muốn bổ sung case oái oăm vào bộ test có hệ thống | Thêm Error Guessing |
Kết luận
Decision Table ngăn bỏ sót tổ hợp điều kiện; State Transition ngăn bỏ sót trạng thái và đường chuyển; Error Guessing tận dụng kinh nghiệm để nhắm vào những failure thực tế. Chúng không cạnh tranh với nhau — một tính năng phức tạp thường cần phối hợp cả ba để có coverage tốt hơn.
