Decision table Testing là gì
Sử dụng Decision table - Bảng quyết định trong kiểm thử phần mềm
Bài đăng này đã không được cập nhật trong 5 nă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
Hướng dẫn sử dụng Bảng quyết định cho việc thiết kế thử nghiệm?
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à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/ |
