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

Kỹ thuật Equivalence partitioning - Phân vùng tương đương và Boundary value analysis - Phân tích giá trị biên thường được áp dụng cho các tình huống hoặc đầu vào cụ thể. Tuy nhiên, nếu kết hợp các yếu tố đầu vào và thực hiện các hành động khác nhau, thì điều này có thể khó khăn hơn khi sử dụng 2 kỹ thuật trên. Hai kỹ thuật khác dựa trên đặc điểm kiểm thử phần mềm là Decision tables - Bảng quyết định và State transition testing - Kiểm thử chuyển trạng thái tập trung hơn vào các logic và quy tắc kinh doanh.

Bảng quyết định là cách tốt nhất để đối ứng với sự kết hợp của các điều kiện. Kỹ thuật này đôi khi còn được gọi là bảng "Nguyên nhân - kết quả". Lý do cho điều này

• Bảng quyết định cung cấp một cách có hệ thống các quy tắc kinh doanh phức tạp, rất hữu ích cho cả developer và tester.
• Bảng quyết định có thể được sử dụng trong test design, vì chúng giúp tester tìm được những tác động khi kết hợp các yếu tốt đầu vào khác nhau và các trạng thái phần mềm mà phải thực hiện đúng các quy tắc nghiệp vụ khác.
• Bảng quyết định giúp developer làm việc tốt hơn cũng có thể dẫn đến các mối quan hệ tốt hơn với họ. Kiểm thử kết hợp có thể là một thách thức vì số lượng các kết hợp điều kiện có thể là rất lớn. Kiểm tra tất cả các kết hợp điều kiện có thể là không thực tế nếu không phải là không thể. Chúng ta phải hài lòng với việc chỉ kiểm thử một phần nhỏ trong số tất cả các kết hợp điều kiện, nhưng lựa chọn kết hợp điều kiện nào để kiểm thử và bỏ qua cũng là vấn đề rất quan trọng. Nếu như bạn không có các kết hợp điều kiện được lựa chọn một cách có hệ thống, một tập tùy ý sẽ được sử dụng và điều này cũng có thể dẫn đến kiểm thử không hiệu quả.

Hướng dẫn sử dụng Bảng quyết định cho việc thiết kế thử nghiệm?

• Nhiệm vụ đầu tiên là xác định một chức năng phù hợp hoặc hệ thống con mà có sự kết hợp của các yếu tố đầu vào. Nên chia chúng thành các tập con và đối ứng với các tập con một lúc. Một khi bạn đã xác định các điều kiện cần phải được kết hợp, sau đó bạn đặt chúng vào một bảng liệt kê tất cả các kết hợp và đánh giá True và False cho mỗi điều kiện.

Chúng ta hãy xem xét một ví dụ về ứng dụng vay tiền, bạn có thể nhập số tiền trả nợ hàng tháng hoặc số năm bạn muốn vay (thời hạn của khoản vay). Nếu bạn nhập vào cả hai, hệ thống sẽ làm cho một sự thỏa hiệp giữa hai nếu họ xung đột. Hai điều kiện là số tiền trả hàng tháng và thời hạn vay, vì vậy ta đặt chúng trong một bảng (xem Bảng 1.1).

Tiếp theo chúng ta sẽ xác định tất cả các kết hợp của hai điều kiện (xem Bảng 1.2). Tính toán bao nhiêu cột là cần thiết trong bảng. Số lượng các cột phụ thuộc vào số lượng các điều kiện và số lượng các lựa chọn thay thế cho mỗi điều kiện. Nếu có hai điều kiện và từng điều kiện có thể là đúng hay sai, bạn cần 4 cột. Nếu có ba điều kiện sẽ có 8 cột và như vậy.

Trong trường hợp này 2^2 = 4 cột.

• Bước tiếp theo chúng ta sẽ xác định được kết quả chính xác cho mỗi sự kết hợp (xem bảng 1.3). Trong ví dụ này, chúng ta có thể nhập vào một hoặc cả hai điều kiện. Mỗi sự kết hợp đôi khi được gọi là một quy luật.

• Tại thời điểm này, có thể nhận ra rằng chúng ta bỏ qua trường hợp nếu khách hàng không nhập thông tin ở một trong hai trường thì sẽ xảy ra điều gì. Bảng quyết định cho thấy sự kết hợp đó đã không được đề cập trong các đặc tả kỹ thuật. Có thể giả định rằng sự kết hợp này sẽ cho kết quả trong một thông báo lỗi, vì vậy cần thêm một hành động (xem Bảng 1.4). Điều này nhấn mạnh ưu điểm của kỹ thuật này để khám phá ra những thiếu sót trong đặc tả kỹ thuật.

• Bây giờ, chúng ta thực hiện sự thay đổi nhỏ trong ví dụ này, khách hàng sẽ không được phép nhập cả hai điều kiện trên. Bây giờ kết quả của bảng sẽ thay đổi, sẽ có một thông báo lỗi nếu cả hai điều kiện được nhập vào (Bảng 1.5):

