Hướng dẫn kỹ thuật Bảng quyết định - Decision Table

Kỹ thuật Bảng Quyết Định - Decision Table trong kiểm thử hộp đen

I. GIỚI THIỆU

Như chúng ta đã biết, kiểm thử phần mềm là một phần quan trọng trong quá trình phát triển phần mềm. Để đảm bảo chất lượng và tính đáng tin cậy của sản phẩm, việc thiết kế và thực hiện các bộ test case hiệu quả là rất quan trọng. Bất kỳ luồng nghiệp vụ nào khó khăn tôi và bạn trải qua đều có thể đơn giản hóa bằng việc sử dụng Decision Table. Mặc dù đòi hỏi công sức phết nhưng sự tiện lợi nó đem lại cứ phải coi là "Được của ló"!

Kiểm thử bảng quyết định (Decision table) là một kỹ thuật kiểm thử phần mềm phổ biến bên cạnh Phân vùng tương đương (Equivalence partitioning) và Phân tích giá trị biên (Boundary value analysis). Nó còn được gọi là kỹ thuật nhân quả hay Ma trận testcase (Matrix testcase).

Kiểm thử bảng quyết định là một kỹ thuật kiểm thử hộp đen được sử dụng để kiểm tra nhiều điều kiện có kết hợp đầu vào trong các trường hợp khác nhau.

Trong bài viết này, chúng ta sẽ tìm hiểu về kỹ thuật sử dụng bảng quyết định (decision table) để tạo ra các test case hiệu quả và chi tiết.

II. ĐỊNH NGHĨA, CÁCH DÙNG

A. Định nghĩa:

Bảng quyết định là một công cụ phân tích và thiết kế test case dựa trên các điều kiện và hành động.

Bảng quyết định bao gồm các cột đại diện cho các điều kiện và hành động kết hợp, và các hàng đại diện cho các quy tắc quyết định. Mỗi ô trong bảng quyết định đại diện cho một trạng thái kết quả dự kiến ( có thể là True/False, Đúng/Sai, Yes/No... hoặc giá trị cụ thể khác).

Có thể thấy rằng, chúng ta tạo một bảng trong đó các hàng trên cùng là các điều kiện đầu vào (Input/Condition), các hàng dưới cùng là các hành động kết quả (Output/Action).

Thứ đề bài đưa cho ta giải quyết ta biến thành Input, còn thứ đề bài mong muốn là Output.

Đây là một cách tiếp cận có hệ thống trong đó các kết hợp đầu vào khác nhau (Input) và hành vi hệ thống tương ứng của chúng (Output) được ghi lại ở dạng bảng. Đó là lý do tại sao nó còn được gọi là bảng Nguyên nhân - Kết quả. Tất cả các Input và Output đều được liệt kê hết và kết hợp chúng lại với nhau.

B. Cách dùng:

Tình huống: Một ứng dụng phần mềm có tên PayLak có mục giỏ hàng cần xử lý các khoản giảm giá dựa trên các loại khách hàng và số lượng đơn đặt hàng khác nhau, nhân dịp Tựu trường của các Cựu thiếu nhi tiên tiến tổ dân phố 2023.

Đối tượng áp dụng:

• Loại khách hàng: Bình dân, Đặc biệt, VIP.
  
• Số tiền đặt hàng: ít tiền hơn $100, $100 - $500, lớn hơn $500.
  

Shop chỉ có giới hạn voucher mà không phải ai cũng được hưởng, cho nên có một số điều kiện nhận voucher:

1. Nếu loại khách hàng là Bình dân và số tiền đặt hàng dưới $100, có voucher.
2. Nếu loại khách hàng là Bình dân và số tiền đặt hàng từ $100 đến $500, không áp dụng chiết khấu.
3. Nếu loại khách hàng là Bình dân và số tiền đặt hàng lớn hơn $500, hãy áp dụng chiết khấu.
4. Nếu loại khách hàng là Đặc biệt và số tiền đặt hàng dưới $100, hãy áp dụng chiết khấu.
5. Nếu loại khách hàng là Đặc biệt và số tiền đặt hàng nằm trong khoảng từ $100 đến 500 đô la, hãy áp dụng giảm giá.
6. Nếu loại khách hàng là Đặc biệt và số tiền đặt hàng lớn hơn $500, không áp dụng giảm giá.
7. Nếu loại khách hàng là VIP và số tiền đặt hàng dưới $100, không áp dụng chiết khấu.
8. Nếu loại khách hàng là VIP và số tiền đặt hàng nằm trong khoảng từ $100 đến 500 đô la, hãy áp dụng giảm giá.
9. Nếu loại khách hàng là VIP và số tiền đặt hàng lớn hơn $500, hãy áp dụng giảm giá.

