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 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.


1. ĐẶ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

hiệ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


nà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


ra 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.

Begin

Chƣơng trình
gốc P

Chỉnh sửa False

Tạo các
đột biến P’

Tạo các trƣờng
hợp kiểm thử T

P đúng
?

Thực hiện T
với P

True

True
End

Các đột
biến đều
bị diệt ?

False

Thực hiện các
trƣờng hợp
kiểm thử
với từng đột
biến “còn
sống”
Phân tích và đánh dấu các
đột biến tƣơng đƣơng

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


trong 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].


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) 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


bậ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 ) và các thuật toán eMOEA,
NSGAII, eNSGAII, NSGAIII và Random [10-15] (tham khảo thêm tại trang
), 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 để


thay đổ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
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.


6. 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.

[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.