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

LỜI CẢM ƠN Trong suốt quá trình học tập và làm luận văn, đã nhận được sự hướng dẫn, giúp đỡ quý báu của quý thầy cô, các anh chị và các bạn Với lòng kính trọng và biết ơn sâu sắc xin được bày tỏ lời cảm ơn chân thành tới: • Ban giám hiệu, Phòng đào tạo sau đại học trường Đại Học Khoa Học Tự Nhiên; • Phó giáo sư - Tiến sĩ Đoàn Văn Ban - người thầy đã hết lòng giúp đỡ, dạy bảo, động viên và tạo mọi điều kiện thuận lợi cho suốt quá trình học tập và hoàn thành luận văn tốt nghiệp • Cùng tất cả các thầy cô khoa, trường, các anh chị lớp • Xin chân thành cảm ơn các thầy cô hội đồng đã cho những đóng góp quý báu để hoàn chỉnh luận văn này Tác giả Phạm Thị Miên MỤC LỤC LỜI CẢM ƠN .1 MỤC LỤC Chương i) dANH MỤC CÁC TỪ VIẾT TẮT, THUẬT NGỮ II) dANH MỤC CÁC BẢNG BIỂU iiI) DANH MỤC CÁC HÌNH VẼ .3 LỜI MỞ ĐẦU .4 CHƯƠNG – KHÁI QUÁT VỀ KIỂM THỬ PHẦN MỀM CHƯƠNG – KỸ THUẬT KIỂM THỬ ĐỘT BIẾN 25 CHƯƠNG - MỘT SỐ CẢI TIẾN KỸ THUẬT .34 KIỂM THỬ ĐỘT BIẾN 34 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) 52 KẾT LUẬN .75 TÀI LIỆU THAM KHẢO 77 PHỤ LỤC .80 PHỤ LỤC .82 PHỤ LỤC .88 PHỤ LỤC .92 PHỤ LỤC .93 LỜI CẢM ƠN .1 MỤC LỤC Chương i) dANH MỤC CÁC TỪ VIẾT TẮT, THUẬT NGỮ II) dANH MỤC CÁC BẢNG BIỂU iiI) DANH MỤC CÁC HÌNH VẼ .3 LỜI MỞ ĐẦU .4 CHƯƠNG – KHÁI QUÁT VỀ KIỂM THỬ PHẦN MỀM CHƯƠNG – KỸ THUẬT KIỂM THỬ ĐỘT BIẾN 25 CHƯƠNG - MỘT SỐ CẢI TIẾN KỸ THUẬT .34 KIỂM THỬ ĐỘT BIẾN 34 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) 52 KẾT LUẬN .75 TÀI LIỆU THAM KHẢO 77 PHỤ LỤC .80 PHỤ LỤC .82 PHỤ LỤC .88 PHỤ LỤC .92 PHỤ LỤC .93 CHƯƠNG .I) DANH MỤC CÁC TỪ VIẾT TẮT, THUẬT NGỮ - CBT (Constraint Based Testing): Kiểm thử dựa ràng buộc - MSG (Mutation Analysis Using Mutant Schemata): Phương pháp tạo lược đồ đột biến - PUT (Program Unit Test): Chương trình gốc II) DANH MỤC CÁC BẢNG BIỂU Bảng 1.1 Ví dụ các lớp tương đương Bảng 2.1 22 toán tử chuẩn được sử dụng Mothra Bảng 4.1 Lựa chọn Nester.exe.config Bảng 4.2 Kết quả chạy NUnit Bảng 4.3 Chất lượng các trường hợp kiểm thử chương trình cs – money sau thực hiện Nester III) DANH MỤC CÁC HÌNH VẼ Hình 1.1 Bốn cấp độ bản của kiểm thử phần mềm Hình 1.2 Đồ thị luồng điều khiển Hình 1.3 Ví dụ minh hoạ phát sinh các trường hợp kiểm thử theo đường dẫn sở Hình 1.4 Các kiểu vòng lặp Hình 2.1 Ví dụ về đột biến tương đương Hình 2.2 Ví dụ về đột biến Hình 3.1 Ba kịch bản có thể có cho quan hệ giữa các tập dữ liệu thử diệt đột biến yếu và mạnh Hình 3.2 Phân bố đột biến toán tử đột biến cho Mothra Hình 3.3 Ví dụ phương thức gốc (PUT) Hình 3.4 Phiên bản đột biến của PUT gốc hình 3.3 Hình 4.1 Quy trình ứng dụng kiểm thử đột biến C# LỜI MỞ ĐẦU Kiểm thử phần mềm là một hoạt động giữ vai trò quan trọng để bảo đảm chất lượng phần mềm và là hoạt động mang tính sống còn các dự án sản xuất gia công phần mềm Vì vậy, kiểm thử phần mềm đã trở thành qui trình bắt buộc các dự án phát triển phần mềm thế giới Ở Việt Nam, ngành công nghiệp phần mềm phát triển thì không thể xem nhẹ việc kiểm thử phần mềm vì xác suất thất bại cao, nữa, hầu hết các công ty phần mềm có uy tín đều đặt yêu cầu nghiêm ngặt là nếu một phần mềm không có tài liệu kiểm thử kèm thì không được chấp nhận Tuy nhiên, hoạt động kiểm thử thường gặp nhiều khó khăn: − Thứ nhất, kiểm thử các hệ thống phức tạp đòi hỏi nhiều nguồn tài nguyên và chi phí cao − Thứ hai, tiến trình phát triển phần mềm trải qua nhiều hoạt động biến đổi thông tin, sự mát thông tin quá trình biến đổi là yếu tố chính làm cho hoạt động kiểm thử khó khăn − Thứ ba, kiểm thử chưa được chú trọng đào tạo người − Cuối cùng, không tồn tại kỹ thuật kiểm thử cho phép khẳng định một phần mềm hoàn toàn đúng đắn hay không chứa lỗi Với mục đích phát hiện lỗi, kiểm thử phần mềm thường phải trải qua các bước: tạo dữ liệu thử, thực thi phần mềm dữ liệu thử và quan sát kết quả nhận được Trong các bước này, bước tạo dữ liệu đóng vai trò quan trọng nhất, vì chúng ta không thể tạo mọi dữ liệu từ miền vào của chương trình, mà chúng ta chỉ có thể tạo các dữ liệu thử có khả phát hiện lỗi cao Vấn đề đặt là làm thế nào để đánh giá được khả phát hiện lỗi của một bộ dữ liệu thử? Một kinh nghiệm để giúp giải quyết vấn đề này, đó là sử dụng khái niệm chất lượng liệu thử là một phương tiện để đánh giá bộ dữ liệu thử thế nào là “tốt” kiểm thử chương trình Ở đây, “tốt” được đánh giá liên quan đến tiêu chuẩn chất lượng được định trước, thường là một số dấu hiệu bao phủ chương trình Ví dụ, tiêu chuẩn bao phủ dòng lệnh đòi hỏi bộ dữ liệu thử thực hiện mọi dòng lệnh chương trình ít một lần Nếu bộ dữ liệu thử được tìm thấy không chất lượng liên quan đến tiêu chuẩn (tức là không phải tất cả các câu lệnh đều được thực hiện ít một lần), thì kiểm thử nữa là bắt buộc Do đó, mục tiêu là tạo một tập các kiểm thử thực hiện đầy đủ tiêu chuẩn chất lượng Tiêu chuẩn chất lượng tiêu biểu bao phủ câu lệnh và kiểm thử quyết định (thực hiện tất cả các đường dẫn đúng và sai qua chương trình) dựa vào việc thực hiện chương trình với số lượng kiểm thử tăng dần để nâng cao độ tin cậy của chương trình đó Tuy nhiên, chúng không tập trung vào nguyên nhân thất bại của chương trình - được gọi là lỗi Kiểm thử đột biến là một tiêu chuẩn vậy Tiêu chuẩn này tạo các phiên bản của chương trình có chứa các lỗi đơn giản và sau đó tìm các kiểm thử để chỉ các dấu hiệu của lỗi Nếu có thể tìm thấy một bộ dữ liệu thử chất lượng làm lộ các dấu hiệu này tất cả các phiên bản bị lỗi, thì sự tin tưởng vào tính đúng đắn của chương trình tăng Kiểm thử đột biến đã được áp dụng cho nhiều ngôn ngữ lập trình là một kỹ thuật kiểm thử hộp trắng Ý thức được là một lĩnh vực nghiên cứu có nhiều triển vọng ứng dụng phát triển phần mềm, đã chọ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 đề tài luận văn của mình Luận văn được tổ chức thành chương sau:  Chương – Trình bày khái quát về kiểm thử phần mềm khái niệm kiểm thử phần mềm, mục đích, mục tiêu và các mức kiểm thử phần mềm Chương này đề cập đến việc sử dụng các kỹ thuật kiểm thử hộp trắng và hộp đen để thiết kế dữ liệu thử  Chương - Mô tả chi tiết các thành phần chính của kỹ thuật kiểm thử đột biến, giới thiệu các giả thuyết bản cần thiết để thực hiện phương pháp này Chương này còn cung cấp quy trình để phân tích đột biến, từ đó rút được những vấn đề còn hạn chế đối với kỹ thuật kiểm thử đột biến, được cải tiến chương  Chương – Giới thiệu một số phương pháp cải tiến kỹ thuật kiểm thử đột biến nhằm giảm chi phí tính toán và tăng tự động hóa  Chương – Tập trung vào ứng dụng kỹ thuật kiểm thử đột biến Phần đầu giới thiệu hai công cụ mã nguồn mở miễn phí là NUnit dùng để kiểm thử đơn vị của chương trình C#, và Nester với chức phân tích và tạo đột biến Tiếp đó là ứng dụng kỹ thuật kiểm thử đột biến để kiểm thử các chương trì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 là quá trình thực thi một hệ thống phần mềm để xác định xem phần mềm có đúng với đặc tả không và thực hiện môi trường mong đợi hay không Mục đích của kiểm thử phần mềm là tìm lỗi chưa được phát hiện, tìm một cách sớm và bảo đảm lỗi được sửa Mục tiêu của kiểm thử phần mềm là thiết kế tài liệu kiểm thử một cách có hệ thống và thực hiện nó cho có hiệu quả, tiết kiệm được thời gian, công sức và chi phí 1.2 Các cấp độ kiểm thử phần mềm Cấp độ kiểm thử phần mềm được thể hiện hình 1.1 [25]: Kiểm Kiểm thử thử mức mức đơn đơn vị vị lập lập trình trình (Unit (Unit test) test) Các Các bộ bộ phận phận đơn đơn lẻ lẻ Kiểm Kiểm thử thử mức mức tích tích hợp hợp các các đơn đơn vị vị (Integration (Integration test) test) Các Các nhóm nhóm bộ bộ phận phận Kiểm Kiểm thử thử mức mức hệ hệ thống, sau thống, sau tích tích hợp hợp (System (System test) test) Kiểm Kiểm thử thử để để chấp chấp nhận nhận sản sản phẩm phẩm (Acceptance (Acceptance test) test) Toàn Toàn bộ bộ hệ hệ thống thống Toàn Toàn bộ bộ hệ hệ thống thống nhìn từ khách nhìn từ khách hàng hà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 vị (Unit) là một thành phần phần mềm nhỏ mà ta có thể kiểm thử được, ví dụ: các hàm (Function), thủ tục (Procedure), lớp (Class), các phương thức (Method) Kiểm thử đơn vị thường lập trình viên thực hiện Công đoạn này cần được thực hiện càng sớm càng tốt giai đoạn viết code và xuyên suốt chu kỳ phát triển phần mềm Mục đích của kiểm thử đơn vị là bảo đảm thông tin được xử lý và kết xuất (khỏi Unit) là chính xác, mối tương quan với dữ liệu nhập và chức xử lý của Unit Điều này thường đòi hỏi tất cả các nhánh bên Unit đều phải được kiểm tra để phát hiện nhánh phát sinh lỗi Cũng các mức kiểm thử khác, kiểm thử đơn vị đòi hỏi phải chuẩn bị trước các ca kiểm thử (hay trường hợp kiểm thử) (test case) kịch bản (test script), đó chỉ định rõ dữ liệu vào, các bước thực hiện và dữ liệu mong muốn xuất Các test case và test script được giữ lại để sử dụng sau này 1.2.2 Kiểm thử tích hợp (Integration Test) Kiểm thử tích hợp kết hợp các thành phần của một ứng dụng và kiểm thử một ứng dụng đã hoàn thành Trong kiểm thử đơn vị kiểm tra các thành phần và Unit riêng lẻ thì kiểm thử tích hợp kết hợp chúng lại với và kiểm tra sự giao tiếp giữa chúng Kiểm thử tích hợp có hai mục tiêu chính là: − Phát hiện lỗi giao tiếp xảy giữa các Unit − Tích hợp các Unit đơn lẻ thành các hệ thống (gọi là subsystem) và cuối là nguyên hệ thống hoàn chỉnh chuẩn bị cho kiểm thử mức hệ thống (system test) Có loại kiểm thử kiểm thử tích hợp sau: − Kiểm thử cấu trúc (Structure test): Kiểm thử nhằm bảo đảm các thành phần bên của một chương trình chạy đúng, chú trọng đến hoạt động của các thành phần cấu trúc nội tại của chương trình, chẳng hạn các lệnh và nhánh bên − Kiểm thử chức (Functional test): Kiểm thử chỉ chú trọng đến chức của chương trình, không quan tâm đến cấu trúc bên trong, chỉ khảo sát chức của chương trình theo yêu cầu kỹ thuật − Kiểm thử hiệu (Performance test): Kiểm thử việc vận hành của hệ thống − Kiểm thử khả chịu tải (Stress test): Kiểm thử các giới hạn của hệ thống 1.2.3 Kiểm thử hệ thống (System Test) Mục đích của kiểm thử hệ thống là kiểm thử xem thiết kế và toàn bộ hệ thống (sau tích hợp) có thỏa mãn yêu cầu đặt hay không Kiểm thử hệ thống kiểm tra cả các hành vi chức của phần mềm lẫn các yêu cầu về chất lượng độ tin cậy, tính tiện lợi sử dụng, hiệu và bảo mật Kiểm thử hệ thống bắt đầu tất cả các bộ phận của phần mềm đã được tích hợp thành công Thông thường loại kiểm thử này tốn nhiều công sức và thời gian Trong nhiều trường hợp, việc kiểm thử đòi hỏi một số thiết bị phụ trợ, phần mềm phần cứng đặc thù, đặc biệt là các ứng dụng thời gian thực, hệ thống phân bố, hệ thống nhúng Ở mức độ hệ thống, người kiểm thử tìm kiếm các lỗi, trọng tâm là đánh giá về hoạt động, thao tác, sự tin cậy và các yêu cầu khác liên quan đến chất lượng của toàn hệ thống Điểm khác then chốt giữa kiểm thử tích hợp và kiểm thử hệ thống là kiểm thử hệ thống chú trọng các hành vi và lỗi toàn hệ thống, còn kiểm thử tích hợp chú trọng sự giao tiếp giữa các đơn thể đối tượng chúng làm việc Thông thường ta phải thực hiện kiểm thử đơn vị và kiểm thử tích hợp để bảo đảm mọi Unit và sự tương tác giữa chúng hoạt động chính xác trước thực hiện kiểm thử hệ thống Sau hoàn thành kiểm thử tích hợp, một hệ thống phần mềm đã được hình thành với các thành phần đã được kiểm tra đầy đủ Tại thời điểm này, lập trình viên kiểm thử viên (Tester) bắt đầu kiểm thử phần mềm một hệ thống hoàn chỉnh Việc lập kế hoạch cho kiểm thử hệ thống nên bắt đầu từ giai đoạn hình thành và phân tích các yêu cầu Đòi hỏi nhiều công sức, thời gian và tính chính xác, khách quan, kiểm thử hệ thống được thực hiện một nhóm kiểm tra viên hoàn toàn độc lập với nhóm phát triển dự án để đảm bảo tính chính xác và khách quan Kiểm thử hệ thống thường có các loại kiểm thử sau: −Kiểm thử chức (Functional test): Bảo đảm các hành vi của hệ thống thỏa mãn đúng yêu cầu thiết kế −Kiểm thử khả vận hành (Performance test): Bảo đảm tối ưu việc phân bổ tài nguyên hệ thống (ví dụ bộ nhớ) nhằm đạt các chỉ tiêu thời gian xử lý hay đáp ứng câu truy vấn, −Kiểm thử khả chịu tải (Stress test hay Load test): Bảo đảm hệ thống vận hành đúng dưới áp lực cao (ví dụ nhiều người truy xuất lúc) Stress test tập trung vào các trạng thái tới hạn, các "điểm chết", các tình huống bất thường giao dịch thì ngắt kết nối (xuất hiện nhiều test thiết bị POS, ATM), −Kiểm thử cấu hình (Configuration test): Đảm bảo hệ thống hoạt động tương thích với các loại phần cứng khác −Kiểm thử khả bảo mật (Security test): Bảo đảm tính toàn vẹn, bảo mật của dữ liệu và của hệ thống −Kiểm thử khả phục hồi (Recovery test): Bảo đảm hệ thống có khả khôi phục trạng thái ổn định trước đó tình huống tài 10 PHỤ LỤC Code Money.cs namespace NUnit.Samples.Money { using System; using System.Text; /// A simple Money. class Money: IMoney { private int fAmount; private String fCurrency; /// Constructs a money from the given amount and /// currency. public Money(int amount, String currency) { fAmount= amount; fCurrency= currency; } /// Adds a money to this money Forwards the request to /// the AddMoney helper. public IMoney Add(IMoney m) { return m.AddMoney(this); } public IMoney AddMoney(Money m) { if (m.Currency.Equals(Currency) ) return new Money(Amount+m.Amount, Currency); return new MoneyBag(this, m); } public IMoney AddMoneyBag(MoneyBag s) { return s.AddMoney(this); } public int Amount { get { return fAmount; } } public String Currency { get { return fCurrency; } } public override bool Equals(Object anObject) { if (IsZero) if (anObject is IMoney) 80 return ((IMoney)anObject).IsZero; if (anObject is Money) { Money aMoney= (Money)anObject; return aMoney.Currency.Equals(Currency) && Amount == aMoney.Amount; } return false; } public override int GetHashCode() { return fCurrency.GetHashCode()+fAmount; } public bool IsZero { get { return Amount == 0; } } public IMoney Multiply(int factor) { return new Money(Amount*factor, Currency); } public IMoney Negate() { return new Money(-Amount, Currency); } public IMoney Subtract(IMoney m) { return Add(m.Negate()); } public override String ToString() { StringBuilder buffer = new StringBuilder(); buffer.Append("["+Amount+" "+Currency+"]"); return buffer.ToString(); } } } 81 PHỤ LỤC Code Moneytest.cs namespace NUnit.Samples.Money.Port { using System; using NUnit.Framework; public class MoneyTest: TestCase { private Money f12CHF; private Money f14CHF; private Money f7USD; private Money f21USD; private MoneyBag fMB1; private MoneyBag fMB2; protected override void SetUp() { f12CHF= new Money(12, "CHF"); f14CHF= new Money(14, "CHF"); f7USD= new Money( 7, "USD"); f21USD= new Money(21, "USD"); fMB1= new MoneyBag(f12CHF, f7USD); fMB2= new MoneyBag(f14CHF, f21USD); } public void TestBagMultiply() { // {[12 CHF][7 USD]} *2 == {[24 CHF][14 USD]} Money[] bag = { new Money(24, "CHF"), new Money(14, "USD") }; MoneyBag expected= new MoneyBag(bag); Assertion.AssertEquals(expected, fMB1.Multiply(2)); Assertion.AssertEquals(fMB1, fMB1.Multiply(1)); Assertion.Assert(fMB1.Multiply(0).IsZero); } public void TestBagNegate() { // {[12 CHF][7 USD]} negate == {[-12 CHF][-7 USD]} 82 Money[] bag= { new Money(-12, "CHF"), new Money(7, "USD") }; MoneyBag expected= new MoneyBag(bag); Assertion.AssertEquals(expected, fMB1.Negate()); } public void TestBagSimpleAdd() { // {[12 CHF][7 USD]} + [14 CHF] == {[26 CHF][7 USD]} Money[] bag= { new Money(26, "CHF"), new Money(7, "USD") }; MoneyBag expected= new MoneyBag(bag); Assertion.AssertEquals(expected, fMB1.Add(f14CHF)); } public void TestBagSubtract() { // {[12 CHF][7 USD]} - {[14 CHF][21 USD] == {[-2 CHF][-14 USD]} Money[] bag= { new Money(-2, "CHF"), new Money(14, "USD") }; MoneyBag expected= new MoneyBag(bag); Assertion.AssertEquals(expected, fMB1.Subtract(fMB2)); } public void TestBagSumAdd() { // {[12 CHF][7 USD]} + {[14 CHF][21 USD]} == {[26 CHF][28 USD]} Money[] bag= { new Money(26, "CHF"), new Money(28, "USD") }; MoneyBag expected= new MoneyBag(bag); Assertion.AssertEquals(expected, fMB1.Add(fMB2)); } public void TestIsZero() { Assertion.Assert(fMB1.Subtract(fMB1).IsZero); Money[] bag = { new Money(0, "CHF"), new Money(0, "USD") }; 83 Assertion.Assert(new MoneyBag(bag).IsZero); } public void TestMixedSimpleAdd() { // [12 CHF] + [7 USD] == {[12 CHF][7 USD]} Money[] bag= { f12CHF, f7USD }; MoneyBag expected= new MoneyBag(bag); Assertion.AssertEquals(expected, f12CHF.Add(f7USD)); } public void TestMoneyBagEquals() { Assertion.Assert(!fMB1.Equals(null)); Assertion.AssertEquals(fMB1, fMB1); MoneyBag equal= new MoneyBag(new Money(12, "CHF"), new Money(7, "USD")); Assertion.Assert(fMB1.Equals(equal)); Assertion.Assert(!fMB1.Equals(f12CHF)); Assertion.Assert(!f12CHF.Equals(fMB1)); Assertion.Assert(!fMB1.Equals(fMB2)); } public void TestMoneyBagHash() { MoneyBag equal= new MoneyBag(new Money(12, "CHF"), new Money(7, "USD")); Assertion.AssertEquals(fMB1.GetHashCode(), equal.GetHashCode()); } public void TestMoneyEquals() { Assertion.Assert(!f12CHF.Equals(null)); Money equalMoney= new Money(12, "CHF"); Assertion.AssertEquals(f12CHF, f12CHF); Assertion.AssertEquals(f12CHF, equalMoney); Assertion.AssertEquals(f12CHF.GetHashCode(), equalMoney.GetHashCode()); Assertion.Assert(!f12CHF.Equals(f14CHF)); } public void TestMoneyHash() 84 { Assertion.Assert(!f12CHF.Equals(null)); Money equal= new Money(12, "CHF"); Assertion.AssertEquals(f12CHF.GetHashCode(), equal.GetHashCode()); } public void TestNormalize() { Money[] bag= { new Money(26, "CHF"), new Money(28, "CHF"), new Money(6, "CHF") }; MoneyBag moneyBag= new MoneyBag(bag); Money[] expected = { new Money(60, "CHF") }; // note: expected is still a MoneyBag MoneyBag expectedBag= new MoneyBag(expected); Assertion.AssertEquals(expectedBag, moneyBag); } public void TestNormalize2() { // {[12 CHF][7 USD]} - [12 CHF] == [7 USD] Money expected= new Money(7, "USD"); Assertion.AssertEquals(expected, fMB1.Subtract(f12CHF)); } public void TestNormalize3() { // {[12 CHF][7 USD]} - {[12 CHF][3 USD]} == [4 USD] Money[] s1 = { new Money(12, "CHF"), new Money(3, "USD") }; MoneyBag ms1= new MoneyBag(s1); Money expected= new Money(4, "USD"); Assertion.AssertEquals(expected, fMB1.Subtract(ms1)); } public void TestNormalize4() { // [12 CHF] - {[12 CHF][3 USD]} == [-3 USD] Money[] s1 = { new Money(12, "CHF"), new Money(3, "USD") }; MoneyBag ms1= new MoneyBag(s1); 85 Money expected= new Money(-3, "USD"); Assertion.AssertEquals(expected, f12CHF.Subtract(ms1)); } public void TestPrint() { Assertion.AssertEquals("[12 CHF]", f12CHF.ToString()); } public void TestSimpleAdd() { // [12 CHF] + [14 CHF] == [26 CHF] Money expected= new Money(26, "CHF"); Assertion.AssertEquals(expected, f12CHF.Add(f14CHF)); } public void TestSimpleBagAdd() { // [14 CHF] + {[12 CHF][7 USD]} == {[26 CHF][7 USD]} Money[] bag= { new Money(26, "CHF"), new Money(7, "USD") }; MoneyBag expected= new MoneyBag(bag); Assertion.AssertEquals(expected, f14CHF.Add(fMB1)); } public void TestSimpleMultiply() { // [14 CHF] *2 == [28 CHF] Money expected= new Money(28, "CHF"); Assertion.AssertEquals(expected, f14CHF.Multiply(2)); } public void TestSimpleNegate() { // [14 CHF] negate == [-14 CHF] Money expected= new Money(-14, "CHF"); Assertion.AssertEquals(expected, f14CHF.Negate()); } public void TestSimpleSubtract() 86 { // [14 CHF] - [12 CHF] == [2 CHF] Money expected= new Money(2, "CHF"); Assertion.AssertEquals(expected, f14CHF.Subtract(f12CHF)); } } } 87 PHỤ LỤC Code MoneyBag.cs namespace NUnit.Samples.Money { using System; using System.Collections; using System.Text; /// A MoneyBag defers exchange rate conversions. /// For example adding /// 12 Swiss Francs to 14 US Dollars is represented as a bag /// containing the two Monies 12 CHF and 14 USD Adding another /// 10 Swiss francs gives a bag with 22 CHF and 14 USD Due to /// the deferred exchange rate conversion we can later value a /// MoneyBag with different exchange rates /// A MoneyBag is represented as a list of Monies and provides /// different constructors to create a MoneyBag. class MoneyBag: IMoney { private ArrayList fMonies= new ArrayList(5); private MoneyBag() { } public MoneyBag(Money[] bag) { for (int i= 0; i < bag.Length; i++) { if (!bag[i].IsZero) AppendMoney(bag[i]); } } public MoneyBag(Money m1, Money m2) { AppendMoney(m1); AppendMoney(m2); } public MoneyBag(Money m, MoneyBag bag) { AppendMoney(m); AppendBag(bag); } public MoneyBag(MoneyBag m1, MoneyBag m2) { AppendBag(m1); AppendBag(m2); } 88 public IMoney Add(IMoney m) { return m.AddMoneyBag(this); } public IMoney AddMoney(Money m) { return (new MoneyBag(m, this)).Simplify(); } public IMoney AddMoneyBag(MoneyBag s) { return (new MoneyBag(s, this)).Simplify(); } private void AppendBag(MoneyBag aBag) { foreach (Money m in aBag.fMonies) AppendMoney(m); } private void AppendMoney(Money aMoney) { IMoney old= FindMoney(aMoney.Currency); if (old == null) { fMonies.Add(aMoney); return; } fMonies.Remove(old); IMoney sum= old.Add(aMoney); if (sum.IsZero) return; fMonies.Add(sum); } private bool Contains(Money aMoney) { Money m= FindMoney(aMoney.Currency); return m.Amount == aMoney.Amount; } public override bool Equals(Object anObject) { if (IsZero) if (anObject is IMoney) return ((IMoney)anObject).IsZero; if (anObject is MoneyBag) { MoneyBag aMoneyBag= (MoneyBag)anObject; if (aMoneyBag.fMonies.Count != fMonies.Count) return false; foreach (Money m in fMonies) { if (!aMoneyBag.Contains(m)) return false; 89 } return true; } return false; } private Money FindMoney(String currency) { foreach (Money m in fMonies) { if (m.Currency.Equals(currency)) return m; } return null; } public override int GetHashCode() { int hash= 0; foreach (Money m in fMonies) { hash^= m.GetHashCode(); } return hash; } public bool IsZero { get { return fMonies.Count == 0; } } public IMoney Multiply(int factor) { MoneyBag result= new MoneyBag(); if (factor != 0) { foreach (Money m in fMonies) { result.AppendMoney((Money)m.Multiply(factor)); } } return result; } public IMoney Negate() { MoneyBag result= new MoneyBag(); foreach (Money m in fMonies) { result.AppendMoney((Money)m.Negate()); } return result; } private IMoney Simplify() { 90 if (fMonies.Count == 1) return (IMoney)fMonies[0]; return this; } public IMoney Subtract(IMoney m) { return Add(m.Negate()); } public override String ToString() { StringBuilder buffer = new StringBuilder(); buffer.Append("{"); foreach (Money m in fMonies) buffer.Append(m); buffer.Append("}"); return buffer.ToString(); } } } 91 PHỤ LỤC Code Imoney.cs namespace NUnit.Samples.Money { /// The common interface for simple Monies and MoneyBags. interface IMoney { /// Adds a money to this money. IMoney Add(IMoney m); /// Adds a simple Money to this money This is a helper method for /// implementing double dispatch. IMoney AddMoney(Money m); /// Adds a MoneyBag to this money This is a helper method for /// implementing double dispatch. IMoney AddMoneyBag(MoneyBag s); /// True if this money is zero. bool IsZero { get; } /// Multiplies a money by the given factor. IMoney Multiply(int factor); /// Negates this money. IMoney Negate(); /// Subtracts a money from this money. IMoney Subtract(IMoney m); } } 92 PHỤ LỤC Code Assemblyinfo.cs using System.Reflection; using System.Runtime.CompilerServices; // // General Information about attributes Change an assembly is controlled through the modify the following // set of these attribute values to information // associated with an assembly // [assembly: AssemblyTitle("")] [assembly: AssemblyDescription("")] [assembly: AssemblyConfiguration("")] [assembly: AssemblyCompany("")] [assembly: AssemblyProduct("")] [assembly: AssemblyCopyright("")] [assembly: AssemblyTrademark("")] [assembly: AssemblyCulture("")] // // Version information for an assembly consists of the following four values: // // Major Version // Minor Version // Build Number // Revision // // You can specify all the values or you can default the Revision and Build Numbers // by using the '*' as shown below: [assembly: AssemblyVersion("2.2.0.0")] // // In order to sign your assembly you must specify a key to use Refer to the // Microsoft NET Framework documentation assembly signing // 93 for more information on // Use the attributes below to control which key is used for signing // // Notes: // // (*) If no key is specified, the assembly is not signed (*) KeyName refers to a key that has been installed in the Crypto Service // Provider (CSP) on your machine KeyFile refers to a file which contains // // a key (*) If the KeyFile and the KeyName values are both specified, the // following processing occurs: // (1) If the KeyName can be found in the CSP, that key is used // (2) If the KeyName does not exist and the KeyFile does exist, the key // // in the KeyFile is installed into the CSP and used (*) In order to create a KeyFile, you can use the sn.exe (Strong Name) utility // When specifying the KeyFile, the location of the KeyFile should be // relative to the project output directory which is // %Project Directory%\obj\ For example, if your KeyFile is // located in the project directory, you would specify the AssemblyKeyFile // attribute as [assembly: AssemblyKeyFile(" \\ \\mykey.snk")] // (*) Delay Signing is an advanced option - see the Microsoft NET Framework // documentation for more information on this // [assembly: AssemblyDelaySign(false)] [assembly: AssemblyKeyFile("")] [assembly: AssemblyKeyName("")] 94 [...]... sau: −Ca c ch c năng thiếu ho c không đúng −Ca c lỗi giao diện −Ca c lỗi c u tru c dữ liệu trong truy c ̣p c sở dữ liệu bên ngoài −Ca c lỗi thư c hiện −Ca c lỗi khởi tạo ho c kết thu c −Và ca c lỗi kha c Không giống với kiểm thử hộp trắng đươ c thư c hiện sớm trong quá trình kiểm thử, kiểm thử hộp đen đươ c áp dụng trong ca c giai đoạn sau của kiểm thử Vì kiểm thử hộp... ho c cho mã nguồn bao gồm ca c bươ c sau: −Bư c 1: Sử dụng mã nguồn ho c thiết kế để xây dựng đồ thị luồng điều khiển tương ứng −Bư c 2: Tính toán độ ph c tạp chu trình V(G) −Bư c 3: Xa c định tập c sở của ca c đường dẫn đô c lập (một đường dẫn đư c gọi là đ c lập với c c đường dẫn kh c nếu nó c ít nhất một c nh không xuất hiện trong c c đường dẫn kh c) −Bư c 4: Chuẩn bị ca c. ..nguyên ho c dữ liệu; đ c biệt quan trọng đối với ca c hệ thống giao dịch như ngân hàng trư c tuyến 1.2.4 Kiểm thử chấp nhận sản phẩm (Acceptance Test) M c đích của kiểm thử chấp nhận là kiểm thử khả năng chấp nhận cuối c ng để chă c chắn rằng sản phẩm là phù hợp và thỏa mãn ca c yêu c ̀u của khách hàng và khách hàng chấp nhận sản phẩm Trong giai đoạn kiểm thử chấp nhận... hợp ca c vòng lặp lồng nhau − Ca c bươ c cần kiểm tra cho vòng lặp phi c u tru c Nếu gặp ca c lớp vòng lặp này chúng ta sẽ không kiểm thử, mà sẽ thiết kế lại tương ứng với sử dụng viê c xây dựng chương trình có c u tru c 23 1.4 Kết luận Trong chương 1 đã nêu tổng quan về ca c cấp độ và loại kiểm thử phần mềm c bản Kiểm thử hộp trắng xem xét chương trình ở m c độ chi... đươ c kiểm tra không phải là chỉ báo rõ ràng về tỷ lệ đột biến (ngoại trừ kiểm tra tất cả ca c đột biến), nhưng thay vào đó, dấu hiệu là ca c dữ liệu thử có khả năng xa c định đột biến nhiều hơn những dấu hiệu kha c Trong trường hợp này, vi c 35 lựa chọn c c đột biến cho kiểm thử c ảnh hưởng đến c c dữ liệu thử đư c tạo ra và tỷ lệ đột biến không? Ca c đột biến có... biến tương đương Hình 2.3 – Quy trình kiểm thử đột biến 31 Chạy test cases trên từng đột biến còn sống ( Lưu ý: Trong hình trên c c bư c biểu diễn trong hộp liền nét đư c th c hiện tự động C n c c bư c biểu diễn trong hộp nét đứt đư c th c hiện bằng tay) 2.5 Hạn chế c a kiểm thử đột biến M c dù đươ c xem là một kỹ thuật kiểm thử đơn vị mạnh, tuy nhiên kiểm thử đột biến gặp phải một số... C, C+ +, C_ Sharp,… Nghiên c u này tập trung kiểm thử ca c chương trình đơn giản, hầu hết ca c toán tử đột biến truyền thống vẫn còn hiệu quả 2.4 Quy trình kiểm thử đột biến Kiểm thử đột biến là một quy trình đươ c lặp đi lặp lại để cải tiến dữ liệu thử đối với một chương trình và đươ c chia thành ca c bươ c cơ bản [13] sau: Bư c 1: Sản sinh đột biến (dùng c ng c ... ngữ cảnh của phương pháp đường dẫn c sở, giá trị đươ c xa c định cho độ ph c tạp chu trình cho biết số lượng đường dẫn đô c lập trong một tập c sở của chương trình và cung c p cho chúng ta một giới hạn trên số lượng kiểm thử bắt buô c để đảm bảo rằng tất cả ca c câu lệnh đươ c thư c hiện ít nhất một lần 17 Viê c tính toán độ ph c tạp chu trình sẽ cho chúng... thử mỗi biên của một lớp tương đương về tất cả ca c phía Một chương trình nếu vượt qua những trường hợp kiểm thử đó có thể vượt qua ca c kiểm thử kha c từ lớp đó 1.3.2 Kỹ thuật kiểm thử hộp trắng (White – box Testing) Kiểm thử hộp trắng hay còn gọi là kiểm thử hướng logic, cho phép kiểm tra c u tru c bên trong của phần mềm với m c đích bảo đảm rằng tất cả ca c câu... hơn cho ca c hệ thống phần mềm lớn hay ca c thành phần quan trọng của chúng Nhưng chỉ sử dụng kiểm thử hộp đen là chưa đủ Bởi vì, kiểm thử ch c năng chỉ dựa trên đ c tả của môđun nên không thể kiểm thử đươ c ca c trường hợp không đươ c khai báo trong đ c tả Ngoài ra, do không phân tích mã nguồn nên không thể biết đươ c môđun nào của chương trình đã hay chưa đươ c kiểm

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

