Các kỹ thuật kiểm thử hộp đen (Phần 2)

3. Decision table

Tại sao lại dùng decision table?

Phân vùng tương đương và Phân tích giá trị biên thường được áp dụng cho một input. Trong trường hợp kết hợp nhiều input trong một chức năng, rất khó để sử dụng Phân vùng tương đương hay Phân tích giá trị biên. Có 2 phương pháp khác nữa có thể áp dụng trong trường hợp này đó là Bảng quyết định (Decision table) và Chuyển đổi trạng thái (State transition)

Bảng quyết định là một cách rất tốt để xử trong trường hợp phải kết hợp nhiều điều kiện (Testing combinations). Testing combination có những khó khăn như là số lượng điều kiện cần kết hợp có thể lớn. Test tất cả điều kiện có thể không thực tế, ta có thể hài lòng với giải pháp chia các điều kiện ra thành các tập con để test. Tuy nhiên việc này cũng không phải là đơn giản. Nếu bạn không có phương pháp chọn các điều kiện một cách hệ thống thì tập con các điều kiện được đưa ra sẽ không hiệu quả.

Mục đích của việc sử dụng Bảng quyết định để chọn ra được những test case hiệu quả. Kĩ thuật này sẽ làm việc hiệu quả hơn khi được dùng chung với Phân vùng tương đương. Bên cạnh Bảng quyết định ta còn có 1 kĩ thuật khác để xử lý khi test các chức năng có sự kết hợp của nhiều điều kiện là Pairwise testing và Orthogonal arrays. Hai phương pháp sẽ không được đề cập trong phạm vi bài viết này nhưng bạn có thể tìm đọc trên mạng hoặc những cuốn sách viết về Software testing.

Sử dụng Bảng quyết định trong quá trình kiểm thử:

• Bước 1: Nhiệm vụ đầu tiên là xác định các chức năng cần sử dụng bảng quyết định để kiểm thử

• Bước 2: Xác định các condition sau đó chia chúng thành các tập con và xử lý với từng tập con một

• Bước 3: Xác định tất cả các sự kêt hợp của True và False. Giả sử ta có 2 điều kiện, mối điều kiện có thể nhận 1 trong 2 giá trị True or False => ta sẽ có 4 sự kết hợp. Nếu ta có 3 điều kiện => có 8 sự kết hợp, 4 điều kiện => 16 sự kết hợp. Số kết hợp được tính bằng lũy thừa của 2 với số mũ là số điều kiện. Điều đó giải thích tại sao cách giải quyết tốt nhất của phương pháp này là dùng với một tập nhỏ các điều kiện ở từng thời điểm test.

Chú ý rằng chỉ có một action Yes ở mỗi cột. Điều này có nghĩa là chỉ có 1 Action/Outcome cho mỗi Rule.Chú ý rằng nếu thấy nhiều hơn 1 action trả về từ một điều kiện thì ta nên trình bày chúng thành các hàng riêng biệt hơn là gộp lại thành một hàng

• Bước 4: Cuối cùng là viết test case để thực thi các rule đã có ở trên.

Trong ví dụ trên ta đã bắt đầu bởi việc xác định điều kiện đầu vào rồi sau đó xác định các đầu ra. Tuy nhiên ta có thể đi theo một cách khác đó là xem xét các đầu ra rồi làm ngược lại để hiểu được nó đã kết hợp các điều kiện đầu vào nào. Cụ thể hơn ta sẽ tìm hiểu ví dụ Credit card worked dưới đây:

Ví dụ Credit card worked :

Nếu bạn có một khách hàng mới mở một tài khoản credit card, bạn sẽ bạn sẽ có 15% lãi suất triết khấu (discount) trong tất cả các hoạt động mua sắm trong ngày hôm nay. Nếu bạn đã là khách hàng trung thành, bạn có 10% lãi suất triết khấu. Nếu bạn có phiếu mua hàng (coupon)(nhưng k phải là khác hàng mới ), bạn được giảm giá 20% trong ngày hôm nay. Từ đặc tả yêu cầu trên ta có các điều kiện sau:

• New customer (15%)

• Loyalty cart (10%)

• Coupon (20%)

Ta có 3 điều kiện => ta có 8 rule cần test. Lập bảng quyết định như sau:

Mỗi sự kết hợp của các điều kiện là một rule. Ta có thể chọn các rule để test hoặc chỉ một số nhỏ các rule. Nếu số lượng rule quá lớn, ta có thể chọn các rule quan trọng để test.

Chú ý rằng chúng ta điền X vào ô mà rule tương ứng ở cột đó không bao giờ có thể xảy ra. Ví dụ như ở cột rule 1 bạn không thể vừa là new customer vừa là loyalty cart được.

Nếu ta áp dụng phương pháp này một cách kĩ càng, ta sẽ test với từng rule trong bảng. Lợi thế của việc này là là có thể test những trường hợp mà đôi khi ta không tiếp cận đến khi sử dụng các phương pháp khác. Tuy nhiên nếu ta có nhiều rule, việc test tất cả các rule là không thể. Nếu bạn đang có những rang buộc về thời gian, tốt hơn là ưu tiên test những rule quan trọng nhất.

