Lý thuyết Kiểm thử Phần mềm: Bảng quyết định Decision Table
Khám phá kỹ thuật kiểm thử Bảng quyết định (Decision Table). Hướng dẫn chi tiết cách lập bảng, ví dụ minh họa và ứng dụng thực tế trong kiểm thử phần mềm.
bảng quyết địnhdecision table testingkiểm thử phần mềmkỹ thuật kiểm thửblack box testinglogic kiểm thử
1. Tổng quan về Kỹ thuật
Kiểm thử Bảng quyết định là một kỹ thuật kiểm thử hộp đen (Black-box testing) mạnh mẽ và có tính hệ thống cao. Kỹ thuật này được thiết kế đặc biệt để giải quyết các hệ thống có logic nghiệp vụ phức tạp, nơi mà đầu ra (kết quả) phụ thuộc chặt chẽ vào sự kết hợp của nhiều đầu vào (điều kiện) khác nhau.
Trong thực tế phát triển phần mềm, các kỹ thuật đơn giản như Phân vùng tương đương (Equivalence Partitioning) hay Phân tích giá trị biên (Boundary Value Analysis) thường thất bại hoặc không đủ độ bao phủ khi phải đối mặt với các quy tắc nghiệp vụ đan chéo nhau. Bảng quyết định ra đời để lấp đầy khoảng trống này bằng cách liệt kê toàn bộ các tổ hợp có thể xảy ra.
Kỹ thuật này còn được gọi là Bảng Nguyên nhân - Kết quả (Cause-Effect Table). Nguyên nhân chính là các điều kiện đầu vào mà người dùng hoặc hệ thống cung cấp. Kết quả chính là những hành động mà phần mềm phải thực thi tương ứng với tổ hợp nguyên nhân đó.
2. Các thành phần cấu trúc của Bảng quyết định
Một bảng quyết định tiêu chuẩn luôn được chia thành 4 phần tư (quadrants) rõ rệt. Sự phân chia này giúp tách biệt rõ ràng giữa "Những gì chúng ta có thể thay đổi" (Điều kiện) và "Những gì hệ thống phải phản hồi" (Hành động).
2.1. Nhóm Điều kiện (Conditions)
Cuống điều kiện (Condition Stub)
Nằm ở góc trên bên trái của bảng. Đây là danh sách liệt kê tất cả các điều kiện, tiêu chí đầu vào hoặc các biến số ảnh hưởng đến quy trình. Nó trả lời câu hỏi: "Hệ thống cần kiểm tra những yếu tố nào?".
Mục điều kiện (Condition Entry)
Nằm ở góc trên bên phải của bảng. Phần này chứa các giá trị cụ thể mà các điều kiện có thể nhận. Thông thường, trong bảng quyết định nhị phân, các giá trị này là Đúng (True - T) hoặc Sai (False - F), hoặc Có (Yes - Y) / Không (No - N).
2.2. Nhóm Hành động (Actions)
Cuống hành động (Action Stub)
Nằm ở góc dưới bên trái. Danh sách tất cả các hành động có thể xảy ra, các kết quả đầu ra hoặc thông báo lỗi mà hệ thống có thể sinh ra. Nó trả lời câu hỏi: "Hệ thống có thể làm những gì?".
Mục hành động (Action Entry)
Nằm ở góc dưới bên phải. Nó chỉ ra liệu một hành động cụ thể có được thực thi hay không ứng với một cột tổ hợp điều kiện cụ thể. Thường được đánh dấu bằng dấu tích (X) để biểu thị sự thực thi, hoặc bỏ trống (hoặc đánh dấu -) nếu không thực thi.
(Danh sách các điều kiện)
(Tổ hợp các giá trị T/F)
(Danh sách kết quả)
(Đánh dấu X cho kết quả tương ứng)
3. Quy trình từng bước xây dựng Bảng quyết định
Việc xây dựng một bảng quyết định đòi hỏi sự tỉ mỉ trong việc phân tích tài liệu đặc tả yêu cầu (SRS - Software Requirements Specification). Bỏ sót một điều kiện hoặc tính toán sai số lượng quy tắc có thể dẫn đến việc bỏ lọt các lỗi nghiêm trọng trong phần mềm. Dưới đây là 5 bước chuẩn hóa để tạo ra một bảng quyết định hoàn chỉnh.
Phân tích và Liệt kê tất cả các Điều kiện
Kỹ sư kiểm thử (Tester) đọc kỹ tài liệu yêu cầu để xác định mọi yếu tố có thể ảnh hưởng đến luồng đi của chức năng. Đây chính là việc tạo ra "Cuống điều kiện".
- Xác định các input từ người dùng (VD: nhập tên, chọn dropdown).
- Xác định các trạng thái của hệ thống (VD: tài khoản đang bị khóa).
- Xác định các yếu tố thời gian (VD: đã quá hạn thanh toán).
Xác định tất cả các Hành động có thể xảy ra
Xác định hệ thống sẽ phản hồi như thế nào. Một hành động có thể là việc chuyển trang, lưu dữ liệu vào cơ sở dữ liệu, hoặc hiển thị một thông báo lỗi. Đây là việc xây dựng "Cuống hành động".
Lưu ý: Đừng bỏ qua các hành động ẩn như "Ghi log lỗi" hoặc "Gửi email thông báo", chúng cũng cần được kiểm thử.
Tính toán số lượng Quy tắc (Tổ hợp Test Case)
Để đảm bảo độ bao phủ 100% các nhánh logic, chúng ta cần tính số lượng cột trong bảng (hay số lượng Rule). Đối với các điều kiện nhị phân (chỉ có True/False), công thức toán học được áp dụng là:
Trong đó N là số lượng điều kiện đã xác định ở Bước 1. Ví dụ, nếu có 3 điều kiện, chúng ta sẽ có quy tắc tương đương với 8 kịch bản kiểm thử (test cases).
Điền các Mục điều kiện và Hành động
Tiến hành điền các giá trị T (True) và F (False) vào phần "Mục điều kiện" sao cho sinh ra đủ các tổ hợp không trùng lặp. Một mẹo nhỏ để điền không bị thiếu là:
- Dòng điều kiện đầu tiên: Điền xen kẽ một nửa T, một nửa F (Ví dụ: T T T T F F F F).
- Dòng điều kiện thứ hai: Chia đôi số lượng lại (Ví dụ: T T F F T T F F).
- Dòng cuối cùng: Đan xen liên tục (T F T F T F T F).
Sau đó, dựa vào logic nghiệp vụ để đánh dấu (X) vào các phần "Mục hành động" tương ứng với mỗi cột.
Rút gọn Bảng quyết định (Tùy chọn nhưng Khuyến nghị)
Trong thực tế, khi số lượng điều kiện lớn, số lượng test case sẽ bùng nổ theo cấp số nhân (Ví dụ 10 điều kiện = 1024 quy tắc). Quá trình rút gọn giúp loại bỏ các điều kiện "Không quan tâm" (Don't Care) - ký hiệu là dấu trừ (-). Nếu một điều kiện có là True hay False cũng không làm thay đổi kết quả cuối cùng trong một ngữ cảnh cụ thể, ta gộp các cột đó lại để tối ưu hóa thời gian kiểm thử mà không làm giảm chất lượng.
4. Ví dụ 1: Ứng dụng Bảng quyết định cho Màn hình Đăng nhập
Hãy bắt đầu với một ví dụ kinh điển và dễ hiểu nhất trong kiểm thử phần mềm: Chức năng Đăng nhập (Login Screen). Giả sử hệ thống yêu cầu người dùng nhập Email và Mật khẩu. Logic nghiệp vụ quy định rằng người dùng chỉ được chuyển hướng đến trang chủ (Homepage) nếu cả Email và Mật khẩu đều được nhập chính xác. Bất kỳ đầu vào nào sai đều hiển thị thông báo lỗi.
4.1. Phân tích Bài toán
Các Điều kiện (Conditions):
- C1: Email chính xác (True/False)
- C2: Mật khẩu chính xác (True/False)
Các Hành động (Actions):
- A1: Cho phép đăng nhập thành công & chuyển tới Homepage.
- A2: Hiển thị thông báo lỗi (Error message).
4.2. Bảng quyết định chi tiết
| Thành phần | Mô tả chi tiết | Rule 1 | Rule 2 | Rule 3 | Rule 4 |
|---|---|---|---|---|---|
| Điều kiện (Conditions) |
C1: Email đúng | F | T | F | T |
| C2: Mật khẩu đúng | F | F | T | T | |
| Hành động (Actions) |
A1: Vào trang chủ | - | - | - | X |
| A2: Báo lỗi | X | X | X | - |
4.3. Giải thích các kịch bản kiểm thử (Test Cases) từ bảng
Tình huống: Người dùng nhập sai Email và sai cả Mật khẩu.
Hệ thống phản hồi: Kích hoạt Hành động A2. Hiển thị thông báo lỗi (VD: "Thông tin đăng nhập không hợp lệ"). Hành động A1 không xảy ra.
Tình huống: Nhập đúng Email nhưng sai Mật khẩu.
Hệ thống phản hồi: Kích hoạt Hành động A2. Vì một điều kiện sai, logic bảo mật ngăn chặn đăng nhập và báo lỗi (VD: "Sai mật khẩu").
Tình huống: Nhập sai Email nhưng nhập Mật khẩu đúng cú pháp.
Hệ thống phản hồi: Kích hoạt Hành động A2. Dù mật khẩu đúng nhưng tài khoản không tồn tại. Hiển thị thông báo lỗi.
Tình huống: Nhập chính xác cả Email và Mật khẩu.
Hệ thống phản hồi: Kích hoạt Hành động A1. Đăng nhập thành công, session được tạo, chuyển vào giao diện Homepage.
Bài học rút ra:
Nhờ có bảng quyết định, Tester có thể tự tin khẳng định rằng mình đã kiểm tra tất cả 100% các trường hợp logic có thể xảy ra của chức năng đăng nhập, không bỏ sót bất kỳ tổ hợp nào giữa Email và Password. Nếu chỉ đoán mò, tester mới vào nghề có thể quên kiểm tra trường hợp Rule 1 (sai cả hai).
5. Ví dụ 2: Hệ thống Giảm giá Thương mại điện tử (Độ phức tạp cao hơn)
Để thấy rõ sức mạnh của Kỹ thuật Bảng quyết định, chúng ta hãy xét một ví dụ phức tạp hơn, nơi các điều kiện đan xen chặt chẽ. Một nền tảng e-commerce áp dụng quy tắc giảm giá như sau:
Đặc tả yêu cầu nghiệp vụ (Business Rules):
Khách hàng sẽ nhận được chiết khấu 20% nếu thỏa mãn MỘT TRONG CÁC điều kiện kết hợp sau:
- Khách hàng là thành viên VIP.
- Hoặc: Là khách hàng thường (Không VIP) NHƯNG có đơn hàng trên 1 triệu VNĐ VÀ có nhập mã Coupon hợp lệ.
Nếu không thỏa mãn các điều kiện trên, thanh toán theo giá gốc (Không giảm giá).
5.1. Khởi tạo Thông số
3 Điều kiện (Conditions):
- C1: Thành viên VIP (Y/N)
- C2: Đơn hàng > 1 Triệu (Y/N)
- C3: Mã Coupon hợp lệ (Y/N)
2 Hành động (Actions):
- A1: Áp dụng giảm giá 20%
- A2: Không giảm giá (Giá gốc)
5.2. Xây dựng Bảng quyết định 8 Quy tắc
| Tham số | R1 | R2 | R3 | R4 | R5 | R6 | R7 | R8 |
|---|---|---|---|---|---|---|---|---|
| C1: Khách VIP | Y | Y | Y | Y | N | N | N | N |
| C2: Đơn > 1 Tr | Y | Y | N | N | Y | Y | N | N |
| C3: Có Coupon | Y | N | Y | N | Y | N | Y | N |
| A1: Giảm 20% | X | X | X | X | X | - | - | - |
| A2: Không Giảm | - | - | - | - | - | X | X | X |
5.3. Phân tích kết quả bảng quyết định
Nhìn vào bảng trên, chúng ta dễ dàng diễn dịch các kịch bản sang bài toán thực tế. Điều này rất hữu ích cho lập trình viên (Developer) để viết code (sử dụng lệnh if-else) và cho người kiểm thử (Tester) để tạo dữ liệu test.
Khách hàng là VIP (C1 = Y). Dựa theo yêu cầu "Thành viên VIP luôn được giảm giá", hệ thống không cần bận tâm đơn hàng bao nhiêu tiền hay có mã giảm giá hay không. Hành động chắc chắn là A1 (Giảm 20%).
Khách thường (C1 = N), nhưng có đơn hàng trên 1 triệu (C2 = Y) và nhập mã coupon hợp lệ (C3 = Y). Thỏa mãn vế 2 của luật kinh doanh. Hành động là A1 (Giảm 20%).
Khách thường (C1 = N) và thiếu một trong hai điều kiện phụ (hoặc không đủ 1 triệu, hoặc không có mã, hoặc thiếu cả hai). Kết quả: Trượt yêu cầu khuyến mãi. Hành động là A2 (Không giảm giá).
6. Kỹ thuật Rút gọn Bảng quyết định (Table Minimization)
Ở ví dụ E-commerce phía trên, bạn có thể nhận thấy một sự lặp lại về kết quả ở các quy tắc từ R1 đến R4. Dù C2 và C3 thay đổi giá trị như thế nào (Y/Y, Y/N, N/Y, N/N), kết quả cuối cùng vẫn là A1 (Giảm 20%). Tại sao phải viết 4 test case cho cùng một kết quả logic khi yếu tố quyết định chỉ nằm ở C1?
Đây là lúc chúng ta sử dụng khái niệm "Don't Care" (Không quan tâm), thường được ký hiệu bằng dấu gạch ngang (-). Việc rút gọn giúp giảm thiểu số lượng kịch bản kiểm thử trùng lặp, tiết kiệm thời gian thực thi (execution time) mà vẫn đảm bảo độ bao phủ rủi ro.
Bảng sau khi Rút gọn
| Tham số | R1-R4 | R5 | R6 | R7 | R8 |
|---|---|---|---|---|---|
| C1: Khách VIP | Y | N | N | N | N |
| C2: Đơn > 1 Tr | - | Y | Y | N | N |
| C3: Có Coupon | - | Y | N | Y | N |
| A1: Giảm giá | X | X |
Hiệu quả của việc rút gọn:
-
Giảm số lượng Test Case: Từ 8 kịch bản ban đầu, chúng ta gộp R1, R2, R3, R4 thành 1 kịch bản duy nhất (Khách VIP thì luôn được giảm giá, không cần quan tâm hóa đơn hay coupon). Giảm tổng số test case xuống còn 5.
-
Tiết kiệm chi phí thực thi: Thời gian thiết lập dữ liệu (Data Setup) và thời gian chạy test (Test Execution) giảm đi đáng kể.
7. Ưu điểm nổi bật
Bảo đảm tính Hoàn chỉnh (Completeness)
Toán học đảm bảo rằng bằng việc tính , mọi tổ hợp của điều kiện đều được cân nhắc. Rất hiếm khi bỏ sót các trường hợp ngoại lệ (corner cases).
Ngôn ngữ chung cho mọi vai trò
Bảng quyết định cực kỳ trực quan. Business Analyst (BA), Lập trình viên (Dev), Tester và thậm chí Khách hàng đều có thể đọc bảng và thống nhất logic mà không cần hiểu mã nguồn.
Dễ dàng cập nhật
Khi logic nghiệp vụ thay đổi (thêm mới một điều kiện khuyến mãi), việc thêm một hàng vào "Cuống điều kiện" và mở rộng bảng sẽ trực quan và ít gây lỗi hồi quy (regression) hơn là đọc lại hàng đống tài liệu text.
8. Nhược điểm và Thách thức
Bùng nổ trạng thái (State Explosion)
Nếu hệ thống có quá nhiều điều kiện, kích thước bảng trở nên không thể quản lý. Ví dụ: 10 điều kiện = 1024 quy tắc, 20 điều kiện = hơn 1 triệu quy tắc. Khi đó, kỹ thuật rút gọn cũng khó cứu vãn và phải dùng các kỹ thuật chia nhỏ phức tạp hơn.
Không phù hợp kiểm thử Dữ liệu lớn/Vòng lặp
Bảng quyết định chỉ mạnh về mặt logic luận lý (Boolean/Logic Gates). Nó không giúp ích nhiều trong việc kiểm thử các giá trị biên (như nhập số nguyên từ 1 đến 100) hoặc lỗi liên quan đến giao diện người dùng, hiệu năng vòng lặp.
Tốn thời gian tạo lập ban đầu
Phải mất rất nhiều công sức để phân tích rạch ròi các điều kiện độc lập từ một tài liệu nghiệp vụ lộn xộn, viết tay hoặc tài liệu không rõ ràng.
9. Khi nào nên áp dụng Kỹ thuật này?
Hệ thống Tài chính
Kiểm thử logic phê duyệt khoản vay, tính lãi suất dựa trên điểm tín dụng, lịch sử trả nợ.
Thương mại Điện tử
Quy tắc áp mã giảm giá, tính phí vận chuyển dựa trên khu vực và khối lượng kiện hàng.
Hệ thống Bảo hiểm
Tính toán mức bồi thường bảo hiểm dựa trên độ tuổi, tiền sử bệnh án và gói dịch vụ.
Form Phức tạp
Các biểu mẫu đăng ký đa bước, nơi nội dung trang sau phụ thuộc vào lựa chọn của trang trước.
Kết luận: Không có kỹ thuật kiểm thử nào là hoàn hảo. Một kỹ sư kiểm thử giỏi (Senior QA/QC) luôn biết cách kết hợp Bảng quyết định (để bao phủ logic) cùng với Phân vùng tương đương và Giá trị biên (để bao phủ dữ liệu đầu vào) nhằm tạo ra bộ kịch bản kiểm thử toàn diện nhất.
2.371 xem 12 kiến thức 5 đề thi
21.150 lượt xem 11/04/2026
20.973 lượt xem 11/04/2026
20.945 lượt xem 11/04/2026
21.038 lượt xem 11/04/2026
21.068 lượt xem 11/04/2026
20.990 lượt xem 11/04/2026
21.011 lượt xem 11/04/2026
21.122 lượt xem 11/04/2026
21.100 lượt xem 11/04/2026
