ParTeG (Partition Test Generator) [16] là một công cụ kiểm thử dựa trên mô hình đã đƣợc phát triển liên tục để triển khai các thuật toán mới thành một nguyên mẫu nhƣ một bằng chứng về khái niệm. Đến nay, ParTeG là có sẵn dƣới dạng một trình cắm thêm miễn phí trên Eclipse, đƣợc lƣu trữ bởi SourceForge. ParTeG dựa trên trình cắm thêm Eclipse UML 2.0. Nó tự động taọ ra các ca kiểm thử từ máy trạng thái và biểu đồ lớp UML đƣợc diễn giải với biểu thức OCL. ParTeG hỗ trợ việc tạo bộ kiểm thử cho Junit 3.8, Junit 4.3, Java Mutation Analysis, và CppUnit 1.12.
Công cụ phát triển hoàn toàn trên Eclipse và chạy trên nền tảng Runtime của Eclipse. Chúng ta cần tạo một project bao gồm tệp đầu vào có đuôi UML để mô tả biểu đồ máy trạng thái của ca sử dụng.
Hình 4.1 là một ví dụ mô tả cấu trúc đầu vào của công cụ ParTeG bao gồm file SortingMachine.uml chính là biểu đồ trạng thái của ca sử dụng SortingMachine.
46
Hình 4.1: Cấu trúc đầu vào của ParTeG.
Sau khi tạo tệp đầu vào, ngƣời dùng có thể bắt đầu tạo các ca kiểm thử tuân theo cú pháp đã định nghĩa của ParTeG. Hình 4.2 biểu diễn một biểu đồ máy trạng thái trong ParTeG.
Hình 4.2: Giao diện máy trạng thái trong ParTeG.
Sau khi có đầu vào, một máy trạng thái sẽ đƣợc tạo ra dƣới dạng biểu đồ bao gồm các trạng thái (state) và các chuyển tiếp (transistion) giữa các trạng thái bao gồm sự kiện kích hoạt của chuyển tiếp.
47
Hình 4.3. Ví dụ máy trạng thái đƣợc sinh ra dƣới dạng biểu đồ.
Diễn giải các rằng buộc OCL: ParTeG hỗ trợ một tập hợp con của ngôn
ngữ ràng buộc đối tƣợng (Object Constraint Language – OCL), ngoại trừ một số biểu thức của tập hợp. Ngƣợc lại với các công cụ kiểm thử khác, nhƣ một nhà thiết kế kiểm thử thông minh (Smartesting Test Designer), ParTeG tránh đƣợc giả thiết nếu ngữ nghĩa biểu thức OCL không rõ ràng. Ví dụ, biểu thức x = y là hậu điều kiện (post-conditions) của một phép toán f() có thể đƣợc hiểu là:
(1) Sau khi thực hiện hàm f(), giá trị của y đƣợc gán cho x. (2) Sau khi thực hiện hàm f(), giá trị của x đƣợc gán cho y.
(3) Sau khi thực hiện hàm f(), cả hai giá trị x và y đã thay đổi nhƣng bây giờ chúng bằng nhau.
ParTeG hỗ trợ cả 3 loại, do đó nó có thể xử lý các tình huống trong đó giá trị cụ thể của một biến là không xác định. Để buộc phải hiểu theo cách đầu tiên, biểu thức nên đƣợc chuyển đổi thành dạng x = y@pre.
Tất cả các biến đƣợc phân loại là cố định (fixed) hoặc có thể thay đổi (changeable) trong biểu thức hiện tại: các giá trị đầu vào, các tham số, các hằng số, và các thuộc tính với @pre là cố định (chúng không thể thay đổi) – các biến không đƣợc đánh dấu @pre là có thể thay đổi trong hậu điều kiện. Diễn giải chung của các biến và các luật chuyển đổi chung tƣơng ứng cho phép đối phó với cả bất đẳng thức trong hậu điều kiện.
Tiêu chí bao phủ (coverage criteria) là phƣơng pháp kiểm thử đƣợc chấp nhận rộng rãi trong việc đánh giá đo lƣờng chất lƣợng bộ kiểm thử. Tiêu chí này có thể đƣợc so sánh sử dụng các mối quan hệ gộp. Tính năng quan trọng nhất
48
của ParTeG là khả năng đáp ứng tiêu chí bao phủ kết hợp (combine coverage criteria). Chẳng hạn nhƣ tiêu chí bao phủ dựa trên luồng điều khiển (control- flow-based) (ví dụ MC/DC) có thể kết hợp với tiêu chí bao phủ dựa trên ranh giới (boundary-based) (ví dụ Multi-demensional). Từ mỗi danh mục (control- flow-based hoặc boundary-based), một tiêu chí bao phủ có thể đƣợc chọn cho sự kết hợp. Hình 4.5 mô tả các tính năng mà hiện tại ParTeG hỗ trợ bao gồm:
- Tất cả các trạng thái (all-states) - Tất cả các giao dịch (all-transitions) - Bao phủ quyết định (decision coverage)
- Bao phủ điều kiện/quyết định (making MC/DC)
- Bao phủ đa điều kiện (multiple condition coverage) nhƣ việc lựa chọn ngẫu nhiên giá trị đầu vào và các biến thể khác nhau của đa chiều (multi- dimensional): MD(0) với các giá trị ranh giới phân vùng và MD(1) với các giá trị ranh giới cho phạm vi tuyệt đối và với các giá trị ngẫu nhiên từ các phân vùng đầu vào.
Các ca kiểm thử đƣợc tạo ra bắt đầu với tiêu chí bao phủ dựa trên giao tiếp tƣơng ứng với luồng điều khiển. Tiêu chí bao phủ này đƣợc chuyển đổi thành một tập hợp các mục tiêu kiểm thử theo mô hình cụ thể. Chẳng hạn, tất cả trạng thái (all-states) đƣợc chuyển đổi thành các mục tiêu kiểm thử (test goals), mỗi mục tiêu đƣợc tham chiếu với một trạng thái của máy trạng thái. Các mục tiêu kiểm thử đƣợc sử dụng để tạo chuỗi chuyển tiếp từ trạng thái ban đầu đến trạng thái đƣợc tham chiếu. Đối với mỗi chuỗi chuyển tiếp, tất cả điều kiện đảm bảo ảnh hƣởng và tiền điều kiện/hậu điều kiện của các hoạt động đều đƣợc ghi lại – chúng đƣợc chuyển đổi và sử dụng cho việc lựa chọn tham số đầu vào tƣơng ứng với tiêu chí bao phủ ranh giới đƣợc lựa chọn. Các trình tự chuyển tiếp và tham số đầu vào tƣơng ứng đƣợc sử dụng để tạo ra các ca kiểm thử.
Trong suốt quá trình sinh ca kiểm thử tự động, một ca kiểm thử cho một mục tiêu kiểm thử có thể bao gồm các mục tiêu kiểm thử khác. ParTeG hỗ trợ giám sát các mục tiêu kiểm thử, tức là tất cả các mục tiêu kiểm thử đã đƣợc đề cập đều bị loại trừ khỏi việc sinh ca kiểm thử tiếp theo.
Hình 4.4 mô tả giao diện sinh ra ca kiểm thử từ biểu đồ máy trạng thái bằng công cụ ParTeG.
49
Hình 4.4: Giao diện sinh ca kiểm thử từ sơ đồ máy trạng thái bằng ParTeG.
Hình 4.5: Các tính năng của ParTeG.
Phân tích đột biến (mutation analysis) là cách tiếp cận phổ biến rộng rãi
để đảm bảo khả năng phát hiện lỗi của bộ kiểm thử trong hệ thống kiểm thử (SUT). Phƣơng pháp tiếp cận này dựa trên việc cấy lỗi trong quy trình thực thi. Tất cả các triển khai bị lỗi đƣợc gọi là các đột biến (mutants). Các đột biến khác
50
biệt về ngữ nghĩa với triển khai ban đầu có thể đƣợc phát hiện và triệt tiêu bởi bộ kiểm thử. Giả định là càng nhiều đột biến đƣợc phát hiện bởi bộ kiểm thử, điều này chứng tỏ khả năng phát hiện lỗi của bộ kiểm thử là rất tốt.
ParTeG hỗ trợ 2 cách phân tích đột biến:
Cách 1, nó có thể sử dụng một tập hợp các đột biến đƣợc cung cấp bởi trình kiểm thử bằng cách lựa chọn “Java Mutation Analysis”. Trình kiểm thử sẽ cung cấp đột biến mới nếu có của mỗi lần thực thi kiểm thử. Những đột biến này có thể đƣợc đƣa vào bộ sƣu tập đột biến theo cách thủ công, hoặc tự động, hoặc bất kì phƣơng pháp tùy ý nào khác.
Cách 2, ParTeG sử dụng công cụ bên ngoài đƣợc gọi là Jumble. Jumble đo khả năng phát hiện lỗi của bộ kiểm thử JUnit.
Bạn có thể sử dụng ParTeG kết hợp với Jumble bằng cách chọn tên của bộ kiểm thử [SUT_name + “Test”] và chọn “JUnit 3.8” cho định dạng đầu ra.