Chúng tôi tìm kiếm các Đột biến bậc cao chất lượng cao và hợp lý để có thể thay thế cho tất cả các đột biến bậc 1 đã kết hợp tạo nên chúng mà không làm giảm đi hiệu quả của kiểm thử và p
Trang 1Khoa 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 luôn là một trong những hoạt động quan trọng nhằm đánh giá chất lượng phần mềm Trong khi đó, kiểm thử đột biến là một công cụ hữu hiệu để đánh giá chất lượng của các bộ kiểm thử Nhưng kiểm thử đột biến chưa được sử dụng rộng rãi trong thực tế bởi những vấn đề hạn chế: số lượng các đột biến được sinh ra quá nhiều, vấn đề lỗi thực tế của các đột biến và vấn đề đột biến tương đương Kiểm thử đột biến bậc cao được đề xuất để khắc phục các hạn chế đó Chúng tôi giới thiệu một phương pháp của chúng tôi để ứng dụng kiểm thử đột biến bậc cao bằng cách sử dụng các thuật toán tối ưu hóa đa mục tiêu (và một thuật toán đề xuất bởi chúng tôi), cũng như phương pháp phân loại đột biến, hàm mục tiêu và hàm thích nghi của chúng tôi Chúng tôi tìm kiếm các Đột biến bậc cao chất lượng cao và hợp lý để có thể thay thế cho tất cả các đột biến bậc 1
đã kết hợp tạo nên chúng mà không làm giảm đi hiệu quả của kiểm thử và phản ánh được các lỗi phức tạp yêu cầu nhiều hơn một thay đổi để hiệu chỉnh chúng Phương pháp của chúng tôi có hiệu quả trong 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 được sinh ra; (2) Các đột biến khó để bị diệt hơn và phản ánh các lỗi thực tế hơn của phần mềm Ngoài ra, chúng tôi cũng đưa ra một chặn trên hợp lý của bậc đột biến trong kiểm thử đột biến bậc cao và do đó giảm được 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
Trang 21 ĐẶT VẤN ĐỀ
Một sản phẩm phần mềm không chỉ đơn giản là các đoạn mã chương trình, mà nó còn bao gồm nhiều thành phần, với nhiều các vai trò khác nhau, ẩn đằng sau nó [1][2] Do đó, việc xảy ra các lỗi phần mềm không chỉ ở công đoạn lập trình, mà còn xảy ra ở tất cả các công đoạn khác nhau của quy trình phát triển phần mềm, với xác suất cao thấp khác nhau Có nhiều cách định nghĩa khác nhau
về lỗi phần mềm, nhưng chung quy lại, có thể phát biểu một cách tổng quát: “Lỗi phần mềm là sự không khớp giữa chương trình và đặc tả của nó“ [16]
Kiểm thử là một công đoạn đóng vai trò tối quan trọng và quyết định đến việc đánh giá chất lượng của một sản phẩm phần mềm [16] Đó là quá trình tìm lỗi được tiến hành trong tất cả các phần tạo nên một sản phẩm phần mềm và nó là một đánh giá cuối cùng về các đặc tả, thiết kế, mã hoá … Mục đích của kiểm thử
là đảm bảo rằng tất cả các thành phần của phần mềm ăn khớp, vận hành như mong đợi và phù hợp các tiêu chuẩn thiết kế
Thông thường, không thể dễ dàng để nói rằng một bộ kiểm thử phần mềm
có thực hiện công việc kiểm thử một cách triệt để một chương trình được kiểm thử hay không [1][2] Nếu một chương trình nào đó “thông qua” được công cụ kiểm thử, thì chúng ta chỉ có thể nói được rằng chương trình đó hoạt động đúng đắn trong các trường hợp kiểm thử mà đã được đề cập đến trong bộ kiểm thử Tuy nhiên, sự chính xác của các trường hợp kiểm thử, đặc biệt là bộ dữ liệu kiểm thử, đã được xây dựng cũng chưa thể chắc chắn được Ngoài ra, còn nhiều trường hợp mà chúng ta chưa đề cập đến (thiếu) trong các trường hợp kiểm thử [1] Do vậy, không thể nói một cách chính xác rằng chương trình đã qua kiểm thử có khả năng hoạt động tốt trong thực tế Cần phải có một phương pháp khoa học để đánh giá sự chính xác của các trường hợp kiểm thử và bộ dữ liệu kiểm thử
Từ đó, kiểm thử đột biến được giới thiệu như là một ý tưởng để giải quyết vấn đề chính xác hay không chính xác của các bộ dữ liệu kiểm thử [1][2] Tuy nhiên, thực tế đã chỉ ra rằng, kiểm thử đột biến cũng tồn tại nhiều vấn đề lớn ảnh hưởng rất nhiều đến việc áp dụng kỹ thuật này vào thực tế Rất nhiều kỹ thuật và phương pháp đã được đề 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 được xem như là một phương pháp hiệu quả có thể đồng thời hạn chế được cùng một lúc các vấn đề của kỹ thuật kiểm thử đột biến truyền thống
2 HẠN CHẾ CỦA KIỂM THỬ PHẦN MỀM [1]
Kiểm thử phần mềm luôn là một trong những hoạt động quan trọng nhất
để đánh giá chất lượng của một phần mềm được xây dựng Tuy nhiên chất lượng của tập các trường hợp kiểm thử (trong đó bao gồm cả bộ các dữ liệu kiểm thử) luôn là một vấn đề cần tranh luận Theo định nghĩa của tổ chức IEEE, trường hợp
kiểm thử là “một tập hợp gồm các dữ liệu đầu vào, các điều kiện thực hiện và các kết quả đầu ra mong muốn được xây dựng cho một mục tiêu/chức năng cụ thể của phần mềm” Một tập các trường hợp kiểm thử chất lượng là “một tập các trường hợp kiểm thử (bao gồm dữ liệu thử) có thể phát hiện ra tất cả các lỗi mà phần mềm có thể có” Tuy nhiên, chúng ta không chắc chắn rằng tập các trường
hợp kiểm thử cho trước (được xây dựng bởi đội ngũ kiểm thử viên) có thể phát
Trang 3hiện ra tất cả các lỗi của phần mềm hay không Ngoài ra, có thể còn rất nhiều các trường hợp kiểm thử khác mà các kiểm thử viên không đề cập đến trong khi xây dựng tập các trường hợp kiểm thử Thêm vào đó, trong quá trình kiểm thử, chúng
ta thưòng mắc phải các đặc trưng của nguyên lý chủ quan như sau:
+ Bộ dữ liệu kiểm thử không thay đổi trong quá trình xây dựng phần mềm + Chỉ kiểm thử các trường hợp chính thống, hợp lệ, không quan tâm đến các cận và các sự cố
+ Cài đặt chức năng nào thì chỉ kiểm thử riêng chức năng đó, không kiểm thử tổng hợp chức năng vừa cài đặt với các chức năng đã cài đặt trước đó
Từ những lý do đó, kiểm thử đột biến được ra đời như một kỹ thuật nhằm đánh giá chất lượng của các trường hợp kiểm thử được xây dựng để kiểm thử phần mềm
3 KỸ THUẬT KIỂM THỬ ĐỘT BIẾN
3.1 Tổng quan về kỹ thuật kiểm thử đột biến
Kiểm thử đột biến (mutation testing) là kỹ thuật được đề xuất đầu tiên ở những năm 1977-1978 bởi Hamlet [4] và DeMillo [3] Kỹ thuật này được xây
dựng căn cứ vào hai giả thuyết cơ bản [1][2][3][4] Giả thuyết “Lập trình viên giỏi” (The Competent Programmer Hypothesis) và 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 rằng thông
thường các lập trình viên đều rất giỏi và họ sẽ không bao giờ viết ra các chương trình một cách tuỳ tiện, cẩu thả Với các yêu cầu đã được đặt ra, một lập trình viên trong quá trình viết lệnh cho chương trình nếu có sai lầm, thì cũng sẽ tạo ra được các chương trình rất “gần” với với chương trình (được cho) là đúng, có nghĩa là một chương trình không đúng đó chỉ có một vài thay đổi rất nhỏ so với chương trình đúng Những thay đổi nhỏ này nếu không được phát hiện và chỉnh sửa, nó sẽ làm cho kết quả đầu ra không như mong muốn Các chương trình này vẫn được biên dịch và thực thi một cách bình thường và lập trình viên và trình biên dịch không thể phát hiện ra được lỗi của nó Hơn thế, các chương trình này
có thể “thông qua” các bộ kiểm thử một cách dễ dàng Giả thuyết “Hiệu ứng liên kết” cho rằng nếu tất cả các lỗi đơn giản được phát hiện và loại bỏ thì tất các các
lỗi phức tạp cũng được loại bỏ Điều đó là bởi vì giả thuyết này quan niệm các lỗi phức tạp được tạo nên bởi các lỗi đơn giản
Kiểm thử đột biến là một kỹ thuật kiểm thử hộp trắng - một kỹ thuật kiểm thử cơ bản [1] Nói chính xác hơn nó là một công cụ hỗ trợ cho công việc kiểm thử, được tạo ra với mục đích kiểm tra, đánh giá các bộ kiểm thử và giúp cho việc tạo ra các bộ kiểm thử tốt, hơn là việc tìm lỗi của các chương trình Nó được xây dựng và hoạt động gắn liền với tiêu chuẩn chính xác Trong khi kiểm thử phần mềm tập trung vào việc đánh giá chất lượng phần mềm bằng cách tìm ra tất
cả các lỗi của phần mềm, thì kiểm thử đột biến tập trung vào việc đánh giá chất lượng của các trường hợp kiểm thử (bao gồm cả dữ liệu kiểm thử)
Ý tưởng chính của kiểm thử đột biến như sau: Giả thiết rằng chúng ta có một bộ kiểm thử hoàn hảo, nghĩa là bộ kiểm thử này bao gồm tất cả các trường hợp kiểm thử có thể Và cũng giả thiết rằng chúng ta có một chương trình hoàn hảo (được gọi là chương trình gốc), đã được “thông qua” bộ kiểm thử hoàn hảo
Trang 4này Bây giờ, công việc chính của kiểm thử đột biến là xác định được tính thích hợp (hay còn gọi là tính chính xác) của các trường hợp kiểm thử trong bộ kiểm thử nói trên Trước tiên, chúng ta tạo ra các phiên bản khác nhau của chương trình gốc bằng cách chèn lỗi vào mã nguồn của nó Các phiên bản này được gọi
là các đột biến Mỗi đột biến được tạo ra bởi chỉ một sự thay đổi cú pháp trong
chương trình gốc Mỗi sự thay đổi cú pháp là một luật hay còn được gọi là một
toán tử đột biến (mutation operator) Lưu ý rằng, các đột biến này là các chương
trình “hợp lệ” và không có lỗi sau khi biên dịch Sau đó, chúng ta thực thi bộ kiểm thử với lần lượt các trường hợp kiểm thử cho từng đột biến với mục đích so sánh kết quả đầu ra của từng phiên bản lỗi với chương trình gốc, từ đó đánh giá được tính thích hợp của các trường hợp kiểm thử Khi tiến thành thực thi kiểm thử lần lượt chương trình gốc P và đột biến P’ của P với một trường hợp kiểm thử T, sẽ có hai kịch bản khác nhau có thể xảy ra:
+ Một là, lỗi được chèn vào trong chương trình đột biến P’ bị nhận biết, nghĩa là thông qua trường hợp kiểm thử T chương trình P và đột biến P’ cho ra
các kết quả khác nhau Trong trường hợp này, đột biến P’ được gọi là bị diệt bởi
trường hợp kiểm thử T và T được gọi là trường hợp kiểm thử thích hợp vì T có khả năng phát hiện được những khác nhau giữa chương trình gốc P (chương trình đúng) và đột biến P’ (chương trình sai)
+ Hai là, chương trình gốc P và đột biến P’ cho ra kết quả hoàn toàn giống nhau Trong trường hợp này sẽ có hai khả năng có thể xuất hiện Khả năng thứ nhất là trường hợp kiểm thử T không đủ tốt (T được gọi là trường hợp kiểm thử không thích hợp), chúng ta sẽ phải tiến hành thực hiện kiểm thử lại với một bộ kiểm thử tốt hơn Khả năng thứ hai là chương trình P và đột biến P’ là những chương trình tương tự nhau, không có một bộ kiểm thử nào tìm ra được cách
phân biệt sự khác nhau giữa chúng, đột biến P’ được gọi là đột biến tương đương Trong cả hai trường hợp này, đột biến P’ được cho là còn sống
Chúng ta có một ví dụ về đột biến (Hình 1a) và đột biến tương đương (Hình 1b) như hình vẽ sau:
(a) (b)
Hình 1 Ví dụ về đột biến và đột biến tương đương Các đột biến tương đương (Equivalent Mutant) là các đột biến của
chương trình gốc nhưng hoạt động hoàn toàn giống với chương trình gốc và cho
Trang 5ra kết quả giống với chương trình gốc trong mọi trường hợp kiểm thử Một vấn
đề đặt ra là quyết định một đột biến P’ có phải là đột biến tương đương với chương trình gốc P hay không, trong nhiều trường hợp, là không thể quyết định được
Quy trình kiểm thử đột biến “truyền thống” được biểu diễn một cách đơn giản như trong Hình 2
Hình 2 – Quy trình kiểm thử đột biến
Có 2 giá trị để đánh giá chất lượng của các bộ kiểm thử trong kỹ thuật kiểm thử đột biến, đó là MSI (Mutation Score Indicator) và MS (Mutation Score)
để đánh giá [9-14] MSI được tính bằng tỷ lệ của số lượng đột biến bị diệt trên tổng số đột biến được sinh ra Trong khi đó, MS được tính bằng tỷ lệ của số lượng đột biến bị diệt trên tổng số đột biến sinh ra trừ đi số lượng đột biến tương đương Cả hai giá trị đều chạy từ 0 đến 1 Một tập các trường hợp kiểm thử có chất lượng sẽ có giá trị MSI/MS gần bằng 1, và ngược lại khi giá trị tiến đến 0, chúng ta có thể nói tập các trường hợp kiểm thử đó không đảm bảo chất lượng vì hầu hết các trường hợp kiểm thử đều không phát hiện ta sự khác biệt giữa chương trình gốc và các đột biến được tạo ra
3.2 Hạn chế của kỹ thuật kiểm thử đột biến
Kỹ thuật kiểm thử đột biến (hay còn được gọi là kiểm thử đột biến bậc 1) được đề cập đến như là một phương pháp có sự tự động hóa và hiệu quả cao
End True
False
gốc P
Tạo các đột biến P’
Tạo các trường hợp kiểm thử T
Thực hiện T với P
P đúng
?
True
Chỉnh sửa
Thực hiện các trường hợp kiểm thử với từng đột biến “còn sống”
Các đột biến đều
bị diệt ?
False
Phân tích và đánh dấu các đột biến tương đương
Trang 6trong việc đánh giá chất lượng của các bộ dữ liệu thử Nó có thể được áp dụng cho kiểm thử phần mềm, với nhiều ngôn ngữ lập trình khác nhau và tại nhiều mức kiểm thử khác nhau, như 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, nó vẫn chưa được áp dụng rộng rãi vì vẫn còn tồn tại 3 hạn chế chính [9], cụ thể như sau:
- Thứ nhất, đó là số lượng các đột biến được sinh ra quá nhiều Như đã trình bày ở trên, các đột biến được sinh ra bởi sự thay đổi duy nhất một toán tử đột biến Một chương trình có thể bao gồm rất nhiều toán tử ở các dòng lệnh khác nhau, vì vậy số lượng các đột biến được tạo ra là rất lớn Ví dụ, có một chương trình đơn gián chỉ với một câu lệnh chính là trả về giá trị của phép toán
“a+b”, chúng ta có thể có các đột biến chứa các phép toán khác, như “a-b”,
“a*b”, “a/b”, “a+b++”, “a+0”, “0+b”,… Số lượng các đột biến lớn sẽ dẫn đến vấn đề chính phí tính toán lớn bởi vì những trường hợp kiểm thử không chỉ được thực hiện trên chương trình gốc mà còn phải thực hiện trên tất cả các đột biến được sinh ra Ví dụ chúng ta có 1 chương trình gốc, 150 đột biến được sinh ra và
200 trường hợp kiểm thử được cho trước Như vậy chúng ta phải thực hiện (1+150)*200 = 30200 lần chạy kiểm thử và so sánh kết quả đầu ra
- Thứ hai, đó là vấn đề liệu các đột biến đó có miêu tả đúng các lỗi thực sự của phần mềm hay không Các đột biến được sinh ra bởi việc chèn lỗi đơn giản (thay đổi các toán tử đột biến), do đó nó sẽ có thể không chứng tỏ một cách chính xác các lỗi thực của phần mềm, vì các lỗi này quá đơn giản Theo Langdon và các cộng sự [7][8], 90% lỗi của các phần mềm là các lỗi phức tạp
- Thứ ba, đó là vấn đề các đột biến tương đương Trong thực tế, có rất nhiều các toán tử đột biến có thể được dùng để tạo ra các đột biến tương đương
có cùng “hành vi” với chương trình gốc Trong trường hợp này, không thể có bất
kỳ một trường hợp kiểm thử đột biến nào có thể tự động phát hiện được sự khác nhau giữa chương trình gốc và đột biến tương đương của nó Điều này chỉ có thể phát hiện được bằng phương pháp thủ công, ví dụ như dùng kỹ thuật thanh tra mã nguồn Bình quân chúng ta có thể mất khoảng 10-15 phút để kiểm tra và phát hiện một đột biến không bị diệt bởi các trường hợp kiểm thử đã cho trước có thật
sự là đột biến tương đương hay không Vì một đột biến không bị diệt bởi các trường hợp kiểm thử cho trước hoặc là “đột biến khó bị diệt” (đòi hỏi chúng ta phải thiết kế các trường hợp kiểm thử tốt hơn, đây chính là mục đích của kỹ thuật kiểm thử), hoặc là đột biến tương đương thật sự
Chúng tôi đã thực hiện tìm kiểm, thống kê và đánh giá tất cả các kỹ thuật, phương pháp được để xuất để cải tiến các vấn đề hạn chế nói trên của kỹ thuật kiểm thử đột biến từ năm 1977 đến cuối năm 2014 [9] Có rất nhiều kỹ thuật đã được đề xuất như Độ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 chỉ là kỹ thuật duy nhất có thể
cải tiến được hạn chế thứ hai mà còn là kỹ thuật duy nhất đồng thời có thể cải tiến cả ba hạn chế của kỹ thuật đột biến truyền thống [9-14]
Trang 74 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) là ý tưởng của Jia, Harman và các cộng sự vào năm 2009 [5][6] Họ đã chia các đột
biến thành 2 loại: Đột biến bậc 1 (được dùng trong kỹ thuật kiểm thử đột biến truyền thống (do vậy được gọi là kỹ thuật kiểm thử đột biến bậc 1), chỉ dùng một sự thay đổi toán tử đột biến để tạo ra đột biến) và Đột biến bậc cao (sử dụng
từ 2 trở lên sự thay đổi các toán tử đột biến để tạo ra các đột biến, do đó được gọi
là 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, một đột biến sẽ bao gồm từ 2 trở lên sự 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 cả 15 bài báo khoa học đã được xuất bản có đề cập đến việc áp dụng kỹ thuật kiểm thử đột biến bậc cao [15] Chúng tôi [15] đã chia các kỹ thuật được giới thiệu trong các bài báo này thành 2
nhóm: Kiểm thử đột biến bậc 2 và Kiểm thử đột biến bậc n
Với nhóm kiểm thử đột biến bậc 2, các tác giả đã sử dụng 2 sự thay đổi thông qua các toán tử đột biến để tạo ra các đột biến Do đó các đột biến sinh ra được gọi là đột biến bậc 2 Có 5 nhóm tác giả đã để xuất các thuật toán khác nhau để áp dụng kiểm thử đột biến bậc 2 Hình 3 thể hiện sự so sánh kết quả của các nhóm tác giả dưới góc nhìn các tỷ lệ (%) về việc giảm số lượng đột biến (Mutant Reduction) và giảm số lượng đột biến tương đương (Equivalent Mutant Reduction) Qua đó, chúng ta có thể thấy số lượng đột biến có thể được giảm khoảng 50% và số lượng đột biến tương đương được giảm xuống từ 40% đến 78%
Hình 3 So sánh kết quả của các nhóm tác giả sử dụng đột biến bậc 2
Với nhóm kỹ thuật đột biến bậc n, chúng tôi xem xét các tác giả sử dụng
từ 2 đến n sự thay đổi thông qua các toán tử đột biến để tạo ra các đột biến Do
đó các đột biến được gọi là đột biến bậc n Có 5 nhóm tác giả đã đề xuất việc áp
dụng các thuật toán tối ưu hóa một mục tiêu và tối ưu hóa đa mục tiêu để tìm kiếm các đột biến bậc cao thích hợp, theo sự phân loại của chính họ Cụ thể các phương pháp và kết quả của các nhóm tác giả được thống kê, phân tích và trình bày trong các bài báo khoa học của chúng tôi [10-15] Các tác giả đã sử dụng lần lượt từ 2 đến 70 sự thay đổi để tạo ra các đột biến từ bậc 2 đến bậc 70 Kết quả nghiên cứu của các tác giả đã chứng tỏ được rằng, với kỹ thuật kiểm thử đột biến
Trang 8bậc cao, các đột biến sinh ra phức tạp và khó bị diệt hơn Điều này chứng tỏ, các đột biến đã miêu tả đúng với lỗi thực của các phần mềm hơn là các đột biến bậc
1 Ngoài ra, với các đột biến khó bị diệt, có nghĩa là chúng ta cần cải thiện chất lượng của các bộ kiểm thử nhằm có thể phát hiện ra sự khác biệt giữa đột biến và chương trình gốc Dó đó chất lượng của các bộ kiểm thử được tăng lên so với khi kiểm thử chương trình gốc Một kết quả đáng lưu ý của kỹ thuật kiểm thử đột biến bậc cao nữa là số lượng các đột biến tương đương đã được giảm xuống Tuy nhiên, có một hạn chế lớn của nhóm này là số lượng các đột biến có thể tăng nhanh theo từng bậc đột biến Ví dụ như trong phương pháp của Langdon và các cộng sự [7][8], họ đã sử dụng thuật toán NSGA-II, một thuật toán tối ưu hóa đa mục tiêu, cùng với lập trình di truyền để tìm các đột biến phức tạp và khó bị diệt hơn Số lượng đột biến tương đương giảm rất nhiều, trong khi đó số lượng đột biến được sinh ra là một con số “khổng lồ” Với một chương trình C đơn giản, trong đó có 17 lượt sử dụng các toán tử so sánh (bao gồm 6 toán tử so sánh <,<=,
==, !=, >=, >), sẽ 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,
5 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 tôi đã thực hiện các đánh giá thực nghiệm hiệu quả của việc áp dụng kỹ thuật kiểm thử đột biến và các thuật toán tối ưu hóa đa mục tiêu dựa trên các đề xuất của chúng tôi
Trước tiên, chúng tôi đã đưa ra một cách phân loại các đột biến bậc cao nhằm bao phủ hết tất cả các trường hợp có thể có của các đột biến được sinh ra [10-15] Trong cách phân loại của chúng tôi, có tất cả 11 nhóm đột biến Trong
đó nhóm đột biến “Chất lượng cao và hợp lý” (High quality and Reasonable
HOMs) [10-15] là nhóm các đột biến mà chúng tôi tập trung vào tìm kiếm Các đột biến này được tạo ra bằng cách kết hợp các đột biến bậc 1 lại với nhau, khó
bị diệt hơn các đột biến bậc 1 (Hợp lý) và tập các trường hợp kiểm thử có thể
diệt được các đột biến này sẽ đồng thời diệt được tất cả các đột biến bậc 1 kết
hợp để tạo ra nó (Chất lượng cao) Đây là các đột biến mà có thể thay thế tất cả
các đột biến bậc 1 của nó là không làm giảm đi hiệu quả của kiểm thử đột biến Điều này sẽ làm giảm số lượng đột biến được sinh ra và đồng thời giải quyết được vấn đề đột biến tương đương và miêu tả được các lỗi thực tế của phần mềm Tiếp theo, chúng tôi, đã để ra các hàm mục tiêu và các hàm thích nghi để từ đó
áp dụng các thuật toán tối ưu hóa đa mục tiêu vào trong lĩnh vực kiểm thử đột biến bậc cao [10-15] Chúng tôi đã sử dụng các phần mềm Java thực, mã nguồn
mở (trong đó đã bao gồm bộ kiểm thử được tạo ra bởi đội ngũ kiểm thử các phần mềm này, có thể tải về từ trang http://sourceforge.net) và các thuật toán eMOEA, NSGAII, eNSGAII, NSGAIII và Random [10-15] (tham khảo thêm tại trang http://www.moeaframework.org), bên cạnh việc sử dụng một thuật toán được đề xuất bởi chúng tôi (eNSGAII-DiffLOC), để tìm kiếm các đột biến bậc cao chất lượng cao và hợp lý eNSGAII-DiffLOC là thuật toán được đề chúng tôi đề xuất dựa trên sự thay đổi thuật toán eNSGAII với nguyên tắc “Không có quá một sự thay đổi (lỗi) trên một dòng lệnh” Sở dĩ chúng tôi lựa chọn thuật toán eNSGA để
Trang 9thay đổi vì trong các đánh giá thực nghiệm thực tế của chúng tôi, đây là thuật
toán tốt nhất trong việc tạo ra các đột biến Chất lƣợng cao và hợp lý [15]
Chúng tôi sử dụng công cụ Judy (có thể tham khảo tại trang http://mutationtesting.org/), là một công cụ được tạo ra bởi chính chúng tôi, để sinh tự động các đột biến bậc cao từ bậc 2 đến bậc 15 bằng cách áp dụng các thuật toán tối ưu hóa đa mục tiêu dựa trên các hàm mục tiêu và thích nghi của chúng tôi Bên cạnh đó, công cụ Judy còn thực hiện việc kiểm thử đột biến và đánh giá các đột biến Hiện này, công cụ Judy là một công cụ hỗ trợ một số lượng lớn các toán tử đột biến có trong ngôn ngữ lập trình Java
Những kết quả thực nghiệm đã chứng tỏ rằng phương pháp đề xuất của chúng tôi đã có hiệu quả cao trong việc áp dụng kiểm thử đột biến nói chung, và
kỹ thuật kiểm thử đột biến bậc cao nói riêng [10-15] Cụ thể là 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 của lỗi (đột biến), và giúp hướng đến việc tạo ra các trường hợp kiểm thử tốt hơn Điều này
có nghĩa là góp phần vào việc cải thiện chất lượng của kiểm thử phần mềm thông qua việc đánh giá chất lượng của các bộ kiểm thử Từ kết quả thực nghiệm, chúng tôi đã đưa ra những kết luận hữu ích [15] trong việc áp dụng kiểm thử đột biến bậc cao và thuật toán tối ưu hóa đa mục tiêu để hạn chế những vấn đề tồn tại của kỹ thuật kiểm thử đột biến, cụ thể như sau:
(1) Có thể giảm chi phí tính toán khi kiểm thử đột biến bằng phương pháp của chúng tôi vì số lượng các đột biến được sinh ra (từ bậc 2 đến bậc 15) đã giảm đi khoảng 78% so với số lượng đột biến bậc 1
(2) Trong phương pháp của chúng tôi, các đột biến bậc cao được sinh ra khó bị diệt và phức tạp hơn các đột biến bậc 1 đã kết hợp để tạo ra nó
Từ đó dẫn đến yêu cầu phải tạo ra các bộ kiểm thử chất lượng hơn để kiểm thử phần mềm
(3) Phương pháp của chúng tôi hạn chế được việc sinh ra các đột biến dễ
bị diệt và không hợp lý Các đột biến này bị diệt bởi số lượng các trường hợp kiểm thử nhiều hơn bất kỳ các đột biến bậc 1 nào đã kết hợp tạo nên chúng Và không có bất kỳ một trường hợp kiểm thử nào
có thể đồng thời diệt chúng và các đột biến bậc 1 tạo nên chúng
(4) Bậc 5 là bậc lớn nhất mà chúng ta có thể sử dụng trong kiểm thử đột
biến bậc cao Vì số lượng các đột biến Chất lƣợng cao và hợp lý
được sinh ra với tỷ lệ khá cao (so với tổng số đột biến được sinh ra) từ bậc 2 đến bậc 5 Từ bậc 6 trở lên, số lượng các đột biến này rất nhỏ, thậm chí gần bằng 0 Trong khi đó, số lượng các đột biến còn sống (không bị diệt bởi bộ kiểm thử đã cho, bao gồm cả các đột biến tương đương) là khá cao, chiếm khoảng từ 25% đến 55%, cho tất cả các bậc
từ 2 đến 15
(5) Không nên sử dụng các đột biến bậc 1 bị diệt để tạo ra các đột biến bậc cao (từ bậc 2 trở lên), vì các đột biến bậc cao này sẽ rất dễ bị diệt (6) Thuật toán eNSGAII-DiffLOC của chúng tôi đề xuất tốt hơn thuật toán eNSGAII (đây là thuật toán tốt nhất trong 5 thuật toán chúng tôi áp dụng) trên phương diện cải thiện chất lượng của kiểm thử đột biến
Trang 106 KẾT LUẬN
Dựa vào các ưu điểm, nhược điểm của kỹ thuật kiểm thử đột biến, và kỹ thuật đột biến bậc cao, chúng tôi đã đề xuất, thực nghiệm và đánh giá kết quả một phương pháp mới ứng dụng kiểm thử đột biến bậc cao và các 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í và thời gian trong quá trình kiểm thử phần mềm nói chung và quy trình ứng dụng kiểm thử đột biến nói riêng Ngoài ra, chúng tôi cũng cung cấp một giải pháp mới bao gồm cách phân loại các đột biến để có thể bao trùm hết các trường hợp đột biến có thể được sinh
ra, các hàm mục tiêu, hàm thích nghi cũng như cách kết hợp các đột biến bậc 1
để tạo ra các đột biến bậc cao Từ đó có thể được dùng để làm tài liệu tham khảo
và áp dụng thực tế cho các đơn vị phát triển phần mềm đang 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 và ứng dụng kiểm thử đột biến (mutation testing) cho các 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ử các chương trình C#”, Tạp chí Khoa học và 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
