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

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

Đinh Thị Mỹ Cảnh

Trường Đại học Công nghệ
Luận văn ThS. Chuyên ngành: Công nghệ thông tin; Mã số: 60 48 10
Người hướng dẫn: PGS.TS. Đoàn Văn Ban
Năm bảo vệ: 2010

Abstract: Chương 1: Trình bày tổng quan về kiểm thử phần mềm như khái niệm kiểm thử phần
mềm, mục đích, mục tiêu và các mức kiểm thử phần mềm; đề cập đến việc sử dụng các kỹ thuật
kiểm thử hộp trắng và hộp đen để thiết kế dữ liệu thử. Chương 2: Mô tả chi tiết các thành phần
chính của kỹ thuật kiểm thử đột biến, giới thiệu các giả thuyết cơ bản cần thiết để thực hiện
phương pháp này. Chương 3: Giới thiệu các 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 toán và tăng tự động hóa. Chương 4: Tập trung vào ứng dụng kỹ thuật
kiểm thử đột biến
Keywords: Phần mềm; Kỹ thuật kiếm thử đột biến; Chương trình Java
Content:
MỞ ĐẦU
Kiểm thử phần mềm là một hoạt động giữ vai trò rất quan trọng để bảo đảm chất lượng
phần mềm và là hoạt động mang tính sống còn trong các dự án sản xuất hoặc 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 trong các dự án phát triển phần
mềm trên thế giới. Ở Việt Nam, ngành công nghiệp phần mềm đang phát triển thì không thể xem
nhẹ việc kiểm thử phần mềm vì xác suất thất bại sẽ rất cao, hơn nữa, hầu hết các công ty phần
mềm có uy tín đều đặt ra yêu cầu nghiêm ngặt là nếu một phần mềm không có tài liệu kiểm thử
đi kèm thì sẽ không được 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ử các hệ
thống phức tạp đòi hỏi rất nhiều nguồn tài nguyên và chi phí cao. Thứ hai, tiến trình phát triển
phần mềm luôn trải qua nhiều hoạt động biến đổi thông tin, sự mất mát thông tin trong quá trình
biến đổi là yếu tố chính làm cho hoạt động kiểm thử khó khăn. Thứ ba, kiểm thử chưa được chú

trọng trong đào tạo con người. Cuối cùng, không tồn tại kỹ thuật kiểm thử cho phép khẳng định
một phần mềm hoàn toàn đúng đắn hay không chứa lỗi.
Với mục đích phát hiện lỗi, kiểm thử phần mềm thường phải trải qua các bước: tạo dữ liệu
thử, thực thi phần mềm trên dữ liệu thử và quan sát kết quả nhận được. Trong các bước này,
bước tạo dữ liệu thử đóng vai trò quan trọng nhất, bởi vì chúng ta không thể tạo ra mọi dữ liệu từ
miền vào của chương trình, mà chúng ta chỉ có thể tạo ra các dữ liệu thử có khả năng phát hiện
lỗi cao nhất. Vấn đề đặt ra là làm thế nào để đánh giá được khả năng phát hiện lỗi của một bộ dữ
liệu thử? Một kinh nghiệm để giúp giải quyết vấn đề này, đó là sử dụng khái niệm chất lượng bộ
dữ liệu thử như là một phương tiện để đánh giá bộ dữ liệu thử như thế nào là “tốt” khi kiểm thử
chương trình. Ở đây, “tốt” được đánh giá liên quan đến tiêu chuẩn chất lượng được định trước,
thường là một 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 bộ
dữ liệu thử thực hiện mọi dòng lệnh trong chương trình ít nhất một lần. Nếu bộ dữ liệu thử được
tìm thấy không chất lượng liên quan đến tiêu chuẩn (tức là không phải tất cả các câu lệnh đều
được thực hiện ít nhất một lần), thì kiểm thử nữa là bắt buộc. Do đó, mục tiêu là tạo ra một tập
các kiểm thử thực hiện đầy đủ tiêu chuẩn chất lượng.
Tiêu chuẩn chất lượng tiêu biểu như bao phủ câu lệnh và kiểm thử quyết định (thực hiện tất
cả các đường dẫn đúng và sai qua chương trình) dựa vào việc thực hiện chương trình với số
lượng kiểm thử tăng dần để nâng cao độ tin cậy của chương trình đó. Tuy nhiên, chúng không
tập trung vào nguyên nhân thất bại của chương trình - được gọi là lỗi. Kiểm thử đột biến [7] là
một tiêu chuẩn như vậy. Tiêu chuẩn này tạo ra các phiên bản của chương trình có chứa các lỗi
đơn giản và sau đó tìm ra các kiểm thử để chỉ ra các dấu hiệu của lỗi. Nếu có thể tìm thấy một bộ
dữ liệu thử chất lượng làm lộ ra các dấu hiệu này ở tất cả các phiên bản bị lỗi, thì sự tin tưởng
vào tính đúng đắn của chương trình sẽ tăng.
Kiểm thử đột biến đã được áp dụng cho nhiều ngôn ngữ lập trình [8] như là một kỹ thuật
kiểm thử hộp trắng. Chẳng hạn, các 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 còn được sử dụng ở
mức thiết kế để kiểm thử các đặc tả hoặc các mô hình của chương trình. Ví dụ, ở mức thiết kế,
kiểm thử đột biến được áp dụng cho các máy trạng thái xác định (FSM), các biểu đồ trạng thái
(State Charts), các giao thức mạng (Network Protocols), các chính sách bảo mật (Security
Policies), các dịch vụ web (Web Services), ….

