Decision Table Testing(Kiểm thử bảng quyết định)

1.Decision Table Testing là gì?

Decision Table Testing (hay còn gọi là Kiểm thử bảng quyết định) là một kỹ thuật thiết kế kiểm thử hộp đen được sử dụng để kiểm tra các tính năng có nhiều điều kiện kết hợp với nhau để đưa ra các hành động hoặc kết quả khác nhau.

Kỹ thuật này giúp bạn hệ thống hóa toàn bộ các kịch bản kết hợp dưới dạng một bảng logic, đảm bảo không bỏ sót bất kỳ trường hợp hay điều kiện đặc biệt nào khi hệ thống xử lý các quy tắc nghiệp vụ (Business Rules) phức tạp.

Nếu kiểm thử viên chỉ sử dụng phương pháp kiểm thử đơn lẻ cho từng điều kiện, họ sẽ bỏ sót hàng loạt các kịch bản kết hợp chéo dẫn đến lỗi hệ thống trầm trọng. Decision Table Testing (Kiểm thử bảng quyết định) ra đời như một công cụ toán học – logic đỉnh cao thuộc nhóm kỹ thuật hộp đen (Black-box Test Design Techniques), giúp mô hình hóa toàn bộ các tổ hợp điều kiện phức tạp một cách trực quan, khoa học và không bị bỏ sót.

Cấu trúc cơ bản của một Bảng quyết định

Bảng quyết định gồm có 4 phần chính:

1. Conditions (Điều kiện): Liệt kê tất cả các điều kiện/yếu tố đầu vào của hệ thống.

2. Actions (Hành động/Kết quả): Liệt kê các hành động hoặc kết quả mà hệ thống sẽ trả về.

3. Rules (Các quy tắc/Kịch bản): Mỗi cột tương ứng với một quy tắc kết hợp các điều kiện đầu vào.

4. Giá trị (True/False hoặc Yes/No): Đánh dấu trạng thái Bật/Tắt của từng điều kiện để cho ra kết quả tương ứng.

Ví dụ thực tế dễ hiểu

Giả sử bạn cần kiểm tra tính năng Giảm giá phí vận chuyển cho một website mua sắm trực tuyến với quy tắc nghiệp vụ sau:

• Nếu khách hàng là Thành viên VIP HOẶC đơn hàng trên 500.000 VNĐ -) Được Miễn phí vận chuyển (Freeship).

• Nếu không thỏa mãn cả 2 điều kiện trên -) Tính phí vận chuyển bình thường.

 Bảng quyết định:

Dựa vào Bảng quyết định trên, nhanh chóng viết ra đúng 4 Test Cases tương ứng với 4 cột Quy tắc (Rules) mà không lo bị trùng lặp hay sót kịch bản.

Khi nào nên sử dụng Decision Table Testing?

• Khi tính năng phần mềm có chứa nhiều quy tắc nghiệp vụ phức tạp (Business Logic).

• Khi kết quả đầu ra phụ thuộc vào sự kết hợp giữa hai hay nhiều điều kiện đầu vào khác nhau.

• Thường áp dụng cho các hệ thống ngân hàng, bảo hiểm, tính tiền thưởng, tính phí ship, hoặc phân quyền người dùng.

2. Bản chất lý luận và phân loại bảng quyết định: Limited-Entry vs. Extended-Entry:

Bảng quyết định là một công cụ biểu diễn dạng bảng gồm các điều kiện logic và các hành động tương ứng. Trong kỹ nghệ phần mềm, bảng quyết định được chia thành hai dạng chính:

• 1. Limited-Entry Decision Table (Bảng quyết định nhập liệu giới hạn / Nhị phân):

  • Là dạng phổ biến nhất. Tất cả các điều kiện đầu vào đều mang giá trị nhị phân đơn giản là  True (Đúng/Có) hoặc False (Sai/Không). Tất cả các hành động cũng được biểu diễn bằng việc thực hiện (x ) hoặc không thực hiện (-).

• 2. Extended-Entry Decision Table (Bảng quyết định nhập liệu mở rộng):

  • Được áp dụng khi các điều kiện đầu vào không chỉ là Đúng/Sai, mà có thể là các tập hợp giá trị đa dạng (ví dụ: Phân khúc khách hàng là Kim cương, Vàng, Bạc hoặc Trạng thái đơn hàng là Đang chờ, Đã duyệt, Đã hủy). Dạng này giúp bảng trở nên gọn gàng hơn khi số lượng giá trị của một điều kiện quá lớn.

3. Cấu trúc chi tiết 4 thành phần cốt lõi :

1. Condition Stubs (Cuống điều kiện): Nằm ở góc trên bên trái, chứa tên các điều kiện logic cần kiểm tra (ví dụ: C1: Là thành viên VIP?, C2: Đơn hàng trên 1 triệu?).

