DSpace at VNU: Phương pháp sinh dữ liệu kiểm thử tự động từ biểu đồ tuần tự UML, biểu đồ lớp và ràng buộc OCL

DSpace at VNU: Phương pháp sinh dữ liệu kiểm thử tự động từ biểu đồ tuần tự UML, biểu đồ lớp và ràng buộc OCL tài liệu,...

i ĐẠI HỌC QUỐC GIA HÀ NỘI TRƢỜNG ĐẠI HỌC CƠNG NGHỆ NGUYỄN VĂN HỊA PHƢƠNG PHÁP SINH DỮ LIỆU KIỂM THỬ TỰ ĐỘNG TỪ BIỂU ĐỒ TUẦN TỰ UML, BIỂU ĐỒ LỚP VÀ RÀNG BUỘC OCL Ngành: Công nghệ thông tin Chuyên ngành: Kỹ thuật phần mềm Mã số: 60480103 LUẬN VĂN THẠC SĨ KỸ THUẬT PHẦN MỀM CÁN BỘ HƢỚNG DẪN KHOA HỌC: PGS TS PHẠM NGỌC HÙNG HÀ NỘI – 2016 MỤC LỤC LỜI CẢM ƠN Error! Bookmark not defined TÓM TẮT Error! Bookmark not defined ABSTRACT Error! Bookmark not defined LỜI CAM ĐOAN Error! Bookmark not defined MỤC LỤC ii DANH SÁCH BẢNG BIỂU iv DANH SÁCH HÌNH VẼ v BẢNG THUẬT NGỮ VIẾT TẮT vii Chƣơng 1: GIỚI THIỆU Chƣơng 2: CÁC KHÁI NIỆM VÀ TỔNG QUAN KIỂM THỬ DỰA TRÊN MƠ HÌNH 2.1 Tổng quan kiểm thử dựa mơ hình 2.1.1 Khái niệm kiểm thử dựa mơ hình 2.1.2 Quy trình chung kiểm thử dựa mơ hình 2.1.3 Phƣơng pháp đặc tả mô hình máy trạng thái UML 2.1.4 Thuận lợi khó khăn kiểm thử tự động dựa mơ hình 2.2 Biểu đồ khối phân đoạn UML 2.2.1 Biểu đồ 2.2.2 Các phân đoạn sử dụng biểu đồ 2.3 Đồ thị dòng điều khiển Error! Bookmark not defined 2.4 Các độ đo kiểm thử Error! Bookmark not defined Chƣơng 3: PHƢƠNG PHÁP SINH ĐỒ THỊ DÕNG ĐIỀU KHIỂN TỪ BIỂU ĐỒ TUẦN TỰ Error! Bookmark not defined 3.1 Điều kiện ràng buộc thiết kế Error! Bookmark not defined 3.2 Thuật toán biến đổi biểu đồ sang đồ thị dòng điều khiển Error! Bookmark not defined 3.2.1 Thuật tốn sinh đồ thị dòng điều khiển Error! Bookmark not defined 3.2.2 Đồ thị dòng điều khiển tƣơng ứng với phân đoạn Error! Bookmark not defined 3.3 Kỹ thuật sinh kịch kiểm thử Error! Bookmark not defined 3.3.1 Kịch kiểm thử cho tốn từ thơng thƣờng .Error! Bookmark not defined 3.3.2 Kịch kiểm thử cho phân đoạn song song (Par, Seq) Error! Bookmark not defined 3.4 Xây dựng hệ ràng buộc Error! Bookmark not defined 3.5 Giải hệ sử dụng SMT-Solver Error! Bookmark not defined 3.6 Các nghiên cứu liên quan Error! Bookmark not defined Chƣơng 4: CÔNG CỤ VÀ THỰC NGHIỆM Error! Bookmark not defined 4.1 Giới thiệu công cụ môi trƣờng thực nghiệm Error! Bookmark not defined 4.2 Thực nghiệm Error! Bookmark not defined 4.3 Ý nghĩa thực nghiệm Error! Bookmark not defined Chƣơng 5: KẾT LUẬN Error! Bookmark not defined TÀI LIỆU THAM KHẢO 14 DANH SÁCH BẢNG BIỂU Bảng 2.1 Ca kiểm thử độ bao phủ yếu Error! Bookmark not defined Bảng 2.2 Ca kiểm thử độ bao phủ trung bình Error! Bookmark not defined Bảng 2.3 Ca kiểm thử độ bao phủ mạnh Error! Bookmark not defined Bảng 3.1 Các khóa ý nghĩa tệp xmi Error! Bookmark not defined Bảng 3.2 Dữ liệu thu thập tƣơng ứng theo nốt đƣợc nối với Error! Bookmark not defined Bảng 4.1 Môi trƣờng thử nghiệm công cụ sinh ca kiểm thử từ thiết kế Error! Bookmark not defined DANH SÁCH HÌNH VẼ Hình 2.1 Qui trình kiểm thử dựa mơ hình Hình 2.2 Phân đoạn Alt Hình 2.3 Phân đoạn Opt Hình 2.4 Phân đoạn Loop vơ hạn 10 Hình 2.5 Phân đoạn Loop với cận cận dƣới 10 10 Hình 2.6 Phân đoạn Loop với cận 5, cận dƣới 10 10 Hình 2.7 Phân đoạn Break 12 Hình 2.8 Phân đoạn Par 12 Hình 2.9 Phân đoạn Seq 12 Hình 2.10 Phân đoạn Strict 13 Hình 2.11 Phân đoạn Ignore 13 Hình 2.12 Phân đoạn Consider 14 Hình 2.13 Phân đoạn Neg Error! Bookmark not defined Hình 2.14 Phân đoạn Assert Error! Bookmark not defined Hình 2.15 Phân đoạn Critical Error! Bookmark not defined Hình 2.16 Đồ thị dòng điều khiển tƣơng ứng phân đoạn Par Error! Bookmark not defined Hình 3.1 Thiết kế tên thông điệp Error! Bookmark not defined Hình 3.2 Thiết kế ràng buộc Error! Bookmark not defined Hình 3.3 Khai báo biến ràng buộc tƣơng ứng cho lớp Error! Bookmark not defined Hình 3.4 Xóa triệt để đối tƣợng khơng dùng Error! Bookmark not defined Hình 3.5 Đồ thị CFG tƣơng ứng cho phân đoạn Alt Error! Bookmark not defined Hình 3.6 Đồ thị CFG tƣơng ứng cho phân đoạn Opt Error! Bookmark not defined Hình 3.7 Đồ thị CFG tƣơng ứng cho phân đoạn Loop Error! Bookmark not defined Hình 3.8 Đồ thị CFG tƣơng ứng cho phân đoạn Break Error! Bookmark not defined Hình 3.9 Đồ thị CFG tƣơng ứng cho phân đoạn Par Error! Bookmark not defined Hình 3.10 Đồ thị CFG tƣơng ứng cho phân đoạn Seq Error! Bookmark not defined Hình 3.11 Đồ thị CFG tƣơng ứng cho phân đoạn Ignore Error! Bookmark not defined Hình 3.12 Đồ thị CFG tƣơng ứng cho phân đoạn Consider Error! Bookmark not defined Hình 3.13 Đồ thị CFG tƣơng ứng cho phân đoạn Neg Error! Bookmark not defined Hình 3.14 Đồ thị CFG tƣơng ứng cho phân đoạn Assert Error! Bookmark not defined Hình 3.15 Đồ thị CFG tƣơng ứng cho phân đoạn Strict Error! Bookmark not defined Hình 3.16 Ví dụ đồ thị cần duyệt Error! Bookmark not defined Hình 3.17 Đồ thị dòng điều khiển Error! Bookmark not defined Hình 3.18 Ví dụ ràng buộc OCL đƣợc khai báo thiết kế .Error! Bookmark not defined Hình 3.19 Mô tả công cụ SMT Solver Error! Bookmark not defined Hình 4.1 Cấu trúc cơng cụ thực nghiệm Error! Bookmark not defined Hình 4.2 Đầu vào cơng cụ ví dụ Error! Bookmark not defined Hình 4.3 Đầu - đồ thị CFG ví dụ Error! Bookmark not defined Hình 4.4 Đồ thị CFG ca kiểm thử độ bao phủ yếu cho ví dụ .Error! Bookmark not defined Hình 4.5 Ca kiểm thử độ bao phủ yếu cho ví dụ Error! Bookmark not defined Hình 4.6 Ca kiểm thử độ bao phủ trung bình cho ví dụ Error! Bookmark not defined Hình 4.7 Dữ liệu kiểm thử sau xuất tệp MS Excel Error! Bookmark not defined Hình 4.8 Đầu vào ví dụ Error! Bookmark not defined Hình 4.9 Đầu đồ thị CFG cho ví dụ Error! Bookmark not defined Hình 4.10 Ca kiểm thử độ bao phủ yếu cho ví dụ Error! Bookmark not defined Hình 4.11 Ca kiểm thử độ bao phủ trung bình cho ví dụ Error! Bookmark not defined Hình 4.12 Ca kiểm thử độ bao phủ mạnh cho ví dụ Error! Bookmark not defined Hình 4.13 Đƣờng tƣơng ứng ca kiểm thử độ bao phủ mạnh ví dụ Error! Bookmark not defined BẢNG THUẬT NGỮ VIẾT TẮT STT Từ viết tắt Tên đầy đủ Ý nghĩa BN Block Node Nốt đơn CFG Control Flow Graph Đồ thị dòng điều khiển DC Decision Node Nốt định FN IDE JN Fork Node Integrated Development Environment Join Node Nốt rẽ nhánh Môi trƣờng phát triển tích hợp Nốt nối MN Merge Node OCL Object Constraint Language SUT Software Under Testing 10 UML Unified Modeling Language Nốt sáp nhập Ngôn ngữ ràng buộc đối tƣợng Phần mềm đƣợc kiểm thử Ngôn ngữ mơ hình hóa thống Chƣơng 1: GIỚI THIỆU Công nghệ phần mềm ngày phát triển chi phối sống ngƣời Ngƣợc lại, ngƣời không ngừng sáng tạo để tạo công nghệ mới, phần mềm dịch vụ Trong q trình phát triển đó, cần phải có qui trình song song để phát kiểm sốt sai lầm mà ngƣời vơ tình cố tình tạo ra, kiểm thử Theo ƣớc tính, q trình kiểm thử chiếm khoảng 50% thời gian 40% - 60% tổng chi phí tồn q trình phát triển phần mềm [1] Q trình kiểm thử định thành cơng, mức độ đảm bảo dự án phần mềm đặc biệt lĩnh vực đòi hỏi độ xác cao nhƣ hàng không, quân sự, khoa học, vũ trụ Vì vậy, để rút ngắn thời gian phát triển nâng cao chất lƣợng dự án phần mềm, trình sinh ca kiểm thử tự động nâng cao chất lƣợng ca kiểm thử trở nên thực cần thiết, phần mềm lớn phức tạp Kiểm thử tự động đƣợc xem giải pháp nhằm giảm chi phí thời gian mà đảm bảo chất lƣợng trình phát triển phần mềm Để giải vấn đề này, nhiều công trình nghiên cứu đƣợc đề xuất nhằm giải quyết, tối ƣu tự động hóa q trình kiểm thử Mỗi cơng trình nghiên cứu mang lại kết khác áp dụng cho mục đích kiểm thử khác Một số nghiên cứu kể đến nhƣ: phƣơng pháp sinh ca kiểm thử tự động từ biểu đồ UML A.V.K Shanthi G Mohan Kumar [6] Sinh liệu kiểm thử tự động từ biểu đồ UML ràng buộc OCL Ashalatha Nayak Debasis Samanta [4] Sinh ca kiểm thử từ biểu đồ hệ thống chuyển đổi đƣợc gắn nhãn Emanuela G Cartaxo[9] Sinh ca kiểm thử tự động từ biểu đồ UML ràng buộc OCL Li Bao-Lin, Li Zhi-shu, Li Qing Chen Yan Hong [10], v.v Trong số nghiên cứu dừng lại dạng đề xuất, nhiều nghiên cứu khác chƣa giải trọn vẹn toán kiểm thử trực tiếp từ biểu đồ từ phần mềm cụ thể Mỗi phƣơng pháp hƣớng tới mục đích kiểm thử khác Để hiểu rõ vài nghiên cứu đƣợc trình bày chi tiết chƣơng ba luận văn Bài nghiên cứu nàytơi trình bày phƣơng pháp khác sinh ca kiểm thử tự động cải tiến công đoạn sinh ca kiểm thử tự động để nâng cao chất lƣợng kiểm thử.Cũng nhƣ phƣơng pháp kiểm thử dựa mơ hình khác, phƣơng pháp đòi hỏi phải có mơ hình tốn học đặc tả xác hành vi hệ thống có sẵn thực tế Các mơ hình thƣờng đƣợc biểu diễn máy hữu hạn trạng thái đơn định Tuy nhiên, xây dựng mơ hình cho phần mềm cơng việc khó khăn tiềm ẩn nhiều lỗi công ty Thay vào việc phân tích thiết kế dựa biểu đồ UML công việc dễ dàng trở nên phổ biến Do việc kiểm thử tính đắn cho thiết kế dựa mơ hình đƣợc nghiên cứu áp dụng thực tế cho kiểm thử dự án phần mềm Khơng tự động hóa đƣợc qui trình kiểm thử mà thời gian bắt đầu kiểm thử đƣợc tiến hành sớm giúp rút ngắn thời gian phát triển phần mềm Giai đoạn kiểm thử thiết kế (kiểm thử dựa mơ hình) chủ yếu tập trung vào ca kiểm thử đƣợc sinh từ đƣờng kiểm thử dựa đồ thị hoạt động sinh liệu kiểm thử từ liệu đầu vào thiết kế từ đặc tả chƣơng trình.Với mục tiêu kiểm thử phần mềm dựa thiết kế biểu đồ tuần tự, mục tiêu nâng cao chất lƣợng kiểm thử nhƣ khả phát lỗi kịch kiểm thử thiết kế chƣơng trình đƣợc thực thi Nội dung nghiên cứu đƣợc trình bày chƣơng phần kết luận Chƣơng giới thiệu đề tài, lý chọn đề tài, trình bày tổng quan nội dung nghiên cứu bố cục luận văn Chƣơng trình bày khái niệm phục vụ cho đề tài bao gồm vấn đề liên quan kiểm thử dựa mơ hình, phƣơng pháp đặc tả mơ hình máy trạng thái UML Các khái niệm biểu đồ phân đoạn thiết kế Cuối giới thiệu đồ thị dòng điều khiển đề xuất ba độ đo kiểm thử áp dụng cho nghiên cứu Chƣơng nghiên cứu đề xuất cách biến đổi từ biểu đồ sang đồ thị dòng điều khiển thuật tốn biến đổi Phƣơng pháp sinh ca kiểm thử sau hoàn thành độ thị dòng điều khiển chia kịch kiểm thử Một cho phân đoạn thông thƣờng (các phân đoạn không chứa luồng song song) kịch kiểm thử cho phân đoạn chứa luồng song song (Par, Seq).Phần cuối chƣơng 3trình bày phƣơng pháp sinh liệu kiểm thử từ đồ thị dòng điều khiển,một số nghiên cứu liên quan để thấy đƣợc ƣu nhƣợc điểm nghiên cứu so với phƣơng pháp khác Chƣơng giới thiệu công cụ thực nghiệm, ví dụ thể tính đắn khả thi phƣơng pháp đề xuất Kết thu đƣợc thực tế từ chƣơng trình rút ý nghĩa phƣơng pháp đề xuất Cuối kết luận, định hƣớng mở rộng tài liệu tham khảo Chƣơng 2: CÁC KHÁI NIỆM VÀ TỔNG QUAN KIỂM THỬ DỰA TRÊN MƠ HÌNH 2.1 Tổng quan kiểm thử dựa mơ hình Ngày nay, cơng ty phần mềm lớn thƣờng sử dụng ngôn ngữ UML (Unified Modeling Language) để phân tích, thiết kế phần mềm trƣớc vào triển khai Sản phẩm tạo mơ hình thiết kế UML Trong UML có nhiều mơ hình phục vụ cho thiết kế, việc lựa chọn mô hình để thiết kế phụ vào mục đích sử dụng định hƣớng phát triển phần mềm công ty Q trình kiểm thử giai đoạn thiết kế đƣợc gọi kiểm thử dựa mô hình Các mơ hình thiết kế biểu đồ lớp, biểu đồ tuần tự, biểu đồ hoạt động, v.v đầu vào cho kiểm thử dựa mô hình, đầu ca kiểm thử để đánh giá, phát lỗi Mục đích kiểm thử dựa mơ hình tìm đƣợc lỗi từ khâu thiết kế, không triển khai thiết kế lỗi, hạn chế rút ngắn đƣợc thời gian kiểm thử nhƣ triển khai dự án sau Việc kiểm thử phát sớm lỗi, khiếm khuyết thiết kế làm giảm thiểu đến mức thấp lỗi phát sinh đƣa vào ứng dụng thực tế, đồng thời làm giảm đáng kể thời gian nhƣ chi phí phát triển, bảo trì Do vậy, việc phát triển phƣơng pháp kiểm thử dựa mơ hình mang lại hiệu cao cần thiết Trong chƣơng này, tơi trình bày lý thuyết phƣơng pháp kiểm thử dựa mơ hình ứng dụng cho kiểm thử phần mềm 2.1.1 Khái niệm kiểm thử dựa mơ hình Kiểm thử dựa mơ hình kỹ thuật kiểm thử hộp đen, dựa phƣơng pháp ứng dụng mơ hình thiết kế vào kiểm thử phần mềm Mơ hình thiết kế đại diện cho hành vi mong muốn hệ thống cần kiểm thử, kiểm thử dựa mơ hình đại diện cho chiến lƣợc thử nghiệm hay mơi trƣờng kiểm thử Một mơ hình đặc tả hệ thống thƣờng tóm tắt, trình bày phần hành vi mong muốn hệ thống Chúng đƣợc biểu diễn máy hữu hạn trạng thái, ôtômat, đặc tả đại số, biểu đồ trạng thái UML, v.v Các ca kiểm thử đƣợc sinh từ mơ hình theo nhiều cách khác Trƣờng hợp kiểm thử dựa mơ hình gọi kiểm thử chức có mức độ trừu tƣợng nhƣ mơ hình Những trƣờng hợp kiểm thử đƣợc gọi kiểm thử trừu tƣợng Một kiểm thử trừu tƣợng khơng thể khẳng định hồn tồn đƣợc tính đắn hệ thống Vì hệ thống thiết kế có mức sai trừu tƣợng Một kiểm thử thực thi cần phải đƣợc bắt nguồn từ thử nghiệm trừu tƣợng tƣơng ứng Các kiểm thử thực thi liên lạc trực tiếp với hệ thống kiểm thử Điều đạt đƣợc cách ánh xạ ca kiểm thử trừu tƣợng với các ca kiểm thử cụ thể phù hợp để thực thi Trong số môi trƣờng kiểm thử dựa mơ hình, mơ hình có đủ thơng tin để tạo dãy ca kiểm thử thực thi trực tiếp Trong trƣờng hợp khác, yếu tố phần mềm kiểm thử cần phải đƣợc ánh xạ tới kiểm thử cụ thể Có bốnphƣơng pháp tiếp cận với kiểm thử dựa mơ hình nhƣ sau[7]:  Sinh liệu đầu vào kiểm thử từ mơ hình chính: đầu vào kiểm thử dựa mơ hình mơ hình, từ tạo ca kiểm thử cách chọn lựa thông minh tập hợp tập giá trị trƣờng hợp có khả để đƣa liệu đầu vào kiểm thử Ví dụ mơ hình cần kiểm thử có tập đầu vào nhƣ sau, A : {red, green, yellow}, B : {1, 2, 3, 4} C : {car, truck, bike} Chúng ta kết hợp lựa chọn số ca kiểm thử tối thiểu thỏa mãn tất đƣờng kiểm thử thực thi thay thực thi tất ca kiểm thử Theo số ca kiểm thử cho ví dụ 12 thay x x = 36 ca kiểm thử  Sinh ca kiểm thử từ mơ hình mơi trƣờng:phƣơng pháp sử dụng loại mơ hình khác, mơ hình miêu tả mơi trƣờng mong muốn SUT Từ mơ hình mơ giả lập đƣa tham số gọi tới SUT Tuy nhiên, nhƣ cách tiếp cận sinh liệu đầu vào kiểm thử từ mơ hình chính, trình tự đƣợc tạo không định rõ đầu mong đợi SUT, điều khơng thể dự đốn giá trị đầu ra, mơ hình mơi trƣờng khơng mơ hình hóa đƣợc tồn hành vi SUT Vì khó để xác định xác kiểm thử thành công hay thất bại  Sinh ca kiểm thử với dự đốn từ mơ hình hành vi:đƣa ca kiểm thử có khả thực thi bao gồm thơng tin dự đốn giá trị đầu mong muốn SUT Hoặc vài khâu kiểm tra tự độngcác giá trị đầu thực tế để nhìn thấy chúng đắn Điều khó việc sinh liệu kiểm thử đầu vào kiểm thử dựa trình tự gọi tới SUT mà không kiểm tra tới kết đầu Để đƣa kiểm thử với dự đốn ngƣời đƣa ca kiểm thử phải có đầy đủ thông tin hành vi mong đợi SUT để tiên đốn kiểm tra liệu đầu SUT Một cách khác, với định nghĩa kiểm thử dựa mơ hình này, mơ hình phải mô tả hành vi mong đợi SUT, nhƣ mối quan hệ chúng, đồng thời mô tả đầu vào đầu cho hành vi Thuận lợi cách tiếp cận phƣơng pháp tiếp cận giải đƣợc vấn đề kiểm thử dựa mơ hình việc chọn lựa giá trị đầu vào việc đƣa trình tự vận hành, việc đƣa ca kiểm thử có khả thực thi bao gồm thông tin định sau ca kiểm thử  Sinh đoạn mã kiểm thử từ kiểm thử trừu tƣợng:sinh ca kiểm thử thực thi bao gồm thơng tin tiên đốn dựa mơ hình hành vi SUT Q trình sinh ca kiểm thử bao gồm việc sinh liệu kiểm thử trình tự phƣơng thức gọi tới kiểm thử tuần tự, sinh dự đoán để kiểm tra kết đầu SUT Đây phƣơng pháp tiếp cận hoàn thiện phức tạp nhất, mang lại hiệu tốt Nó tự động hồn thiện tiến trình thiết kế, đƣa mơ hình hồn thiện, tái đầy đủ kiểm thử chuyển đổi thành kịch kiểm thử thực thi Với cách nhìn kiểm thử dựa mơ hình, định nghĩa kiểm thử dựa mơ hình nhƣ việc tự động tạo ca kiểm thử hộp đen thiết kế 2.1.2 Quy trình chung kiểm thử dựa mơ hình Mơ hình UML đƣợc thiết kế từ đặc tả u cầu hệ thống Mơ hình đƣợc biểu diễn loại mơ hình biểu đồ khác Việc xây dựng mơ hình phải dựa yếu tố liệu đầu vào đầu Mơ hình đƣợc sử dụng để sinh đầu vào cho ca kiểm thử Tiếp đến, sinh giá trị đầu mong muốn ứng với đầu vào Khi kết thúc bƣớc này, có ca kiểm thử Sau thực thi ca kiểm thử tƣơng ứng theo giai đoạn phƣơng pháp tiếp cận, kết thu đƣợc đƣợc so sánh với kết mong đợi Từ định hành động nhƣ sửa đổi mơ hình dừng kiểm thử, v.v Thiết kế Các đặc tả u cầu Mơ hình Phản hồi Phản hồi Tạo tự động Các chuỗi kiểm thử Kiểm thử dự đoán Kết luận: Pass / Fail Theo dõi Điều khiển Thực thi Phản hồi Hình 2.1Qui trình kiểm thử dựa mơ hình Hình 2.1 mơ tả quy trình chung kiểm thử tự động dựa mơ hình[8] Kiểm thử tự động dựa mơ hình gồm giai đoạn sau:      Sinh mơ hình dựa u cầu chức hệ thống Sinh ca kiểm thử (bộ đầu vào giá trị đầu mong đợi cho ca kiểm thử) Chạy kịch kiểm thử để phát lỗi/khiếm khuyết sản phẩm So sánh kết đầu thực tế với kết đầu dự kiến Quyết định hành động (sửa đổi mơ hình, tạo thêm ca kiểm thử, dừng kiểm thử, đánh giá chất lƣợng phần mềm) [1] 2.1.3 Phương pháp đặc tả mơ hình máy trạng thái UML Các phƣơng pháp đặc tả mơ hình sử dụng cơng cụ tốn học thƣờng khó phổ biến thƣờng đƣợc thực chuyên gia đặc tả hình thức [1] Phù hợp cho mơi trƣờng cơng nghiệp, đặc tả mơ hình máy trạng thái UML thƣờng đƣợc dùng để đặc tả hành vi động (chuyển trạng thái) lớp đối tƣợng, ca sử dụng (use cases), hệ thống chí tồn hệ thống Tuy nhiên, máy trạng thái UML thƣờng đƣợc sử dụng cho lớp đối tƣợng Trong UML, trạng thái ứng với điều kiện quan trọng đối tƣợng Trạng thái đƣợc định giá trị thời đối tƣợng, mối quan hệ với đối tƣợng khác hành động (phƣơng thức) mà đối tƣợng thực Một phép chuyển trạng thái mối quan hệ hai trạng thái Một phép chuyển trạng thái UML bao gồm kiện đƣợc kích hoạt, điều kiện hành động tƣơng ứng Các kiện đƣợc kích hoạt phép chuyển trạng thái kiện sau:     Một lời gọi ứng với phƣơng thức Một tín hiệu nhận đƣợc từ trạng thái khác máy trạng thái Một thay đổi giá trị thuộc tính đối tƣợng Hết thời gian (timeout) 2.1.4 Thuận lợi khó khăn kiểm thử tự động dựa mơ hình Kiểm thử tự động ln mang lại ƣu điểm hiệu vƣợt trội so với kiểm thử thủ cơng, góp phần hồn thiện qui trình kiểm thử phát triển dự án phần mềm Sau ƣu điểm thuận lợi kiểm thử tự động dựa mơ hình:  Phát lỗi sớm từ khâu thiết kế: Lỗi phát sớm, lỗi thiết kế giúp hạn chế đƣợc hàng loạt lỗi phát sinh sau theo phản       ứng dây chuyền, không phát đƣợc lỗi giai đoạn đơi dẫn tới việcphải xây dựng lại mơ hình làm lại từ khâu thiết kế Tiết kiệm thời gian chi phí: Rút ngắn đƣợc thời gian sinh ca kiểm thử phân tích kết nhờ qui trình tự động Việc phát đƣợc lỗi sớm giúp ích giảm thiểu thiệt hại rủi ro cho hệ thống phần mềm, rút ngắn thời gian kiểm thử Nâng cao chất lƣợng kiểm thử: Có thể đánh giá đƣợc mức độ hiệu kiểm thử thông qua mức độ bao phủ mơ hình ca kiểm thử Nếu mơ hình hệ thống đƣợc xây dựng tốt q trình kiểm thử dựa mơ hình sinh nhiều ca kiểm thử phát nhiều lỗi Kiểm thử mơ hình cho phép giảm lỗi chủ quan ngƣời kiểm thử sinh trình kiểm thử sản phẩm Phát lỗi đặc tả, yêu cầu: Kiểm thử dựa mô hình đơi khơng phát đƣợc lỗi thiết kế mà phát đƣợc lỗi tài liệu đặc tả Các đặc tả thiếu logic dẫn tới thiết kế sai thực thi Khả tái sử dụng cao: Mỗi phần mềm đƣợc nâng cấp, dễ dàng sinh thêm ca kiểm thử kiểm thử lại cách nhanh chóng hiệu Hiểu hệ thống: Kiểm thử dựa mơ hình giúp ngƣời phát triển hiểu hệ thống cần kiểm thử thông qua việc xây dựng phân tích mơ hình hệ thống Việc sinh ca kiểm thử tự động dựa thuật toán phƣơng pháp tiếp cận khoa học, có tính tốn làm giảm số lƣợng ca kiểm thử trùng khơng hữu hiệu Có nhiều ƣu điểm thuận lợi nhƣng kiểm thử dựa mơ hình khơng dễ đƣợc áp dụng thực tế số khó khăn nhƣ sau:  Khơng thể đảm bảo tìm đƣợc tất lỗi sai khác thiết kế thực thi  Khó xây dựng mơ hình xác: Kiểm thử dựa mơ hình cần có mơ hình đặc tả xác hành vi hệ thống Trong thực tế, việc xây dựng mơ hình khó, tốn tiềm ẩn nhiều lỗi  Chỉ áp dụng kiểm thử chức năng: Các mơ hình kiểm thử phải nhỏ so với kích thƣớc hệ thống, kiểm thử mà khơng q nhiều chi phí, nhƣng chúng phải đủ chi tiết để mơ tả thực tế đặc điểm cần  Không thể bao phủ hết giai đoạn kiểm thử: Ví dụ khơng kiểm thử đƣợc tiến trình cài đặt  Tạo giá trị đầu mong đợi cho ca kiểm thử vấn đề khó khăn kiểm thử dựa mơ hình Thơng thƣờng cần có chun gia chun viên riêng tính tốn kết mong đợi 2.2 Biểu đồ khối phân đoạn UML 2.2.1 Biểu đồ Biều đồ biểu đồ thể trình tự kiện dẫn đến kết mong muốn Biểu đồ cho ta thấy qui trình hoạt động nhƣ tƣơng tác phân đoạn hệ thống Thành phần biểu đồ gồm: Đối tƣợng, thông điệp phân đoạn Đối tƣợng: Đƣợc biểu diễn haiphần: phần tiêu đề khai báo đối tƣợng chu kỳ sống, đối tƣợng tƣơng tác với thông qua thông điệp Thời gian đối tƣợng tồn đƣợc biểu diễn đƣờng đứt nét, chu kỳ sống biểu diễn đƣờng nét đôi Thông điệp: Đƣợc biểu diễn dạng đƣờng mũi tên từ chu kỳ sống đối tƣợng gửi đến đối tƣợng nhận Các mũi tên đƣợc xếp theo trình tự thời gian từ xuống Có ba loại thơng điệp: Thơng điệp đồng (nét liền), thông điệp phản hồi (nét đứt), thông điệp đệ quy (gọi tới đối tƣợng) Phân đoạn: Với luồng điều khiển phức tạp, dùng phân đoạn lồng ghép (combined fragment) Mỗi phân đoạn có từ khóa có nhiều đoạn (gọi toán hạng tƣơng tác –interaction operands) Tƣơng ứng với cấu trúc điều khiển ngơn ngữ lập trình nhƣ lặp, rẽ nhánh, song song, có phân đoạn khác với nhãn tƣơng ứng Loop, Alt, Par, v.v 2.2.2 Các phân đoạn sử dụng biểu đồ Phân đoạn tƣơng tác lựa chọn đầy đủ (Alternative) phân đoạn kết hợp (Combined Fragment) biểu diễn lựa chọn hành vi Toán hạng phân đoạn có biểu thức gác (guard expression), biểu thức gác tốn hạng đƣợc thực thi Nếu tốn hạng khơng có biểu thức gác biểu thức đƣợc ngầm hiểu true Nếu biểu thức gác else, toán hạng đƣợc thực thi điều kiện gác tốn hạng khác sai Hình 2.2 ví dụ minh họa số dƣ (balance) tài khoản lớn cho phép rút tiền (accept()), khơng từ chối (reject()) Phân đoạn tƣơng tác lựa chọn không đầy đủ (Option) phân đoạn kết hợp biểu diễn lựa chọn hành vi Trong phân đoạn có tốn hạng, tốn hạng đƣợc thực thi khơng đƣợc thực thi tùy vào điều kiện gác Phân đoạn Opt gần giống với phân đoạn Alt, có điều Opt có tốn hạng Hình 2.3 ví dụ minh hoạ thực đăng bình luận (post_comments()) khơng có lỗi (no errors) Alt [balance > 0] Accept() [else] Reject() Hình 2.2 Phân đoạn Alt Opt [No error] post_coment() Hình 2.3 Phân đoạn Opt Phân đoạn tƣơng tác lặp (Loop) phân đoạn kết hợp biểu diễn vòng lặp.Tốn hạng lặp đƣợc lặp lặp lại số lần Điều kiện gác gồm cận dƣới (minint), cận (maxint) biểu thức đúng-sai (boolean) Sau minint lần lặp, biểu thức đƣợc kiểm tra, chừng biểu thức số lần lặp nhỏ maxint vòng lặp tiếp tục Loop notify() Hình 2.4 Phân đoạn Loop vơ hạn Loop(10) notify() Hình 2.5 Phân đoạn Loop với cận cận dƣới 10 Loop(5,10) [size < 0] notify() Hình 2.6 Phân đoạn Loop với cận 5, cận dƣới 10 Hình 2.4 miêu tả phân đoạnLoop với vòng lặp vơ hạn Hình 2.5 miêu tả phân đoạnLoop với vòng lặp với cận cận dƣới 10, khơng có điều kiện cần kiểm tra Hình 2.6 miêu tả sau lặp hết lần, điều kiện size < dừng lặp, việc kiểm tra thực chừng số lần lặp thực save() ln khỏi vòng lặp Phân đoạn tƣơng tác song song (Parallel) toán hạng phân đoạn kết hợp đƣợc thực thi song song với Các kiện toán hạng khác đan xen vào theo cách nào, miễn thứ tự kiện tốn hạng đƣợc bảo tồn Hình 2.8 ví dụ minh họa thứ tự thực phân đoạn Thông điệp 1a: searchGoogle phải đƣợc thực trƣớc thông điệp 2: readResult, thông điệp 1b: searchBing phải đƣợc thực trƣớc thông điệp 3: readResult, thông điệp 1c: searchYahoo phải đƣợc thực trƣớc thông điệp 4: readResult Tuy nhiên thứ tự thông điệp (1a, 2), (1b, 3), (1c, 4) đan xen theo cách Tìm Yahoo đƣợc thực trả kết trƣớc sau với tìm Google Bing, v.v Phân đoạn tƣơng tác yếu (weak Sequencing) phân đoạn kết hợp biểu diễn trình tự yếu hành vi tốn hạng Trình tự yếu đƣợc định nghĩa tập vết với đặc tính:  Thứ tự kiện (EventOccurences) tốn hạng đƣợc trì  Các kiện trục thời gian (lifeline) khác tốn hạng khác xảy theo thứ tự  Các kiện trục thời gian toán hạng khác đƣợc thứ tự cho kiện toán hạng thứ phải xảy trƣớc kiện tốn hạng thứ hai Hình 2.9 ví dụ minh họa: Tìm kiếm Google song song với Bing Yahoo, nhiên phải tìm Bing trƣớc tìm Yahoo Loop(10) add() Break [y > 0] add() Hình 2.7 Phân đoạn Break Par 1a: searchGoogle() 2: readResult() 1b: searchBing() 3: readResult() 1c: searchYahoo() 4: readResult() Hình 2.8 Phân đoạn Par Seq Search_google() search_bing() Search_yahoo() Hình 2.9 Phân đoạn Seq Phân đoạn tƣơng tác ngặt (StrictSequencing) phân đoạn kết hợp biểu diễn trình tự ngặt hành vi toán hạng Hình 2.10 ví dụ minh họa: Tìm Google, đến tìm Bing, sau Yahoo Thứ tự hành vi tốn hạng ln tn theo trình tự bắt buộc theo trục thời gian không đƣợc phép xáo trộn Điều tuân theo qui luật thiết kế thực thi biểu đồ nên phân đoạn Strict khơng có nhiều ý nghĩa Chỉ có ý nghĩa biểu đạt tuân thủ nghiêm ngặt thiết kế Phân đoạn Strict thƣờng đƣợc dùng kết hợp với phân đoạn khác nhƣ Critical regigon, Par, Seq Strict Search_google() search_bing() Search_yahoo() Hình 2.10 Phân đoạn Strict Phân đoạn tƣơng tác từ chối (Ignore) có số kiểu thông điệp không đƣợc hiển thị phân đoạn kết hợp Các kiểu thơng điệp bị coi vô nghĩa bị bỏ qua Hình 2.11 ví dụ minh họa thiết kế sử dụng phân đoạn Ignore với ràng buộc bỏ qua thơng điệp get() set()nếu có Các thơng điệp khác đƣợc thực thi bình thƣờng Ignore{get,set} add() remove() Hình 2.11 Phân đoạn Ignore Phân đoạn tƣơng tác lƣu ý (Consider) thông điệp nên đƣợc lƣu ý phân đoạn kết hợp Điều tƣơng đƣơng với việc định nghĩa thông điệp khác bị bỏ qua Ví dụ minh họa Hình2.12 sử dụng phân đoạn Consider để lƣu ý đến hai thông điệp add() remove() sảy ra, thông điệp khác bị coi vô nghĩa bị bỏ qua Consider {add, remove} add() remove() Hình 2.12 Phân đoạn Consider Phân đoạn tƣơng tác phủ định (Negative) phân đoạn kết hợp biểu diễn vết (traces) đƣợc định nghĩa khơng hợp lệ Hình 2.13 biểu diễn qui trình hoạt động lò vi sóng có sử dụng phân đoạn Neg thiết kế Trong phân đoạn Neg có thơng điệp open() từ trục thời gian Cheftừ bên vào trục thời gian Door nằm bên thơng điệp Vì vậy, thơng điệp Open() không đƣợc phép thời gian thông điệp Neg thực thi Nếu thông điệp Open() đƣợc thực bắt buộc từ ngƣời sử dụng thơng điệp khác bên phân đoạn Neg bị dừng lại.Điều nói lên, việc mở cửa lò vi sóng không đƣợc phép nấu.Hoặc, mở cửa lò vi sóng nấu, nhiệm vụ khác bên phân đoạn Neg bị dừng lại Các nhiệm vụ đến từ bên bên phân đoạn Neg không đƣợc phép thực thi song song Phân đoạn tƣơng tác định (Assertion) phân đoạn kết hợp biểu diễn vết hợp lệ Phân đoạn Assert thƣờng đƣợc sử dụng với Ignore Consider Hình 2.14 minh họa phân đoạn Assert đƣợc sử dụng kết hợp với phân đoạn Consider Trong phân đoạn Consider cho phép thông điệp q, v, w đƣợc phép sảy TÀI LIỆU THAM KHẢO Tiếng Việt [1] PhạmNgọcHùng, Trƣơng Anh Hoàng, Đặng Văn Hƣng (2014), “Giáotrìnhkiểm thử phần mềm”, Nhà xuất ĐH Quốc Gia HN [2] Nguyễn Đức Anh (2015), “Phƣơng pháp công cụ hỗ trợ kiểm thử tự động đơn vị chƣơng trình C”,Khóa luận tốt nghiệp Đại học, Trƣờng Đại học Công nghệ, Đại học Quốc Gia Hà Nội Tiếng Anh Vũ Thị Đào, Phạm Ngọc Hùng, Vũ Việt Hà, Automated Test Data Generation From Sequence_OCL [4] Ashalatha Nayak, Debasis Samanta (2010), “Automatic Test Data Synthesis using UML Sequence Diagrams”, in Journal of Object Technology , vol 09, no 2, March 2010, pp 75-104 [5] http://www.uml-diagrams.org/sequence-diagrams-combined-fragment.html [6] A.V.K Shanthi and G Mohan Kumar(2012), “Automated Test Cases Generation from UML Sequence Diagram”, IPCSIT vol 41 © (2012) IACSIT Press, Singapore [7] Mark Utting and Bruno Legeard, “Practical Model-Based Testing: A Tools Approach”Morgan Kaufmann, 2006, pp 6-10 [8] El-Far I K and Whittaker J.A (2002), “Model-based software testing”, Encyclopedia of Software Engineering, pp 825-837 [9] Emanuela G Cartaxo, Francisco G O Neto and Patr´ıcia D L Machado, "Test Case Generation by means of UML Sequence Diagrams and Labeled Transition Systems", IEEE 2007 [10] Li Bao-Lin, Li Zhi-shu, Li Qing, Chen Yan Hong , “Test Case automate Generation from UML Sequence diagram and OCL Expression”, International Conference on Computational Intelligence and Security 2007, pp 1048-1052 [3]  ... [6] Sinh liệu kiểm thử tự động từ biểu đồ UML ràng buộc OCL Ashalatha Nayak Debasis Samanta [4] Sinh ca kiểm thử từ biểu đồ hệ thống chuyển đổi đƣợc gắn nhãn Emanuela G Cartaxo[9] Sinh ca kiểm thử. .. mềm Giai đoạn kiểm thử thiết kế (kiểm thử dựa mơ hình) chủ yếu tập trung vào ca kiểm thử đƣợc sinh từ đƣờng kiểm thử dựa đồ thị hoạt động sinh liệu kiểm thử từ liệu đầu vào thiết kế từ đặc tả chƣơng... trình kiểm thử giai đoạn thiết kế đƣợc gọi kiểm thử dựa mơ hình Các mơ hình thiết kế biểu đồ lớp, biểu đồ tuần tự, biểu đồ hoạt động, v.v đầu vào cho kiểm thử dựa mơ hình, đầu ca kiểm thử để