Đọc đến đây có vẻ như hơi lú vì nhiều điều kiện kết hợp, vì vậy việc của chúng ta bây giờ là đơn giản hóa đề bài:

• Chúng ta sắp xếp lần lượt điều kiện và output rồi kết hợp chúng thành từng case riêng lẻ.

• Tổng số case có thể xảy ra theo công thức sau: 2^n... (n là số input đầu vào).

• Tuy nhiên do 3 điều kiện con của 2 input Loại khách hàng và Số tiền đặt hàng thì không thể kết hợp với nhau. công thức sau: n 1 n2 * n3... (n là số input đầu vào)*.

• Mỗi điều kiện của "Order Amount" (3 điều kiện) kết hợp với mỗi điều kiện của "Customer Type" (3 điều kiện) sẽ tạo ra một test case riêng. Do đó, tổng số test case là 9.

  Cho nên trường hợp này tổng số case sẽ là: 3*3 = 9 cases.

C. Ưu điểm của bảng quyết định trong kiểm thử

• Cho phép đơn giản hóa các luồng nghiệp vụ phức tạp, đảm bảo review một cách tổng quan chức năng.
• Cho phép biểu diễn rõ ràng các điều kiện và hành động trong một bảng, giúp cho người xem testcase như QA, PM, Customers có cái nhìn khách quan minh bạch và rõ ràng hơn bao giờ hết, đó chính là sự ưu việt cực kỳ lớn không thể thay thế bởi bất kỳ một kỹ thuật nào.
• Giúp tạo ra các test case dễ hiểu, chi tiết và toàn diện.
• Cho phép tìm ra các trường hợp kiểm thử bị bỏ sót và tránh lặp lại test case không cần thiết.

D. Nhược điểm của bảng quyết định

• Mặc dù thử nghiệm hiệu quả và có lợi, nhưng nó có thể hơi tốn thời gian. Càng nhiều thời gian, chi phí kiểm tra càng nhiều. Vì vậy, đây là một trong những trở ngại lớn.

• Như đã đề cập ở trên, kiểm thử bảng quyết định cung cấp đầu ra là 'true' hoặc 'false'. Do đó, nó không cung cấp dữ liệu quan trọng khác liên quan đến bảo mật và hiệu suất tổng thể của phần mềm.

• Thử nghiệm này yêu cầu người thử nghiệm có kỹ năng và chuyên môn để xử lý các bảng quyết định phức tạp, vì có nhiều đầu vào trong các bảng phức tạp. Người mới là cũng hơi căng thẳng.

• Bất cứ khi nào có bất kỳ thay đổi nào trong phần mềm, bắt buộc phải kết hợp tương tự trong các bảng quyết định. Do đó, bạn phải duy trì và cập nhật chúng thường xuyên, điều này sẽ gây ra nhiều chi phí và nỗ lực hơn cho nhóm.

III. Xây dựng bảng quyết định

1. Xác định các điều kiện và hành động:

Đầu tiên, xác định các điều kiện (conditions) và hành động (actions) mà bạn muốn kiểm tra. Điều kiện là các yếu tố hoặc sự kiện ảnh hưởng đến kết quả của chức năng hoặc tính năng cần kiểm thử.

2. Xây dựng bảng quyết định:

• Tạo một bảng có các cột tương ứng với các điều kiện và hành động đã xác định.
• Dựa trên quy tắc quyết định, điền các giá trị true hoặc false vào các ô tương ứng để biểu thị kết quả dự kiến.

3. Tạo test case từ bảng quyết định:

• Mỗi hàng trong bảng quyết định đại diện cho một test case.
• Tạo test case bằng cách lấy giá trị của các điều kiện từ các cột và ghi lại. Ta có công thức chung. Tổng số testcase:
  công thức chung sau:
  SL = N1 * N2 * N3... (n là số lượng input đầu vào).
  Số lần xuất hiện của mỗi input trong tất cả các case là:
  F = SL/N Ví dụ như trường hợp bên trên: Tổng số testcase = 9, tần suất hiển thị của loại KH Bình Dân, Đặc Biệt, VIP sẽ là 9/3 = 3