2. Action Stubs (Cuống hành động): Nằm ở góc dưới bên trái, chứa toàn bộ các hành động hoặc kết quả đầu ra mà hệ thống sẽ thực hiện (ví dụ: A1: Giảm giá 20%, A2: Miễn phí vận chuyển, A3: Giữ nguyên giá).

3. Condition Entries (Thân điều kiện): Nằm ở góc trên bên phải, chứa các cột quy tắc (Rules). Mỗi cột đại diện cho một tổ hợp giá trị điều kiện cụ thể.

4. Action Entries (Thân hành động): Nằm ở góc dưới bên phải, xác định xem hành động nào sẽ được kích hoạt cho từng cột quy tắc tương ứng phía trên.

4. Quy trình chuẩn hóa 5 bước xây dựng, giải quyết và tối ưu hóa bảng quyết định:

Để triển khai Decision Table Testing trong dự án thực tế, kiểm thử viên tuân thủ chu trình 5 bước:

1. Phân tích tài liệu yêu cầu (Requirement Analysis): Đọc kỹ tài liệu đặc tả (SRS) hoặc các quy định nghiệp vụ để trích xuất chính xác n điều kiện đầu vào và m hành động đầu ra.

2. Tính toán số lượng quy tắc lý thuyết (Theoretical Rules):

   • Với $n$ điều kiện nhị phân, tổng số tổ hợp quy tắc tối đa được tính bằng công thức toán học: $2^n$.

3. Xây dựng Bảng quyết định đầy đủ (Full Decision Table): Điền các giá trị True/False vào phần thân điều kiện theo quy luật phân phối đều (ví dụ: điều kiện đầu tiên chia đôi True/False, điều kiện thứ hai chia tư…), sau đó xác định hành động cho từng cột.

4. Rút gọn bảng quyết định (Table Reduction): Gom nhóm các cột có cùng hành động và có thể bỏ qua một số điều kiện không ảnh hưởng (ký hiệu là dấu - hay Don’t care), giúp giảm số lượng test cases thừa thãi.

5. Thiết kế Ca kiểm thử thực tế (Test Case Generation): Mỗi cột còn lại sau khi rút gọn chính là một ca kiểm thử hoàn chỉnh dùng để thực thi trên ứng dụng.

5. Ví dụ thực tế minh họa chi tiết: Hệ thống tính chiết khấu thương mại điện tử:

Xét một quy tắc nghiệp vụ của một website thương mại điện tử khi tính chính sách ưu đãi cho khách hàng dựa trên 3 điều kiện:

• Điều kiện 1 (C1): Khách hàng là thành viên VIP? (True/False)

• Điều kiện 2 (C2): Giá trị đơn hàng lớn hơn 2.000.000 VND? (True/False)

• Điều kiện 3 (C3): Thanh toán qua ví điện tử liên kết? (True/False)

Các hành động đầu ra hệ thống:

• A1: Áp dụng mã giảm giá 15% + Miễn phí vận chuyển.

• A2: Chỉ áp dụng miễn phí vận chuyển.

• A3: Không áp dụng ưu đãi nào (Giá chuẩn).

Bảng quyết định phân tích (Ví dụ rút gọn):

• Quy tắc 1 (Rule 1): VIP = Đúng, Đơn hàng > 2tr = Đúng, Ví điện tử = Đúng-) Kích hoạt A1.

• Quy tắc 2 (Rule 2): VIP = Đúng, Đơn hàng > 2tr = Đúng, Ví điện tử = Sai -) Kích hoạt A1 (vì là VIP và đơn lớn nên vẫn được ưu đãi cao nhất).

• Quy tắc 3 (Rule 3): VIP = Sai, Đơn hàng > 2tr = Đúng, Ví điện tử = Đúng -) Kích hoạt A2.

• Quy tắc 4 (Rule 4): Các trường hợp còn lại -) Kích hoạt A3.

Thông qua bảng quyết định, kiểm thử viên dễ dàng thiết kế các ca kiểm thử bao phủ toàn bộ các ma trận điều kiện này mà không sợ bị bỏ sót bất kỳ tình huống thương mại nào.

6. Kỹ thuật rút gọn bảng quyết định (Table Collapsing) và xử lý giá trị “Don’t Care” (-):

Một trong những kỹ năng quan trọng nhất khi làm việc với Decision Table là Rút gọn bảng (Table Reduction):

• Khi hai cột quy tắc có kết quả hành động hoàn toàn giống nhau, và giá trị của một điều kiện nào đó ở hai cột thay đổi từ True sang False mà không làm thay đổi kết quả hành động, ta có thể gộp hai cột đó thành một cột duy nhất và thay thế điều kiện đó bằng dấu gạch ngang – (Don’t care).

• Kỹ thuật này giúp cắt giảm đáng kể số lượng ca kiểm thử cần thực thi, tối ưu hóa thời gian nhưng vẫn đảm bảo độ bao phủ logic toàn diện.

7. Sự cộng hưởng giữa Decision Table Testing:

