0
Tải bản đầy đủ (.pdf) (77 trang)

Sử dụng mô hình

Một phần của tài liệu KIỂM THỬ PHẦN MỀM TRÊN CƠ SỞ CÁC BIỂU ĐỒ UML (Trang 43 -47 )

Kiểm thử dựa trên trạng thái tập trung vào kiểm tra việc thực thi đúng đắn mô hình trạng thái của các thành phần. Việc thiết kế các trƣờng hợp kiểm thử là dựa trên các trạng thái riêng và sự biến đổi giữa các trạng thái. Trong kiểm thử dựa trên các thành phần và hƣớng đối tƣợng, bất kỳ loại kiểm thử là dựa trên trạng thái hiệu quả khi đối tƣợng hoặc thành phần đƣa ra các trạng thái, thậm trí nếu việc kiểm thử là không giành đƣợc từ mô hình trạng thái. Trong trƣờng hợp này không có các trƣờng hợp kiểm thử, cũng không có khái niệm của trạng thái hoặc biến đổi trạng thái. Nói cách khác tiền điều kiện và hậu điều kiện của mỗi trƣờng hợp kiểm thử phải xem xét hành vi và trạng thái. Binder trình bày một cái nhìn toàn diện về tạo ra trƣờng hợp kiểm thử dựa trên trạng thái, và ông cũng đề xuất sử dụng cái gọi là phƣơng thức báo cáo trạng thái có truy cập và báo cáo hiệu quả thông tin trạng thái bên trong bất cứ khi nào cần. Đây là những căn bản giống nhƣ sự hoạt động thông tin trạng thái đƣợc xác định bởi công nghệ kiểm thử chéo (hoạt động kiểm thử trạng thái). Đoạn văn dƣới đây miêu tả chiến lƣợc thiết kế trƣờng hợp kiểm thử chính hoặc tiêu chí kiểm thử cho kiểm thử dựa trên trạng thái:

Thống kê từng phần: Thống kê từng phần tập trung vào từng phần đặc tả riêng, ví dụ, thống kê tất cả trạng thái, tất cả sự kiện, hoặc tất cả hành động. Những kỹ thuật này không liên quan trực tiếp tới cấu trúc của trạng thái máy thực hiện các hành vi, do đó nó chỉ là hiệu quả tình cờ phát hiện các lỗi của hành vi. Nó có thể thăm tất cả các trạng thái và bỏ qua một vài sự kiện hoặc hành động hoặc tạo ra tất cả các hoạt động mà không thăm tất cả các trạng thái hoặc nhận tất cả các sự kiện.

Thống kê biến đổi: Thống kê biến đổi đầy đủ là giành đƣợc thông qua một bộ kiểm tra nếu mọi sự biến đổi đƣợc xác định trong mô hình trạng thái đƣợc thực hiện ít nhất một lần. Nhƣ một hệ quả, nó bảo gồm tất cả trạng thái,

36

tất cả sự kiện, tất cả hành động. Thống kê biến đổi có thể đƣợc cải thiện nếu tuần tự mọi biến đổi đƣợc xác định là đƣợc thực hiện ít nhất một lần; điều này đề cập tới nhƣ thống kê biến đổi n, và nó cũng là một kỹ thuật kiểm thử đƣợc dựa tuần tự các phƣơng pháp.

Thống kê khứ hồi: Thống kê khứ hồi đƣợc xác định qua tuần tự phạm vi của biến đổi đƣợc xác định bắt đầu và kết thúc trong cùng trạng thái. Khứ hồi ngắn nhất là sự biến đổi là vòng lại cùng trạng thái. Một bộ kiểm thử đạt đƣợc thống kê khứ hồi đầy đủ sẽ tiết lộ tất cả không chính xác hoặc cặp sự kiện/ hành động thiếu.

Hình 2.1 cho thấy biểu đồ trạng thái sự đặc tả thành phần của máy bán hàng tự động. Mỗi một số hình tròn trong biểu đồ trạng thái đề cập tới sự biến đổi đơn, xác định trong bảng trạng thái trong Bảng 2.1. Bảng trạng thái này miêu tả sự luôn phiên của biểu đồ trạng thái tập trung vào biến đổi hơn vào trạng thái. Bảng trạng thái không chứa chi tiết tính toán đƣợc xác định bên trong biểu tƣợng trạng thái của biểu đồ trạng thái. Một biểu đồ trạng thái là công cụ tuyệt vời cho miêu tả nhiều sự biến đổi giữa một vài trạng thái và bổ sung cực kỳ hữu ích cho định nghĩa trƣờng hợp kiểm thử. Một trƣờng hợp kiểm thử bao gồm một tiền điều kiện, một biểu thức điều kiện nên đúng trƣớc khi sự kiện kiểm thử đƣợc thực hiện, một sự kiện, hoặc tuần tự sự kiện, và hậu điều kiện nên đúng sau khi sự kiện đƣợc thực hiện. Tiền điều kiện và hậu điều kiện tạo nên một số các biểu thức điều kiện đề cập đến giá trị tham số đầu vào của sự kiện cũng nhƣ thuộc tính bên trong của đối tƣợng trƣớc và sau khi sự kiện thực hiện. Đôi khi chúng cũng bao gồm các hành động đƣợc thực hiện trên các đối tƣợng khác có liên quan, đó là, nếu chúng thay đổi hiện quả trạng thái của đối tƣợng khác. Chúng có thể gọi đây là kết quả của sự kiện. Sự kết hợp của các thuộc tính bên trong của đối tƣợng là trạng thái bên trong của nó. Một trạng thái bên trong là bất kỳ sự kết hợp tùy ý các thuộc tính của đối

