Kỹ thuật kiểm thử đột biến và ứng dụng để kiểm thử các chương trình java

ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ ĐINH THỊ MỸ CẢNH KỸ THUẬT KIỂM THỬ ĐỘT BIẾN VÀ ỨNG DỤNG ĐỂ KIỂM THỬ CÁC CHƯƠNG TRÌNH JAVA Ngành : Công nghệ thông tin Chuyên ngành : Công nghệ phần mềm Mã số : 60 48 10 LUẬN VĂN THẠC SỸ NGƯỜI HƯỚNG DẪN KHOA HỌC: PGS.TS ĐOÀN VĂN BAN Hà Nội – 2010 MỤC LỤC CÁC THUẬT NGỮ VÀ CÁC TỪ VIẾT TẮT DANH SÁCH CÁC HÌNH DANH SÁCH CÁC BẢNG MỞ ĐẦU CHƢƠNG - TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM 1.1 Kiểm thử phần mềm gì? 1.2 Các mức kiểm thử phần mềm 1.2.1 Kiểm thử đơn vị 10 1.2.2 Kiểm thử tích hợp 10 1.2.3 Kiểm thử hệ thống 11 1.2.4 Kiểm thử chấp nhận 12 1.3 Thiết kế trường hợp kiểm thử 12 1.3.1 Kỹ thuật kiểm thử hộp trắng 13 1.3.1.1 Kiểm thử đường dẫn sở 13 1.3.1.2 Kiểm thử cấu trúc điều khiển 17 1.3.2 Kỹ thuật kiểm thử hộp đen 19 1.3.2.1 Phân hoạch tương đương 20 1.3.2.2 Phân tích giá trị biên 22 1.4 Kết luận 23 CHƢƠNG – KỸ THUẬT KIỂM THỬ ĐỘT BIẾN 24 2.1 Giới thiệu 24 2.2 Khái niệm kiểm thử đột biến 25 2.3 Cơ sở kiểm thử đột biến 26 2.4 Toán tử đột biến 26 2.5 Quy trình kiểm thử đột biến 28 2.6 Một số vấn đề kiểm thử đột biến 31 2.7 Kết luận 31 CHƢƠNG - CÁC CẢI TIẾN KỸ THUẬT KIỂM THỬ ĐỘT BIẾN 33 3.1 Giảm chi phí tính tốn 33 3.1.1 Làm 33 3.1.1.1 Lấy mẫu đột biến 33 3.1.1.2 Đột biến ràng buộc 35 3.1.1.3 N - đột biến lựa chọn 36 3.1.2 Làm nhanh 37 3.1.2.1 Phương pháp tạo lược đồ đột biến 38 3.1.3 Làm thông minh 40 3.1.3.1 Đột biến yếu 40 3.2 Tăng tự động hóa 42 3.2.1 Tạo liệu thử tự động 42 3.2.2 Xác định đột biến tương đương tự động 43 3.2.3 Vấn đề Oracle 45 3.3 Kết luận 46 CHƢƠNG - ỨNG DỤNG KỸ THUẬT KIỂM THỬ ĐỘT BIẾN ĐỂ KIỂM THỬ CÁC CHƢƠNG TRÌNH JAVA 47 4.1 Công cụ MuJava 47 4.1.1 Mô tả công cụ MuJava 47 4.1.2 Các toán tử đột biến cho MuJava 50 4.1.2.1 Các toán tử đột biến mức phương thức 50 4.1.2.2 Các toán tử đột biến mức lớp 53 4.1.3 Phương pháp thực thi MuJava 55 4.2 Công cụ Junit 56 4.3 Quy trình ứng dụng kiểm thử đột biến để kiểm thử chương trình Java 57 4.4 Ứng dụng kỹ thuật kiểm thử đột biến để kiểm thử chương trình SXQSort.java 58 4.4.1 Đặc tả chương trình xếp dãy số tăng dần 58 4.2.2 Thuật tốn chương trình SXQSort.java 58 4.2.3 Thiết kế trường hợp kiểm thử cho chương trình SXQSort.java 59 4.2.3.1 Thiết kế trường hợp kiểm thử cho module FindPivot 59 4.2.3.2 Thiết kế trường hợp kiểm thử cho Module Partition 61 4.2.3.3 Thiết kế trường hợp kiểm thử cho Module QuickSort 63 4.4.4 Kiểm thử chương trình SXQSort.java với JUnit 65 4.4.5 Tạo phân tích đột biến cho chương trình SXQSort.java MuJava 66 4.4.5.1 Tạo đột biến 66 4.4.5.2 Phân tích đột biến 69 KẾT LUẬN 72 TÀI LIỆU THAM KHẢO 73 CÁC THUẬT NGỮ VÀ CÁC TỪ VIẾT TẮT Viết tắt Tên đầy đủ ABS Absolute value insertion ACR Array reference for constant replacement AOR Arithmetic operator replacement AORB Arithmetic operator replacement (binary) AORS Arithmetic operator replacement (short-cut) ASR BCEL Array reference for scalar variable replacement Byte code engineering library CBT Constraint-based testing COR Conditional operator replacement CSR Constant for scalar variable replacement DU Một chuỗi khai báo – sử dụng JID Member variable initialisation deletion JSI static modifier insertion JTI this keyword insertion LCR Logical connector replacement MSG Mutant schema generation PUT Program under test ROR Relational operator replacement SCR Scalar for constant replacement SRC Source constant replacement SVR Scalar variable replacement UOI Unary operator insertion DANH SÁCH CÁC HÌNH Số Tên hình Trang Hình 1.1 Bốn mức độ kiểm thử phần mềm Hình 1.2 Đồ thị luồng điều khiển 13 Hình 1.3 Ví dụ minh hạo phát sinh trường hợp kiểm thử theo đường dẫn sở 15 Hình 1.4 Các kiểu vịng lặp 18 Hình 2.1 Ví dụ đột biến 25 Hình 2.2 Quy trình kiểm thử đột biến 29 Hình 2.3 Ví dụ đột biến tương đương 30 Hình 3.1 Ba kịch có cho quan hệ tập liệu thử diệt đột biến yếu mạnh 34 Hình 3.2 Phân bố đột biến tốn tử đột biến cho Mothra 36 Hình 3.3 Ví dụ phương thức PUT gốc 39 Hình 3.4 Phiên đột biến PUT gốc hình 3.3 39 Hình 4.1 Cấu trúc tổng thể MuJava 47 Hình 4.2 Giao diện tạo đột biến MuJava 48 Hình 4.3 Giao diện biểu diễn đột biến MuJava 49 Hình 4.4 Giao diện thực thi đột biến MuJava 49 Hình 4.5 Hệ thống thực thi MuJava 55 Hình 4.6 Giao diện đồ họa JUnit 56 Hình 4.7 Quy trình ứng dụng kỹ thuật kiểm thử đột biến 57 Hình 4.8 Đồ thị luồng điều khiển Partiton 62 Hình 4.9 Kết kiểm thử SXQSort.java JUnit 65 Hình 4.10 Giao diện tạo đột biến cho SXQSort.java 67 Hình 4.11 Hiển thị đột biến truyền thống SXQSort.java 68 Hình 4.12 Hiển thị đột biến lớp SXQSort.java 68 Hình 4.13 Kết thực thi đột biến SXQSort.java 69 DANH SÁCH CÁC BẢNG Số Tên bảng Trang Bảng 1.1 Ví dụ lớp tương đương 21 Bảng 2.1 22 toán tử đột biến chuẩn sử dụng Mothra 27 Bảng 4.1 Các toán tử đột biến mức phương thức cho MuJava 51 Bảng 4.2 Các toán tử đột biến mức lớp MuJava 54 Bảng 4.3 Mô tả trường hợp kiểm thử cho module FindPivot 60 Bảng 4.4 Mô tả trường hợp kiểm thử cho module Partition 63 Bảng 4.5 Mô tả trường hợp kiểm thử cho module QuickSort 64 Bảng 4.6 Các toán tử đột biến mức phương thức mức lớp chọn để tạo đột biến cho SXQSort.java 66 Bảng 4.7 Chất lượng 22 trường hợp kiểm thử cho SXQSort.java 70 MỞ ĐẦU Kiểm thử phần mềm hoạt động giữ vai trò quan trọng để bảo đảm chất lượng phần mềm hoạt động mang tính sống cịn dự án sản xuất gia công phần mềm Vì vậy, kiểm thử phần mềm trở thành qui trình bắt buộc dự án phát triển phần mềm giới Ở Việt Nam, ngành công nghiệp phần mềm phát triển khơng thể xem nhẹ việc kiểm thử phần mềm xác suất thất bại cao, nữa, hầu hết công ty phần mềm có uy tín đặt u cầu nghiêm ngặt phần mềm khơng có tài liệu kiểm thử kèm khơng chấp nhận Tuy nhiên, hoạt động kiểm thử thường gặp nhiều khó khăn Thứ nhất, kiểm thử hệ thống phức tạp đòi hỏi nhiều nguồn tài nguyên chi phí cao Thứ hai, tiến trình phát triển phần mềm trải qua nhiều hoạt động biến đổi thông tin, mát thơng tin q trình biến đổi yếu tố làm cho hoạt động kiểm thử khó khăn Thứ ba, kiểm thử chưa trọng đào tạo người Cuối cùng, không tồn kỹ thuật kiểm thử cho phép khẳng định phần mềm hồn tồn đắn hay khơng chứa lỗi Với mục đích phát lỗi, kiểm thử phần mềm thường phải trải qua bước: tạo liệu thử, thực thi phần mềm liệu thử quan sát kết nhận Trong bước này, bước tạo liệu thử đóng vai trị quan trọng nhất, khơng thể tạo liệu từ miền vào chương trình, mà tạo liệu thử có khả phát lỗi cao Vấn đề đặt làm để đánh giá khả phát lỗi liệu thử? Một kinh nghiệm để giúp giải vấn đề này, sử dụng khái niệm chất lượng liệu thử phương tiện để đánh giá liệu thử “tốt” kiểm thử chương trình Ở đây, “tốt” đánh giá liên quan đến tiêu chuẩn chất lượng định trước, thường số dấu hiệu bao phủ chương trình Ví dụ, tiêu chuẩn bao phủ dịng lệnh địi hỏi liệu thử thực dòng lệnh chương trình lần Nếu liệu thử tìm thấy khơng chất lượng liên quan đến tiêu chuẩn (tức tất câu lệnh thực lần), kiểm thử bắt buộc Do đó, mục tiêu tạo tập kiểm thử thực đầy đủ tiêu chuẩn chất lượng Tiêu chuẩn chất lượng tiêu biểu bao phủ câu lệnh kiểm thử định (thực tất đường dẫn sai qua chương trình) dựa vào việc thực chương trình với số lượng kiểm thử tăng dần để nâng cao độ tin cậy chương trình Tuy nhiên, chúng không tập trung vào nguyên nhân thất bại chương trình - gọi lỗi Kiểm thử đột biến [7] tiêu chuẩn Tiêu chuẩn tạo phiên chương trình có chứa lỗi đơn giản sau tìm kiểm thử để dấu hiệu lỗi Nếu tìm thấy liệu thử chất lượng làm lộ dấu hiệu tất phiên bị lỗi, tin tưởng vào tính đắn chương trình tăng Kiểm thử đột biến áp dụng cho nhiều ngơn ngữ lập trình [8] kỹ thuật kiểm thử hộp trắng Chẳng hạn, chương trình Fortran, Ada, C, Java, C#, SQL, … Bên cạnh việc sử dụng kiểm thử đột biến mức thực thi phần mềm, kiểm thử đột biến sử dụng mức thiết kế để kiểm thử đặc tả mơ hình chương trình Ví dụ, mức thiết kế, kiểm thử đột biến áp dụng cho máy trạng thái xác định (FSM), biểu đồ trạng thái (State Charts), giao thức mạng (Network Protocols), sách bảo mật (Security Policies), dịch vụ web (Web Services), … Ý thức lĩnh vực nghiên cứu có nhiều triển vọng ứng dụng phát triển phần mềm, chọn hướng nghiên cứu Kỹ thuật kiểm thử đột biến cho đề tài luận văn Luận văn xây dựng dựa nghiên cứu có lĩnh vực kiểm thử phần mềm kể từ năm 1978, mà gần nghiên cứu kỹ thuật kiểm thử đột biến vào năm 2009 TS.Nguyễn Thanh Bình – Đại học Bách khoa, Đại học Đà Nẵng [2] Đồng thời, xin đề xuất “quy trình ứng dụng kỹ thuật kiểm thử đột biến để kiểm thử chương trình Java” Luận văn tổ chức thành chương sau:  Chƣơng – Trình bày tổng quan kiểm thử phần mềm khái niệm kiểm thử phần mềm, mục đích, mục tiêu mức kiểm thử phần mềm Chương đề cập đến việc sử dụng kỹ thuật kiểm thử hộp trắng hộp đen để thiết kế liệu thử  Chƣơng - Mô tả chi tiết thành phần kỹ thuật kiểm thử đột biến, giới thiệu giả thuyết cần thiết để thực phương pháp Chương cung cấp quy trình để phân tích đột biến, từ rút vấn đề cịn hạn chế kỹ thuật kiểm thử đột biến, cải tiến chương  Chƣơng – Giới thiệu phương pháp cải tiến kỹ thuật kiểm thử đột biến nhằm giảm chi phí tính tốn tăng tự động hóa  Chƣơng – Tập trung vào ứng dụng kỹ thuật kiểm thử đột biến Phần đầu giới thiệu hai cơng cụ mã nguồn mở miễn phí MuJava với chức phân tích tạo đột biến, JUnit dùng để kiểm thử đơn vị chương trình Java Đồng thời, đề xuất quy trình ứng dụng kỹ thuật kiểm thử đột biến để kiểm thử chương trình Java sử dụng hai cơng cụ Cụ thể, kiểm thử chương trình xếp dãy số tăng dần theo thuật tốn QuickSort viết ngơn ngữ Java, từ đó, tập trung phân tích đánh giá chất lượng liệu thử dùng để kiểm thử chương trình CHƢƠNG - TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM 1.1 Kiểm thử phần mềm gì? Kiểm thử phần mềm thường đồng nghĩa với việc tìm lỗi chưa phát Tuy nhiên, có nhiều bối cảnh kiểm thử khơng bộc lộ lỗi Kiểm thử phần mềm trình thực thi hệ thống phần mềm để xác định xem phần mềm có với đặc tả khơng thực môi trường mong đợi hay không [19] Mục đích kiểm thử phần mềm tìm lỗi chưa phát hiện, tìm cách sớm bảo đảm lỗi sửa, kiểm thử phần mềm khơng làm cơng việc chẩn đốn ngun nhân gây lỗi phát sửa lỗi Mục tiêu kiểm thử phần mềm thiết kế tài liệu kiểm thử cách có hệ thống thực cho có hiệu quả, tiết kiệm thời gian, cơng sức chi phí 1.2 Các mức kiểm thử phần mềm Chiến lược kiểm thử tổng thể hệ thống [3] sử dụng rộng rãi chiến lược từ mức thấp đến mức cao, bao gồm bốn mức thể hình 1.1: Kiểm thử mức đơn vị lập trình (Unit test) Các phận đơn lẻ Kiểm thử mức tích hợp đơn vị (Integration test) Các nhóm phận Kiểm thử mức hệ thống, sau tích hợp (System test) Kiểm thử để chấp nhận sản phẩm (Acceptance test) Toàn hệ thống Toàn hệ thống nhìn từ khách hàng Hình 1.1- Bốn mức độ kiểm thử phần mềm 61 4.2.3.2 Thiết kế trường hợp kiểm thử cho Module Partition Đoạn chương trình phân hoạch dãy A thành hai dãy A[i] A[L-1] A[L] A[j] với điểm phân hoạch L sau: public int Partition(int i,int j,int Pivot) { int L,R; L = i; //1 R = j; //1 while (L = Pivot) R ; if (L < R) { //4 //5 //6 //7 //8 int tmp; tmp = A[L]; //9 A[L] = A[R]; //9 A[R] = tmp; //9 } } //10 return L; //3 } Áp dụng phương pháp đường dẫn sở để thiết kế trường hợp kiểm thử cho module Partition, thực theo bước sau:  Xây dựng đồ thị luồng điều khiển cho đoạn chương trình Partition (với đỉnh đồ thị tương ứng với dòng lệnh đánh số phần thích đoạn chương trình ) 62 F T T F T F T F 10 Hình 4.8 - Đồ thị luồng điều khiển Partiton (Đồ thị có đỉnh điều kiện: 2, 4, 6, )  Đối chiếu với hình 4.8, xác định độ phức tạp chu trình V(G) sau: V(G) = P (số đỉnh điều kiện) + = + =  Xác định tập sở đường dẫn độc lập Vì V(G) =5 nên đồ thị luồng điều khiển hình 4.8 có đường dẫn độc lập sau: + Đường dẫn 1:   + Đường dẫn 2:      10   … + Đường dẫn 3:       10   … + Đường dẫn 4:      … + Đường dẫn 5:       … Các dấu chấm lửng (…) phía sau đường dẫn có nghĩa đường dẫn qua phần lại đồ thị chấp nhận  Thiết kế trường hợp kiểm thử cho đường dẫn 3, 4, sau: 63 Đầu vào STT Tên kiểm thử PartitionPath3 N Dãy A 15 PartitionPath4 226187 PartitionPath5 6 10 Kết mong đợi 15 Điểm phân hoạch: 221687 Điểm phân hoạch: 10 Điểm phân hoạch: Bảng 4.4 – Mô tả trường hợp kiểm thử cho module Partition (Lưu ý: Đường dẫn khơng thể kiểm thử mình, mà phải kiểm thử phần kiểm thử đường dẫn 3, 4, 5.) 4.2.3.3 Thiết kế trường hợp kiểm thử cho Module QuickSort Đây module cuối gọi thực FindPivot, Partiton gọi đệ quy QuickSort Do đó, khả xảy lỗi module xảy Vì vậy, cần thiết kế trường hợp kiểm thử cho module để thực việc kiểm thử tích hợp module tích hợp lại thành module QuickSort Dựa vào phương pháp kiểm thử hộp đen cách sử dụng phân hoạch tương đương phân tích giá trị biên giá trị đầu vào:  Số phần tử dãy N (1  N  30): 0, 1, 5, 8, 30, 31, chữ cái, 2.5  Dãy A: + Các phần tử dãy ngẫu nhiên + Các phần tử dãy có giá trị + Dãy theo thứ tự tăng dần + Dãy theo thứ tự giảm dần + Dãy có phần tử chữ + Dãy có phần tử số thực Từ việc phân tích giá trị đầu vào thuật toán xếp QuickSort, thiết kế trường hợp kiểm thử sau: 64 Đầu vào STT Tên kiểm thử N Kết mong đợi Dãy A QuickSort1 [] Thất bại QuickSort2 5 QuickSort3 45722 22457 QuickSort4 44444 44444 5 QuickSort5 10 17 30 10 17 30 QuickSort6 16 12 0 12 16 QuickSort7 15 12 7 12 15 QuickSort8 77777777 77777777 QuickSort9 12 16 19 25 12 16 19 25 10 QuickSort10 17 10 -3 -3 10 17 11 QuickSort11 15 … 10 10 15… 12 QuickSort12 6 6 6… 6 6 6… 30 13 QuickSort13 12 …15 12 15… 14 QuickSort14 17 10 ….-3 -3 10 17… 15 QuickSort15 31 -4 20 1…… Thất bại 16 QuickSort16 a 17 QuickSort17 18 QuickSort18 2.5 19 QuickSort19 Thất bại 56a Thất bại Thất bại 1.5 Thất bại Bảng 4.5 – Mô tả trường hợp kiểm thử cho module QuickSort Như vậy, có tất 28 trường kiểm thử thiết kế để kiểm thử cho chức module cho toàn hệ thống chương trình SXQSort.java 65 Trong đó, có 22 trường hợp kiểm thử mong đợi làm cho chương trình thành cơng trường hợp kiểm thử mong đợi làm cho chương trình thất bại Chúng ta chọn 22 trường hợp kiểm thử mong đợi làm cho chương trình SXQSort.java thành cơng để thực kiểm thử đột biến 4.4.4 Kiểm thử chƣơng trình SXQSort.java với JUnit Chương trình SXQSort.java phải hiển thị để cung cấp đầu mong muốn thực với 22 trường hợp kiểm thử (được mong đợi làm cho chương trình thành cơng) Vì q trình thực kiểm thử đột biến, bên cạnh đột biến tương đương, tất đột biến khác hiển thị để tạo đầu không so với đầu chương trình SXQSort.java Nếu có đầu khơng chứng tỏ chương trình SXQSort.java chứa lỗi Các lỗi nên sữa chữa để bắt đầu trình kiểm thử đột biến Chúng ta sử dụng kiểm thử JUnit (phiên 3.8.1) để kiểm thử chương trình SXQSort.java, với 22 trường hợp kiểm thử thiết kế sẵn QuickSortTest.java Kết kiểm thử thể hình 4.9 Hình 4.9 – Kết kiểm thử SXQSort.java JUnit Trên hình 4.9, JUnit hiển thị màu xanh Điều chứng tỏ rằng, chương trình SXQSort.java chương trình tốt (tức chương trình khơng có lỗi) “góc nhìn” JUnit với liệu thử xây dựng 22 trường hợp kiểm thử 66 4.4.5 Tạo phân tích đột biến cho chƣơng trình SXQSort.java MuJava Dùng MuJava để tạo đột biến cho chương trình SXQSort.java, thực thi đột biến với 22 trường hợp kiểm thử xây dựng SXQSortTest.Java, báo cáo tỷ lệ đột biến trường hợp kiểm thử 4.4.5.1 Tạo đột biến MuJava tạo hai loại đột biến: đột biến truyền thống đột biến lớp tương ứng với hai loại toán tử đột biến Nếu chọn tất toán tử đột biến mức phương thức mức lớp, MuJava tạo 262 đột biến cho chương trình SXQSort.Java, có 258 đột biến truyền thống đột biến lớp Nếu MuJava thực thi tất đột biến với 22 trường hợp kiểm thử xây dựng SXQSortTest.java tốn nhiều thời gian, đồng thời số lượng đột biến tương đương tăng Do đó, làm tăng chi phí kiểm thử cho chương trình SXQSort.Java Để giảm chi phí kiểm thử cho chương trình SXQSort.Java, sử dụng phương pháp đột biến ràng buộc cách chọn số toán tử đột biến mức phương thức mức lớp MuJava để tạo đột biến Trong chương trình SXQSort.Java xuất tốn tử: { +, -}, {++, }, {=, , = =,!=}, {&&} Đây tốn tử bị “viết nhầm” lập trình viên, lỗi xảy tốn tử Ngồi ra, việc khai báo sử dụng biến {L, R, n, i, j, k}, {a[1], a[2], …, a[n]} khơng xác Vì vậy, số tốn tử đột biến mức phương thức mức lớp MuJava chọn để tạo đột biến cho chương trình SXQSort.java sau: Toán tử đột biến mức phƣơng thức Toán tử Mơ tả Ví dụ AORB Thay tốn tử số học nhị nguyên a=b+ca=b−c AORS Thay toán tử số học short – cut a ++  a −− ROR Thay toán tử quan hệ COR Thay toán tử điều kiện if(a < b)  if(a > b) while(a < b) && (c > d)  while(a < b) || (c > d) 67 Tốn tử đột biến mức lớp Tốn tử Mơ tả JTI Thêm từ khóa this JSI Thêm từ bổ nghĩa static Ví dụ n this.n public int n;  public static int n; public int[] a = new int[n]; JID Xóa khởi tạo biến thành phần  public int[] a Bảng 4.6 – Các toán tử đột biến mức phương thức mức lớp chọn để tạo đột biến cho SXQSort.java Trong thành phần Mutants Genertor MuJava, đánh dấu chọn toán tử đột biến mức phương thức: AORB, AORS, ROR, COR, chọn toán tử đột biến mức lớp: JTI, JSI, JDI, chọn file SXQSort.java Sau đó, bấm nút “Generate” để tạo đột biến cho chương trình SXQSort.java, biểu diễn hình 4.10 Hình 4.10 – Giao diện tạo đột biến cho SXQSort.java MuJava tạo 43 đột biến truyền thống cho chương trình SXQSort.java, biểu diễn Tab Traditional Mutants Viewer thành phần Mutants Genertor MuJava 68 Hình 4.11 –Hiển thị đột biến truyền thống SXQSort.java MuJava tạo đột biến lớp cho chương trình SXQSort.java, biểu diễn Tab Class Mutants Viewer thành phần Mutants Genertor MuJava Hình 4.12 – Hiển thị đột biến lớp SXQSort.java 69 Như vậy, MuJava tạo 47 đột biến cho chương trình SXQSort.java, có 43 đột biến truyền thống đột biến lớp, áp dụng toán tử đột biến mức phương thức: AORB, AORS, ROR, COR toán tử đột biến mức lớp: JTI, JSI, JID 4.4.5.2 Phân tích đột biến Chúng ta sử dụng thành phần Mutants executor MuJava để thực thi chương trình SXQSort.java 47 đột biến nó, với 22 trường hợp kiểm thử xây dựng SXQSortTest.Java, kết trình thực thi biểu diễn hình 4.13 Hình 4.13 –Kết thực thi đột biến SXQSort.java Đối với đột biến lớp, trình MuJava thực thi với 22 trường hợp kiểm thử thiết kế sẵn SXQSortTest.Java, có đột biến bị diệt đột biến “còn sống” Tỷ lệ đột biến xấp xỉ 25% Đối với 43 đột biến truyền thống, có 38 đột biến bị diệt đột biến “còn sống” Tỷ lệ đột biến xấp xỉ 88% Cụ thể với trường hợp kiểm thử thể bảng 4.7 70 STT Tên kiểm thử Số đột biến diệt đƣợc Số đột biến không diệt đƣợc FindPivot1 37 10 FindPivot 38 FindPivot 35 12 FindPivot 36 11 FindPivot 15 32 FindPivot 14 33 PartitionPath3 37 10 PartitionPath 39 PartitionPath 38 10 QuickSort 14 33 11 QuickSort 39 12 QuickSort 15 32 13 QuickSort 28 19 14 QuickSort 36 11 15 QuickSort 38 16 QuickSort 15 32 17 QuickSort 28 19 18 QuickSort 10 36 11 19 QuickSort 11 39 20 QuickSort 12 15 32 21 QuickSort 13 28 19 22 QuickSort 14 36 11 Bảng 4.7 - Chất lượng 22 trường hợp kiểm thử cho SXQSort.java Q trình MuJava phân tích đột biến chương trình SXQSort.java cho thấy rằng: chất lượng liệu thử mà tạo 22 trường hợp kiểm thử cao (tỷ lệ đột biến 88%) Nó có khả phát 71 hầu hết lỗi có chương trình SXQSort.java Bên cạnh đó, đột biến bị diệt, lỗi (lỗi mà sửa đổi từ chương trình SXQSort.java để tạo đột biến đó) khơng xuất chương trình SXQSort.java Như vậy, MuJava góp phần làm tăng lịng tin vào tính đắn chương trình SXQSort.java liệu thử 72 KẾT LUẬN Với cách tiếp cận dựa đề xuất có lĩnh vực nghiên cứu kiểm thử phần mềm, luận văn trình bày nét kiểm thử phần mềm nói chung kiểm thử đột biến nói riêng với cải tiến Qua đó, cho thấy tác dụng kiểm thử đột biến không cung cấp phương tiện để đánh giá cải tiến chất lượng liệu thử dựa cơng thức tính tỷ lệ đột biến, mà giúp kiểm thử biết khơng có lỗi (các lỗi sửa đổi từ PUT để tạo đột biến) xuất PUT tất đột biến PUT bị diệt Điều này, góp phần làm tăng tin tưởng kiểm thử viên vào tính đắn PUT liệu thử Luận văn giới thiệu hai cơng cụ mã nguồn mở miễn phí MuJava để tạo phân tích đột biến, JUnit để kiểm thử đơn vị, đồng thời đề xuất quy trình ứng dụng kiểm thử đột biến để kiểm thử chương trình Java Sử dụng kỹ thuật kiểm thử đột biến ràng buộc (chỉ lựa chọn số toán tử đột biến) để kiểm thử chương trình xếp dãy tăng dần theo thuật toán QuickSort với 22 trường hợp kiểm thử, kết có 88% đột biến bị diệt, phải kiểm tra với 17,9% đột biến Kiểm thử đột biến kỹ thuật kiểm thử nhiều nhà nghiên cứu quan tâm khả ứng dụng Tuy nhiên, ngồi vấn đề nêu, tồn nhiều vấn đề cần phải tiếp tục nghiên cứu Các vấn đề phát đột biến tương đương vấn đề Oracle Chưa có vấn đề giải nghiên cứu này, với giả định tồn phương pháp thích hợp để giải vấn đề Tuy nhiên, để tạo thuận lợi để kiểm thử đột biến chấp nhận ngành công nghiệp, giải pháp khả thi cần thiết cho vấn đề Phát đột biến tương đương đơn giản liên quan đến việc bỏ qua chúng dựa vào tỷ lệ đột biến thấp để phát triển liệu thử - cải tiến liệu thử liên tục diễn ra, thu liệu thử tốt Do đó, thời gian tới, tơi tiếp tục nghiên cứu để loại bỏ đột biến tương đương số đột biến sống chương trình, đồng thời cải tiến trường hợp kiểm thử để đạt tỷ lệ đột biến 100% 73 TÀI LIỆU THAM KHẢO Tiếng Việt [1] Nguyễn Thanh Bình, Hồ Văn Phi (2010), “Giải pháp kiểm thử đột biến câu lệnh truy vấn sở liệu”, Tạp chí Khoa học Cơng nghệ, Đại học Đà Nẵng, 2(37) [2] Nguyễn Thanh Bình, Nguyễn Quang Vũ (2009), “Ứng dụng kỹ thuật kiểm thử đột biến để kiểm thử chương trình C-Sharp”, Tạp chí Khoa học Công nghệ, Đại học Đà Nẵng, 5(34) [3] Nguyễn Văn Vỵ, Nguyễn Việt Hà (2006), Giáo trình kỹ nghệ phần mềm, Khoa CNTT, Đại học Công nghệ, ĐHQGHN Tiếng Anh [4] T A Budd and D Angluin (1982), “Two notions of correctness and their relation to testing”, Acta Informatica [5] Mattias Bybro (2003), A Mutation Testing Tool for Java Programs, Thesis, Department of Numerical Analysis and Computer Science, Nada at the Royal Institute of Technology [6] M E Delamaro and J C Maldonado (1996), “Proteum - a tool for the assessment of test adequacy for C programs: User's guide”, Technical report [7] R DeMillo, R Lipton, and F Sayward (1978), “Hints on test data selection: Help for the practicing programmer”, IEEE Computer [8] Yue Jia and Mark Harman (2009), “An Analysis and Survey of the Development of Mutation Testing”, Technical Report, Crest Centre, King’s College London [9] R M Hierons, M Harman, and S Danicic (1999), “Using Program Slicing to Assist in the Detection of Equivalent Mutants,” Software Testing, Verification and Reliability [10] W.E Howden (1982), “Weak mutation testing and completeness of test sets”, IEEE Transactions on Software Engineering, 8(4) [11] K N King and A Jefferson Offutt (1991), “A Fortran language system for mutation-based software testing”, Software - Practice and Experience, 21(7) 74 [12] Edward William Krauser (1991), Compiler-Integrated Software Testing, PhD thesis, Purdue University [13] Y S Ma, A J Offutt, and Y R Kwon (2002), “Inter-class Mutation Operators for Java”, in Proceedings of the 13th International Symposium on Software Reliability Engineering (ISSRE’02), Annapolis, Maryland: IEEE Computer Society [14] Y.S Ma, A J Offutt, and Y.R Kwon (2004), “An Experimental Mutation System for Java”, ACM SIGSOFT Software Engineering Notes [15] Y S Ma, A J Offutt, and Y R Kwon (2005), “MuJava: An Automated Class Mutation System”, Software Testing, Verification & Reliability [16] Y S Ma, A J Offutt, and Y R Kwon (2006), “MuJava: a Mutation System for Java”, in Proceedings of the 28th international Conference on Software Engineering (ICSE ’06), Shanghai, China [17] Aditya P Mathur and W Eric Wong (1993), Comparing the fault detection ef- fectiveness of mutation and data flow testing: An empirical study, Software Engineering Research Center, Purdue University, West Lafayette, Indiana [18] P S May (2007), Test Data Generation: Two Evolutionary Approaches to Mutation Testing, PhD Thesis, University of Kent, Canterbury, Kent [19] G J Myers (1979), The Art of Software Testing, John Wiley & Sons, Inc., New York [20] Jeff Offutt (1992), “Investigations of the software testing coupling effect”, ACM Transactions on Software Engineering and Methodology [21] Jeff Offutt, W M Craft (1996), Using Compiler Optimization Techniques to Detect Equivalent Mutants, George Mason University [22] Jeff Offutt, Ammei Lee, Gregg Rothermel, Roland H Untch, and Christian Zapf (1996), An Experimental Determination of Sufficient Mutant Operators, George Mason University, pp 4-6 [23] Jeff Offutt and Stephen D Lee (1996), An Empirical Evaluation of Weak Mutation, George Mason University [24] Jeff Offutt and J Pan (1997), “Automatically Detecting Equivalent Mutants and Infeasible Paths”, Software Testing, Verification and Reliability, vol (b) 75 [25] Jeff Offutt, Gregg Rothermel, Roland H Untch, and Christian Zapf (1993), An Experimental Evaluation of Selective Mutation, Baltimore, MD [26] A J Offutt and R H Untch (2001), “Mutation 2000: Uniting the Orthogonal”, in Proceedings of the 1st Workshop on Mutation Analysis (MUTATION’ 00), published in book form, as Mutation Testing for the New Century [27] Jeff Tian (2005), Software Quality Engineering: Testing, Quality Assurance, and Quantifiable Improvement, Wiley-IEEE Computer Society Press [28] Maryam Umar (2006), An Evaluation Of Mutation Operators For Equivalent Mutants, Department of Computer Science King’s College, London [29] Roland H Untch, A Jefferson Offutt, and Mary Jean Harrold (1993), “Mutation analysis using mutant schemata”, International Symposium on Software Testing and Analysis [30] W E Wong and A P Mathur (1995), “Reducing the Cost of Mutation Testing: An Empirical Study”, Journal of Systems and Software, vol 31 [31] SourceForge, “JUnit”, http://www.junit.org, 2009 [32] SourceForge, “MuJava”, http://www.cs.gmu.edu/~offutt/mujava/, 2008 ... ứng dụng kiểm thử đột biến để kiểm thử chương trình Java 57 4.4 Ứng dụng kỹ thuật kiểm thử đột biến để kiểm thử chương trình SXQSort .java 58 4.4.1 Đặc tả chương trình. .. quy trình ứng dụng kỹ thuật kiểm thử đột biến để kiểm thử chương trình Java sử dụng hai cơng cụ Cụ thể, kiểm thử chương trình xếp dãy số tăng dần theo thuật toán QuickSort viết ngơn ngữ Java, ... cứu kỹ thuật kiểm thử đột biến vào năm 2009 TS.Nguyễn Thanh Bình – Đại học Bách khoa, Đại học Đà Nẵng [2] Đồng thời, xin đề xuất “quy trình ứng dụng kỹ thuật kiểm thử đột biến để kiểm thử chương