Ý thức được đây là một lĩnh vực nghiên cứu có nhiều triển vọng ứng dụng trong phát triển
phần mềm, tôi đã chọn hướng nghiên cứu Kỹ thuật kiểm thử đột biến cho đề tài luận văn của
mình. Luận văn được xây dựng dựa trên nền các nghiên cứu đã có trong lĩnh vực kiểm thử phần
mềm kể từ năm 1978, mà gần đây nhất là các nghiên cứu về kỹ thuật kiểm thử đột biến vào năm
2009 của TS.Nguyễn Thanh Bình – Đại học Bách khoa, Đại học Đà Nẵng [2]. Đồng thời, tôi xin
đề xuất một “quy trình ứng dụng kỹ thuật kiểm thử đột biến để kiểm thử các chương trình Java”.
Luận văn được tổ chức thành 4 chương như sau:
 Chương 1 – Trình bày tổng quan về kiểm thử phần mềm như khái niệm kiểm thử phần
mềm, mục đích, mục tiêu và các mức kiểm thử phần mềm. Chương này cũng đề cập
đến việc sử dụng các kỹ thuật kiểm thử hộp trắng và hộp đen để thiết kế dữ liệu thử.
 Chương 2 - Mô tả chi tiết các thành phần chính của kỹ thuật kiểm thử đột biến, giới
thiệu các giả thuyết cơ bản cần thiết để thực hiện phương pháp này. Chương này còn
cung cấp quy trình để phân tích đột biến, từ đó rút ra được những vấn đề còn hạn chế
đối với kỹ thuật kiểm thử đột biến, được cải tiến ở chương 3.
 Chương 3 – Giới thiệu các 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 toán và tăng tự động hóa.
Chương 4 – 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 năng phân tích và tạo đột biến, và JUnit dùng để kiểm
thử đơn vị của 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ử các chương trình Java sử dụng hai công cụ trên. Cụ thể, kiểm thử chương trình
sắp xếp dãy số tăng dần theo thuật toán QuickSort viết bằng ngôn ngữ Java, từ đó, tập trung phân
tích và đánh giá chất lượng của các bộ dữ liệu thử dùng để kiểm thử chương trình này
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ác câu lệnh truy
vấn cơ sở dữ liệu”, Tạp chí Khoa học và 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ử các chương trình C-Sharp”, Tạp chí Khoa học và 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).
[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. 7.
[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”, , 2009 .
[32] SourceForge, “MuJava”, 2008.


6

6
5

5

9
(b)