• Bạn có thể nhận thấy chỉ có một hành động xảy ra đối với mỗi sự kết hợp các điều kiện. Có thể thể hiện điều này một cách khác nhau bằng cách liệt kê các hành động trong một cột của một hàng, như trong Bảng 1.6. Lưu ý, nếu có nhiều hơn một kết quả hành động từ bất kỳ kết hợp nào, thì nên đặt thành hàng riêng biệt hơn là kết hợp chúng thành một hàng.

• Bước cuối cùng là viết testcase cho các trường hợp kết hợp điều kiện từ kết quả của bảng điều kiện bên trên

Bài toán ví dụ Thẻ tín dụng:

Áp dụng giảm giá dành cho khách hàng mở thẻ tín dụng khi đạt các điều kiện sau. Điều kiện đầu tiên nếu khách hàng mới và muốn mở tài khoản thẻ tín dụng sẽ được giảm giá 15% áp dụng cho tất cả các giao dịch mua bán trong ngày hôm nay. Nếu đã là khách hàng và có thẻ loyalty - thẻ thành viên trung thành sẽ được giảm giá 10%. Và nếu khách hàng có phiếu mua hàng thì sẽ được giảm giá 20% (không áp dụng đồng thời với điều kiện giảm giá cho khách hàng mới). Các khoản giảm giá được cộng dồn (nếu áp dụng).

Trong bảng 2.1, các điều kiện và hành động được liệt kê trong cột bên trái. Tất cả các cột khác trong bảng quyết định đều thể hiện cho 1 kết hợp các điều kiện. Có thể chọn để kiểm tra từng quy tắc / kết hợp và nếu không có nhiều quy tắc thì sẽ test hết các trường hợp. Tuy nhiên, nếu số lượng các quy tắc / kết hợp lớn thì chúng ta nên lấy 1 số trường hợp điển hình để thử nghiệm.

Bây giờ chúng ta hãy xem các bảng quyết định cho thẻ tín dụng hiển thị ở trên:

• Lưu ý, trên bảng quyết định dấu X để thể hiện được giảm giá cho hai cột (Điều kiện 1 và 2). Tuy nhiên điều này là vô lý. Bạn không có thể vừa là khách hàng mới và cũng đang có thẻ loyalt card theo các điều kiện nêu trên. Do đó cần có một thông báo lỗi ở trường hợp này.

• Một giả định ở quy tắc 3, sử dụng phiếu giảm giá thì được giảm giá nhiều hơn so với khách hàng mới mở thẻ, giả sử khách hàng chọn 20% thay vì chọn 15%. Như bài toán nêu bên trên thì khách hàng có phiếu giảm giá sẽ không được áp dụng giảm giá đồng thời với điều kiện giảm giá cho khách hàng mới. Giảm giá 20% là một giả định và chúng ta nên kiểm tra giả định này bằng cách xác nhận với người viết ra spec hoặc người sử dụng hệ thống.

• Ở quy tắc 4, có thể áp dụng đồng thời hai điều kiện giảm giá là sử dụng thẻ loyalty và coupon.

• Ở quy tắc 5,6,7 thì chỉ có một loại giảm giá và quy tắc 8 thì không được giảm giá vì không thỏa mãn điều kiện nào.

Bài toán Đóng phí bảo hiểm xe hơi

Xét đặc tả của một hệ thống đóng phí bảo hiểm xe hơi. • Đối với nữ < 65 tuổi, phí bảo hiểm là: 500$ • Đối với nam < 25 tuổi, phí bảo hiểm là: 3000$ • Đối với nam từ 25 đến 64, phí bảo hiểm là: 1000$ • Nếu tuổi từ 65 trở lên, phí bảo hiểm là: 1500$

Bảng quyết định như bên dưới:

Sau khi loại trừ các kết hợp điều kiện không hợp lý (ví dụ như không thể vừa là nam vừa là nữ, không thể < 25 tuổi và >65 tuổi...) thì số cột của bảng sẽ hiển thị như trên hình 3.1.

KẾT LUẬN

Ưu điểm của kỹ thuật này là chúng ta có thể kiểm tra sự kết hợp của các điều kiện mà có thể đã bị lack và không được thử nghiệm và có thể tìm thấy khiếm khuyết. Tuy nhiên nếu có quá nhiều kết hợp các điều kiện, sử dụng kỹ thuật này có thể không khả quan hoặc không hợp lý để kiểm tra từng kết hợp điều kiện. Đừng cho rằng tất cả các kết hợp cần phải được kiểm tra, nên ưu tiên kiểm tra những kết hợp quan trọng nhất. Có đầy đủ các kết hợp điều kiện sẽ giúp chúng ta quyết định được kết hợp điều kiện nào cần kiểm tra và chưa cần kiểm tra ở thời điểm nhất định nào đó.

Bài viết có tham khảo từ nguồn http://istqbexamcertification.com/what-is-decision-table-in-software-testing/