zunia.vn

Tuyển sinh 2024 dành cho Gen-Z

zunia.vn

» Luận Văn - Báo Cáo

» Báo cáo khoa học

Báo cáo khoa học: "ỨNG DỤNG KỸ THUẬT KIỂM THỬ ĐỘT BIẾN ĐỂ KIỂM THỬ CÁC CHƯƠNG TRÌNH C-SHARP"

Chia sẻ: Nguyễn Phương Hà Linh Nguyễn Phương Hà Linh | Ngày: | Loại File: PDF | Số trang:8

Báo xấu

188
lượt xem 24
download

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

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. Một trong những kỹ thuật kiểm thử có khả năng tự động hóa cao là kỹ thuật kiểm thử đột biến (mutation testing). Bài báo trình bày ứng dụng kỹ thuật kiểm thử đột biến trong việc kiểm thử các chương trình được phát triển bởi ngôn ngữ lập trình C-Sharp. Kỹ thuật kiểm thử đột biến được trình bày và phân tích các hạn chế, cũng như các phương pháp cải tiến.......

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 khoa học: "Ứ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 - SỐ 5(34).2009 ỨNG DỤNG KỸ THUẬT KIỂM THỬ ĐỘT BIẾN ĐỂ KIỂM THỬ CÁC CHƯƠNG TRÌNH C-SHARP APPLYING MUTATION TESTING TO C-SHARP PROGRAM TESTS Nguyễn Thanh Bình Nguyễn Quang Vũ Trường Đại học Bách khoa, Đại học Đà Nẵng Trường CĐ 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. Một trong những kỹ thuật kiểm thử có khả năng tự động hóa cao là kỹ thuật kiểm thử đột biến (mutation testing). Bài báo trình bày ứng dụng kỹ thuật kiểm thử đột biến trong việc kiểm thử các chương trình được phát triển bởi ngôn ngữ lập trình C-Sharp. Kỹ thuật kiểm thử đột biến được trình bày và phân tích các hạn chế, cũng như các phương pháp cải tiến. Từ đó, một quy trình kiểm thử các chương trình C-Sharp ứng dụng kiểm thử đột biến sử dụng các công cụ Nester và Nunit được đề xuất. Bài báo minh họa một ứng dụng cụ thể cho thấy kết quả khả quan. Kết quả của bài báo có thể áp dụng vào các quy trình kiểm thử trong các đơn vị phát triển phầ n mềm. ABSTRACT Software testing is always one of the important activities in order to evaluate the software quality. One of the testing techniques with high automation is mutation testing. This paper presents the application of mutation testing to testing programs developed by C-Sharp language. Thus, mutation testing is introduced, its limitations and some methods for improvement are also analyzed. Then, a testing process for C-Sharp programs applying mutation testing using Nester and Nunit tools is proposed. The paper also shows some promising experimental results. This approach can be applied to testing processes of software development companies. 1. Đặt vấn đề Kiểm thử phần mềm là một trong những hoạt động quan trọng trong tiến trình phát triển phần mềm. Nó góp một phần rất lớn trong việc đánh giá chất lượng của một phần mềm và là 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 cũng như trong nước. 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. 8
TẠP CHÍ KHOA HỌC VÀ CÔNG NGHỆ, ĐẠI HỌC ĐÀ NẴNG - SỐ 5(34).2009 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 đó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 sao để đánh giá được khả năng phát hiện lỗi của một bộ dữ liệu thử ? Chính kỹ thuật kiểm thử đột biến là câu trả lời. Kỹ thuật này cho phép đánh giá chất lượng (khả năng phát hiện lỗi) của một bộ dữ liệu thử. Trong bài báo này chúng tôi sẽ tập trung vào vấn đề đánh giá chất lượng của các bộ dữ liệu thử dùng để kiểm thử các chương trình C-Sharp. 2. Kỹ thuật kiểm thử đột biến 2.1 Khái niệm Kiểm thử đột biến (mutation testing) được đề xuất đầu tiên năm 1978 bởi DeMillo [5], và được thiết kế để tạo ra một bộ dữ liệu kiểm thử hiệu quả có khả năng phát hiện lỗi của chương trình. Kiểm thử đột biến tập trung vào việc đánh giá khả năng phát hiện lỗi của dữ liệu dùng để kiểm thử. Kiểm thử đột biến được dùng kết hợp với các kỹ thuật kiểm thử thông thường nhưng không thể được dùng để thay thế cho các kỹ thuật kiểm thử thông thường đó. Kiểm thử đột biến là một kỹ thuật kiểm thử hộp trắng hay kiểm th ử cấu trúc, được xây dựng dựa vào hai gi thuyết cơ bản [4]: giả thuyết “lập trình viên giỏi” ả (competent programmer) và giả thuyết “ hiệu ứng liên kết” (coupling effect). Giả thuyết “lập trình viên giỏi” giả thiết rằng lập trình viên chỉ phạm những lỗi đơn giản do sơ suất. Giả thuyết “hiệu ứng liên kết” giả thuyết rằng, nếu dữ liệu thử phát hiện được các lỗi đơn giản thì dữ liệu đó cũng cho phép phát hiện các lỗi phức tạp. Kiểm thử đột biến bao gồm việc tạo ra các phiên bản lỗi của chương trình gốc được kiểm thử nhờ vào các toán tử đột biến. Các phiên bản lỗi đó được gọi là các đột biến (mutant). Hình 1. Một ví dụ về đột biến 9
TẠP CHÍ KHOA HỌC VÀ CÔNG NGHỆ, ĐẠI HỌC ĐÀ NẴNG - SỐ 5(34).2009 Toán tử đột biến (mutation operator) là một luật được áp dụng vào chương trìn h gốc để tạo ra các đột biến. Các toán tử đột biến được xác định bởi ngôn ngữ của chương trình được kiểm thử và hệ thống đột biến được dùng để kiểm thử. Khi tiến hà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 dữ liệu kiểm thử T, sẽ có hai kịch bản khác nhau có thể xảy ra: Một là, đột biến P’ được gọi là bị diệt bởi dữ liệu kiểm thử T. - 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, - đột biến P’ được cho là còn số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ử. Tỷ số MS = 100 * D/(N - E) được gọi là tỷ lệ đột biến (Mutation Score - MS). Trong đó, D là đột biến đã bị diệt; N là tổng số các đột biến; E là số đột biến tương đương. Tỷ lệ đột biến cho phép đánh giá chất lượng bộ dữ liệu thử. 2.2 Thuật toán kiểm thử đột biến Thuật toán kiểm thử đột biến [4] gồm các bước cơ bản sau: Bước 1: Sản sinh đột biến (dùng công cụ sản sinh tự động hoặc sản sinh thủ công) từ chương trình gốc. Bước 2: Sản sinh các dữ liệu kiểm thử. Bước 3: Thực hiện từng dữ liệu kiểm thử với chương trình gốc. Bước 3.1: N kết quả không đúng, phi chỉnh sửa chương trình và ếu ả kiểm thử lại. Bước 3.2: Nếu kết quả đúng, thực hiện bước tiếp theo. Bước 4: Thực hiện từng dữ liệu kiểm thử với từng đột biến còn sống. Bước 4.1: N kết quả ra c đột biến khác với chương trình gốc, ếu ủa chương trình độ t b iến được xem là k hông đúng và bị diệt. Hoàn thành kiểm thử. Bước 4.2: Nếu đột biến sống sót được (qua kiểm thử): phân tích các đột biến còn sống. Có hai khả năng xảy ra: Hoặc các đột biến là đột biến tương đương: không thể bị diệt. - Hoặc có thể diệt các đột biến được nhưng các dữ liệu kiểm thử - không đủ mạnh để diệt đột biến. Do đó phải tạo ra các dữ liệu kiểm thử khác và lặp lại bước 1. 2.3 Hạn chế của kỹ thuật kiểm thử đột biến Kỹ thuật kiểm thử đột biến rất hiệu quả trong việc đánh giá chất lượng dữ liệu thử và dễ dàng tự động hóa. Tuy nhiên, kỹ thuật này có một số hạn chế. Thứ nhất, việc nhận dạng các đột biến tương đương là rất quan trọng nhưng rất khó khăn để thực hiện 10
TẠP CHÍ KHOA HỌC VÀ CÔNG NGHỆ, ĐẠI HỌC ĐÀ NẴNG - SỐ 5(34).2009 nhận dạng chúng. Thứ hai, một số các đột biến không tương đương nhưng vẫn còn tồn tại, được gọi là các đột biến không tương đương “ngoan cố”, và rất khó trong việc diệt chúng. Cuối cùng, “chi phí tính toán” của kiểm thử đột biến rất cao. 3. Các cải tiến kỹ thuật kiểm thử đột biến Nhằm nâng cao hiệu quả của kỹ thuật kiểm thử đột biến, một số cải tiến đã được đề xuất [1, 3, 7, 8, 9,10]. 3.1 Đột biến yếu Đột biến yếu (weak mutation), được đề nghị bởi Howden [10], như là một sự cải tiến và mở rộng của kiểm thử đột biến. Ý tưởng chính của đột biến yếu như sau: Trong thuật ngữ của Howden, P là một chương trình, C là một thành phần của P, C’ là một phiên bản đột biến của C, và P’ có chứa C’ là một phiên bản đột biến của P. Kiểm thử đột biến yếu chỉ đòi hỏi một dữ liệu kiểm thử T phải làm cho C’ tính toán ra một giá trị sai khác so với giá trị được tính toán bởi C. 3.2 Phân tích đột biến dựa vào giản đồ Một kỹ thuật mới để thực hiện phân tích đột biến sử dụng các giản đồ chương trình [6, 7] (program schemata), cho phép mã hoá tất cả các đột biến của chương trình vào một siêu chương trình (meta -program). Sau đó, siêu chương trnh này được biên ì dịch và chạy với tốc độ cao hơn, so với việc biên dịch và thực thi từng đột biến riêng lẻ. 3.3 Đột biến lựa chọn Do số lượng đột biến được sản sinh ra bởi các toán tử đột biến thường là rất lớn, nên Mathur [1] đã đề xuất phương pháp đột biến lựa chọn (selective mutation). Đó là phương pháp cho phép ựa chọn trước tập các toán tử có thể sinh ra đột biến. Ý tưởng l này nhằm làm cho các độ t biến được sản sinh ra thật sự khác biệt với các đột biến khác [2, 3]. Điều đó làm giảm số lượng các đột biến được sản sinh ra. 3.4 Đột biến lạc quan Một trong những bước thực hiện thủ công rất khó khăn của việc dùng hệ thống kiểm thử đột biến là việc xác định các đột biến tương đương. Có một vài đột biến có thể bị diệt nhưng đã không bị diệt, và có thể gần như chúng bị bỏ quên. Do đó, kiểm thử viên phải hết sức chú ý để phát hiện các đột biến tương đương thông qua tập dữ liệu thử. 3.5 Sản sinh dữ liệu kiểm thử dựa vào ràng buộc Phương pháp sản sinh dữ liệu kiểm thử dựa vào ràng buộc [8] gồm một tập các thủ tục được thiết kế để tạo dữ liệu thử thoả mãn kiểm thử đột biến. Phương pháp này yêu cầu một dữ liệu kiểm thử diệt được đột biến phải thoả mãn ba điều kiện: điều kiện có thể đạt đến được, điều kiện cần và điều kiện đủ. Điều kiện có thể đạt đến được là các câu lệnh đã bị biến đổi trong các đột biến phải được kích hoạt khi kiểm thử. Điều kiện cần là khi một câu lệnh bị biến đổi được thực thi, thì dữ liệu kiểm thử phải làm cho chương trình đột biến chạy sai, nghĩa là lỗi đã được chèn vào trong chương trình phải tạo ra trạng thái lỗi cho các hoạt động của chương trình. Điều kiện đủ là các sai sót đó phải được truyền đến các tính toán của chương trình để cho ra kết quả sai. 11
TẠP CHÍ KHOA HỌC VÀ CÔNG NGHỆ, ĐẠI HỌC ĐÀ NẴNG - SỐ 5(34).2009 4. Ứng dụng kỹ thuật kiểm thử đột biến để kiểm thử các chương trình C-Sharp Gần đây, ngôn ngữ C-Sharp trong môi trường .NET là một trong ngôn ngữ được sử dụng rộng rãi để phát triển các ứng dụng. Trong bài báo này, chúng tôi đề xuất quy trình áp dụng kỹ thuật kiểm thử đột biến cho các ứng dụng được phát triển dùng C- Sharp. Quy trình ứng dụng kiểm thử đột biến để kiểm thử các chương trình C-Sharp áp dụng kỹ thuật kiểm thử đột biến lựa chọn và sử dụng công cụ Nester, dùng để phân tích và tạo đột biến, và công cụ Nunit dùng để kiểm thử đơn vị. Quy trình này được minh họa trong Hình 2. Chúng tôi tiến hành kiểm thử một chương trình cs-money được viết bằng ngôn ngữ C-Sharp gồm có các lớp, như: AssemblyInfo.cs, Imoney.cs, Money.cs, MoneyBag.cs, gồm khoảng 200 dòng lệnh và 21 trường hợp kiểm thử cùng dữ liệu thử được xây dựng trong MoneyTest.cs. Trước hết, chúng ta sẽ kiểm thử chương trình này bằng bộ kiểm thử Nunit (phiên bản 2.2.0), với các trường hợp kiểm thử và dữ liệu thử được thiết kế sẵn đó, kết quả sẽ được mô tả như trong Hình 3. Chương t r P ình Nunit 2.2.0 Không t ố t Tốt ? Chỉnh sửa P Tố t Đột biế n P’ NESTER Không t ố t Gọi lệ nh biên dch ị Tố t KẾT QUẢ Nunit 2.2.0 Hình 2. Quy trình ứng dụng kỹ thuật kiểm thử đột biến Rõ ràng, đ ây là một chương trình tốt dưới “góc nhìn” của Nunit với dữ liệu thử được xây dựng trong 21 trường hợp kiểm thử đó. 12
TẠP CHÍ KHOA HỌC VÀ CÔNG NGHỆ, ĐẠI HỌC ĐÀ NẴNG - SỐ 5(34).2009 Hình 3. Kết quả kiểm thử bằng Nunit 2.2.0 Tiếp theo, chúng ta sử dụng Nester với tập toán tử đột biến được lựa chọn để thực hiện đột biến. Tập toán tử đột biến được lựa chọn gồm: {true, false}, {+,-}, {==,!=}, {if(,if(true}, {xyz, a b c, 12, ?}, {1, 2, 3, 4}, {a, b, c, d}. Đây là các toán tử có xuất hiện trong chương trình và có thể bị “viết nhầm” bởi các lập trình viên. Trong quá trình thực thi, Nester sinh ra số các đột biến là 78 và trong đó có 70 đột biến bị diệt và 8 đột biến “còn sống”. Tỷ lệ đột biến ở đây là xấp xỉ 90%. Cụ thể với từng trường hợp kiểm thử được cho trong Bảng 1. Bảng 1 - Chất lượng các trường hợp kiểm thử chương trình cs-money sau khi th ực thi Nester. Số đột biến diệt Số đột biến không Trường hợp kiểm thử được diệt được 1. BagMultiply 67 11 2. BagNegate 71 7 3. BagSimpleAdd 68 10 4. BagSubtract 67 11 5. BagSumAdd 68 10 6. IsZero 68 10 7. MixedSimpleAdd 71 7 8. MoneyBagEquals 71 7 9. MoneyBagHash 76 2 10. MoneyEquals 73 5 13
TẠP CHÍ KHOA HỌC VÀ CÔNG NGHỆ, ĐẠI HỌC ĐÀ NẴNG - SỐ 5(34).2009 11. MoneyHash 76 2 12. Normalize 71 7 13. Normalize2 68 10 14. Normalize3 66 12 15. Normalize4 67 11 16. Print 76 2 17. SimpleAdd 74 4 18. SimpleBagAdd 68 10 19. SimpleMultiply 75 3 20. SimpleNegate 74 4 21. SimpleSubtract 73 5 Điều này chứng tỏ, chất lượng bộ dữ liệu thử mà các kiểm thử viên tạo ra trong 21 trường hợp kiểm thử ở trên rõ ràng là chưa cao, vì không có bất kỳ một trường hợp kiểm thử nào diệt được tất cả các đột biến. Đặc biệt, 4 đột biến được sinh ra khi Nester “chèn lỗi” vào lớp AssemlyInfo.cs, thì không có bất cứ trường hợp kiểm thử nào diệt được. Như vậy, Nester đã đưa ra được một cảnh báo rất kịp thời để các kiểm thử viên xem xét và xây dựng lại các trường hợp kiểm thử và bộ dữ liệu thử tốt hơn để đảm bảo chất lượng của phần mềm 5. Kết luậ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 nhiều thành phần với nhiều các vai trò khác nhau. Do đó, việc xảy ra ồm 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 n hau. Kiểm thử là một giai đoạn đóng vai trò rất quan trọng, quyết định đến việc đánh giá chất lượng của một sản phẩm phần mềm. 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ế. Kiểm thử đột biến được giới thiệu như là một ý tưởng để đánh giá ch lượng ất của các bộ dữ liệu kiểm thử. Dựa vào các ưu điểm, nhược điểm của kỹ thuật kiểm thử đột biến, có các phương pháp nh cải tiến kỹ thuật kiểm thử đột biến , như: đột biến ằm yếu, đột biến lựa chọn, đột biến lạc quan... Bài báo đề xuất và xây dựng một giải pháp kiểm thử các chương trình C-Sharp hiệu quả, giảm chi phí và thời gian. Hiện nay, cho dù vấn đề kiểm thử phần mềm đã được chú trọng đầu tư và quan tâm nhiều trong suốt t iến trình phát triển sản phẩm phần mềm. Tuy nhiên, vấn đề chất 14
TẠP CHÍ KHOA HỌC VÀ CÔNG NGHỆ, ĐẠI HỌC ĐÀ NẴNG - SỐ 5(34).2009 lượng của các bộ dữ liệu kiểm thử gần như chưa được đánh giá một cách chính xác, điều đó góp phần làm giảm đi chất lượng và hiệu quả của các sản phẩm phần mềm. Đặc biệt là trong thời điểm Việt Nam đang mong mu xây dựng một ngành công nghiệp ốn phần mềm. Do đó, việc tạo điều kiện thuận lợi để nghiên cứu và ứng dụng kỹ thuật kiểm thử đột biến vào thực tế sẽ góp phần rất lớn trong việc nâng cao chất lượng các sản phẩm phần mềm. TÀI LIỆU THAM KHẢO [1] A.P. Mathur (1991), Performance, effectiveness and reliability issues in software testing, Tokyo, Japan. [2] Jeff Offutt, Ammei Lee, Gregg Rothermel, Roland H. Untch, and Christian Zapf (1996), An Experimental Determination of Sufficient Mutant Operators, George Mason University. [3] Jeff Offutt, Gregg Rothermel, Roland H. Untch, and Christian Zapf (1993), An Experimental Evaluation of Selective Mutation, Baltimore, MD. [4] Mark Harman and Rob Hierons (2006), “An Overview of Mutation Testing”, Genetic Algorithms for Mutation Testing, Brunel University, London. [5] R.A. DeMillo and A.J. Offutt (1993), Experimental results from an automatic test case generator, ACM transactions on Softwar Engineering Methodology, 2(2) pages 109-127. [6] R.Untch (1992), “Mutation-based software testing using program schemata”, Proceedings of 30th ACM Southeast Regional Conference, Raleigh, NC. [7] R. Untch, A.J. Offutt and M.J. Harold (1993), Mutation Analysis using program schemate, pages 139-148, Cambridge, MA. [8] T.A. Budd (1980), Mutation Analysis of Program Test Data, Ph.D Thesis, Yale University, New Haven CT. [9] Nguyen Thanh Binh, C. Robach (2001), “Mutation Testing Applied to Hardware: the Mutants Genenration”, Proceedings of the 11th IFIP International Conference on Very Large Scale Integration,118--123, Montpellier, France. [10] W.E. Howden (1982), Weak mutation testing and completeness of test sets, IEEE Transactions on Software Engineering, 8(4) pages 371-379. 15

CÓ THỂ BẠN MUỐN DOWNLOAD

TL.01: Bộ Tiểu Luận Triết Học

207 tài liệu

1470 lượt tải

THÔNG TIN

TRỢ GIÚP

HỖ TRỢ KHÁCH HÀNG

Theo dõi chúng tôi

Chịu trách nhiệm nội dung:

Nguyễn Công Hà - Giám đốc Công ty TNHH TÀI LIỆU TRỰC TUYẾN VI NA

LIÊN HỆ

Địa chỉ: P402, 54A Nơ Trang Long, Phường 14, Q.Bình Thạnh, TP.HCM

Hotline: 093 303 0098

Email: support@tailieu.vn

Giấy phép Mạng Xã Hội số: 670/GP-BTTTT cấp ngày 30/11/2015 Copyright © 2022-2032 TaiLieu.VN. All rights reserved.