IV. Tối ưu testcase, loại bỏ case dư thừa:

Dưới đây là một ví dụ:

• Loại bỏ các trường hợp trùng lặp:

Kiểm tra các hàng trong bảng quyết định và loại bỏ các trường hợp có cùng giá trị của các điều kiện. Nếu hai hoặc nhiều trường hợp có cùng giá trị của các điều kiện và kết quả của chúng là giống nhau, bạn chỉ cần giữ lại một trường hợp duy nhất và loại bỏ các trường hợp trùng lặp khác.

Trong một bảng quyết định, nếu có một trường hợp mà các điều kiện đều là False và kết quả dự kiến cũng là False, ta có thể loại bỏ trường hợp đó vì nó không đóng góp vào kiểm thử bổ sung. Ví dụ như case cả Username và password đều không hợp lệ.

• Kết hợp các điều kiện tương đương:

Xem xét các điều kiện và xác định xem có các điều kiện nào có thể được kết hợp lại thành một điều kiện tương đương. Nếu hai điều kiện có cùng kết quả hoặc ảnh hưởng đến kết quả một cách tương tự, bạn có thể kết hợp chúng thành một điều kiện duy nhất để giảm số lượng trường hợp trong bảng quyết định.

Khi xây dựng bảng quyết định, có thể xảy ra trường hợp một số testcase có các điều kiện giống nhau. Trong trường hợp này, ta có thể loại bỏ các testcase trùng lặp và chỉ chọn một testcase duy nhất đại diện cho nhóm testcase đó. Điều này giúp giảm số lượng testcase cần kiểm tra mà vẫn đảm bảo độ phủ của bảng quyết định.

• Sử dụng phương pháp tách biến:

Thay vì xây dựng bảng quyết định với tất cả các tổ hợp của tên người dùng và mật khẩu, ta tách biến thành hai bảng quyết định riêng biệt cho tên người dùng và mật khẩu.

• Sắp xếp và liệt kê hết các case trong ma trận quyết định:

Ví dụ bạn có 3 input, bạn có thể dùng nhị phân để dễ kiểm soát testcase. Bằng việc đảo vị trí 0,1:

Tuy nhiên, việc loại bỏ các trường hợp trùng lặp và không mang lại kiểm thử bổ sung cần được thực hiện cẩn thận để đảm bảo độ phủ của bảng quyết định không bị giảm đi quá nhiều và vẫn đảm bảo đủ kiểm thử các trường hợp quan trọng.

V. Multiple Condition Decision Coverage (MCDC)

MC/DC đòi hỏi mỗi điều kiện trong Decision Table phải có ít nhất một testcase để kiểm tra khi điều kiện đó đúng và ít nhất một testcase để kiểm tra khi điều kiện đó sai. Điều này giúp đảm bảo rằng mọi điều kiện được kiểm tra đầy đủ và không bỏ sót bất kỳ trường hợp nào.

Trường hợp đơn giản hơn, khi có ít điều kiện và hành động, thì Decision Table thực sự là một phương pháp của Multiple Condition Decision Coverage. Decision Table cho phép biểu diễn rõ ràng các quy tắc quyết định và tạo ra các test case tương ứng.

Lưu ý rằng Multiple Condition Decision Coverage (MCDC) là một chuẩn kiểm thử đặc biệt, yêu cầu mỗi điều kiện độc lập phải được kiểm tra đúng và sai ít nhất một lần. MCDC có thể được áp dụng khi có các yêu cầu đặc biệt về độ bao phủ và độ tin cậy cao. Các bạn có thể tìm hiểu thêm về MCDC.

Tuy nhiên, việc sử dụng Decision Table trong trường hợp đơn giản hơn là phù hợp và tiện lợi hơn, vì nó cung cấp sự rõ ràng và dễ hiểu trong biểu diễn quyết định và tạo ra các test case liên quan trực tiếp đến các quyết định.

VI. Kết luận

Kỹ thuật dùng bảng quyết định cực kỳ quan trọng và góp công rất lớn vào việc kiến tạo mindset và tốc độ xử lý công việc cho Tester nói riêng và cho tất cả mọi ngành nghề nói chung. Qua bài viết đơn giản này, hi vọng các bạn có cái nhìn khái quát và biết cách sử dụng Decision Table trong việc kiểm thử phần mềm. Mong các bạn góp ý và bổ sung, khám phá ra nhiều technique khác nhau để áp dụng cho công việc trơn tru hơn.

Author: PoppinKhiem