Nên có 1 bảng để chỉ ra những combination nào đc chọn để test. Có thể có nhiều đầu ra cho mỗi rule. Trong ví dụ trên ta chỉ có 1 đầu ra là Discount.

Trong ví dụ trên điều kiện ta dùng để test chỉ có 2 giá trị là True và Failse do đó nó được gọi là Binary Condition. Thường thì điều kiện test có thể phức tạp, có thể có 3 hoặc nhiều giá trị hơn.

4. State transtition testing

State transition testing được sử dụng khi một vài mặt của hệ thống được mô tả bằng máy trạng thái. Hiểu một cách đơn giản là hệ thống có thể ở một số lượng (có hạn) các trạng thái và phiên làm việc từ một trạng thái này đến một trạng thái kia được qui định bởi một rule của máy trạng thái. Đây mà mô hình mà ta sẽ dựa vào đó làm cơ sở để kiểm thử. Bất kì hệ thống nào mà bạn có những output khác nhau từ những input giống nhau và việc có được output còn phụ thuộc vào những trạng thái xảy ra trước đố được gọi là "finite sate system" và một hệ thống như vậy sẽ được thể hiện bởi một Sate diagram. Ví dụ:

Nếu bạn muốn rú 100$$từ cây ATM, bạn đưa thẻ vào máy. Sau đó bạn thực hiện đầy đủ các bước mà cây ATM yêu cầu Sau đó bạn thực hiện đầy đủ các bước mà hệ thống yêu cầu, tuy nhiên việc rút tiền lại không thành công (vì số dư trong tài khoản của bạn không đủ để thực hiện rút tiền). Việc rút tiền không thành công là vì tài khoản ngân hàng đã chuyển trạng thái từ đủ đủ để thực hiện rút tiền sang không đủ để thực hiện rút tiền. Sự chuyển đổi trạng thái này là do việc rút tiền của bạn ở lần trước đó. Một sơ đồ trạng thái có thể được trình bày bởi một mô hình dưới cái nhìn của hệ thống, của tài khoản hay của khách hàng.

Một mô hình chuyển đổi trạng thái bao gồm 4 phần sau:

• Các trạng thái (state) mà chương trình có thể có (ví dụ như không đủ số dư, tài khoản hết hạn...)
• Các phiên chuyền đổi (transition) từ một trạng thái này đến trạng thái kia
• Các sự kiện (event) gây ra phiên chuyển đổi (ví dụ như nhập mã PIN, đóng file...)
• Các action là kết quả của phiên chuyển đổi (ví dụ như message báo lỗi, trả lại thẻ ATM...)

Chú ý rằng trong một trạng thái, một sự kiện chỉ có thể gây ra 1 action duy nhất. Tuy nhiên cũng với sự kiện đó nhưng lại xảy ra ở các trạng thái khác nhau thì có thể cho ta các action khác nhau.

Hình 4.2 Cho to một ví dụ về nhập mã PIN ở cây ATM. Các trạng thái được thể hiện ở dạng hình tròn. Các phiên chuyển đổi là các mũi tên. Các event là dòng text cạnh mũi tên:

Từ biểu đồ trạng thái, ta tiến hành tạo test case bắt đầu từ việc xác định các kịch bản (scenario). Kịch bản đầu tiên là với trường hợp normal, khi mà mã PIN được nhập đúng ngay ở lần đầu tiên. Kịch bản thứ 2 là người dùng nhập sai mã PIN ở cả lần 1, lần 2 và lần 3. Tiếp theo là thử nghiệm với từng trạng thái ví dụ như nhập đúng ở lần đầu tiên, sai ở lần thứ 2 hoặc sai ở 2 lần đầu và đúng ở lần thứ 3. Xét về độ ưu tiên thì 2 kịch bản sau sẽ xếp sau bằng 2 kịch bản đầu tiên.

Điều kiện test có thể thu được từ biểu đồ trạng thái bằng nhiều cách. Một trạng thái có thể được nhìn nhận như một test condition hoặc mỗi một phiên chuyển đổi sẽ được nhìn nhận như một test condition. Ngoài ra ta có thể xác định độ bao phủ của tập các trạng thái (xem lại các chương trước về kĩ thuật test hộp trắng). Mức độ bao phủ cho phép ta xác định được mức độ bao phủ đạt được dưới quan điểm test hộp trắng.

Một trong những ưu điểm của chuyển đổi trạng thái là mô hình hóa được tất cả các nghiệp vụ một cách chi tiết hay trừu tượng tùy vào nhu cầu. Nếu phần cần test quan trọng hơn, bạn có thể chi tiết hóa nó sâu hơn và ngược lại nếu phần ít quan trọng hơn, bạn có thể mô tả nó đơn giản vào 1 trạng thái duy nhất thay vì một loạt các trạng thái con.