Đây là module cuối cùng gọi thực hiện FindPivot, Partiton và gọi đệ quy QuickSort. Do đó, khả năng xảy ra lỗi ở module này có thể xảy ra. Vì vậy, chúng ta cần thiết kế các trường hợp kiểm thử cho module này để thực hiện việc kiểm thử tích hợp khi các module con được tích hợp lại thành module QuickSort.
Dựa vào phương pháp kiểm thử hộp đen bằng cách sử dụng phân hoạch tương đương và phân tích giá trị biên đối với các giá trị đầu vào:
Số phần tử của 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ử của dãy là ngẫu nhiên
+ Các phần tử của dãy đều có giá trị bằng nhau
+ Dãy đã theo thứ tự tăng dần
+ Dãy theo thứ tự giảm dần
+ Dãy có một phần tử là chữ cái
+ Dãy có một phần tử là số thực
Từ việc phân tích các giá trị đầu vào của thuật toán sắp xếp QuickSort, chúng ta thiết kế được các trường hợp kiểm thử như sau:
STT Tên kiểm thử
Đầu vào
Kết quả mong đợi
N Dãy A 1 QuickSort1 0 [] Thất bại 2 QuickSort2 1 5 5 3 QuickSort3 5 4 5 7 2 2 2 2 4 5 7 4 QuickSort4 4 4 4 4 4 4 4 4 4 4 5 QuickSort5 1 5 10 17 30 1 5 10 17 30 6 QuickSort6 16 12 3 1 0 0 1 3 12 16 7 QuickSort7 8 8 15 6 2 5 4 12 7 2 4 5 6 7 8 12 15 8 QuickSort8 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 9 QuickSort9 2 3 6 8 12 16 19 25 2 3 6 8 12 16 19 25 10 QuickSort10 17 10 8 5 4 2 1 -3 -3 1 2 4 5 8 10 17 11 QuickSort11 30 8 15 6 2 5 … 10 2 5 6 8 10 15… 12 QuickSort12 6 6 6 6 6 6… 6 6 6 6 6 6… 13 QuickSort13 2 6 8 12 …15 2 6 8 12 15… 14 QuickSort14 17 10 8 5 ….-3 -3 5 8 10 17… 15 QuickSort15 31 5 -4 3 20 1…… Thất bại 16 QuickSort16 a Thất bại 17 QuickSort17 3 5 6 a Thất bại 18 QuickSort18 2.5 Thất bại 19 QuickSort19 5 3 6 7 2 1.5 Thất bại
Bảng 4.5 – Mô tả các trường hợp kiểm thử cho module QuickSort
Như vậy, có tất cả 28 trường kiểm thử được thiết kế để kiểm thử cho chức năng của từng module và cho toàn bộ hệ thống của chương trình SXQSort.java.
Trong đó, có 22 trường hợp kiểm thử được mong đợi làm cho chương trình thành công và 6 trường hợp kiểm thử được 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ử được mong đợi làm cho chương trình SXQSort.java thành công để thực hiện 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 được hiển thị để cung cấp các đầu ra mong muốn khi thực hiện 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ì trong quá trình thực hiện kiểm thử đột biến, bên cạnh các đột biến tương đương, tất cả các đột biến khác được hiển thị để tạo các đầu ra không đúng so với đầu ra đúng của chương trình SXQSort.java. Nếu có bất kỳ đầu ra nào là không đúng thì chứng tỏ rằng chương trình SXQSort.java chứa lỗi. Các lỗi này nên được sữa chữa để bắt đầu quá trình kiểm thử đột biến.
Chúng ta sử dụng bộ kiểm thử JUnit (phiên bản 3.8.1) để kiểm thử chương trình SXQSort.java, với 22 trường hợp kiểm thử trên được thiết kế sẵn trong QuickSortTest.java. Kết quả kiểm thử được thể hiện ở hình 4.9.
Hình 4.9 – Kết quả kiểm thử SXQSort.java bằng JUnit
Trên hình 4.9, JUnit hiển thị thanh màu xanh. Điều này chứng tỏ rằng, chương trình SXQSort.java là một chương trình tốt (tức là chương trình không có lỗi) dưới “góc nhìn” của JUnit với dữ liệu thử được xây dựng trong 22 trường hợp kiểm thử trên.
4.4.5. Tạo và phân tích đột biến cho chƣơng trình SXQSort.java bằng MuJava
Dùng MuJava để tạo các đột biến cho chương trình SXQSort.java, thực thi các đột biến với 22 trường hợp kiểm thử được xây dựng trong SXQSortTest.Java, và báo cáo tỷ lệ đột biến của các trường hợp kiểm thử.
4.4.5.1. Tạo các đột biến
MuJava tạo ra hai loại đột biến: đột biến truyền thống và đột biến lớp tương ứng với hai loại toán tử đột biến. Nếu chúng ta chọn tất cả các toán tử đột biến mức phương thức và mức lớp, MuJava tạo ra 262 đột biến cho chương trình SXQSort.Java, trong đó có 258 đột biến truyền thống và 4 đột biến lớp. Nếu MuJava thực thi tất cả những đột biến này với 22 trường hợp kiểm thử được xây dựng trong SXQSortTest.java sẽ tốn rất nhiều thời gian, đồng thời số lượng các đột biến tương đương cũng tăng. Do đó, sẽ 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, chúng ta sẽ sử dụng phương pháp đột biến ràng buộc bằng cách chỉ chọn một số toán tử đột
biến mức phương thức và mức lớp trong MuJava để tạo đột biến. Trong chương trình SXQSort.Java xuất hiện các toán tử: { +, -}, {++, --}, {<=, >=, <, >, = =,!=}, {&&}. Đây là các toán tử có thể bị “viết nhầm” bởi các lập trình viên, lỗi có thể xảy ra ở những toán tử này. Ngoài ra, việc khai báo và sử dụng các biến {L, R, n, i, j, k}, {a[1], a[2], …, a[n]} có thể là không chính xác. Vì vậy, một số toán tử đột biến mức phương thức và mức lớp trong MuJava được chọn để tạo các đột biến cho chương trình SXQSort.java như sau:
Toán tử đột biến mức phƣơng thức
Toán tử Mô tả Ví dụ
AORB Thay thế các toán tử số học nhị nguyên a = b + c a = b − c AORS Thay thế các toán tử số học short – cut a ++ a −−
ROR Thay thế các toán tử quan hệ if(a < b) if(a > b) COR Thay thế các toán tử điều kiện
while(a < b) && (c > d) while(a < b) || (c > d)
Toán tử đột biến mức lớp
Toán tử Mô tả Ví dụ
JTI Thêm từ khóa this n this.n
JSI Thêm từ bổ nghĩa static
public int n; public static int n; JID Xóa khởi tạo biến thành phần
public int[] a = new int[n];
public int[] a
Bảng 4.6 – Các toán tử đột biến mức phương thức và mức lớp được chọn để tạo đột biến cho SXQSort.java
Trong thành phần Mutants Genertor của MuJava, chúng ta sẽ đánh dấu
chọn các toán tử đột biến mức phương thức: AORB, AORS, ROR, COR, chọn các toán tử đột biến mức lớp: JTI, JSI, JDI, và chọn file SXQSort.java. Sau đó, bấm nút “Generate” để tạo các đột biến cho chương trình SXQSort.java, được 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 ra 43 đột biến truyền thống cho chương trình SXQSort.java, được biểu diễn ở Tab Traditional Mutants Viewer trong thành phần Mutants Genertor của MuJava.
Hình 4.11 –Hiển thị đột biến truyền thống của SXQSort.java
MuJava tạo ra 4 đột biến lớp cho chương trình SXQSort.java, được biểu diễn ở Tab Class Mutants Viewer trong thành phần Mutants Genertor của
MuJava.
Như vậy, MuJava đã tạo ra 47 đột biến cho chương trình SXQSort.java, trong đó có 43 đột biến truyền thống và 4 đột biến lớp, chỉ áp dụng các toán tử đột biến mức phương thức: AORB, AORS, ROR, COR và các 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 của MuJava để thực thi
chương trình SXQSort.java và 47 đột biến của nó, với 22 trường hợp kiểm thử được xây dựng trong SXQSortTest.Java, kết quả của quá trình thực thi được biểu diễn ở hình 4.13.
Hình 4.13 –Kết quả thực thi các đột biến của SXQSort.java
Đối với 4 đột biến lớp, trong quá trình MuJava thực thi với 22 trường hợp kiểm thử được thiết kế sẵn trong SXQSortTest.Java, chỉ có 1 đột biến bị diệt và 3 đột biến “còn sống”. Tỷ lệ đột biến ở đây là xấp xỉ 25%. Đối với 43 đột biến truyền thống, có 38 đột biến bị diệt và 5 đột biến “còn sống”. Tỷ lệ đột biến ở đây là xấp xỉ 88%. Cụ thể với từng trường hợp kiểm thử được thể hiện trong bảng 4.7.
STT Tên kiểm thử Số đột biến diệt đƣợc Số đột biến không diệt đƣợc 1 FindPivot1 37 10 2 FindPivot 2 38 9 3 FindPivot 3 35 12 4 FindPivot 4 36 11 5 FindPivot 5 15 32 6 FindPivot 6 14 33 7 PartitionPath3 37 10 8 PartitionPath 4 39 8 9 PartitionPath 5 38 9 10 QuickSort 2 14 33 11 QuickSort 3 39 8 12 QuickSort 4 15 32 13 QuickSort 5 28 19 14 QuickSort 6 36 11 15 QuickSort 7 38 9 16 QuickSort 8 15 32 17 QuickSort 9 28 19 18 QuickSort 10 36 11 19 QuickSort 11 39 8 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
Quá trình MuJava phân tích các đột biến của chương trình SXQSort.java cho thấy rằng: chất lượng bộ dữ liệu thử mà chúng ta tạo ra trong 22 trường hợp kiểm thử ở trên là khá cao (tỷ lệ đột biến 88%). Nó có khả năng phát hiện được
hầu hết các lỗi có thể có trong chương trình SXQSort.java. Bên cạnh đó, đối với các đột biến bị diệt, các lỗi (lỗi mà được sửa đổi từ chương trình SXQSort.java để tạo ra đột biến đó) sẽ không xuất hiện trong chương trình SXQSort.java. Như vậy, MuJava đã góp phần làm tăng lòng tin của chúng ta vào tính đúng đắn của chương trình SXQSort.java và của dữ liệu thử.
KẾT LUẬN
Với cách tiếp cận dựa trên những đề xuất đã có trong lĩnh vực nghiên cứu về kiểm thử phần mềm, luận văn trình bày những nét chính trong kiểm thử phần mềm nói chung và kiểm thử đột biến nói riêng cùng với những cải tiến. Qua đó, cho thấy được tác dụng của kiểm thử đột biến không chỉ cung cấp một phương tiện để đánh giá và cải tiến chất lượng dữ liệu thử dựa trên công thức tính tỷ lệ đột biến, mà còn giúp kiểm thử biết rằng không có các lỗi (các lỗi được sửa đổi từ PUT để tạo ra các đột biến) xuất hiện trong PUT nếu tất cả các đột biến của PUT đều bị diệt. Điều này, góp phần làm tăng sự tin tưởng của kiểm thử viên vào tính đúng đắn của PUT và của dữ 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 và phân tích đột biến, và 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ử các 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 một số toán tử đột biến) để kiểm thử chương trình sắp 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 quả là có 88% đột biến bị diệt, nhưng chỉ phải kiểm tra với 17,9% đột biến.
Kiểm thử đột biến là một kỹ thuật kiểm thử được khá nhiều nhà nghiên cứu quan tâm bởi khả năng ứng dụng của nó. Tuy nhiên, ngoài những vấn đề đã nêu, vẫn còn tồn tại nhiều vấn đề cần phải tiếp tục nghiên cứu. Các vấn đề về phát hiện đột biến tương đương và vấn đề Oracle. Chưa có vấn đề nào được giải quyết trong nghiên cứu này, với giả định rằng tồn tại các phương pháp thích hợp để giải quyết vấn đề này. Tuy nhiên, để tạo thuận lợi để kiểm thử đột biến chấp nhận trong ngành công nghiệp, giải pháp khả thi là cần thiết cho những vấn đề này. Phát hiện đột biến tương đương chỉ đơn giản có thể liên quan đến việc bỏ qua chúng và dựa vào tỷ lệ đột biến còn thấp để phát triển các dữ liệu thử - nếu cải tiến dữ liệu thử liên tục diễn ra, thì sẽ thu được bộ dữ liệu thử tốt nhất. Do đó, trong thời gian tới, tôi sẽ tiếp tục nghiên cứu để loại bỏ các đột biến tương đương trong số các đột biến còn sống của chương trình, đồng thời cải tiến các trường hợp kiểm thử để đạt tỷ lệ đột biến 100%.
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”, http://www.junit.org, 2009 .