Các kỹ thuật kiểm thử đột biến và ứng dụng kiểm thử chương trình C (luận văn thạc sĩ)

78 358 0
Các kỹ thuật kiểm thử đột biến và ứng dụng kiểm thử chương trình C (luận văn thạc sĩ)

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

Thông tin tài liệu

Các kỹ thuật kiểm thử đột biến và ứng dụng kiểm thử chương trình C (luận văn thạc sĩ)Các kỹ thuật kiểm thử đột biến và ứng dụng kiểm thử chương trình C (luận văn thạc sĩ)Các kỹ thuật kiểm thử đột biến và ứng dụng kiểm thử chương trình C (luận văn thạc sĩ)Các kỹ thuật kiểm thử đột biến và ứng dụng kiểm thử chương trình C (luận văn thạc sĩ)Các kỹ thuật kiểm thử đột biến và ứng dụng kiểm thử chương trình C (luận văn thạc sĩ)Các kỹ thuật kiểm thử đột biến và ứng dụng kiểm thử chương trình C (luận văn thạc sĩ)Các kỹ thuật kiểm thử đột biến và ứng dụng kiểm thử chương trình C (luận văn thạc sĩ)Các kỹ thuật kiểm thử đột biến và ứng dụng kiểm thử chương trình C (luận văn thạc sĩ)Các kỹ thuật kiểm thử đột biến và ứng dụng kiểm thử chương trình C (luận văn thạc sĩ)Các kỹ thuật kiểm thử đột biến và ứng dụng kiểm thử chương trình C (luận văn thạc sĩ)Các kỹ thuật kiểm thử đột biến và ứng dụng kiểm thử chương trình C (luận văn thạc sĩ)

