Sử dụng bảng quyết định trong kiểm thử phần mềm

Bài viết được sự cho phép của vntesters.com

Trong các kỹ thuật viết kịch bản kiểm thử, đối với các trường dữ liệu đơn như textbox, chúng ta thường sử dụng các phương pháp như lớp tương đương (Equivalence partitioning) hay phương pháp phân tích giá trị biên (Boundary value analysis). Đối với kiểm thử hành vi của hệ thống với nhiều trường dữ liệu, bảng quyết định (Decision table) sẽ giúp chúng ta phân loại và định hình được kịch bản kiểm thử một cách chính xác và rõ ràng hơn.

  10 bước để bắt đầu áp dụng kiểm thử tự động vào dự án
  Các trường hợp kiểm thử OTP

Về cơ bản, bảng quyết định sử dụng mô hình luận lý phức tạp để người dùng dễ dàng thấy các kết hợp có thể có của các điều kiện đang xem xét và các hành động tương ứng với tập hợp giá trị của chuỗi điều kiện.

Một ví dụ cơ bản nhất cho bảng quyết định là hệ thống máy rút tiền tự động ATM: Để có thể rút được tiền từ máy ATM, người dùng cần một trong hai điều kiện: tiền trong tài khoản vẫn còn và lớn hơn số tiền muốn rút (Đối với thẻ debit) hoặc là, người dùng được cấp cho một khoản tín dụng từ trước (Đối với thẻ Credit). Diễn đạt bằng lời như thế này, đôi khi dễ làm chúng ta nhầm lẫn về các điều kiện thực tế, chưa kể đến từ “và” và “hoặc”. Khi đưa các điều kiện này vào bảng quyết định, chúng ta sẽ thấy mọi thứ rõ ràng hơn nhiều:

Điều kiện Trường hợp 1 Trường hợp 2 Trường 3
Số tiền trong tài khoản lớn hơn số tiền định rút Đúng (T) Sai (F) Sai (F)
Đã được cấp tín dụng Đúng (T) Sai (F)
Hành động của hệ thống
Cho rút Có (T) Có (T) Không (F)

Thông thường, bảng quyết định sử dụng giá trị luận lý để diễn đạt các điều kiện và hành động của hệ thống. Đối với “đúng/sai” hay “true/false”, chúng ta sẽ dễ dàng ứng dụng các phép toán luận lý như “”/”hoặc” hơn.

Việc liệt kê các điều kiện và các giá trị có thể có của từng điều kiện, chúng ta sẽ có thể đảm bảo toàn bộ kết hợp của các điều kiện được xuất hiện trong bảng quyết định, từ đó chúng ta sẽ đảm bảo sẽ không bỏ qua bất kỳ một kịch bản kiểm thử nào. Hơn nữa, với bảng quyết định, chúng ta có thể phát hiện nhanh chóng những yêu cầu vô lý, qua đó giúp chúng ta tiết kiệm thời gian và công sức thực thi những kịch bản kiểm thử vô nghĩa.

Mặt khác, chúng ta có thể thấy rằng, bảng quyết định không chỉ tốt cho kỹ sư kiểm thử, nó còn có tác dụng cực lớn cho tất cả mọi thành viên của nhóm phát triển phần mềm, từ chủ của sản phẩm (product owner) khi đưa ra ý tưởng, đến các lập trình viên để họ tạo dựng và phát triển hệ thống.

Các bước để tạo một bảng quyết định

1. Phân tích các điều kiện và hành động của hệ thống

Trở lại ví dụ ở trên về máy ATM, chúng ta có thể thấy có hai điều kiện xác định:

  • Số tiền trong tài khoản lớn hơn số tiền định rút
  • Được cấp tín dụng

Và chỉ có một hành động tương ứng của hệ thống: Được rút tiền hay không?

Điều kiện
Số tiền trong tài khoản lớn hơn số tiền định rút
Đã được cấp tín dụng
Hành động của hệ thống
Cho rút

2. Thêm các cột trường hợp giá trị của điều kiện

Đối với 2 điều kiện như trên, chúng ta sẽ có 4 sự kết hợp đúng/sai (2²)

Điều kiện Trường hợp 1 Trường hợp 2 Trường hợp 3 Trường hợp 4
Số tiền trong tài khoản lớn hơn số tiền định rút Đúng (T) Đúng (T) Sai (F) Sai (F)
Đã được cấp tín dụng Đúng (T) Sai (F) Đúng (T) Sai (F)
Hành động của hệ thống
Cho rút

3. Cố gắng giảm số lượng các cột điều kiện

Ở đây, chúng ta có thể thấy rằng, trường hợp 1 và trường hợp 2 là gần như nhau, khi số tiền trong tài khoản lớn hơn số tiền cần rút, chúng ta không cần quan tâm việc khách hàng có được cấp tín dụng hay không 🙂 Do đó, chúng ta có thể giảm bớt một trường hợp ở đây, chúng ta đánh dấu bằng “-“

Điều kiện Trường hợp 1 Trường hợp 2 Trường 3
Số tiền trong tài khoản lớn hơn số tiền định rút Đúng (T) Sai (F) Sai (F)
Đã được cấp tín dụng Đúng (T) Sai (F)
Hành động của hệ thống
Cho rút

4. Xác định hành động tương ứng của hệ thống

Dựa trên điều kiện, chúng ta sẽ có kết quả cuối cùng:

Điều kiện Trường hợp 1 Trường hợp 2 Trường 3
Số tiền trong tài khoản lớn hơn số tiền định rút Đúng (T) Sai (F) Sai (F)
Đã được cấp tín dụng Đúng (T) Sai (F)
Hành động của hệ thống
Cho rút Có (T) Có (T) Không (F)

5. Viết các kịch bản kiểm thử

Ở bước này, chúng ta bắt đầu viết chi tiết các bước và thiết lập dữ liệu kiểm thử cho kịch bản kiểm thử.


Một câu hỏi nhỏ thôi. Theo các bạn, việc chúng ta gom trường hợp 1 và 2 ở bước thứ 3 có tốt hay không? Có khả năng nào chúng ta sẽ bỏ lỡ một lỗi (bug) ở đây? Và trong trường hợp gom được, chúng ta nên chọn giá trị T hay F cho điều kiện thứ 2?

Bài viết gốc được đăng tải tại vntesters.com

Có thể bạn quan tâm:

Xem thêm Việc làm Developer hấp dẫn trên TopDev