tƣợng. Đôi khi điều này cũng đề cập tới nhƣ trạng thái máy hay trạng thái vật lý. Trong phát triển hệ thống chúng ta thƣờng chỉ quan tâm phạm vi giá trị của việc kết hợp thuộc tính gây ra đối tƣợng để đƣa ra các hành vi khác nhau. Phạm vi giá trị miêu tả trạng thái có thể nhìn thấy hay logic.

Hình 2.1. Biểu đồ trạng thái sự đặc tả thành phần của máy bán hàng tự động

Một bảng trạng thái cho thấy các trạng thái logic từ biểu đồ trạng thái tƣơng ứng nhƣ một phần của tiền điều kiện phải đƣợc thực hiện trƣớc khi một biến đổi trạng thái có thể xẩy ra. Nó cho thấy các trạng thái cuối nhƣ là một phần của hậu điều kiện mà nên giữ sau khi biến đổi, và sự kiện kích hoạt sự biến đổi. Tất cả các items này đến dƣới các hình thức mà chúng ta có thể dễ dàng biến đổi thành trƣờng hợp kiểm thử. Trong thực tế tất cả các mục trong bảng 2.1 miêu tả các kiểm thử dẫn đến thống kê biến đổi của mô hình trạng thái.

Các kiểm thử, tuy nhiên là tất cả trừu tƣợng, bởi vì chúng không xác định giá trị rõ cho các biến trong bảng trạng thái. Khi chúng ta có nhiều thông tin hơn về số lƣợng các items mà các máy bán hàng tự động sẽ bán, giá của chúng, và các loại tiền sẽ đƣợc chấp nhận bởi máy, chúng ta có thể bằng ví dụ

38

mỗi kiểm thử trừu tƣợng và thay thế nó bằng một số trƣờng hợp kiểm thử cụ thể với các giá trị đầu vào thực. Mỗi trƣờng hợp kiểm thử trừu tƣợng trong bảng 2.1 có thể là đƣa ra ví dụ phù hợp với các quyết định này. Kiểm thử này vẫn là trừu tƣợng, vì chúng ta không thể thực hiện chúng. Nhƣng chúng phải thêm nhiều cụ thể hơn kiểm thử trừu tƣợng trong bảng 2.1. Chúng ta có thể thêm nhiều thông tin cụ thể để thực hiện cài đặt cụ thể của các trƣờng hợp kiểm thử này.

Bảng 2.1. Bảng biến đổi trạng thái nhận được đặc tả biểu đồ trạng thái

No1 Initial State Precondition Transition Postcondition Final State 1 Idle [!EmptyItem] SelectItem

(Item)

Display(Item.Price) Idle

2 Idle [EmptyItem] SelectItem (Item) Display(Empty) Idle 3 Idle InsertCoin (Coin) Display(Amount) Coins Inserted 4 Coins Inserted

abort Return Inserted Coins Idle 5 Coins

Inserted

Timeout Dispense Inserted Coins Idle 6 Coins Inserted InsertCoin (Coin) Display(Amount) Coins Inserted 7 Coins Inserted [Amount < Item.Price] SelectItem (Item) Display(Amount) Coins Inserted 8 Coins Inserted [EmptyItem] SelectItem (Item) Display Empty; Dispense Change Idle 9 Coins Inserted [Amount < Item.Price] SelectItem (Item) Dispense Item; Dispense Change Idle 10 Coins Inserted [Amount < Item.Price] SelectItem (Item)

Dispense Item Idle

Ví dụ, chúng ta không bắt đầu bất kỳ việc đánh giá nào về các mục, hoặc chúng không xác định đƣợc thời gian mà chúng ta phải đợi trƣớc khi xuất hiện trạng thái đợi trong trƣờng hợp 5.2. Đây là phần đặc tả để quyết định trong quá trình xác định và phát triển của máy bán hàng. Vì vậy trong cùng

một cách trong đó chúng ta loại bỏ trừu tƣợng của hệ thống chúng ta song song loại bỏ trừu tƣợng của hệ thống kiểm thử và di chuyển về phía biểu diễn cứng nhắc của phần mềm kiểm thử.

Một phần của tài liệu KIỂM THỬ PHẦN MỀM TRÊN CƠ SỞ CÁC BIỂU ĐỒ UML (Trang 43 -47 )

×