Trong bức tranh toàn cảnh của thiết kế kiểm thử hộp đen, Decision Table Testing không đứng độc lập mà bổ trợ hoàn hảo cho các kỹ thuật khác:

• Kết hợp với Equivalence Partitioning (EP) và Boundary Value Analysis (BVA): Trong khi EP và BVA giúp xử lý các giá trị dữ liệu bên trong một trường nhập liệu cụ thể, thì Decision Table lại giải quyết các mối quan hệ logic kết hợp giữa nhiều trường dữ liệu và nhiều quy tắc nghiệp vụ khác nhau.

8. Lợi ích chiến lược kinh tế – kỹ thuật :

• Lợi ích chiến lược tối ưu:

  • Loại bỏ sự mơ hồ: Giúp chuyển hóa các tài liệu yêu cầu nghiệp vụ dài dòng, phức tạp và dễ mâu thuẫn thành các ma trận logic rõ ràng, minh bạch.

  • Độ bao phủ tuyệt đối: Đảm bảo không có tổ hợp điều kiện nào bị bỏ sót trong quá trình kiểm thử hệ thống doanh nghiệp.

• Các cạm bẫy cần tránh:

  • Cạm bẫy 1: Số lượng điều kiện quá lớn (n > 8) khiến bảng trở nên cồng kềnh, khó kiểm soát (cần chia nhỏ thành các module phụ).

  • Cạm bẫy 2: Lạm dụng dấu Don’t care (-) dẫn đến việc bỏ sót các điều kiện biên nhạy cảm thực sự có tác động đến hệ thống.

9. Cảm nhận, chiêm nghiệm:

• Thông qua quá trình nghiên cứu tường tận và vận dụng Decision Table Testing, em nhận thức sâu sắc rằng nghề kiểm thử phần mềm đòi hỏi tư duy logic cấu trúc bậc cao.

• Kỹ sư QC giỏi không chỉ chạy theo giao diện, mà phải là người nắm giữ và kiểm soát được toàn bộ bức tranh logic nghiệp vụ của hệ thống. Decision Table Testing đã rèn luyện cho tôi khả năng phân tích sắc sảo, tư duy hệ thống mạch lạc, giúp tôi tự tin thiết kế những bộ test cases hoàn mỹ, loại bỏ triệt để các lỗ hổng logic từ giai đoạn sớm của dự án.

Vu Do

Xem tất cả bài viết của tác giả

Bài viết khác

Dio & HTTP Client

     Trong hệ sinh thái Flutter/Dart, lập trình viên có thể sử dụng nhiều thư viện khác nhau để thực hiện các yêu cầu HTTP. Trong đó, HTTP Client là khái niệm và công cụ nền tảng giúp ứng dụng gửi, nhận dữ liệu qua HTTP; còn Dio là một thư viện HTTP Client […]

Đọc thêm

Dependency Injection

     Trong quá trình phát triển phần mềm, một chương trình hiếm khi chỉ bao gồm những lớp hoặc hàm hoạt động độc lập. Các thành phần thường phải sử dụng dịch vụ, dữ liệu hoặc chức năng do thành phần khác cung cấp. Ví dụ, một lớp xử lý đơn hàng có thể […]

Đọc thêm

Flutter Flavors & Multiple Environments

Flutter Flavors & Multiple Environments 1. Tổng quan về Flutter Flavors & Multiple Environments Trong quá trình phát triển ứng dụng Flutter, một dự án thường cần nhiều môi trường hoạt động khác nhau để phục vụ các giai đoạn phát triển, kiểm thử và triển khai thực tế. Ví dụ, ứng dụng có thể […]

Đọc thêm

Firebase Analytics – Phân tích dữ liệu và hành vi người dùng trong ứng dụng

Firebase Analytics – Phân tích dữ liệu và hành vi người dùng trong ứng dụng 1. Tổng quan về Firebase Analytics Firebase Analytics là một dịch vụ phân tích dữ liệu được tích hợp trong nền tảng Firebase của Google, giúp nhà phát triển thu thập, theo dõi và phân tích hành vi của người […]

Đọc thêm

Firebase Cloud Messaging (FCM)

Firebase Cloud Messaging (FCM) 1. Tổng quan về Firebase Cloud Messaging Firebase Cloud Messaging (FCM) là dịch vụ nhắn tin đám mây do Google cung cấp, cho phép ứng dụng gửi và nhận thông báo hoặc dữ liệu từ máy chủ đến các thiết bị như điện thoại Android, iPhone và trình duyệt web. FCM […]

Đọc thêm

API Error Handling

API Error Handling 1. Tổng quan về API Error Handling API Error Handling là kỹ thuật xử lý lỗi trong quá trình giao tiếp giữa các thành phần của hệ thống thông qua API (Application Programming Interface). Kỹ thuật này bao gồm việc phát hiện lỗi, phân loại nguyên nhân, trả về thông tin phù […]

Đọc thêm