Sử dụng Decision Table technique để viết Test Case cho các ứng dụng kinh doanh phức tạp (part 1)

I. Giới thiệu

Có nhiều kỹ thuật và phương pháp để thiết kế các test case. Trong mục này, chúng ta sẽ tìm hiểu cách sử dụng kỹ thuật bảng quyết định - Decision Table technique hiệu quả để viết test case cho ứng dụng với logic kinh doanh phức tạp.

Sau đây là ví dụ:

Chúng ta đều biết rằng các giá trị và quy định, quy tắc công thức kinh doanh đều là các yêu cầu được đưa ra từ phía các khách hàng. Trong khi xem xét, phân tích các nguyên tắc, giá trị kinh doanh trên thành phân tích hệ thống (sofware system) là do đội ngũ phân tích thiết kế hệ thống thực hiện. Từ đó, chúng ta có thể tiếp cận tới các yêu cầu của khách hàng theo góc độ của người lập trình, người kiểm thử... Khi đó các phân tích yêu cầu sẽ được đưa thành các sơ đồ (diagram) logic phù hợp với 1 hệ thống phần mềm hơn.

Sơ đồ dòng chảy logic cho 1 yêu cầu phức tạp bao gồm nhiều nhánh, các nút và các hộp quyết định. Hy vọng, các testers chúng ta được kỳ vọng để hiểu hết các nhánh này và chạm vào mọi ngóc ngách của một cây logic phức tạp như vậy. Tôi cũng đã từng phải đối mặt với 1 follow kinh doanh phức tạp như vậy và đã thử rất nhiều kỹ thuật chuẩn bị test case để làm cho quá trình trở nên dễ dàng tiếp cận hơn.

Cuối cùng, tôi quyết định sử dụng kỹ thuật test bảng quyết định và tôi thấy nó rất có hiệu quả trong trường hợp này. Đây là cách giúp cho việc chuẩn bị kịch bản test logic kinh doanh phức tạp trở nên dễ dàng hơn.

Ví dụ: Sử dụng bảng quyết định để viết test case cho business requirement của 1 màn hình login

**Những điểm nên nhớ: **

• Toàn bộ các giá trị được ghi trong hộp quyết định nên được ghi trong các cột của bảng
• Toàn bộ kết quả ( đầu ra) dc gợi ý trong sơ đồ dòng chảy nên dc bao hàm trong bảng quyết định.
• Toàn bộ những kết hợp của đầu vào cần có được 1 kết quả chắc chắn sẽ được ghi nhận trong cột những kết hợp và có thể dc cho vào trong khi viết test case.
• Sau khi hoàn thành xong bảng quyết định cần kiểm tra lại xem có nhánh nào và đầu ra nào đã được cover.

1. Ưu điểm:

• Bất cứ dòng chảy kinh doanh phức tạp nào đều dc trình bày dưới dạng sơ đồ có thể dễ dàng dc cover trong kỹ thuật này.
• Nó cung cấp sựu tin cậy nhanh chóng trên các test case. Nó không cần nhiều thời gian để xem lại xem các case đó có chính xác không
• Rất dễ hiểu.Bất kỳ ai cũng có thể làm dc 1 test case dựa trên mẫu bảng quyết định.
• Làm việc lại trên các test case và các kịch bản test có thể hoàn toàn tránh dc khi nó nó đã hoàn toàn dc bao gồm trong lần đầu thực hiện.

2. Giới hạn:

• Kỹ thuật chuẩn bị test case giống như phân tích giá trị Boundary, phần tương đương (equivalence partitioning) không liên quan trực tiếp trong mẫu này.Tuy nhiên, nó có thể được note ở dưới của cột những kết hợp và sẽ dc sử dụng trong khi viết test case.
• Trước khi giải thích tại sao những kỹ thuật viết test case khác không thể chắc chắn về độ chính xác giống như bàn quyết định, tôi nhắc lại nhanh về kỹ thuật viết test case black box và white box.

II. Other Test Case Design Techniques:

1. Boundary value analysis: là kỹ thuật test phần mềm trong đó các test case dc thiết kế để bao gồm các đại diện của các giá trị boundary trong và ngoài của các mục được đưa ra trước đó.

2. Equivalence partitioning: được gọi là Equivalence Class Partitioning là 1 kỹ thuật test phần mềm được chia ra các điều kiện vào các phần và những dữ liệu đầu vào từ mỗi phần có thể được chọn để test.

3. State transition testing: là kỹ thuật test hộp đen, nó có thể được sử dụng để thiết kế các test case cho 1 hệ thống, nó thâu tóm 1 số hữu hạn của các đơn vị và có thể chuyển từ 1 đơn vị này sang đơn vị khác dựa trên 1 sự kiện đặc biệt.

4. Error Guessing: là 1 kỹ thuật mà các kinh nghiệm của các tester được sử dụng để tìm ra lỗi hoặc 1 phần của ứng dụng với khả năng cao có lỗi. Đây là kỹ thuật skill base mà không có luật lệ nào.

5. Use case testing: trong kỹ thuật này, sử dụng các kịch bản, case được sử dụng để viết các test case. Sự tương tác của người sử dụng và hệ thống được miêu tả trong 1 case sử dụng.

III. Tại sao các kỹ thuật test case cho logic kinh doanh không thể chứng minh được việc sử dụng hiệu quả như bảng quyết định.

1. Boundary value analysis and Equivalence class: được định nghĩa cho 1 hạng các con số và độ dài. Cả 2 kỹ thuật này không thể chắc chán 100% test coverage cho các luật kinh doanh.

2. Việc dự đoán lỗi là dựa vào kinh nghiệm, qua những kinh nghiệm được yêu cầu, nó không thể chứng minh tất cả mọi thứ.

3. Với kỹ thuật state transition testing technique, có thể chắc chắn rằng mọi phần của cây logic đều được cover nhưng nó không gợi ý tài liệu hay sự tạo ra như là bàn quyết định có thể chắc chắn nhứng thứ dc bao hàm.

IV. Kết luận:

Với kỹ thuật test này, nó có thể được thực hiện dựa trên các bước sau để đảm bảo sự hoàn thiện của việc test:

B1: Sử dụng decision table test case design technique  để bao hàm 100% nội dung logic.

B2: Boundary value analysis and Equivalence partitioning cho việc bao hàm các dãy khác nhau của đầu vào.

B3: Các kết hợp và hoán vị cho các dãy giá trị ( mặc dù không phải tất cả các hoán vị đều được yêu cầu)

B4: Dự đoán lỗi( 1 phần từ các lỗi đó có thể dc xác định từ 3 bước trên) với các kinh nghiệm đã gặp.

Với những kết hợp có được cho những kỹ thuật này, tôi hy vọng bạn có thể khám phá hầu hết các kịch bản test cho bất cứ ứng dụng nào.