Thông tin tài liệu

Từ khóa liên quan

Mục lục

LỜI CẢM ƠN

MỤC LỤC

Chương 1 i) dANH MỤC CÁC TỪ VIẾT TẮT, THUẬT NGỮ

II) dANH MỤC CÁC BẢNG BIỂU

iiI) DANH MỤC CÁC HÌNH VẼ

LỜI MỞ ĐẦU

CHƯƠNG 1 – 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)

1.2.4. Kiểm thử chấp nhận sản phẩm (Acceptance Test)

1.3. Kỹ thuật kiểm thử phần mềm

1.3.1. Kỹ thuật kiểm thử hộp đen (Black – box Testing)

1.3.1.1. Phân hoạch tương đương

1.3.1.2. Phân tích giá trị biên

1.3.2. Kỹ thuật kiểm thử hộp trắng (White – box Testing)

1.3.2.1. Kiểm thử đường dẫn cơ sở

1.3.2.2. Kiểm thử cấu trúc điều khiển

1.4. Kết luận

CHƯƠNG 2 – KỸ THUẬT KIỂM THỬ ĐỘT BIẾN

2.1. Một số khái niệm

2.1.1. Kiểm thử đột biến

2.1.2. Đột biến

2.1.3. Toán tử đột biến

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

Tài liệu liên quan