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

Chia sẻ: Phạm Huy | Ngày: | Loại File: PDF | Số trang:5

Thêm vào BST

Báo xấu

79
lượt xem 8
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

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

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Báo cáo " 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 Thạc sĩ ngành: Công nghệ phần mềm; Mã số: 60 48 10 Người hướng dẫn: PGS.TS Đoàn Văn Ban Năm bảo vệ: 2009 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 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. 2
 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. References 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). 3
[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. 4
[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 . [32] SourceForge, “MuJava”, http://www.cs.gmu.edu/~offutt/mujava/, 2008. 5