PHƯƠNG PHÁP SINH tự ĐỘNG các CA KIỂM THỬ từ đặc tả CA sử DỤNG

ĐẠI HỌC QUỐC GIA HÀ NỘI TRƢỜNG ĐẠI HỌC CÔNG NGHỆ PHÙNG THỊ HƢƠNG PHƢƠNG PHÁP SINH TỰ ĐỘNG CÁC CA KIỂM THỬ TỪ ĐẶC TẢ CA SỬ DỤNG LUẬN VĂN THẠC SĨ KỸ THUẬT PHẦN MỀM Hà Nội - 2021 ĐẠI HỌC QUỐC GIA HÀ NỘI TRƢỜNG ĐẠI HỌC CÔNG NGHỆ PHÙNG THỊ HƢƠNG PHƢƠNG PHÁP SINH TỰ ĐỘNG CÁC CA KIỂM THỬ TỪ ĐẶC TẢ CA SỬ DỤNG Nghành: Kỹ thuật phần mềm Chuyên ngành: Kỹ thuật phần mềm Mã số: 8480103.01 LUẬN VĂN THẠC SĨ KỸ THUẬT PHẦN MỀM CÁN BỘ HƢỚNG DẪN: TS ĐẶNG ĐỨC HẠNH Hà Nội – 2021 LỜI CẢM ƠN Đầu tiên, xin đƣợc gửi lời cảm ơn sâu sắc tới Tiến sĩ Đặng Đức Hạnh – giảng viên môn Công nghệ Phần mềm – ngƣời dành nhiều thời gian công sức suốt năm vừa qua để hƣớng dẫn tơi hồn thành luận văn Thầy giúp từ bƣớc đầu tiên, từ việc lựa chọn đề tài phù hợp với đến chia sẻ phƣơng pháp nghiên cứu, kinh nghiệm làm việc, giao tiếp, kĩ cần thiết khơng luận văn mà sống, nghiệp tƣơng lai Tôi xin đƣợc cảm ơn hỗ trợ đề tài nghiên cứu khoa học cấp Đại học Quốc Gia Hà Nội, mã số QG.20.54 Tôi xin gửi lời cảm ơn chân thành đến thành viên nhóm nghiên cứu hỗ trợ tơi tận tình khoảng thời gian vừa qua Các anh chị em nhóm biểu tình thần đồn kết cao, tƣơng trợ lẫn cơng việc lớn nhỏ, thảo luận, đóng góp ý kiến với vấn đề thành viên Đó chắn kỉ niệm khó quên ngƣời nhóm, đặc biệt với tơi Ngồi ra, tơi xin gửi lời cảm ơn đến thầy cô giảng viên Trƣờng Đại học Công nghệ - Đại học Quốc gia Hà Nội Những kiến thức chuyên môn, nghiệp vụ kĩ mềm mà thầy cô dạy cho suốt khóa học trở thành tảng để tơi phát triển xây dựng luận văn Cuối cùng, tơi xin cảm ơn gia đình, bạn bè ngƣời thân đồng hành sống, cung cấp cho tơi ý chí nghị lực để ln vƣơn lên sống ii LỜI CAM ĐOAN Tôi Phùng Thị Hƣơng, học viên khóa K24, chuyên ngành Kỹ thuật phần mềm thuộc chƣơng trình đào tạo Thạc sĩ Trƣờng Đại học Công nghệ - Đại học Quốc gia Hà Nội Tôi xin cam đoan luận văn “Phƣơng pháp sinh tự động ca kiểm thử từ đặc tả ca sử dụng” Tôi trích dẫn đầy đủ tài liệu tham khảo, cơng trình nghiên cứu liên quan nƣớc quốc tế Ngoại trừ tài liệu tham khảo này, luận văn hồn tồn cơng việc riêng tơi Hà Nội, ngày 16 tháng 12 năm 2021 Học viên Phùng Thị Hƣơng iii MỤC LỤC LỜI CẢM ƠN ii LỜI CAM ĐOAN iii MỤC LỤC iv DANH MỤC CÁC KÝ HIỆU VÀ TỪ VIẾT TẮT vi DANH MỤC CÁC BẢNG vii DANH MỤC CÁC HÌNH VẼ viii CHƢƠNG 1: GIỚI THIỆU CHƢƠNG 2: KIẾN THỨC NỀN TẢNG 2.1 Giới thiệu chƣơng 2.2 Đặc tả yêu cầu đặc tả ca sử dụng 2.2.1 Đặc tả yêu cầu chức phi chức 2.2.2 Đặc tả ca sử dụng 2.3 Kiểm thử dựa mơ hình 2.3.1 Tổng quan kiểm thử dựa mơ hình 2.3.2 Đặc tả ca kiểm thử 2.4 Kỹ nghệ hƣớng mơ hình 10 2.4.1 2.4.2 2.4.3 2.4.4 Chuyển đổi mơ hình 10 Các ràng buộc siêu mơ hình UML/OCL 11 Ngôn ngữ Kermeta 12 Ngôn ngữ lập trình tốn học AMPL 13 2.5 Tổng kết chƣơng 14 CHƢƠNG 3: PHƢƠNG PHÁP SINH TỰ ĐỘNG CÁC CA KIỂM THỬ TỪ ĐẶC TẢ CA SỬ DỤNG 15 3.1 Giới thiệu chƣơng 15 3.2 Tổng quan phƣơng pháp 16 3.3 Đặc tả ca sử dụng 18 3.3.1 3.3.2 3.3.3 3.3.4 Khuôn mẫu RUCM 18 Luật giới hạn sử dụng ngôn ngữ tự nhiên 20 Luật giới hạn sử dụng từ khóa 23 Đặc tả ca sử dụng RUCM 24 3.4 Chuyển đổi đặc tả ca sử dụng sang biểu đồ trạng thái 25 3.4.1 Siêu mơ hình UCMeta 26 3.4.2 Luật chuyển đổi 27 iv 3.5 Phƣơng pháp sinh tự động ca kiểm thử 34 3.5.1 Chuẩn hóa mục tiêu kiểm thử 35 3.5.2 Quy hoạch toán học 36 3.5.2.1 Chuyển đổi biến mơ hình kiểm thử thành biến AMPL 36 3.5.2.2 Chuyển đổi tiền điều kiện chuyển tiếp máy trạng thái sang AMPL 38 3.5.2.3 Chuyển đổi hậu điều kiện chuyển tiếp máy trạng thái sang AMPL 38 3.5.2.4 Thêm ràng buộc có tính liên tục vào mơ hình AMPL 38 3.5.2.5 Chuyển đổi trạng thái bất biến thành ràng buộc AMPL 39 3.5.3 Sinh ca kiểm thử trừu tượng liệu kiểm thử cụ thể 39 3.5.3.1 Phát đường dẫn khả thi 41 3.5.3.2 Sự khởi động nóng 42 3.5.3.3 Phân tích giá trị biên 43 3.5.4 Sinh ca kiểm thử đơn vị 43 3.6 Tổng kết chƣơng 44 CHƢƠNG 4: CÀI ĐẶT VÀ THỰC NGHIỆM 45 4.1 Giới thiệu chƣơng 45 4.2 Công cụ hỗ trợ 45 4.2.1 Giới thiệu công cụ 45 4.2.2 Đánh giá kết 50 4.2.2.1 Tỷ lệ hài lòng mục tiêu kiểm thử 51 4.2.2.2 Độ bao phủ mã nguồn 51 4.2.2.3 Phân tích giá trị biên 52 4.3 Thực nghiệm 53 CHƢƠNG 5: KẾT LUẬN 56 5.1 Các đóng góp luận văn 56 5.2 Hƣớng phát triển 57 TÀI LIỆU THAM KHẢO 58 v DANH MỤC CÁC KÝ HIỆU VÀ TỪ VIẾT TẮT Ký hiệu, Nguyên nghĩa Tiếng Anh Từ viết tắt UCS Use Case Specication RUCM Restricted Use Case Modeling SUT System Under Test MBT Model Based Testing MBD Model Based Design IXIT Implementation eXtra Information for Testing MDE Model Driven Engineering MDD Model Driven Development MDA Model Driven Architecture DFS Depth First Search 10 11 POS M2M 12 M2T 13 IEEE 14 XML 15 UML 16 AMPL 17 OCL 18 19 OMG QVT 20 21 MOF EMOF 22 CMOF STT Ý nghĩa Tiếng Việt Đặc tả ca sử dụng Mơ hình hóa ca sử dụng có giới hạn/bị hạn chế Hệ thống kiểm thử Kiểm thử dựa mơ hình Thiết kế dựa mơ hình Thơng tin bổ sung cho việc triển khai kiểm thử Kỹ thuật hƣớng mơ hình Phát triển hƣớng mơ hình Kiến trúc hƣớng mơ hình Giải thuật tìm kiếm theo chiều sâu Part-Of-Speech Từ loại (trong Tiếng Anh) Model-to-model Chuyển đổi mơ hình sang transformation mơ hình Model-to-text transformation Chuyển đổi mơ hình sang văn Institute of Electrical and Hội kỹ sƣ điện điện tử Electronics Engineers giới eXtensible Markup Ngôn ngữ đánh dấu mở Language rộng Unified Modeling Language Ngơn ngữ mơ hình hóa thống A Mathematical Ngơn ngữ lập trình tốn Programming Language học Object Constraint Language Ngôn ngữ ràng buộc đối tƣợng Object Management Group Tổ chức quản lý đối tƣợng Query/View/Transformation Ngơn ngữ truy vấn/biểu diễn/chuyển đổi mơ hình (của OMG) Meta Object Facility Cơ sở siêu đối tƣợng Essential Meta Object Cơ sở siêu đối tƣợng Facility Complete Meta Object Cơ sở siêu đối tƣợng hoàn Facility chỉnh vi DANH MỤC CÁC BẢNG Bảng 2.1: Đặc tả ca sử dụng “Đăng nhập” phân hệ “Quản lý xác thực ngƣời dùng” Bảng 2.2: Cấu trúc ca kiểm thử Bảng 3.1: Khuôn mẫu RUCM 19 Bảng 3.2: Bộ luật giới hạn RUCM (R1 – R7) 21 Bảng 3.3: Bộ luật giới hạn RUCM (R8 – R16) 22 Bảng 3.4: Bộ luật giới hạn RUCM (R17-R26) 24 Bảng 3.5: Ca sử dụng Disconnect 25 Bảng 3.6: Tóm tắt luật biến đổi 28 Bảng 3.7: Các toán tử đƣợc hỗ trợ việc định nghĩa ràng buộc OCL 36 Bảng 4.1: So sánh ParTeG với công cụ thƣơng mại 50 Bảng 4.2: Tỷ lệ đáp ứng mục tiêu kiểm thử ParTeG 51 Bảng 4.3: Báo cáo độ bao phủ mã nguồn ParTeG 52 Bảng 4.4: Đặc tả toán sử dụng để đánh giá ParTeG 52 Bảng 4.5: Ví dụ đặc tả ca sử dụng theo khuôn mẫu RUCM 53 vii DANH MỤC CÁC HÌNH VẼ Hình 2.1: Phân hệ “Quản lý xác thực ngƣời dùng” Hình 2.2: Cài đặt MBT thơng thƣờng Hình 2.3: Ví dụ quy trình kiểm thử dựa mơ hình Hình 3.1: Qui trình tạo ca kiểm thử từ mơ hình ca sử dụng 16 Hình 3.2: Đoạn trích mã Kermeta để triển khai luật 5.3 30 Hình 3.3: Đoạn trích mã Kermeta để triển khai luật 5.4.2 32 Hình 3.4: Mối quan hệ Include Extend ca sử dụng 33 Hình 3.5: Phân loại cách tiếp cận MBT khác 34 Hình 3.6: Cấu trúc liệu cho việc lƣu trữ liệu 37 Hình 3.7: Mơ tả đƣờng khả thi (infeasible path detection) 42 Hình 3.8: Siêu mơ hình kiểm thử đơn vị 44 Hình 4.1: Cấu trúc đầu vào ParTeG 46 Hình 4.2: Giao diện máy trạng thái ParTeG 46 Hình 4.3 Ví dụ máy trạng thái đƣợc sinh dƣới dạng biểu đồ 47 Hình 4.4: Giao diện sinh ca kiểm thử từ sơ đồ máy trạng thái ParTeG 49 Hình 4.5: Các tính ParTeG 49 Hình 4.6: Biểu đồ máy trạng thái để phân loại tam giác 54 Hình 4.7: Giao diện tạo ca kiểm thử ParTeG 55 Hình 4.8: Các ca kiểm thử đƣợc tạo từ công cụ ParTeG 55 viii CHƢƠNG 1: GIỚI THIỆU Hiện nay, hoạt động kiểm thử nhằm đảm bảo chất lƣợng phần mềm đóng vai trị quan trọng q trình phát triển phần mềm Chính hoạt động kiểm thử định đến tồn phát triển hệ thống phần mềm Đối mặt với vấn đề thực tiễn đặt ra, hệ thống phần mềm ngày gia tăng quy mô nhƣ độ phức tạp nghiệp vụ để thực hoạt động kiểm thử phần mềm hiệu cần tốn nhiều thời gian cơng sức Trong đó, việc sinh ca kiểm thử toán quan trọng nghiên cứu kiểm thử phần mềm Tuy nhiên thiết kế ca kiểm thử thủ công tốn thời gian dễ gặp lỗi Do đó, việc nghiên cứu phƣơng pháp để sinh tự động ca kiểm thử việc tối quan trọng trình sản xuất phần mềm ngày Có nhiều hƣớng tiếp cận việc sinh ca kiểm thử tự động, sinh từ đặc tả yêu cầu phần mềm, từ ca sử dụng, từ mã nguồn Thiết kế ca kiểm thử từ mã nguồn khó tự động đƣợc phần mềm thƣờng nhiều lập trình viên phát triển, lập trình viên có phong cách lập trình khác dẫn đến khơng thống trình xây dựng luật sinh tự động Thiết kế ca kiểm thử từ ca sử dụng hƣớng tiếp cận khả thi nhất, kí hiệu thiết kế ca sử dụng có luật riêng, làm sở cho việc thiết kế đầu vào, đầu kiểm thử, điều giúp giảm đáng kể phần chi phí q trình kiểm thử Ngồi ra, q trình sinh ca kiểm thử từ ca sử dụng giúp kiểm thử viên phát sớm vấn đề thiết kế phần mềm để điều chỉnh kịp thời, giảm thời gian chi phí cho dự án Mơ hình ca sử dụng bao gồm biểu đồ ca sử dụng đặc tả ca sử dụng dạng văn bản, thƣờng đƣợc áp dụng cho yêu cầu cấu trúc tài liệu Đặc tả ca sử dụng thƣờng tài liệu dạng văn tuân theo mẫu ca sử dụng thông thƣờng mô tả ngôn ngữ tự nhiên Tuy nhiên hạn chế ngôn ngữ tự nhiên liên kết lỏng lẻo, ý nghĩa mơ hồ, khó tự động hóa Vì đặc tả ca sử dụng cần hƣớng đến phƣơng pháp đặc tả hình thức mà máy hiểu đƣợc Trong báo cáo, luận văn đề xuất phƣơng pháp tiếp cận mơ hình hóa ca sử dụng ngôn ngữ RUCM (Restricted Use Case Modeling) Mục đích để hạn chế việc ngƣời dùng đặc tả ca sử dụng cách mơ hồ, cải thiện tính dễ hiểu mơ hình ca sử dụng tạo điều kiện phân tích tự động để tạo mơ hình phân tích ban đầu Trong ngơn ngữ mơ hình hóa thống UML (Unified Modeling Language), đƣợc gọi biểu đồ lớp, biểu đồ tƣơng tác, loại biểu đồ ràng buộc khác CHƢƠNG 4: CÀI ĐẶT VÀ THỰC NGHIỆM 4.1 Giới thiệu chƣơng Trong chƣơng này, luận văn trình bày phƣơng pháp sinh tự động ca kiểm thử từ đặc tả ca sử dụng dựa mơ hình Dƣới dạng mơ hình kiểm thử, biểu đồ lớp (class diagrams) biểu đồ trạng thái (state diagrams) đƣợc sử dụng, ràng buộc đƣợc biểu diễn OCL Kỹ thuật đề xuất đƣợc thực thi công cụ ParTeG Công cụ cho thấy kết tốt mặt thời gian thực thi việc sinh ca kiểm thử, tỉ lệ hài lòng mục tiêu kiểm thử, độ bao phủ mã nguồn, việc tạo giá trị biên Kiểm thử dựa mơ hình đối chiếu hệ thống dƣới hệ thống kiểm thử với thông số kĩ thuật tham chiếu dƣới dạng mơ hình Cơng cụ hỗ trợ cho việc kiểm thử dựa mơ hình quan trọng Trong phần này, luận văn trình bày cơng cụ kiểm thử dựa mơ hình, ParTeG Luận văn mô tả cách tiếp cận để sinh tự động ca kiểm thử, nhƣ thuật tốn, cấu trúc liệu siêu mơ hình để xây dựng công cụ 4.2 Công cụ hỗ trợ 4.2.1 Giới thiệu công cụ ParTeG (Partition Test Generator) [16] cơng cụ kiểm thử dựa mơ hình đƣợc phát triển liên tục để triển khai thuật toán thành nguyên mẫu nhƣ chứng khái niệm Đến nay, ParTeG có sẵn dƣới dạng trình cắm thêm miễn phí Eclipse, đƣợc lƣu trữ SourceForge ParTeG dựa trình cắm thêm Eclipse UML 2.0 Nó tự động taọ ca kiểm thử từ máy trạng thái biểu đồ lớp UML đƣợc diễn giải với biểu thức OCL ParTeG hỗ trợ việc tạo kiểm thử cho Junit 3.8, Junit 4.3, Java Mutation Analysis, CppUnit 1.12 Công cụ phát triển hoàn toàn Eclipse chạy tảng Runtime Eclipse Chúng ta cần tạo project bao gồm tệp đầu vào có UML để mơ tả biểu đồ máy trạng thái ca sử dụng Hình 4.1 ví dụ mơ tả cấu trúc đầu vào công cụ ParTeG bao gồm file SortingMachine.uml biểu đồ trạng thái ca sử dụng SortingMachine 45 Hình 4.1: Cấu trúc đầu vào ParTeG Sau tạo tệp đầu vào, ngƣời dùng bắt đầu tạo ca kiểm thử tuân theo cú pháp định nghĩa ParTeG Hình 4.2 biểu diễn biểu đồ máy trạng thái ParTeG Hình 4.2: Giao diện máy trạng thái ParTeG Sau có đầu vào, máy trạng thái đƣợc tạo dƣới dạng biểu đồ bao gồm trạng thái (state) chuyển tiếp (transistion) trạng thái bao gồm kiện kích hoạt chuyển tiếp Hình 4.3 ví dụ giao diện máy trạng thái đƣợc sinh 46 Hình 4.3 Ví dụ máy trạng thái đƣợc sinh dƣới dạng biểu đồ Diễn giải buộc OCL: ParTeG hỗ trợ tập hợp ngôn ngữ ràng buộc đối tƣợng (Object Constraint Language – OCL), ngoại trừ số biểu thức tập hợp Ngƣợc lại với công cụ kiểm thử khác, nhƣ nhà thiết kế kiểm thử thông minh (Smartesting Test Designer), ParTeG tránh đƣợc giả thiết ngữ nghĩa biểu thức OCL khơng rõ ràng Ví dụ, biểu thức x = y hậu điều kiện (post-conditions) phép tốn f() đƣợc hiểu là: (1) Sau thực hàm f(), giá trị y đƣợc gán cho x (2) Sau thực hàm f(), giá trị x đƣợc gán cho y (3) Sau thực hàm f(), hai giá trị x y thay đổi nhƣng chúng ParTeG hỗ trợ loại, xử lý tình giá trị cụ thể biến 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 biến đƣợc phân loại cố định (fixed) thay đổi (changeable) biểu thức tại: giá trị đầu vào, tham số, số, thuộc tính với @pre cố định (chúng thay đổi) – biến không đƣợc đánh dấu @pre thay đổi hậu điều kiện Diễn giải chung biến luật chuyển đổi chung tƣơng ứng cho phép đối phó với bất đẳng thức hậu điều kiện Tiêu chí bao phủ (coverage criteria) phƣơng pháp kiểm thử đƣợc chấp nhận rộng rãi việc đánh giá đo lƣờng chất lƣợng kiểm thử Tiêu chí đƣợc so sánh sử dụng mối quan hệ gộp Tính quan trọng 47 ParTeG khả đá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 luồng điều khiển (controlflow-based) (ví dụ MC/DC) kết hợp với tiêu chí bao phủ dựa ranh giới (boundary-based) (ví dụ Multi-demensional) Từ danh mục (controlflow-based boundary-based), tiêu chí bao phủ đƣợc chọn cho kết hợp Hình 4.5 mơ tả tính mà ParTeG hỗ trợ bao gồm: - Tất trạng thái (all-states) - Tất giao dịch (all-transitions) - Bao phủ đị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 biến thể khác đa chiều (multidimensional): MD(0) với giá trị ranh giới phân vùng MD(1) với giá trị ranh giới cho phạm vi tuyệt đối với giá trị ngẫu nhiên từ phân vùng đầu vào Các ca kiểm thử đƣợc tạo bắt đầu với tiêu chí bao phủ dựa giao tiếp tƣơng ứng với luồng điều khiển Tiêu chí bao phủ đƣợc chuyển đổi thành tập hợp mục tiêu kiểm thử theo mơ hình cụ thể Chẳng hạn, tất trạng thái (all-states) đƣợc chuyển đổi thành mục tiêu kiểm thử (test goals), mục tiêu đƣợc tham chiếu với trạng thái 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 chuỗi chuyển tiếp, tất điều kiện đảm bảo ảnh hƣởng tiền điều kiện/hậu điều kiện hoạt động đƣợc ghi lại – chúng đƣợc chuyển đổi 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 tham số đầu vào tƣơng ứng đƣợc sử dụng để tạo ca kiểm thử Trong suốt trình sinh ca kiểm thử tự động, ca kiểm thử cho mục tiêu kiểm thử bao gồm mục tiêu kiểm thử khác ParTeG hỗ trợ giám sát mục tiêu kiểm thử, tức tất mục tiêu kiểm thử đƣợc đề cập bị loại trừ khỏi việc sinh ca kiểm thử Hình 4.4 mô tả giao diện sinh ca kiểm thử từ biểu đồ máy trạng thái công cụ ParTeG 48 Hình 4.4: Giao diện sinh ca kiểm thử từ sơ đồ máy trạng thái ParTeG Hình 4.5: Các tính ParTeG Phân tích đột biến (mutation analysis) cách tiếp cận phổ biến rộng rãi để đảm bảo khả phát lỗi kiểm thử hệ thống kiểm thử (SUT) Phƣơng pháp tiếp cận dựa việc cấy lỗi quy trình thực thi Tất triển khai bị lỗi đƣợc gọi đột biến (mutants) Các đột biến khác 49 biệt ngữ nghĩa với triển khai ban đầu đƣợc phát triệt tiêu kiểm thử Giả định nhiều đột biến đƣợc phát kiểm thử, điều chứng tỏ khả phát lỗi kiểm thử tốt ParTeG hỗ trợ cách phân tích đột biến: Cách 1, sử dụng tập hợp đột biến đƣợc cung cấp trình kiểm thử cách lựa chọn “Java Mutation Analysis” Trình kiểm thử cung cấp đột biến có lần thực thi kiểm thử Những đột biến đƣợc đƣa vào sƣu tập đột biến theo cách thủ cơng, tự động, phƣơng pháp tùy ý khác Cách 2, ParTeG sử dụng cơng cụ bên ngồi đƣợc gọi Jumble Jumble đo khả phát lỗi kiểm thử JUnit Bạn sử dụng ParTeG kết hợp với Jumble cách chọn tên kiểm thử [SUT_name + “Test”] chọn “JUnit 3.8” cho định dạng đầu 4.2.2 Đánh giá kết Báo cáo nghiên cứu điển hình, thực so sánh ParTeG với Rhapsody ATG Leirios (hiện Smartersting) Test Designer (LTD) đƣợc thể Bảng 4.1 Luận văn sử dụng việc phân tích đột biến nhƣ tiêu chí đánh giá chất lƣợng kiểm thử Đối với bốn ví dụ liên quan đến thang máy chở hàng, 24 đột biến đƣợc tạo Bảng 4.1 thể kết cho ví dụ tƣơng đối đơn giản này, thấy ParTeG có khả phát đƣợc tất đột biến Chúng thấy hỗ trợ đồng thời việc kết hợp tiêu bao phủ có ảnh hƣởng lớn đến chất lƣợng kiểm thử đƣợc sinh Chẳng hạn, LTD hỗ trợ thỏa mãn tất chuyển tiếp (alltransitions) ParTeG đảm bảo tập hợp tiêu chí bao phủ kết hợp Bảng 4.1: So sánh ParTeG với công cụ thƣơng mại Công cụ Các ca kiểm thử Các đột biến đƣợc phát Rhapsody ATG 10/24 LTD 10/24 ParTeG 24/24 Việc so sánh với cơng cụ khác dựa phiên có sẵn công cụ Để xác thực kết cũ, việc so sánh với phiên cần thiết 50 4.2.2.1 Tỷ lệ hài lòng mục tiêu kiểm thử Tỷ lệ hài lòng mục tiêu kiểm thử đƣợc tính tốn cho cơng cụ ParTeG, nhƣ cho vấn đề tiêu chí phạm vi Đánh giá phản ánh sức mạnh thuật toán tạo ca kiểm thử trừu tƣợng, thuật toán đƣợc đề xuất để chuyển đổi toán tạo ca kiểm thử thành toán toán học sử dụng giải để giải vấn đề toán học tạo Bảng 4.2: Tỷ lệ đáp ứng mục tiêu kiểm thử ParTeG Tỷ lệ thỏa mãn mục tiêu kiểm thử ParTeG Bộ giải Bài toán Triangle Classifier Without Boolean LpSolve Operations Minos Triangle Classifier With Operations AllStates AllTransitions 12,5% 7,14% Boolean GeCoDE 100% 90,90% JaCoP Tỷ lệ hài lòng mục tiêu kiểm thử tất nghiên cứu điển hình đƣợc trình bày Bảng 4.2 Sử dụng hai giải để giải toán Đối với toán đầu tiên, sử dụng công cụ Parteg với giải LpSolve Minos Kết đánh giá 12,5% 7,14% cho hai tiêu chí mức độ phù hợp All-States All-Transitions Đối với toán thứ hai, Parteg đƣợc sử dụng để tạo ca kiểm thử giải đƣợc chọn GeCoDE, tất mục tiêu kiểm thử đƣợc tạo All-States All-Transitions, đƣợc thỏa mãn (nghĩa kết 100%) Tuy nhiên, sử dụng tiêu chí bao phủ phù hợp cho All-States All-Transitions cho Parteg với giải JaCoP 90,90% 4.2.2.2 Độ bao phủ mã nguồn Sau ca kiểm thử đƣợc tạo, chúng đƣợc chạy dựa mã nguồn bao phủ hƣớng dẫn mã nguồn đƣợc tính cơng cụ “EclEmma” Kết cho “Mức độ bao phủ mã nguồn” đƣợc trình bày Bảng 4.3 51 Bảng 4.3: Báo cáo độ bao phủ mã nguồn ParTeG ParTeG Bài toán All-States All-Transitions Triangle Without Operations Classifier 15/110 = 13,6% Boolean 83/110 = 75,5% Triangle Classifier With 138/138 = 100% Boolean Operations 138/138 = 100% Mã nguồn tốn đầu tiên, bao gồm 110 dịng lệnh Khi ca kiểm thử đƣợc tạo ParTeG với tiêu chí mức độ phù hợp với All-States đƣợc chạy dựa mã nguồn, 15/110 dòng lệnh đƣợc đề cập (mức độ phù hợp 13,6%) Giá trị tiêu chí sử dụng ParTeG với tiêu chí All-States Khi tiêu chí phạm vi bao phủ All-Transitions đƣợc sử dụng để tạo ca kiểm thử cho vấn đề đầu tiên, 83/110 dòng lệnh đƣợc đề cập cách sử dụng ParTeG (75,5%) Mã nguồn toán thứ hai, bao gồm 138 dịng lệnh Đối với hai tiêu chí phù hợp sử dụng công cụ, ca kiểm thử đƣợc tạo bao gồm tất dòng lệnh mã nguồn 4.2.2.3 Phân tích giá trị biên Phân tích giá trị biên đƣợc thực để tạo liệu biên Nếu tất ràng buộc mô hình tuyến tính, việc sử dụng giải tuyến tính tạo liệu kiểm tra biên Tuy nhiên, ràng buộc mơ hình phi tuyến tính, việc sử dụng hàm mục tiêu thích hợp tạo liệu kiểm thử biên Bảng 4.4: Đặc tả toán sử dụng để đánh giá ParTeG Bài toán Tuyến Quyết Số Số Loại Độ Kiểu tính định trạng chuyển phức liệu thái tiếp toán tạp Triangle Classifier Without Boolean Operations Yes Yes 17 30 ILP NPHard Integer Triangle Classifier With Boolean Operations Yes Yes 10 12 SMT NPHard Integer 52 4.3 Thực nghiệm Bảng 4.5 đặc tả ca sử dụng toán phân loại tam giác theo khn mẫu RUCM Bảng 4.5: Ví dụ đặc tả ca sử dụng theo khuôn mẫu RUCM Use Case Name Triangle Classification Brief Description The system checks the lengths of the sides of a triangle to classify them Precondition None Primary Actor None Secondary Actors None Dependency None Generalization None Basic Flow Steps The system have the lengths of the three sides of the triangle are x, y, x The system VALIDATES THAT the lengths of the sides of a triangle is valid IF [(x0 THEN IF [(x=y) or (x=z) or (y=z)] THEN Triangle Classification is isosceles IF [(x=y) and (y=z)] THEN Triangle Classification is equilateral Specific ENDIF ENDIF 10 ENDIF Postcondition None RFS 53 Alternative Flows ELSE Triangle Classification is illegal ENDIF Postcondition None Specific RFS Alternative Flows ELSE Triangle Classification is scalene ENDIF Postcondition None Từ mơ hình ca sử dụng đƣợc mô tả khuôn mẫu RUCM, biểu đồ máy trạng thái đƣợc sinh nhờ công cụ aToucan [10] Cần đảm bảo việc đặc tả ca sử dụng phải tuân theo 26 luật RUCM nhƣ trình bày chi tiết Chƣơng (Mục 3.3) q trình mơ hình hóa ca sử dụng thực tự động đƣợc Hình 4.6 biểu đồ máy trạng thái toán phân loại dạng tam giác (tam giác thƣờng, tam giác cân, tam giác đều) Hình 4.6: Biểu đồ máy trạng thái để phân loại tam giác Sau có đầu vào máy trạng thái, ca kiểm thử đƣợc sinh cách sử dụng giao diện ParTeG để khởi tạo nhƣ thể Hình 4.7 54 Hình 4.7: Giao diện tạo ca kiểm thử ParTeG Hình 4.8 giao diện ca kiểm thử đƣợc sinh sau thực chạy sinh tự động từ cơng cụ ParTeG Hình 4.8: Các ca kiểm thử đƣợc tạo từ công cụ ParTeG 55 CHƢƠNG 5: KẾT LUẬN 5.1 Các đóng góp luận văn Kiểm thử đƣợc xem giải pháp chủ yếu nhằm đảm bảo chất lƣợng cho sản phẩm phần mềm Tuy nhiên, hoạt động kiểm thử chủ yếu đƣợc thực cách thủ công tiêu tốn khoảng 30-50% tài nguyên (thời gian, nhân lực chi phí) q trình phát triển sản phẩm phần mềm Thêm vào đó, cách thực thủ cơng cịn dễ gặp lỗi, đặc biệt độ phức tạp phần mềm ngày tăng quy mô nhƣ nghiệp vụ Trong môi trƣờng cạnh tranh nhƣ địi hỏi cơng ty phần mềm phải áp dụng phƣơng pháp công cụ nhằm tự động hóa hoạt động kiểm thử Vì thế, luận văn thực nghiên cứu cài đặt công cụ hỗ trợ nhằm giải vấn đề Luận văn đạt đƣợc kết sau: - Thứ nhất, luận văn trình bày đầy đủ kiến thức sở liên quan đến vấn đề nội dung nghiên cứu bao gồm kiến thức đặc tả yêu cầu phần mềm, đặc tả ca sử dụng; kỹ thuật kiểm thử dựa mơ hình, kỹ thuật chuyển đổi mơ hình; ngơn ngữ hỗ trợ việc sinh tự động ca kiểm thử từ đặc tả ca sử dụng Chi tiết đƣợc trình bày Chƣơng luận văn - Thứ hai, luận văn nghiên cứu đề xuất sử dụng ngôn ngữ RUCM để đặc tả ca sử dụng giúp đặc tả ca sử dụng đƣợc rõ ràng, dễ hiểu sử dụng tự động hóa Luận văn diễn giải chi tiết luật chuyển đổi đặc tả ca sử dụng biểu đồ UML, đầu vào nhiều công cụ hỗ trợ sinh tự động kiểm thử phát triển tƣơng lai Nội dung đƣợc đƣa Chƣơng luận văn - Thứ ba, luận văn trình bày phƣơng pháp sinh tự động ca kiểm thử từ biểu đồ trạng thái (state diagram) Đây dạng biểu đồ UML, mơ tả trạng thái có chuyển đổi trạng thái có kiện tác động đối tƣợng Đối với đối tƣợng có nhiều trạng thái biểu đồ trạng thái lựa chọn tốt giúp hiểu rõ hệ thống Đó lý mà luận văn sử dụng biểu đồ trạng thái làm đầu vào cho việc sinh tự động ca kiểm thử Luận văn đề xuất sử dụng công cụ ParTeG để thực hoạt động Cũng Chƣơng 3, luận văn trình bày nội dung với đầy đủ bƣớc chuyển quan trọng 56 - Thứ tƣ, luận văn trình bày quy trình cài đặt cơng cụ hỗ trợ, ParTeG công cụ mà luận văn lựa chọn báo cáo Luận văn tiến hành thực nghiệm với toán thực tế phát triển mã nguồn nhằm mục đích hỗ trợ chạy liệu kiểm thử đƣợc sinh từ cơng cụ Ngồi ra, luận văn đƣa ƣu điểm, nhƣợc điểm công cụ ParTeG đƣa đánh giá chất lƣợng liệu kiểm thử sinh so với nhiều công cụ hỗ trợ tƣơng tự khác nhiều tiêu chí, báo cáo thực nghiệm đƣợc trình bày Chƣơng 5.2 Hƣớng phát triển Luận văn tiếp tục cung cấp quy trình kiểm thử hồn chỉnh từ việc tạo mơ hình kiểm thử (sử dụng trình cắm thêm UML trình chỉnh sửa TopCased) tới việc sinh kiểm thử cách kết hợp tiêu chí bao phủ việc thực kiểm thử Trạng thái tại, ParTeG hỗ trợ tự động tạo phân vùng đầu vào nhiều tham số đầu vào tƣơng tác, số chiến lƣợc tìm kiếm khác nhau, độ ƣu tiên mục tiêu kiểm thử, điều chỉnh mơ hình kiểm thử dẫn xuất máy trạng thái với mối quan hệ kế thừa lớp Một so sánh ngắn ParTeG với công cụ thƣơng mại khác thể ParTeG phát nhiều đột biến hẳn ParTeG có kế hoạch mở rộng cách tiếp cận triển khai tƣơng lai Ví dụ, tạo kiểm thử đƣợc hỗ trợ cho mơ hình khác nhƣ kết hợp mô hình đƣợc tích hợp (biểu đồ lớp, máy trạng thái) với biểu đồ tƣơng tác Luận văn có kế hoạch nghiên cứu thêm số dạng khác liệu kiểm thử đƣợc sinh Trong tƣơng lai, ngƣời dùng tự định nghĩa đƣợc định dạng ca kiểm thử dựa ngôn ngữ lập trình Siêu mơ hình đƣợc đề xuất để tạo ca kiểm thử đƣợc sử dụng cho mục đích Luận văn xem xét số phần phép toán biểu thức OCL, thêm phép tốn biểu thức OCL khác vào phƣơng pháp đƣợc đề xuất Ví dụ, luận văn đề cập đến biểu thức tập hợp Một ý tƣởng khác xem xét số hoạt động chức AMPL không tồn OCL Nhƣng luận văn cần phải xem xét chúng ràng buộc phân tích cú pháp tạo cú pháp trừu tƣợng Cuối cùng, luận văn dự định xem xét biểu đồ trạng thái song song nhƣ trạng thái lịch sử để mơ hình hóa hành vi động hệ thống 57 TÀI LIỆU THAM KHẢO [1] IEEE (2011), Systems and software engineering – Life cycle processes Requirements engineering, ISO/IEC/IEEE [2] Ivar Jacobson Object-Oriented Software Engineering: A Use Case Driven Approach Addison Wesley Longman Publishing Co., Inc., 2004 [3] Alistair Cockburn Writing Effective Use Cases Addison-Wesley Professional, Boston, edition edition, October 2000 [4] Mark Utting and Bruno Legeard Practical Model-Based Testing: A Tools Approach Morgan Kaufmann Publishers Inc., San Francisco, CA, USA, 2007 ISBN 978-0-12-372501-1 978-0-08-046648-4 [5] Chu Thi Minh Hue, Dang Duc Hanh, Nguyen Ngoc Binh and Le Minh Duc 2018, “USL: Domain-Specific Language for Precise Specification of Use Cases and Its Tranformations”, Informatica, volume 42, pp 325–343 [6] Kermeta: Kermeta metaprogramming environment Vol 2010 Triskell team [7] Robert Fourer, David M Gay and Brian W Kernighan, A Modeling Language for Mathematical Programming." Management Science 36 (1990) 519-554 [8] B Selic, “The pragmatics of model-driven development,” Software, IEEE, vol 20, no 5, pp 19–25, 2003 [9] Chu Thi Minh Hue, Dang Duc Hanh, Nguyen Ngoc Binh and Truong Anh Hoang (2019), “USLTG: Test Case Automatic Generation by Transforming Use Cases”, Int Journal of Software Engineering and Knowledge Engineering, volumne 29, pp 1313–1345 [10] Yue, T., Briand, L.C., Labiche, Y.: Automatically Deriving a UML Analysis Model from a Use Case Model Simula Research Laboratory, Technical Report 2010-15 (2010) [11] Benoit Combemale, Robert B France, Jean-Marc Jézéquel, Bernhard Rumpe RWTH Aachen, Jim Steel, Didier Vojtisek, 2017, Engineering Modeling Languages-Turning Domain Knowledge into Tools, Taylor & Francis Group, LLC 58 [12] F Kurth, “Automated Generation of Unit Tests from UML Activity Diagrams using the AMPL Interface for Constraint Solvers,” Master’s thesis, Hamburg University of Technology, Germany, Hamburg, jan 2014.31 [13] Tao Yue, Lionel C Briand, and Yvan Labiche Facilitating the Transition from Use Case Models to Analysis Models: Approach and Experiments ACM Trans Softw Eng Methodol., 22(1):5:1–5:38, March 2013 ISSN 1049-331X URL http://doi.acm.org/10.1145/2430536.2430539 [14] Shafique, M., Labiche, Y.: A Systematic Review of Model Based Testing Tool Support Carleton University, Technical Report SCE-10-04 [15] M Utting, A Pretschner, and B Legeard, “A taxonomy of model-based testing approaches,” Software Testing, Verification and Reliability, vol 22, no 5, pp 297–312, 2012 [16] Stephan Weißleder ParTeG http://parteg.sourceforge.net 59 (Partition Test Generator) ... đƣợc sử dụng việc sinh biểu đồ trạng thái từ ca sử dụng ngơn ngữ lập trình tốn học AMPL đƣợc sử dụng việc sinh ca kiểm thử từ biểu đồ trạng thái 2.2 Đặc tả yêu cầu đặc tả ca sử dụng Đặc tả yêu... trợ cho việc sinh tự động ca kiểm thử từ đặc tả ca sử dụng - Thứ hai, luận văn đề xuất phƣơng pháp tiếp cận mơ hình hóa ca sử dụng khn mẫu RUCM để giảm mơ hồ việc đặc tả ca sử dụng, đặc biệt dùng... ngày Có nhiều hƣớng tiếp cận việc sinh ca kiểm thử tự động, sinh từ đặc tả yêu cầu phần mềm, từ ca sử dụng, từ mã nguồn Thiết kế ca kiểm thử từ mã nguồn khó tự động đƣợc phần mềm thƣờng nhiều