CẢI THIỆN CHẤT LƯỢNG KIỂM THỬ PHẦN MỀM BẰNG KỸ THUẬT KIỂM THỬ ĐỘT BIẾN BẬC CAO

CẢI THIỆN CHẤT LƢỢNG KIỂM THỬ PHẦN MỀM BẰNG KỸ THUẬT KIỂM THỬ ĐỘT BIẾN BẬC CAO TS Nguyễn Quang Vũ Khoa Công nghệ thông tin Trường Cao đẳng CNTT hữu nghị Việt Hàn TÓM TẮT Kiểm thử phần mềm hoạt động quan trọng nhằm đánh giá chất lượng phần mềm Trong đó, kiểm thử đột biến công cụ hữu hiệu để đánh giá chất lượng kiểm thử Nhưng kiểm thử đột biến chưa sử dụng rộng rãi thực tế vấn đề hạn chế: số lượng đột biến sinh nhiều, vấn đề lỗi thực tế đột biến vấn đề đột biến tương đương Kiểm thử đột biến bậc cao đề xuất để khắc phục hạn chế Chúng giới thiệu phương pháp để ứng dụng kiểm thử đột biến bậc cao cách sử dụng thuật toán tối ưu hóa đa mục tiêu (và thuật toán đề xuất chúng tôi), phương pháp phân loại đột biến, hàm mục tiêu hàm thích nghi Chúng tìm kiếm Đột biến bậc cao chất lượng cao hợp lý để thay cho tất đột biến bậc kết hợp tạo nên chúng mà không làm giảm hiệu kiểm thử phản ánh lỗi phức tạp yêu cầu nhiều thay đổi để hiệu chỉnh chúng Phương pháp có hiệu việc: (1) Giảm chi phí tính toán kiểm thử đột biến nhờ vào việc giảm số lượng đột biến sinh ra; (2) Các đột biến khó để bị diệt phản ánh lỗi thực tế phần mềm Ngoài ra, đưa chặn hợp lý bậc đột biến kiểm thử đột biến bậc cao giảm chi phí kiểm thử đột biến ABSTRACT Software testing is always one of the important activities in order to evaluate the software quality Mutation testing is a powerful technique to evaluate the quality of test suites Unfortunately, it is not yet widely used due to the problems of a large number of generated mutants, limited realism (mutants not necessarily reflect real software defects), and equivalent mutants problem Higher order mutation (HOM) testing has been proposed to overcome these limitations of first order mutation testing We present an our approach to apply higher order mutation testing by using multi-objective optimization algorithms (including one modified by us), as well as our classification of HOMs, proposed objectives and fitness functions We search for “High Quality and Reasonable HOMs” able to replace all of its constituent FOMs without scarifying test effectiveness and to reflect complex defects requiring more than one change to correct them Our approach leads to: 1) reduced cost of mutation testing due to reduced number of HOMs, 2) harder to kill mutants (which mimic harder to find defects) and represent more real-defects of software Furthermore, we establish a relevant upper bound on mutation order in higher order mutation testing and thus reduce the cost of mutation even further Từ khóa: Kiểm thử đột biến; Kiểm thử đột biến bậc cao; Đột biến bậc cao; Thuật toán tối ưu hóa đa mục tiêu 1 ĐẶT VẤN ĐỀ Một sản phẩm phần mềm không đơn giản đoạn mã chương trình, mà bao gồm nhiều thành phần, với nhiều vai trò khác nhau, ẩn đằng sau [1][2] Do đó, việc xảy lỗi phần mềm không công đoạn lập trình, mà xảy tất công đoạn khác quy trình phát triển phần mềm, với xác suất cao thấp khác Có nhiều cách định nghĩa khác lỗi phần mềm, lại, phát biểu cách tổng quát: “Lỗi phần mềm không khớp chương trình đặc tả nó“ [16] Kiểm thử công đoạn đóng vai trò tối quan trọng định đến việc đánh giá chất lượng sản phẩm phần mềm [16] Đó trình tìm lỗi tiến hành tất phần tạo nên sản phẩm phần mềm đánh giá cuối đặc tả, thiết kế, mã hoá … Mục đích kiểm thử đảm bảo tất thành phần phần mềm ăn khớp, vận hành mong đợi phù hợp tiêu chuẩn thiết kế Thông thường, dễ dàng để nói kiểm thử phần mềm có thực công việc kiểm thử cách triệt để chương trình kiểm thử hay không [1][2] Nếu chương trình “thông qua” công cụ kiểm thử, nói chương trình hoạt động đắn trường hợp kiểm thử mà đề cập đến kiểm thử Tuy nhiên, xác trường hợp kiểm thử, đặc biệt liệu kiểm thử, xây dựng chưa thể chắn Ngoài ra, nhiều trường hợp mà chưa đề cập đến (thiếu) trường hợp kiểm thử [1] Do vậy, nói cách xác chương trình qua kiểm thử có khả hoạt động tốt thực tế Cần phải có phương pháp khoa học để đánh giá xác trường hợp kiểm thử liệu kiểm thử Từ đó, kiểm thử đột biến giới thiệu ý tưởng để giải vấn đề xác hay không xác liệu kiểm thử [1][2] Tuy nhiên, thực tế rằng, kiểm thử đột biến tồn nhiều vấn đề lớn ảnh hưởng nhiều đến việc áp dụng kỹ thuật vào thực tế Rất nhiều kỹ thuật phương pháp đề xuất nhằm cải tiến kỹ thuật kiểm thử đột biến Trong đó, kỹ thuật đột biến bậc cao xem phương pháp hiệu đồng thời hạn chế lúc vấn đề kỹ thuật kiểm thử đột biến truyền thống HẠN CHẾ CỦA KIỂM THỬ PHẦN MỀM [1] Kiểm thử phần mềm hoạt động quan trọng để đánh giá chất lượng phần mềm xây dựng Tuy nhiên chất lượng tập trường hợp kiểm thử (trong bao gồm liệu kiểm thử) vấn đề cần tranh luận Theo định nghĩa tổ chức IEEE, trường hợp kiểm thử “một tập hợp gồm liệu đầu vào, điều kiện thực kết đầu mong muốn xây dựng cho mục tiêu/chức cụ thể phần mềm” Một tập trường hợp kiểm thử chất lượng “một tập trường hợp kiểm thử (bao gồm liệu thử) phát tất lỗi mà phần mềm có” Tuy nhiên, không chắn tập trường hợp kiểm thử cho trước (được xây dựng đội ngũ kiểm thử viên) phát tất lỗi phần mềm hay không Ngoài ra, nhiều trường hợp kiểm thử khác mà kiểm thử viên không đề cập đến xây dựng tập trường hợp kiểm thử Thêm vào đó, trình kiểm thử, thưòng mắc phải đặc trưng nguyên lý chủ quan sau: + Bộ liệu kiểm thử không thay đổi trình xây dựng phần mềm + Chỉ kiểm thử trường hợp thống, hợp lệ, không quan tâm đến cận cố + Cài đặt chức kiểm thử riêng chức đó, không kiểm thử tổng hợp chức vừa cài đặt với chức cài đặt trước Từ lý đó, kiểm thử đột biến đời kỹ thuật nhằm đánh giá chất lượng trường hợp kiểm thử xây dựng để kiểm thử phần mềm KỸ THUẬT KIỂM THỬ ĐỘT BIẾN 3.1 Tổng quan kỹ thuật kiểm thử đột biến Kiểm thử đột biến (mutation testing) kỹ thuật đề xuất năm 1977-1978 Hamlet [4] DeMillo [3] Kỹ thuật xây dựng vào hai giả thuyết [1][2][3][4] Giả thuyết “Lập trình viên giỏi” (The Competent Programmer Hypothesis) giả thuyết “Hiệu ứng liên kết” (Coupling Effect Hypothesis) Giả thuyết “Lập trình viên giỏi” cho thông thường lập trình viên giỏi họ không viết chương trình cách tuỳ tiện, cẩu thả Với yêu cầu đặt ra, lập trình viên trình viết lệnh cho chương trình có sai lầm, tạo chương trình “gần” với với chương trình (được cho) đúng, có nghĩa chương trình vài thay đổi nhỏ so với chương trình Những thay đổi nhỏ không phát chỉnh sửa, làm cho kết đầu không mong muốn Các chương trình biên dịch thực thi cách bình thường lập trình viên trình biên dịch phát lỗi Hơn thế, chương trình “thông qua” kiểm thử cách dễ dàng Giả thuyết “Hiệu ứng liên kết” cho tất lỗi đơn giản phát loại bỏ tất các lỗi phức tạp loại bỏ Điều giả thuyết quan niệm lỗi phức tạp tạo nên lỗi đơn giản Kiểm thử đột biến kỹ thuật kiểm thử hộp trắng - kỹ thuật kiểm thử [1] Nói xác công cụ hỗ trợ cho công việc kiểm thử, tạo với mục đích kiểm tra, đánh giá kiểm thử giúp cho việc tạo kiểm thử tốt, việc tìm lỗi chương trình Nó xây dựng hoạt động gắn liền với tiêu chuẩn xác Trong kiểm thử phần mềm tập trung vào việc đánh giá chất lượng phần mềm cách tìm tất lỗi phần mềm, kiểm thử đột biến tập trung vào việc đánh giá chất lượng trường hợp kiểm thử (bao gồm liệu kiểm thử) Ý tưởng kiểm thử đột biến sau: Giả thiết có kiểm thử hoàn hảo, nghĩa kiểm thử bao gồm tất trường hợp kiểm thử Và giả thiết có chương trình hoàn hảo (được gọi chương trình gốc), “thông qua” kiểm thử hoàn hảo Bây giờ, công việc kiểm thử đột biến xác định tính thích hợp (hay gọi tính xác) trường hợp kiểm thử kiểm thử nói Trước tiên, tạo phiên khác chương trình gốc cách chèn lỗi vào mã nguồn Các phiên gọi đột biến Mỗi đột biến tạo thay đổi cú pháp chương trình gốc Mỗi thay đổi cú pháp luật hay gọi toán tử đột biến (mutation operator) Lưu ý rằng, đột biến chương trình “hợp lệ” lỗi sau biên dịch Sau đó, thực thi kiểm thử với trường hợp kiểm thử cho đột biến với mục đích so sánh kết đầu phiên lỗi với chương trình gốc, từ đánh giá tính thích hợp trường hợp kiểm thử Khi tiến thành thực thi kiểm thử chương trình gốc P đột biến P’ P với trường hợp kiểm thử T, có hai kịch khác xảy ra: + Một là, lỗi chèn vào chương trình đột biến P’ bị nhận biết, nghĩa thông qua trường hợp kiểm thử T chương trình P đột biến P’ cho kết khác Trong trường hợp này, đột biến P’ gọi bị diệt trường hợp kiểm thử T T gọi trường hợp kiểm thử thích hợp T có khả phát khác chương trình gốc P (chương trình đúng) đột biến P’ (chương trình sai) + Hai là, chương trình gốc P đột biến P’ cho kết hoàn toàn giống Trong trường hợp có hai khả xuất Khả thứ trường hợp kiểm thử T không đủ tốt (T gọi trường hợp kiểm thử không thích hợp), phải tiến hành thực kiểm thử lại với kiểm thử tốt Khả thứ hai chương trình P đột biến P’ chương trình tương tự nhau, kiểm thử tìm cách phân biệt khác chúng, đột biến P’ gọi đột biến tƣơng đƣơng Trong hai trường hợp này, đột biến P’ cho sống Chúng ta có ví dụ đột biến (Hình 1a) đột biến tương đương (Hình 1b) hình vẽ sau: (a) (b) Hình Ví dụ đột biến đột biến tƣơng đƣơng Các đột biến tƣơng đƣơng (Equivalent Mutant) đột biến chương trình gốc hoạt động hoàn toàn giống với chương trình gốc cho kết giống với chương trình gốc trường hợp kiểm thử Một vấn đề đặt định đột biến P’ có phải đột biến tương đương với chương trình gốc P hay không, nhiều trường hợp, định Quy trình kiểm thử đột biến “truyền thống” biểu diễn cách đơn giản Hình Begin Chƣơng trình gốc P Chỉnh sửa False Tạo đột biến P’ Tạo trƣờng hợp kiểm thử T P ? Thực T với P True True End Các đột biến bị diệt ? False Thực trƣờng hợp kiểm thử với đột biến “còn sống” Phân tích đánh dấu đột biến tƣơng đƣơng Hình – Quy trình kiểm thử đột biến Có giá trị để đánh giá chất lượng kiểm thử kỹ thuật kiểm thử đột biến, MSI (Mutation Score Indicator) MS (Mutation Score) để đánh giá [9-14] MSI tính tỷ lệ số lượng đột biến bị diệt tổng số đột biến sinh Trong đó, MS tính tỷ lệ số lượng đột biến bị diệt tổng số đột biến sinh trừ số lượng đột biến tương đương Cả hai giá trị chạy từ đến Một tập trường hợp kiểm thử có chất lượng có giá trị MSI/MS gần 1, ngược lại giá trị tiến đến 0, nói tập trường hợp kiểm thử không đảm bảo chất lượng hầu hết trường hợp kiểm thử không phát ta khác biệt chương trình gốc đột biến tạo 3.2 Hạn chế kỹ thuật kiểm thử đột biến Kỹ thuật kiểm thử đột biến (hay gọi kiểm thử đột biến bậc 1) đề cập đến phương pháp có tự động hóa hiệu cao việc đánh giá chất lượng liệu thử Nó áp dụng cho kiểm thử phần mềm, với nhiều ngôn ngữ lập trình khác nhiều mức kiểm thử khác nhau, kiểm thử đơn vị, kiểm thử tích hợp, kiểm thử hệ thống, kiểm thử chấp nhận,… Tuy nhiên, chưa áp dụng rộng rãi tồn hạn chế [9], cụ thể sau: - Thứ nhất, số lượng đột biến sinh nhiều Như trình bày trên, đột biến sinh thay đổi toán tử đột biến Một chương trình bao gồm nhiều toán tử dòng lệnh khác nhau, số lượng đột biến tạo lớn Ví dụ, có chương trình đơn gián với câu lệnh trả giá trị phép toán “a+b”, có đột biến chứa phép toán khác, “a-b”, “a*b”, “a/b”, “a+b++”, “a+0”, “0+b”,… Số lượng đột biến lớn dẫn đến vấn đề phí tính toán lớn trường hợp kiểm thử không thực chương trình gốc mà phải thực tất đột biến sinh Ví dụ có chương trình gốc, 150 đột biến sinh 200 trường hợp kiểm thử cho trước Như phải thực (1+150)*200 = 30200 lần chạy kiểm thử so sánh kết đầu - Thứ hai, vấn đề liệu đột biến có miêu tả lỗi thực phần mềm hay không Các đột biến sinh việc chèn lỗi đơn giản (thay đổi toán tử đột biến), không chứng tỏ cách xác lỗi thực phần mềm, lỗi đơn giản Theo Langdon cộng [7][8], 90% lỗi phần mềm lỗi phức tạp - Thứ ba, vấn đề đột biến tương đương Trong thực tế, có nhiều toán tử đột biến dùng để tạo đột biến tương đương có “hành vi” với chương trình gốc Trong trường hợp này, có trường hợp kiểm thử đột biến tự động phát khác chương trình gốc đột biến tương đương Điều phát phương pháp thủ công, ví dụ dùng kỹ thuật tra mã nguồn Bình quân khoảng 10-15 phút để kiểm tra phát đột biến không bị diệt trường hợp kiểm thử cho trước có thật đột biến tương đương hay không Vì đột biến không bị diệt trường hợp kiểm thử cho trước “đột biến khó bị diệt” (đòi hỏi phải thiết kế trường hợp kiểm thử tốt hơn, mục đích kỹ thuật kiểm thử), đột biến tương đương thật Chúng thực tìm kiểm, thống kê đánh giá tất kỹ thuật, phương pháp để xuất để cải tiến vấn đề hạn chế nói kỹ thuật kiểm thử đột biến từ năm 1977 đến cuối năm 2014 [9] Có nhiều kỹ thuật đề xuất Đột biến mẫu, Đột biến lựa chọn, Đột biến nhóm, Đột biến yếu, Đột biến bậc cao,… để cải thiện hạn chế thứ nhất; Đột biến bậc cao để cải tiến hạn chế thứ hai; Tối ưu hóa biên dịch, Sử dụng mô hình kiểm tra Lesar, Đột biến lựa chọn, Đồng tiến hóa, Đột biến bậc cao,… để cải tiến hạn chế thứ ba Trong số đó, kiểm thử đột biến bậc cao không kỹ thuật cải tiến hạn chế thứ hai mà kỹ thuật đồng thời cải tiến ba hạn chế kỹ thuật đột biến truyền thống [9-14] 4 KỸ THUẬT KIỂM THỬ ĐỘT BIẾN BẬC CAO Kỹ thuật kiểm thử đột biến bậc cao (higher order mutation testing) ý tưởng Jia, Harman cộng vào năm 2009 [5][6] Họ chia đột biến thành loại: Đột biến bậc (được dùng kỹ thuật kiểm thử đột biến truyền thống (do gọi kỹ thuật kiểm thử đột biến bậc 1), dùng thay đổi toán tử đột biến để tạo đột biến) Đột biến bậc cao (sử dụng từ trở lên thay đổi toán tử đột biến để tạo đột biến, gọi kỹ thuật kiểm thử đột biến bậc cao) Trong kỹ thuật kiểm thử đột biến bậc cao, đột biến bao gồm từ trở lên sai khác (lỗi) so với chương trình gốc Cho đến tháng tháng 02 năm 2015, có tất 15 báo khoa học xuất có đề cập đến việc áp dụng kỹ thuật kiểm thử đột biến bậc cao [15] Chúng [15] chia kỹ thuật giới thiệu báo thành nhóm: Kiểm thử đột biến bậc Kiểm thử đột biến bậc n Với nhóm kiểm thử đột biến bậc 2, tác giả sử dụng thay đổi thông qua toán tử đột biến để tạo đột biến Do đột biến sinh gọi đột biến bậc Có nhóm tác giả để xuất thuật toán khác để áp dụng kiểm thử đột biến bậc Hình thể so sánh kết nhóm tác giả góc nhìn tỷ lệ (%) việc giảm số lượng đột biến (Mutant Reduction) giảm số lượng đột biến tương đương (Equivalent Mutant Reduction) Qua đó, thấy số lượng đột biến giảm khoảng 50% số lượng đột biến tương đương giảm xuống từ 40% đến 78% Hình So sánh kết nhóm tác giả sử dụng đột biến bậc Với nhóm kỹ thuật đột biến bậc n, xem xét tác giả sử dụng từ đến n thay đổi thông qua toán tử đột biến để tạo đột biến Do đột biến gọi đột biến bậc n Có nhóm tác giả đề xuất việc áp dụng thuật toán tối ưu hóa mục tiêu tối ưu hóa đa mục tiêu để tìm kiếm đột biến bậc cao thích hợp, theo phân loại họ Cụ thể phương pháp kết nhóm tác giả thống kê, phân tích trình bày báo khoa học [10-15] Các tác giả sử dụng từ đến 70 thay đổi để tạo đột biến từ bậc đến bậc 70 Kết nghiên cứu tác giả chứng tỏ rằng, với kỹ thuật kiểm thử đột biến bậc cao, đột biến sinh phức tạp khó bị diệt Điều chứng tỏ, đột biến miêu tả với lỗi thực phần mềm đột biến bậc Ngoài ra, với đột biến khó bị diệt, có nghĩa cần cải thiện chất lượng kiểm thử nhằm phát khác biệt đột biến chương trình gốc Dó chất lượng kiểm thử tăng lên so với kiểm thử chương trình gốc Một kết đáng lưu ý kỹ thuật kiểm thử đột biến bậc cao số lượng đột biến tương đương giảm xuống Tuy nhiên, có hạn chế lớn nhóm số lượng đột biến tăng nhanh theo bậc đột biến Ví dụ phương pháp Langdon cộng [7][8], họ sử dụng thuật toán NSGA-II, thuật toán tối ưu hóa đa mục tiêu, với lập trình di truyền để tìm đột biến phức tạp khó bị diệt Số lượng đột biến tương đương giảm nhiều, số lượng đột biến sinh số “khổng lồ” Với chương trình C đơn giản, có 17 lượt sử dụng toán tử so sánh (bao gồm toán tử so sánh ), có 85 đột biến bậc 1, 3400 đột biến bậc 2, 85000 đột biến bậc 3, 1487500 đột biến bậc 4, MỘT PHƢƠNG PHÁP NÂNG CAO HIỆU QUẢ CỦA KỸ THUẬT KIỂM THỬ ĐỘT BIẾN BẬC CAO Chúng thực đánh giá thực nghiệm hiệu việc áp dụng kỹ thuật kiểm thử đột biến thuật toán tối ưu hóa đa mục tiêu dựa đề xuất Trước tiên, đưa cách phân loại đột biến bậc cao nhằm bao phủ hết tất trường hợp có đột biến sinh [10-15] Trong cách phân loại chúng tôi, có tất 11 nhóm đột biến Trong nhóm đột biến “Chất lƣợng cao hợp lý” (High quality and Reasonable HOMs) [10-15] nhóm đột biến mà tập trung vào tìm kiếm Các đột biến tạo cách kết hợp đột biến bậc lại với nhau, khó bị diệt đột biến bậc (Hợp lý) tập trường hợp kiểm thử diệt đột biến đồng thời diệt tất đột biến bậc kết hợp để tạo (Chất lƣợng cao) Đây đột biến mà thay tất đột biến bậc không làm giảm hiệu kiểm thử đột biến Điều làm giảm số lượng đột biến sinh đồng thời giải vấn đề đột biến tương đương miêu tả lỗi thực tế phần mềm Tiếp theo, chúng tôi, để hàm mục tiêu hàm thích nghi để từ áp dụng thuật toán tối ưu hóa đa mục tiêu vào lĩnh vực kiểm thử đột biến bậc cao [10-15] Chúng sử dụng phần mềm Java thực, mã nguồn mở (trong bao gồm kiểm thử tạo đội ngũ kiểm thử phần mềm này, tải từ trang http://sourceforge.net) thuật toán eMOEA, NSGAII, eNSGAII, NSGAIII Random [10-15] (tham khảo thêm trang http://www.moeaframework.org), bên cạnh việc sử dụng thuật toán đề xuất (eNSGAII-DiffLOC), để tìm kiếm đột biến bậc cao chất lượng cao hợp lý eNSGAII-DiffLOC thuật toán đề đề xuất dựa thay đổi thuật toán eNSGAII với nguyên tắc “Không có thay đổi (lỗi) dòng lệnh” Sở dĩ lựa chọn thuật toán eNSGA để thay đổi đánh giá thực nghiệm thực tế chúng tôi, thuật toán tốt việc tạo đột biến Chất lƣợng cao hợp lý [15] Chúng sử dụng công cụ Judy (có thể tham khảo trang http://mutationtesting.org/), công cụ tạo chúng tôi, để sinh tự động đột biến bậc cao từ bậc đến bậc 15 cách áp dụng thuật toán tối ưu hóa đa mục tiêu dựa hàm mục tiêu thích nghi Bên cạnh đó, công cụ Judy thực việc kiểm thử đột biến đánh giá đột biến Hiện này, công cụ Judy công cụ hỗ trợ số lượng lớn toán tử đột biến có ngôn ngữ lập trình Java Những kết thực nghiệm chứng tỏ phương pháp đề xuất có hiệu cao việc áp dụng kiểm thử đột biến nói chung, kỹ thuật kiểm thử đột biến bậc cao nói riêng [10-15] Cụ thể giảm chi phí tính toán thông qua việc giảm số lượng đột biến, tăng độ thực lỗi (đột biến), giúp hướng đến việc tạo trường hợp kiểm thử tốt Điều có nghĩa góp phần vào việc cải thiện chất lượng kiểm thử phần mềm thông qua việc đánh giá chất lượng kiểm thử Từ kết thực nghiệm, đưa kết luận hữu ích [15] việc áp dụng kiểm thử đột biến bậc cao thuật toán tối ưu hóa đa mục tiêu để hạn chế vấn đề tồn kỹ thuật kiểm thử đột biến, cụ thể sau: (1) Có thể giảm chi phí tính toán kiểm thử đột biến phương pháp số lượng đột biến sinh (từ bậc đến bậc 15) giảm khoảng 78% so với số lượng đột biến bậc (2) Trong phương pháp chúng tôi, đột biến bậc cao sinh khó bị diệt phức tạp đột biến bậc kết hợp để tạo Từ dẫn đến yêu cầu phải tạo kiểm thử chất lượng để kiểm thử phần mềm (3) Phương pháp hạn chế việc sinh đột biến dễ bị diệt không hợp lý Các đột biến bị diệt số lượng trường hợp kiểm thử nhiều đột biến bậc kết hợp tạo nên chúng Và trường hợp kiểm thử đồng thời diệt chúng đột biến bậc tạo nên chúng (4) Bậc bậc lớn mà sử dụng kiểm thử đột biến bậc cao Vì số lượng đột biến Chất lƣợng cao hợp lý sinh với tỷ lệ cao (so với tổng số đột biến sinh ra) từ bậc đến bậc Từ bậc trở lên, số lượng đột biến nhỏ, chí gần Trong đó, số lượng đột biến sống (không bị diệt kiểm thử cho, bao gồm đột biến tương đương) cao, chiếm khoảng từ 25% đến 55%, cho tất bậc từ đến 15 (5) Không nên sử dụng đột biến bậc bị diệt để tạo đột biến bậc cao (từ bậc trở lên), đột biến bậc cao dễ bị diệt (6) Thuật toán eNSGAII-DiffLOC đề xuất tốt thuật toán eNSGAII (đây thuật toán tốt thuật toán áp dụng) phương diện cải thiện chất lượng kiểm thử đột biến 6 KẾT LUẬN Dựa vào ưu điểm, nhược điểm kỹ thuật kiểm thử đột biến, kỹ thuật đột biến bậc cao, đề xuất, thực nghiệm đánh giá kết phương pháp ứng dụng kiểm thử đột biến bậc cao thuật toán tối ưu hóa đa mục tiêu nhằm nâng cao hiệu quả, giảm chi phí thời gian trình kiểm thử phần mềm nói chung quy trình ứng dụng kiểm thử đột biến nói riêng Ngoài ra, cung cấp giải pháp bao gồm cách phân loại đột biến để bao trùm hết trường hợp đột biến sinh ra, hàm mục tiêu, hàm thích nghi cách kết hợp đột biến bậc để tạo đột biến bậc cao Từ dùng để làm tài liệu tham khảo áp dụng thực tế cho đơn vị phát triển phần mềm cần nâng cao chất lượng kiểm thử phần mềm TÀI LIỆU THAM KHẢO Tiếng Việt [1] Nguyễn Quang Vũ (2007), Nghiên cứu ứng dụng kiểm thử đột biến (mutation testing) cho chương trình C#, Luận văn thạc sĩ kỹ thuật, Chuyên ngành khoa học máy tính, Trường đại học Bách khoa - Đại học Đà Nẵng [2] Nguyễn Thanh Bình, Nguyễn Quang Vũ (2009), “Ứng dụng kỹ thuật đột biến để kiểm thử chương trình C#”, Tạp chí Khoa học Công nghệ Đại học Đà Nẵng, (5(34).2009), 8-15 Tiếng Anh [3] R A DeMillo, R J Lipton, and F G Sayward Hints on Test Data Selection: Help for the Practicing Programmer, Computer, vol 11, no 4, pp 34–41, April 1978 [4] R G Hamlet Testing Programs with the Aid of a Compiler IEEE Transactions on Software Engineering, vol 3, no 4, pp 279–290, July 1977 [5] Y Jia and M Harman Higher order mutation testing Information and Software Technology, 51:1379–1393, 2009 [6] M Harman, Y Jia, and W B Langdon A manifesto for higher order mutation testing Third International Conf on Software Testing, Verification, and Validation Workshops, 2010 [7] W.B Langdon, M Harman, and Y Jia Multi-objective higher order mutation testing with genetic programming Proceedings Fourth Testing: Academic and Industrial Conference Practice and Research, 2009 [8] W.B Langdon, M Harman, and Y Jia Efficient multiobjective higher order mutation testing with genetic programming The Journal of Systems and Software, 83, 2010 [9] Quang Vu Nguyen and L Madeyski Problems of mutation testing and higher order mutation testing Advanced Computational Methods for Knowledge Engineering, Advances in Intelligent Systems and Computing, 282, 2014 [10] Quang Vu Nguyen and L Madeyski Searching for strongly subsuming higher order mutants by applying multiobjective optimization algorithm Advanced Computational Methods for Knowledge Engineering , Advances in IntelligentSystemsandComputing,358:391–402,2015 [11] Quang Vu Nguyen and L Madeyski Higher order mutation testing to drive development of new test cases: an empirical comparison of three strategies Lecture Notes in Computer Science, 2016 [12] Quang Vu Nguyen and L Madeyski On the relationship between the order of mutation testing and the properties of generated higher order mutants Lecture Notes in Computer Science, 2016 [13] Quang Vu Nguyen and L Madeyski Empirical evaluation of multiobjective optimization algorithms searching for higher order mutants Cybernetic and Systems: An International Journal, 47 (1-2), 2016 [14] Quang Vu Nguyen and L Madeyski Addressing mutation testing problems by applying multi-objective optimization algorithms and higher order mutation Journal of Intelligent & Fuzzy Systems, 2016 [15] Quang Vu Nguyen Searching for high quality higher order mutants Wroclaw University of Science and Technology, PhD Thesis, 2016 [16] I Sommerville Software Engineering Addison-Wesley, 9th edition, 2011