ĐẠI HỌC QUỐC GIA HÀ NỘI TRƢỜNG ĐẠI HỌC KHOA HỌC TỰ NHIÊN - - PHẠM THỊ MIÊN CÁC KỸ THUẬT KIỂM THỬ ĐỘT BIẾN VÀ ỨNG DỤNG KIỂM THỬ CHƢƠNG TRÌNH C LUẬN VĂN THẠC SĨ KHOA HỌC Hà Nội - 2014 MỤC LỤC LỜI CẢM ƠN MỤC LỤC I) DANH MỤC CÁC TỪ VIẾT TẮT, THUẬT NGỮ Error! Bookmark not defined II) DANH MỤC CÁC BẢNG BIỂU Error! Bookmark not defined III) DANH MỤC CÁC HÌNH VẼ Error! Bookmark not defined LỜI MỞ ĐẦU CHƢƠNG – KHÁI QUÁT VỀ KIỂM THỬ PHẦN MỀM 1.1 Khái niệm 1.2 Các cấp độ kiểm thử phần mềm 1.2.1 Kiểm thử đơn vị (Unit Test) 1.2.2 Kiểm thử tích hợp (Integration Test) 1.2.3 Kiểm thử hệ thống (System Test) 10 1.2.4 Kiểm thử chấp nhận sản phẩm (Acceptance Test) 12 1.3 Kỹ thuật kiểm thử phần mềm 12 1.3.1 Kỹ thuật kiểm thử hộp đen (Black – box Testing) 12 1.3.1.1 Phân hoạch tƣơng đƣơng 14 1.3.1.2 Phân tích giá trị biên 16 1.3.2 Kỹ thuật kiểm thử hộp trắng (White – box Testing) 17 1.3.2.1 Kiểm thử đƣờng dẫn sở 17 1.3.2.2 Kiểm thử cấu trúc điều khiển 22 1.4 Kết luận 25 CHƢƠNG – KỸ THUẬT KIỂM THỬ ĐỘT BIẾN 26 2.1 Một số khái niệm 26 2.1.1 Kiểm thử đột biến 26 2.1.2 Đột biến 26 2.1.3 Toán tử đột biến 29 2.2 Cơ sở kiểm thử đột biến 29 2.3 Toán tử đột biến 29 2.4 Quy trình kiểm thử đột biến 31 2.5 Hạn chế kiểm thử đột biến 33 2.6 Kết luận 34 CHƢƠNG - MỘT SỐ CẢI TIẾN KỸ THUẬT KIỂM THỬ ĐỘT BIẾN 35 3.1 Giảm chi phí tính toán 35 3.1.1 Phƣơng pháp làm (A “do fewer” approach) 35 3.1.1.1 Lấy mẫu đột biến (Mutant Sampling) 36 3.1.1.2 Đột biến ràng buộc (Constrained Mutation) 38 3.1.1.3 N - đột biến lựa chọn (N - Selective Mutation) 39 3.1.2 Phƣơng pháp làm nhanh (A “do smarter” approach) 41 3.1.2.1 Phƣơng pháp tạo lƣợc đồ đột biến 42 3.1.2.2 Đột biến yếu (Weak Mutation) 44 3.2 Tăng tự động hóa 47 3.2.1 Tạo liệu thử tự động 47 3.2.2 Xác định đột biến tƣơng đƣơng tự động 49 3.3 Kết luận 52 CHƢƠNG - ỨNG DỤNG KỸ THUẬT KIỂM THỬ ĐỘT BIẾN ĐỂ KIỂM THỬ CÁC CHƢƠNG TRÌNH C (C – Sharp) 53 4.1 Tìm hiểu NUnit 54 4.1.1 Định nghĩa 54 4.1.2 Đặc điểm NUnit 54 4.1.3 Thuộc tính hay dùng thƣ viện NUnit.Framework 54 4.1.4 Phƣơng thức tĩnh hay dùng NUnit.Framework.Assert 56 4.1.5 Cài đặt NUnit 58 4.1.6 Cách sử dụng NUnit 60 4.2 Công cụ Nester 68 4.2.1 Điều kiện tiên 68 4.2.2 Giải pháp cho đột biến 68 4.2.3 Chạy Nester 69 4.2.4 Lựa chọn Nester.exe.config 71 4.3 Quy trình ứng dụng kiểm thử đột biến để kiểm thử chƣơng trình C - Sharp 71 4.3.1 Kiểm thử 72 4.3.2 Tạo đột biến 73 4.4 Kết luận 75 KẾT LUẬN 76 TÀI LIỆU THAM KHẢO 78 PHỤ LỤC Error! Bookmark not defined PHỤ LỤC Error! Bookmark not defined PHỤ LỤC Error! Bookmark not defined PHỤ LỤC Error! Bookmark not defined PHỤ LỤC Error! Bookmark not defined LỜI MỞ ĐẦU Kiểm thử phần mềm hoạt động giữ vai trò quan trọng để bảo đảm chất lƣợng phần mềm hoạt động mang tính sống dự án sản xuất 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 dự án phát triển phần mềm giới Ở Việt Nam, ngành công nghiệp phần mềm phát triển xem nhẹ việc kiểm thử phần mềm xác suất thất bại cao, nữa, hầu hết công ty phần mềm có uy tín đặt yêu cầu nghiêm ngặt phần mềm tài liệu kiểm thử kèm 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ử hệ thống phức tạp đòi hỏi nhiều nguồn tài nguyên chi phí cao  Thứ hai, tiến trình phát triển phần mềm trải qua nhiều hoạt động biến đổi thông tin, mát thông tin trình biến đổi yếu tố làm cho hoạt động kiểm thử khó khăn  Thứ ba, kiểm thử chƣa đƣợc trọng đào tạo ngƣời  Cuối cùng, không tồn kỹ thuật kiểm thử cho phép khẳng định phần mềm hoàn toàn đắn hay không chứa lỗi Với mục đích phát lỗi, kiểm thử phần mềm thƣờng phải trải qua bƣớc: tạo liệu thử, thực thi phần mềm liệu thử quan sát kết nhận đƣợc Trong bƣớc này, bƣớc tạo liệu đóng vai trò quan trọng nhất, tạo liệu từ miền vào chƣơng trình, mà tạo liệu thử có khả phát lỗi cao Vấn đề đặt làm để đánh giá đƣợc khả phát lỗi liệu thử? Một kinh nghiệm để giúp giải vấn đề này, sử dụng khái niệm chất lượng liệu thử nhƣ phƣơng tiện để đánh giá liệu thử nhƣ “tốt” 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 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 liệu thử thực dòng lệnh chƣơng trình lần Nếu liệu thử đƣợc tìm thấy không chất lƣợng liên quan đến tiêu chuẩn (tức tất câu lệnh đƣợc thực lần), kiểm thử bắt buộc Do đó, mục tiêu tạo tập kiểm thử thực đầ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 kiểm thử định (thực tất đƣờng dẫn sai qua chƣơng trình) dựa vào việc thực chƣơng trình với số lƣợng kiểm thử tăng dần để nâng cao độ tin cậy chƣơng trình Tuy nhiên, chúng không tập trung vào nguyên nhân thất bại chƣơng trình - đƣợc gọi lỗi Kiểm thử đột biến tiêu chuẩn nhƣ Tiêu chuẩn tạo phiên chƣơng trình có chứa lỗi đơn giản sau tìm kiểm thử để dấu hiệu lỗi Nếu tìm thấy liệu thử chất lƣợng làm lộ dấu hiệu tất phiên bị lỗi, tin tƣởng vào tính đắn chƣơng trình tăng Kiểm thử đột biến đƣợc áp dụng cho nhiều ngôn ngữ lập trình nhƣ kỹ thuật kiểm thử hộp trắng Ý thức đƣợc lĩnh vực nghiên cứu có nhiều triển vọng ứng dụng phát triển phần mềm, chọn hƣớng nghiên cứu “ Các kỹ thuật kiểm thử đột biến ứng dụng kiểm thử chương trình C” cho đề tài luận văn Luận văn đƣợc tổ chức thành chƣơng nhƣ sau:  Chƣơng – Trình bày khái quát 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 mức kiểm thử phần mềm Chƣơng đề cập đến việc sử dụng kỹ thuật kiểm thử hộp trắng hộp đen để thiết kế liệu thử  Chƣơng - Mô tả chi tiết thành phần kỹ thuật kiểm thử đột biến, giới thiệu giả thuyết cần thiết để thực phƣơng pháp Chƣơng cung cấp quy trình để phân tích đột biến, từ rút đƣợc vấn đề hạn chế kỹ thuật kiểm thử đột biến, đƣợc cải tiến chƣơng  Chƣơng – Giới thiệu số 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 tăng tự động hóa  Chƣơng – 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í NUnit dùng để kiểm thử đơn vị chƣơng trình C#, Nester với chức phân tích tạo đột biến Tiếp ứng dụng kỹ thuật kiểm thử đột biến để kiểm thử chƣơng trình C# sử dụng hai công cụ CHƢƠNG – KHÁI QUÁT VỀ KIỂM THỬ PHẦN MỀM 1.1 Khái niệm Kiểm thử phần mềm trình thực thi hệ thống phần mềm để xác định xem phần mềm có với đặc tả không thực môi trƣờng nhƣ mong đợi hay không Mục đích kiểm thử phần mềm tìm lỗi chƣa đƣợc phát hiện, tìm cách sớm bảo đảm lỗi đƣợc sửa Mục tiêu kiểm thử phần mềm thiết kế tài liệu kiểm thử cách có hệ thống thực cho có hiệu quả, nhƣng tiết kiệm đƣợc thời gian, công sức chi phí 1.2 Các cấp độ kiểm thử phần mềm Cấp độ kiểm thử phần mềm đƣợc thể hình 1.1 [25]: Kiểm thử mức đơn vị lập trình (Unit test) Các phận đơn lẻ Kiểm thử mức tích hợp đơn vị (Integration test) Các nhóm phận Kiểm thử mức hệ thống, sau tích hợp (System test) Kiểm thử để chấp nhận sản phẩm (Acceptance test) Toàn hệ thống Toàn hệ thống nhìn từ khách hàng Hình 1.1- Bốn cấp độ kiểm thử phần mềm 1.2.1 Kiểm thử đơn vị (Unit Test) Một đơn vị (Unit) thành phần phần mềm nhỏ mà ta kiểm thử đƣợc, ví dụ: hàm (Function), thủ tục (Procedure), lớp (Class), phƣơng thức (Method) Kiểm thử đơn vị thƣờng lập trình viên thực Công đoạn cần đƣợc thực sớm tốt giai đoạn viết code xuyên suốt chu kỳ phát triển phần mềm Mục đích kiểm thử đơn vị bảo đảm thông tin đƣợc xử lý kết xuất (khỏi Unit) xác, mối tƣơng quan với liệu nhập chức xử lý Unit Điều thƣờng đòi hỏi tất nhánh bên Unit phải đƣợc kiểm tra để phát nhánh phát sinh lỗi Cũng nhƣ mức kiểm thử khác, kiểm thử đơn vị đòi hỏi phải chuẩn bị trƣớc ca kiểm thử (hay trƣờng hợp kiểm thử) (test case) kịch (test script), định rõ liệu vào, bƣớc thực liệu mong muốn xuất Các test case test script đƣợc giữ lại để sử dụng sau 1.2.2 Kiểm thử tích hợp (Integration Test) Kiểm thử tích hợp kết hợp thành phần ứng dụng kiểm thử nhƣ ứng dụng hoàn thành Trong kiểm thử đơn vị kiểm tra thành phần Unit riêng lẻ kiểm thử tích hợp kết hợp chúng lại với kiểm tra giao tiếp chúng Kiểm thử tích hợp có hai mục tiêu là:  Phát lỗi giao tiếp xảy Unit  Tích hợp Unit đơn lẻ thành hệ thống (gọi subsystem) cuối nguyên hệ thống hoàn chỉnh chuẩn bị cho kiểm thử mức hệ thống (system test) Có loại kiểm thử kiểm thử tích hợp nhƣ sau:  Kiểm thử cấu trúc (Structure test): Kiểm thử nhằm bảo đảm thành phần bên chƣơng trình chạy đúng, trọng đến hoạt động thành phần cấu trúc nội chƣơng trình, chẳng hạn lệnh nhánh bên  Kiểm thử chức (Functional test): Kiểm thử trọng đến chức chƣơng trình, không quan tâm đến cấu trúc bên trong, khảo sát chức chƣơng trình theo yêu cầu kỹ thuật  Kiểm thử hiệu (Performance test): Kiểm thử việc vận hành hệ thống  Kiểm thử khả chịu tải (Stress test): Kiểm thử giới hạn hệ thống 1.2.3 Kiểm thử hệ thống (System Test) Mục đích kiểm thử hệ thống kiểm thử xem thiết kế toàn hệ thống (sau tích hợp) có thỏa mãn yêu cầu đặt hay không Kiểm thử hệ thống kiểm tra hành vi chức phần mềm lẫn yêu cầu chất lƣợng nhƣ độ tin cậy, tính tiện lợi sử dụng, hiệu bảo mật Kiểm thử hệ thống bắt đầu tất phận phần mềm đƣợc tích hợp thành công Thông thƣờng loại kiểm thử tốn nhiều công sức thời gian Trong nhiều trƣờng hợp, việc kiểm thử đòi hỏi số thiết bị phụ trợ, phần mềm phần cứng đặc thù, đặc biệt ứng dụng thời gian thực, hệ thống phân bố, hệ thống nhúng Ở mức độ hệ thống, ngƣời kiểm thử tìm kiếm lỗi, nhƣng trọng tâm đánh giá hoạt động, thao tác, tin cậy yêu cầu khác liên quan đến chất lƣợng toàn hệ thống Điểm khác then chốt kiểm thử tích hợp kiểm thử hệ thống kiểm thử hệ thống trọng hành vi lỗi toàn hệ thống, kiểm thử tích hợp trọng giao tiếp đơn thể đối tƣợng chúng làm việc Thông thƣờng ta phải thực kiểm thử đơn vị kiểm 10  Bƣớc 12: Tạo phƣơng thức MyTest lớp test Lƣu ý phƣơng thức sử dụng public void, đối số truyền vào Xác định phƣơng thức test việc trang trí với thuộc tính [Test]  Bƣớc 13: Viết test Trong trƣờng hợp này, kiểm thử phƣơng thức Add MyMath  Hoàn thành tình test 64 b Sử dụng NUnit Sau hoàn thành công việc viết code cho tình test bắt đầu sử dụng NUnit để kiểm tra trình viết code tạo test case Quá trình test NUnit:  Bƣớc 1: Chạy NUnit giao diện NUnit nhƣ sau:  Bƣớc 2: Add project vừa viết vào công cụ NUnit nhƣ sau: (trƣớc thực công việc Add project cần phải Built project đó.) File →Open Project →Tìm tới File MyAppTest.exe(file vừa viết) 65  Kích vào MyAppTest.exe →Open Lúc giao diện NUnit nhƣ sau:  Bƣớc 4: Kiểm tra cách ấn vào Run Lúc giao diện NUnit hiển thị nhƣ sau: Trong giao diện NUnit gồm có: MyAppTest namespace để thực thi, MyAddTest lớp test, MyTest phƣơng thức test 66 Trƣờng hợp lỗi xảy viết code test case bị sai: Ví dụ: Đƣa sai mong đợi đầu test case giao diện NUnit nhƣ sau: Trong giao diện có hiển thị: Expected(mong đợi): 11 nhƣng But was (thực tế):10 Chú ý: Có số trƣờng hợp Add vào NUnit file mà hiển thị ra: Cách khắc phục nhƣ sau: (add NUnit vào Visual Studio) Mở project chuẩn bị test Thực vào: Menu Tools→ External Tools→ Add→…(điền thông số nhƣ hình vẽ sau:) 67 Thực test case khác làm tƣơng tự nhƣ 4.2 Công cụ Nester Nester công cụ miễn phí hệ thống đột biến cho C-Sharp hỗ trợ toàn trình đột biến cho chƣơng trình C-Sharp Nó sản sinh đột biến cách tự động, thực thi đột biến với liệu thử báo cáo tỷ lệ đột biến liệu thử Nó liên quan đến việc sửa đổi bổ sung chƣơng trình để phân biệt chƣơng trình ban đầu từ chƣơng trình bị sửa đổi Phiên Nester 0.3 Alpha hỗ trợ cho chƣơng trình CSharp Microsoft Visual Studio 2005 NUnit Framework 4.2.1 Điều kiện tiên Microsoft NET Framework 2.0 (tải miễn phí) Đây phiên đƣợc hỗ trợ thời điểm 4.2.2 Giải pháp cho đột biến Tạo sở mã nguồn Mở ứng dụng Visual Studio 2005 Xây dựng cấu hình phát hành Chạy đơn vị thử nghiệm 68 4.2.3 Chạy Nester Tải Nester.zip Giải nén nội dung kho lƣu trữ vào thƣ mục đích Sao chép NUnit.core.dll NUnit.core.interfaces.dll từ cài đặt NUnit vào thƣ mục mục tiêu Nester Lƣu ý thƣ mục NET Framework (% SystemRoot% \ Microsoft.NET \ Framework \ v2.0.50727) đƣờng dẫn để Nester chạy msbuild.exe Nếu không, thêm thông qua Control Panel / System / Advanced / Biến môi trƣờng Run Nester.exe Giao diện chạy Nester: 69 Minh họa chƣơng trình chạy hệ thống đột biến đƣợc hiển thị chế độ xem mã nguồn: Trong đoạn mã nguồn trên, điểm mã màu xanh nơi xảy đột biến đột biến bị diệt Điểm màu đỏ đại diện cho đột biến chƣa diệt đƣợc 70 4.2.4 Lựa chọn Nester.exe.config Giá trị Key Mô tả mặc định Báo cáo thông tin đột biến cố gắng ReportKilledMutations giết chết Nếu sai Nester sử dụng kiểm tra chạy thất bại ClearReadOnlyFlag Tự động rõ ràng đọc cờ từ nguồn Nếu đơn vị kiểm tra thời gian thực vƣợt quy định thời gian chờ Nester, UnitTestTimeOut 5000 xem xét kiểm tra nhƣ thất bại Đặt bạn muốn chuyển đổi thời gian chờ việc DetectAssertions BuildConfiguration Phát hành shadowfiles.path Hãy thử để phát Debug.Assert () Chỉ định Nester nên xây dựng cấu hình gỡ rối phát hành Đƣờng dẫn NUnit AppDomain bóng Bảng 4.1 Lựa chọn Nester.exe.config 4.3 Quy trình ứng dụng kiểm thử đột biến để kiểm thử chƣơng trình C - Sharp Quy trình kiểm thử chƣơng trình C # đƣợc minh hoạ hình 4.1 Trong phần minh hoạ ứng dụng kiểm thử đột biến xin đƣợc minh họa chƣơng trình cs-money đƣợc viết ngôn ngữ C-Sharp gồm có lớp nhƣ: AssemblyInfo.cs, Imoney.cs, Money.cs, MoneyBag.cs, gồm 71 khoảng 200 dòng lệnh 21 trƣờng hợp kiểm thử liệu thử đƣợc xây dựng MoneyTest.cs Phần code lớp đƣợc trình bày phần phụ lục 4.3.1 Kiểm thử Kiểm thử chƣơng trình kiểm thử NUnit (phiên 2.5.2), với trƣờng hợp kiểm thử liệu thử đƣợc thiết kế sẵn Dƣới “góc nhìn” NUnit với liệu thử đƣợc xây dựng 21 trƣờng hợp kiểm thử chƣơng trình tốt Kết chạy NUnit: Bảng 4.2 Kết chạy NUnit 72 Phân tích kết sau chạy NUnit : Kiểm tra tất mục, có giá trị nhƣ tổng số cột Nhìn vào bảng kết thấy mẫu BagNegative () diệt tổng cộng 21 đột biến, đột biến tƣơng tự bị diệt MixedSimpleAdd () Điều nghĩa nên loại bỏ BagNegative (), MixedSimpleAdd () thay Kiểm tra tất mục, có điểm đặc biệt số đột biến bị diệt thấp Từ để viết trƣờng hợp thử nghiệm cho hợp lý Rõ ràng vấn đề với việc kiểm tra nhỏ đƣợc tăng kích thƣớc mã kiểm tra đơn vị bảo trì tốn Kiểm tra tất mục, có tổng số đột biến bị diệt cao 4.3.2 Tạo đột biến Sử dụng Nester với tập toán tử đột biến đƣợc lựa chọn để thực độ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 toán tử có xuất chƣơng trình bị “viết nhầm” lập trình viên Trong trình thực thi, Nester sinh số đột biến 78 có 70 đột biến bị diệt đột biến “còn sống” Tỷ lệ đột biến xấp xỉ 90% Cụ thể với trƣờng hợp kiểm thử đƣợc cho Bảng 4.3 73 Bảng 4.3 – Chất lượng trường hợp kiểm thử chương trình cs-money sau thực thi Nester Số đột biến Trƣờng hợp kiểm thử diệt đƣợc Số đột biến không diệt đƣợc BagMultiply 67 11 diệt BagNegate 71 BagSimpleAdd 68 đƣợc 10 BagSubtract 67 11 BagSumAdd 68 10 IsZero 68 10 MixedSimpleAdd 71 MoneyBagEquals 71 MoneyBagHash 76 10 MoneyEquals 73 11 MoneyHash 76 12 Normalize 71 13 Normalize2 68 10 14 Normalize3 66 12 15 Normalize4 67 11 16 Print 76 17 SimpleAdd 74 18 SimpleBagAdd 68 10 19 SimpleMultiply 75 20 SimpleNegate 74 21 SimpleSubtract 73 Điều chứng tỏ, chất lƣợng liệu thử đƣợc tạo 21 trƣờng hợp kiểm thử rõ ràng chƣa cao, trƣờng hợp kiểm thử diệt đƣợc tất đột biến Đặc biệt, đột biến đƣợc sinh Nester “chèn lỗi” vào lớp AssemlyInfo.cs, bất 74 trƣờng hợp kiểm thử diệt đƣợc Nhƣ vậy, Nester đƣa đƣợc cảnh báo kịp thời để xem xét xây dựng lại trƣờng hợp kiểm thử liệu thử tốt để đảm bảo chất lƣợng phần mềm 4.4 Kết luận Kiểm thử đột biến đƣợc giới thiệu nhƣ ý tƣởng để đánh giá chất lƣợng liệu kiểm thử Dựa vào ƣu điểm, nhƣợc điểm kỹ thuật kiểm thử đột biến, có phƣơng pháp nhằm cải tiến kỹ thuật kiểm thử đột biến nhƣ chƣơng 3; chƣơng ứng dụng để kiểm thử chƣơng trình C-Sharp hiệu quả, giảm chi phí thời gian Tuy nhiên từ chất lƣợng trƣờng hợp kiểm thử chƣơng trình sau chạy Nester cho thấy chất lƣợng liệu thử đƣợc tạo 21 trƣờng hợp kiểm thử rõ ràng chƣa cao, trƣờng hợp kiểm thử diệt đƣợc tất đột biến Vì cần xây dựng lại trƣờng hợp kiểm thử liệu thử tốt nhằm nâng cao chất lƣợng chƣơng trình cs – money 75 KẾT LUẬN Với cách tiếp cận dựa đề xuất có lĩnh vực nghiên cứu kiểm thử phần mềm, luận văn tổng hợp nét kiểm thử phần mềm nói chung kiểm thử đột biến nói riêng với cải tiến Sau điểm mà luận văn tập trung nghiên cứu:  Trình bày cách tổng quan kiểm thử phần mềm: khái niệm, mục đích mục tiêu kiểm thử, giới thiệu hai phƣơng pháp thiết kế liệu thử phổ biến đƣợc hầu hết kiểm thử viên sử dụng phƣơng pháp kiểm thử hộp trắng phƣơng pháp kiểm thử hộp đen, kèm theo ví dụ  Giới thiệu kỹ thuật kiểm thử đột biến, quy tắc để tạo đột biến quy trình phân tích đột biến; vấn đề hạn chế kiểm thử đột biến, từ giới thiệu số kỹ thuật cải tiến nhằm khắc phục hạn chế  Sử dụng hai công cụ mã nguồn mở miễn phí Nester để tạo - phân tích đột biến, NUnit để kiểm thử đơn vị ứng dụng kiểm thử đột biến chƣơng trình C#; cụ thể sử dụng kỹ thuật đột biến lựa chọn để kiểm thử chƣơng trình cs – money với 21 trƣờng hợp kiểm đạt tỷ lệ xấp xỉ 90% Trong trình thực luận văn nhƣ thời gian trƣớc đó, cố gắng tập trung nghiên cứu kỹ thuật kiểm thử nhƣ tham khảo nhiều tài liệu liên quan Tuy nhiên, thời gian trình độ có hạn nên không tránh khỏi hạn chế thiếu sót định Tôi thật mong muốn nhận đƣợc góp ý chuyên môn lẫn cách trình bày luận văn từ bạn đọc 76 HƢỚNG PHÁT TRIỂN Kiểm thử đột biến kỹ thuật kiểm thử đƣợc nhiều nhà nghiên cứu quan tâm tác dụng Tuy nhiên, luận văn này, tồn nhiều vấn đề, thời gian tới, cần phải tiếp tục nghiên cứu: - Các vấn đề phát đột biến tƣơng đƣơng chƣơng trình đƣợc kiểm thử - Tìm hiểu thêm phƣơng pháp khác nhằm giảm chi phí tính toán tăng tính tự động hoá cho chƣơng trình đƣợc kiểm thử - Đối với ứng dụng kỹ thuật kiểm thử đột biến để kiểm thử chƣơng trình cs - money, luận văn dừng lại mức độ đánh giá chất lƣợng 21 trƣờng hợp kiểm thử đƣợc xây dựng trên, chƣa cải tiến để đạt tỷ lệ đột biến 100% Do đó, thời gian tới, tiếp tục nghiên cứu để loại bỏ đột biến tƣơng đƣơng số đột biến sống chƣơng trình này, đồng thời cải tiến trƣờng hợp kiểm thử để đạt tỷ lệ đột biến 100% Cuối cùng, hy vọng sau giải xong vấn đề tồn nêu trên, tiếp tục nghiên cứu kiểm thử đột biến để ứng dụng cho ngôn ngữ khác nhƣ: JAVA, SQL, ….Bởi vì, qua trình nghiên cứu kỹ thuật kiểm thử đột biến, thấy có nhiều công cụ hỗ trợ để thực kiểm thử đột biến cho ngôn ngữ 77 TÀI LIỆU THAM KHẢO Tiếng Việt [1] Nguyễn Xuân Huy (1994), Công nghệ phần mềm, Trƣờng Đại học Tổng hợp TP.HCM [2] Lê Văn Tƣờng Lân (2004), Giáo trình công nghệ phần mềm, Trƣờng Đại học Khoa học Huế - Đại học Huế [3] Hồ Văn Phi (2008), Nghiên cứu ứng dụng kiểm thử đột biến cho câu lệnh truy vấn SQL, 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 Tiếng Anh [4] A.P Mathur (1991), Performance, effectiveness and reliability issues in software testing, Tokyo, Japan [5] A.J.Offutt and K.N.King, “A Fortran 77 interpreter for mutation analysis”, in 1987 Symposium on Interpreters and Interpretive Techniqes, pp 177-188, ACM SIGPLAN, June 1987 [6] A.J Offutt and W.M Craft, “Using compiler optimization techniques to detect equivalent mutants,” The Journal of Softwave Testing, Verification, and Reliability, vol.4, pp 131-154, September 1994 [7] A.T Acree, T.A Budd, R.A DeMillo, R.J Lipton, and F.G Sayward, “Mutation Analysis”, Georgia Institute of Technology, Technical Report, GIT – ICS – 79/08, 1979 [8] A.T.Acree, On Mutation, PhD thesis, Georgia Institute of Technology, Atlanta GA, 1980 [9] Jeff Offutt, Ammei Lee, Gregg Rothermel, Roland H Untch, and Christian Zapf (1996), An Experimental Determination of Sufficient Mutant Operators, George Mason University 78 ... kỹ thuật kiểm thử hộp trắng Ý th c đƣ c lĩnh v c nghiên c u c nhiều triển vọng ứng dụng phát triển phần mềm, chọn hƣớng nghiên c u “ C c kỹ thuật kiểm thử đột biến ứng dụng kiểm thử chương trình. ..  C c ch c thiếu không  C c lỗi giao diện  C c lỗi c u tr c liệu truy c p sở liệu bên  C c lỗi th c  C c lỗi khởi tạo kết th c  Và lỗi kh c Không giống với kiểm thử hộp trắng đƣ c th c. .. thử đơn vị chƣơng trình C# , Nester với ch c phân tích tạo đột biến Tiếp ứng dụng kỹ thuật kiểm thử đột biến để kiểm thử chƣơng trình C# sử dụng hai c ng c CHƢƠNG – KHÁI QUÁT VỀ KIỂM THỬ PHẦN MỀM

Ngày đăng: 16/12/2016, 19:37

Từ khóa liên quan

Tài liệu cùng người dùng

Tài liệu liên quan