Đồ án Nghiên cứu lý thuyết kiểm thử và kiểm thử đơn vị với nunit 2.5

ộ nhớ 4 Design issue Thiết kế được chỉ rõ liên quan vấn đề 5 Coding standard Vấn đề với chuẩn viết mã nguồn 6 Document Lỗi phát hiện trong khi xem lại văn bản: Kế hoạch dự án, SRS, Kế hoạch kiểm thử,… liên quan tới chuẩn văn bản (mẫu, phiên bản, header/footer,...) 7 Data and Database Integrity Vấn đề với xử lý dữ liệu hay luồng dữ liệu: vào/ra 8 Security and Access Control Vấn đề với đặc quyền người dùng, vấn đề bảo mật 9 Portability Mã nguồn không độc lập với platform 10 Other không như những dạng trên 11 Tools Lỗi gây ra bởi sử dụng công cụ Bảng 1.1 Dạng chung của lỗi Ngoài ra, trong quá trình kiểm thử còn xuất hiện một số lỗi nguy hại như: # Dạng nguy hại Giải thích 1 Fatal Lỗi không cho người sử dụng tiếp tục sử dụng hệ thống, có lẽ hệ thống bị tấn công 2 Serious Hệ thống không thể làm việc tốt 3 Medium Lỗi này không ngăn người sử dụng xử lý, nhưng gây ra sự bất tiện 4 Cosmetic Một lỗi mà không có cách nào ảnh hưởng đến hiệu năng của sản phẩm. Nó có lẽ là một lỗi ngữ pháp. Bảng 1.2 Dạng lỗi nguy hại 1.3.3. Trạng thái của lỗi Một lỗi có một số trạng thái sau đây trong vòng đời của nó: # Trạng thái Mô tả 1 ERROR Lỗi không được sửa hay sửa nhưng không được hài lòng như mong muốn 2 ASSIGNED Lỗi được xem lại và được giao sửa nó 3 PENDING Lỗi được sửa xong và được kiểm thử lại 4 TESTED Lỗi được sửa một cách hài lòng như mong muốn 5 ACCEPTED Lỗi không được sửa một cách hài lòng như mong muốn, nhưng nó được chấp nhận bởi sự nhượng bộ của tác giả hay khách hàng. 6 CANCELLED Nó không là một lỗi hay lỗi được loại bỏ bởi những hành động khác với sửa lỗi Bảng 1.3 Trạng thái của lỗi 1.4.KIỂM THỬ ĐƠN VỊ Kiểm thử đơn vị ứng dụng ở mức môđun. Thường là được thực hiện bới nhà phát triển trước khi các môđun được tích hợp với các mô đun khác . Kiểm thử đơn vị là mức thấp nhất trong tiến trình kiểm thử, thường là áp dụng phương pháp kiểm thử hộp trắng . Kết quả của kiểm thử Unit thường tìm ra khoảng 20% lỗi trong tất cả cá lỗi của dự án. 1.4.1. Tiến trình kiểm thử 1.4.1.1. Kế hoạch kiểm thử Lập kế hoạch cho kiểm thử khác nhau (như kiểm thử hệ thống, kiểm thử tích hợp). Quyết định xem dặc điểm nào cần phải kiểm thử. Các hướng tiếp cận để kiểm thử unit § Phương thức phân tích kiểm thử. § Kĩ thuật kiểm thử (hộp đen hay hộp trắng). § Các công cụ dùng trong kiểm thử. 1.4.1.2. Thiết kế kiểm thử Tạo các trường hợp kiểm thử Thiết kế các thủ tục kiểm thử: §Thủ tục làm thế nào để thực thi một trường hợp kiểm thử § Một thủ tục có thể áp dụng cho một vài trường hợp kiểm thử khác Triển khai chương trình kiểm thử: § Kiểm thử gốc(stub): Kiểm thử lần lượt từ gốc của chương trình, sau khi xong thì tiếp tục kiểm thử Stub tiếp theo ở bên dưới. § Kiểm thử driver : Driver là một trình điều khiển kiểm thử unit . 1.4.1.3. Thực hiện và đánh giá kiểm thử UNit § Chuẩn bị kiểm thử môi trường. § Thực hiện kiểm thử unit. § Phát hiện ra lỗi trong kiểm thử unit. § Làm báo cáo ghi lại toàn bộ sự thành công hay thất bại trong từng unit một dựa theo các kết quả yêu cầu. 1.4.2. Kế hoạch kiểm thử Unit Để thực hiện một kiểm thử có hiệu quả, thì cần thiết phải có một kế hoạch kiểm thử có hiệu quả. Cần phải lập kế hoạch thật chi tiết, càng chi tiết càng tốt. Kế hoạch kiểm thử unit cần phải đưa ra các tài liệu chỉ dẫn việc thực hiện kiểm thử trên từng môđun như thế nào. Mục tiêu là mỗi mô đun sau khi dược kiểm thử thì phải thoả mãn tất các yêu cầu đặt ra về chức năng Kế hoạch kiểm thử cần phải đưa ra một danh sách các đầu vào cho môđun và một danh sách các đầu ra phù hợp với các mô đun đó. Mộ môđun dược gọi là đạt nếu tất cả các đầu vào đều có đầu ra tương ứng. Mỗi một sự sai trệch nào của đầu ra đều phải cần xem xét cụ thể. Danh sách các đầu vào phải thoả mãn yêu cầu của phần mềm, tối thiểu là lần đầu tiên. Kế hoạch kiểm thử giúp cho các nhà phát triển có thể đảm bảo chắc chắn rằng mỗi dòng mà, và mỗi câu lệnh điều kiện đều phải thực hiện được tối thiểu một lần 1.4.3. Kỹ thuật kiểm thử hộp đen ( Black box ) Là phương pháp tập trung vào yêu cầu về mặt chức năng của phần mềm. Có thể tạo ra một bộ các điều kiện các input để kiểm thử tất cả các chức năng của một chương trình. Kiểm thử hộp đen về bản chất không phải là một phương pháp trái ngược với kiểm thử hộp trắng. Đúng hơn đây là phương pháp bổ sung cho phương pháp kiểm thử hộp trắng để phát hiện tất cả các loại lỗi khác nhau nhiều hơn là phương pháp kiểm thử hộp trắng đã biết. Kiểm thử hộp đen cố gắng phát hiện các loại lỗi như sau: § Không đúng hay mất môt số hàm/module § Giao diện không phù hợp/ lỗi về interface. § Lỗi về cấu trúc dữ liệu hay thao tác lên data bên ngoài. § Lỗi thực thi. § Lỗi về khởi động và hủy dữ liệu, biến. Không giống như phương pháp kiểm thử hộp trắng có thể được thực hiện ở những giai đoạn đầu của quá trình kiểm thử phần mềm, phương pháp này tập trung vào phần sau của quá trình kiểm thử. Mục đích của quá trình kiểm thử là tập trung trên vùng thông tin chứ không phải trên vùng mã chương trình. Các trường hợp kiểm thử để trả lời các câu hỏi sau: § Như thế nào là hàm/chức năng hợp lệ? § Lớp gì của thông tin đầu vào sẽ tạo ra những trường hợp kiểm thử tốt ? § Hệ thống có khả năng bị thương tổn vói một giá trị nhập vào nào đó không? § Ranh giới của các vùng dữ liệu có đôc lập với nhau hay không ? § Tỷ lệ và kích thước dữ liệu mà hệ thống có thể hứng chịu là bao nhiêu? 1.4.4. Kỹ thuật kiểm thử hộp trắng ( White Box) Trong kiểm thử hộp trắng, các trường hợp kiểm thử được thiết kế để xem xét trên cấu trúc nội bộ của module và cấu trúc logic và cấu trúc điều khiển. Các trường hợp kiểm thử sẽ duyệt qua tất cả các lệnh trong chương trình.Tuy nhiên điều này cũng gặp các khó khăn như trình bày ở trên bởi số lượng công việc phải làm. Vậy tại sao ta không tập trung vào chỉ thiết kế các trường hợp kiểm thử dựa trên kỹ thuật kiểm thử hộp đen. Câu trả lời nằm trong những yếu điểm tự nhiên của phần mềm: § Những lỗi về lý luận và những giả sử không chính xác có xác xuất xảy ra tương đương với những trường hợp đúng. Những lỗi có khuynh hướng xuất hiện khi chúng ta thiết kế và cài đặt chương trình, các biểu thức điều kiện, hoặc các biểu thức điều khiển, và các lỗi thường có khuynh hướng xuất hiện ở các trường hợp đặc biệt. § Chúng ta thường tin rằng một đường diễn tiến nào đó sẽ không được thực thi. Tuy nhiên thực tế thì nó có thể được thực thi. Luồng diễn tiến của chương trình đôi khi chỉ là mang tính trực giác, có thể hiểu là một giả định tưởng tượng của người lập trình về luồng điều khiển và dữ liệu đã làm cho chúng ta tạo ra lỗi. Lỗi loại này có thể được phát hiện bằng một trường hợp kiểm thử trên một đường diễn tiến. § Những lỗi về cài đặt sai do lỗi gõ phím là ngẫu nhiên và có thể xuất hiện tại bất kỳ đâu trong chương trình. Khi một chương trình được chuyển đổi từ ý tưởng thiết kế sang thành mã chương trình một số lỗi do đánh sai hiểu sai xuất hiện. Phần lớn có thể được phát hiện bởi những hệ thống kiểm tra cú pháp của ngôn ngữ, nhưng một số khác sẽ không được phát hiện cho đến khi chạy kiểm thử. Mỗi một lý do giải thích tại sao phải tạo ra các trường hợp kiểm thử dựa trên kỹ thuật hộp trắng. Hộp đen cũng được nhưng có thể một số loại lỗi ở trên sẽ không được phát hiện bởi các trường hợp sử dụng phương pháp này. 1.4.5. Các trường hợp kiểm thử và dữ liệu kiểm thử § Kiểm tra các toán tử ở mức giá trị thông thường. § Kiểm tra với các giá trị giới hạn. § Kiểm tra ngoài vùng giá trị. § Kiểm tra các lỗi ở trong vòng lặp. § Kiểm tra các kết thúc không bình thường trong vòng lặp. § Kiểm tra các kết thúc không bình thường trong đệ quy. § Kiểm tra tất các các cấu trúc dữ liệu được truy nhập bởi hàm. § Kiểm tra tất cả các loại file được truy nhập bởi hàm thành viên. § Kiểm tra tất cả các lỗi điều kiện. § Kiểm tra tính hiệu quả của kiểm thử nếu thấy cần thiết. § Đảm bảo rằng mọi câu lệnh đều được thực hiện. § Đảm bảo rằng mọi câu lệnh điều kiện đều thực hiện ở tất cả các nhánh. 1.4.6. Vòng đời của Unit Testing Unit Testing có 3 trạng thái cơ bản: Ø Fail (trạng thái lỗi) Ø Ignore (tạm ngừng thực hiện) Ø Pass (trạng thái làm việc) Toàn bộ Unit Testing được vận hành trong một hệ thống tách biệt. Có rất nhiều phần mềm hỗ trợ thực thi Unit Testing với giao diện trực quan. Thông thường, trạng thái của Unit Testing được biểu hiện bằng các màu khác nhau: màu xanh (pass), màu vàng (ignore) và màu đỏ (fail). Unit Testing chỉ thực sự đem lại hiệu quả khi: Ø Được vận hành lặp lại nhiều lần Ø Tự động hoàn toàn Ø Độc lập với các Unit Testing khác. 1.4.7. Lợi ích của Unit Testing Thời gian đầu, người ta thường do dự khi phải viết UT thay vì tập trung vào viết mã cho các chức năng nghiệp vụ. Công việc viết UT có thể ngốn nhiều thời gian, tuy nhiên UT đem lại lợi ích to lớn như: § Tạo ra môi trường lý tưởng để kiểm tra bất kỳ đoạn mã nào, có khả năng thăm dò và phát hiện lỗi chính xác, duy trì sự ổn định của toàn bộ phần mềm và giúp tiết kiệm thời gian so với công việc gỡ rối truyền thống. § Phát hiện các thuật toán thực thi không hiệu quả, các thủ tục chạy vượt quá giới hạn thời gian. § Phát hiện các vấn đề về thiết kế, xử lý hệ thống, thậm chí các mô hình thiết kế. § Phát hiện các lỗi nghiêm trọng có thể xảy ra trong những tình huống rất hẹp. § Tạo hàng rào an toàn cho các khối mã: Bất kỳ sự thay đổi nào cũng có thể tác động đến hàng rào này và thông báo những nguy hiểm tiềm tàng. UT là môi trường lý tưởng để tiếp cận các thư viện API bên ngoài một cách tốt nhất. Sẽ rất nguy hiểm nếu chúng ta ứng dụng ngay các thư viện này mà không kiểm tra kỹ lưỡng công dụng của các thủ tục trong thư viện. Dành ra thời gian viết UT kiểm tra từng thủ tục là phương pháp tốt nhất để khẳng định sự hiểu đúng đắn về cách sử dụng thư viện đó. Ngoài ra, UT cũng được sử dụng để phát hiện sự khác biệt giữa phiên bản mới và phiên bản cũ của cùng một thư viện. Trong môi trường làm việc cạnh tranh, UT còn có tác dụng rất lớn đến năng suất làm việc: § Giải phóng chuyên viên QA khỏi các công việc kiểm tra phức tạp. §Tăng sự tự tin khi hoàn thành một công việc. Chúng ta thường có cảm giác không chắc chắn về các đoạn mã của mình như liệu các lỗi có quay lại không, hoạt động của module hiện hành có bị tác động không, hoặc liệu công việc hiệu chỉnh mã có gây hư hỏng đâu đó... § Là công cụ đánh giá năng lực của bạn. Số lượng các tình huống kiểm tra (test case) chuyển trạng thái "pass" sẽ thể hiện tốc độ làm việc, năng suất của bạn. Chiến lược viết mã hiệu quả với UT: §Phân tích các tình huống có thể xảy ra đối với mã. Đừng bỏ qua các tình huống tồi tệ nhất có thể xảy ra, thí dụ dữ liệu nhập làm một kết nối cơ sở dữ liệu thất bại, ứng dụng bị treo vì một phép toán chia cho không, các thủ tục đưa ra lỗi ngoại lệ sai có thể phá hỏng ứng dụng một cách bí ẩn... § Mọi UT phải bắt đầu với trạng thái "fail" và chuyển trạng thái "pass" sau một số thay đổi hợp lý đối với mã chính. § Mỗi khi viết một đoạn mã quan trọng, hãy viết các UT tương ứng cho đến khi bạn không thể nghĩ thêm tình huống nào nữa. § Nhập một số lượng đủ lớn các giá trị đầu vào để phát hiện điểm yếu của mã theo nguyên tắc: Ø Nếu nhập giá trị đầu vào hợp lệ thì kết quả trả về cũng phải hợp lệ Ø Nếu nhập giá trị đầu vào không hợp lệ thì kết quả trả về phải không hợp lệ § Sớm nhận biết các đoạn mã không ổn định và có nguy cơ gây lỗi cao, viết UT tương ứng để khống chế. § Ứng với mỗi đối tượng nghiệp vụ (business object) hoặc đối tượng truy cập dữ liệu (data access object), nên tạo ra một lớp kiểm tra riêng vì những lỗi nghiêm trọng có thể phát sinh từ các đối tượng này. § Để ngăn chặn các lỗi có thể phát sinh trở lại thực thi tự động tất cả UT mỗi khi có một sự thay đổi quan trọng, hãy làm công việc này mỗi ngày. Các UT lỗi cho chúng ta biết thay đổi nào là nguyên nhân gây lỗi. § Để tăng hiệu quả và giảm rủi ro khi viết các UT, cần sử dụng nhiều phương thức kiểm tra khác nhau. Hãy viết càng đơn giản càng tốt. Cuối cùng, viết UT cũng đòi hỏi sự nỗ lực, kinh nghiệm và sự sáng tạo như viết PM. Trước khi kết thúc phần này, chúng tôi có một lời khuyên là viết UT cũng tương tự như viết mã một chương trình, điều bạn cần làm là không ngừng thực hành. Hãy nhớ UT chỉ thực sự mang lại lợi ích nếu chúng ta đặt vấn đề chất lượng phần mềm lên hàng đầu hơn là chỉ nhằm kết thúc công việc đúng thời hạn. CHƯƠNG 2: CÔNG CỤ KIỂM THỬ NUnit 2.1. GIỚI THIỆU: NUnit là một tool mới ,có nhiều version khác nhau,trong đó NUnit version 2.5 mới phát hành vào tháng 2/2008 nên cũng còn mới lạ với nhiều người,đặc biệt phiên bản này hỗ trợ cho bộ .NET frameword của Microsoft. NUnit có hai cách khác nhau để chạy chương trình thử nghiệm +Console runer:NUnit –console.exe là khởi chạy nhanh nhất nhưng không phải là tương tác +NUnit-Gui.exe:là một hình thức cho phép bạn lựa chọn làm việc với các bài test của bạn và cung cấp các thông tin phản hồi đồ họa. 2.2. NUnit-Console The NUnit-console.exe chương trình là một văn bản dựa trên runner và có thể được sử dụng khi bạn muốn chạy tất cả các bài thi của bạn và không cần phải có màu đỏ /màu vàng / xanh chỉ của thành công hay thất bại. Nó rất hữu ích cho tự động hóa của bài thi và tích hợp vào các hệ thống khác. Nó tự động lưu kết quả của nó trong định dạng XML, cho phép bạn để sản xuất các báo cáo hay xử lý các kết quả. Sau đây là một ảnh chụp màn hình của chương trình. 2.3. NUnit gui runner Là một chương trình đồ họa nunit.exe runner. Điều đó cho các bài kiểm tra trong một thám hiểm-như cửa sổ trình duyệt và cung cấp một hình ảnh chỉ biểu của thành công hay thất bại của các bài kiểm tra. Nó cho phép bạn lựa chọn để chạy một bài kiểm tra hoặc một lớp nào đó và tự động reload khi bạn chỉnh sửa và biên soạn lại mã của bạn. Sau đây là một ảnh chụp màn hình của NUnit chạy cùng một thử-assembly.dll 2.4 Lớp Assert Lớp Assert được sử dụng trong các kiểm thử để khẳng định một điều kiện đã được biết đến. Ví dụ, sau khi chạy một số logic, để khẳng định rằng kết quả trả về có giá trị như dự kiến, thì sử dụng phương thức Assert.Equals. Các phương thức trong lớp Assert: Ø Phương thức tĩnh: § AssertEquals: Sử dụng Assert.Equals (Đối tượng dự kiến, Đối tượng thực tế) § AssertFalse: Sử dụng Assert.False (bool Expression) § AssertNotEquals: Sử dụng Assert.NotEquals (Object obj1, Object obj2) § AssertTrue: Sử dụng Assert.True (bool expression § Contains: Khẳng định rằng một chuỗi là thành viên của một mảng chuỗi. Các tìm kiếm là trường hợp nhạy cảm(sensitive). § Equals: Khẳng định hai đối tượng bằng nhau. § Fail: Gọi phương thức này ngay lập tức, phải có ném một ngoại lệ. Được sử dụng cho các trường hợp ngoại lệ. § False: Xác minh cho dù biểu hiện là 'sai'. § Greater: Khẳng định rằng một đối tượng mạnh hơn là một đối tượng khác. Cả hai đối tượng phải cùng một kiểu, và kiểu đó phải thực thi các giao diện System.Icomparable § Less: Xác nhận rằng một đối tượng yếu hơn một đối tượng khác. Cả hai đối tượng phải cùng một kiểu, và kiểu đó phải thực thi các giao diện System.IComparable. § NotEquals: Khẳng định hai đối tượng là không bằng nhau. § NotNull: Khẳng định không phải là đối tượng rỗng. § Null: Khẳng định một tham chiếu là 'rỗng'. § ReferenceEquals: Khẳng định rằng đối tượng tham chiếu đề cập đến một đối tượng giống như vậy. § StartsWith: Khẳng định rằng một chuỗi bắt đầu với việc cộng chuỗi. Sự kiểm tra này là trường hợp nhạy cảm. § True: Xác minh cho dù biểu hiện là 'đúng'. Ø Phương thức động: § Equals (inherited from Object): Xác định xem có chỉ định đối tượng là bằng đối tượng hiện hành. § GetHashCode (inherited from Object): Phục vụ như một hash chức năng cho một loại, thích hợp cho sử dụng trong các thuật toán hashing và dữ liệu cấu trúc giống như một bảng hash. § GetType (inherited from Object): Lấy kiểu của đối tượng hiện hành § ToString (inherited from Object): Trả về một kiểu chuỗi của đối tượng hiện hành. § Finalize (inherited from Object): Cho phép một đối tượng cố gắng thử với mã nguồn mở và thực hiện các hoạt động trước khi đối tượng phản đối lại do tập hợp các dữ liệu vô nghĩa hoặc không tương thích. § MemberwiseClone (inherited from Object): Tạo ra một bản sao của đối tượng hiện hành. § Assert Constructor: Khởi tạo một instance mới của lớp Assert 2.5 Các thuộc tính trong NUnit: Phiên bản 1 của NUnit sử dụng phương pháp cổ điển để xác định các trường hợp kiểm thử dựa trên thừa kế và tên quy ước.Từ phiên bản 2.0, NUnit đã sử dụng các thuộc tính tùy chỉnh cho mục đích này. 2.5.1 ExpectedExceptionAttribute Lớp ExpectedExceptionAttribute có thể được dùng để đánh dấu một kiểm thử, vì vậy mà khi không có ngoại lệ của một loại kiểu đã được ném, việc kiểm thử sẽ được báo cáo như là không thành công(failed). Nếu ngoại lệ đã được ném, việc kiểm thử sẽ được báo cáo vượt qua. Một số phương thức trong lớp ExpectedExceptionAttribute: § ExpectedExceptionAttribute Constructor: Khởi tạo một đối tượng ExpectedExceptionAttribute. Sử dụng constructor này nếu nó là đủ khả năng để kiểm tra cho các loại ngoại lệ. § ExceptionType: Lấy các kiểu hệ thống dự kiến của các ngoại lệ. § TypeId (inherited from Attribute ): Khi triển khai thực hiện trong một lớp bắt nguồn, lấy một định danh duy nhất cho Attribute (thuộc tính) này. § GetHashCode (inherited from Attribute ): Trả về mã băm § GetType (inherited from Object ): Lấy kiểu của đối tượng hiện hành. § IsDefaultAttribute (inherited from Attribute ): Khi ghi đè trong một lớp , trả lại một dấu hiệu cho dù giá trị này là giá trị mặc định cho các lớp bắt nguồn. § IsEqualTo: So sánh kiểu ngoại lệ với một kiểu ngoại lệ. Nếu thêm vào đó một ngoại lệ, đặc biệt là đối tượng đã được cung cấp, các ngoại lệ sẽ được so với nó. § Match (inherited from Attribute ): Khi ghi đè trong một lớp, trả lại một giá trị cho dù nó bằng một đối tượng xác định. § ToString (inherited from Object ): Trả về một kiểu chuỗi của đối tượng hiện hành. § Finalize (inherited from Object ): Cho phép một đối tượng cố gắng thử với mã nguồn mở và thực hiện các hoạt động trước khi đối tượng phản đối lại do tập hợp các dữ liệu vô nghĩa hoặc không tương thích. § MemberwiseClone (inherited from Object ): Tạo ra một bản sao của đối tượng hiện hành 2.5.2 FixtureSetUpAttribute Lớp FixtureSetUpAttribute: Một phương thức trong một test fixture mà đã được đánh dấu với FixtureSetUpAttribute thì phương thức đó sẽ được gọi một lần trước khi chạy tất cả các test trong test fixture. Một số phương thức trong lớp FixtureSetUpAttribute: § FixtureSetUpAttribute Constructor: Xây dựng một đối tượng FixtureSetUpAttribute § TypeId (inherited from Attribute): Khi triển khai thực hiện trong một lớp bắt nguồn, lấy một định danh duy nhất cho Attribute (thuộc tính) này. § GetHashCode (inherited from Attribute): Trả về mã băm. § GetType (inherited from Object): Lấy kiểu của đối tượng hiện hành. § IsDefaultAttribute (inherited from Attribute): Khi ghi đè trong một lớp , trả lại một dấu hiệu cho dù giá trị này là giá trị mặc định cho các lớp bắt nguồn. § Match (inherited from Attribute): Khi ghi đè trong một lớp, trả lại một giá trị cho dù nó bằng một đối tượng xác định. § ToString (inherited from Object): Trả về một kiểu chuỗi của đối tượng hiện hành. § Finalize (inherited from Object ): Cho phép một đối tượng cố gắng thử với mã nguồn mở và thực hiện các hoạt động trước khi đối tượng phản đối lại do tập hợp các dữ liệu vô nghĩa hoặc không tương thích. § MemberwiseClone (inherited from Object ): Tạo ra một bản sao của đối tượng hiện hành 2.5.3 Lớp FixtureTearDownAttribute Lớp FixtureTearDownAttribute: Một phương thức trong một test fixture đã được đánh dấu với FixtureTearDownAttribute sẽ được gọi một lần sau khi chạy tất cả các test trong test Fixture. Một số phương thức của lớp FixtureTearDownAttribute: § FixtureTearDownAttribute Constructor: Xây dựng một đối tượng FixtureSetUpAttribute. § TypeId (inherited from Attribute): Khi triển khai thực hiện trong một lớp bắt nguồn, lấy một định danh duy nhất cho Attribute (thuộc tính) này. § GetHashCode (inherited from Attribute): Trả về mã băm. § GetType (inherited from Object): Lấy kiểu của đối tượng hiện hành. § IsDefaultAttribute (inherited from Attribute): Khi ghi đè trong một lớp , trả lại một dấu hiệu cho dù giá trị này là giá trị mặc định cho các lớp bắt nguồn. § Match (inherited from Attribute): Khi ghi đè trong một lớp, trả lại một giá trị cho dù nó bằng một đối tượng xác định. § ToString (inherited from Object): Trả về một kiểu chuỗi của đối tượng hiện hành. § Finalize (inherited from Object ): Cho phép một đối tượng cố gắng thử với mã nguồn mở và thực hiện các hoạt động trước khi đối tượng phản đối lại do tập hợp các dữ liệu vô nghĩa hoặc không tương thích. § MemberwiseClone (inherited from Object ): Tạo ra một bản sao của đối tượng hiện hành. 2.5.4 IgnoreAttribute Lớp IgnoreAttribute: IgnoreAttribute có thể được dùng để đánh dấu một test fixture hay một test. Khi đã đánh dấu cách này, test hay toàn bộ test fixture sẽ không được thực hiện. Một số phương thức: § IgnoreAttribute Constructor: Xây dựng một đối tượng IgnoreAttribute. Khi đặt nó trên một kiểm thử, kiểm thử sẽ bị bỏ qua bởi csUnit trong suốt thời gian thực hiện thử nghiệm. § Reason: Lý do tại sao một đơn vị kiểm thử lại được bỏ qua. § TypeId (inherited from Attribute): Khi triển khai thực hiện trong một lớp bắt nguồn, lấy một định danh duy nhất cho Attribute (thuộc tính) này. § GetHashCode (inherited from Attribute): Trả về mã băm. § GetType (inherited from Object): Lấy kiểu của đối tượng hiện hành. § IsDefaultAttribute (inherited from Attribute): Khi ghi đè trong một lớp , trả lại một dấu hiệu cho dù giá trị này là giá trị mặc định cho các lớp bắt nguồn. § Match (inherited from Attribute): Khi ghi đè trong một lớp, trả lại một giá trị cho dù nó bằng một đối tượng xác định. § ToString (inherited from Object): Trả về một kiểu chuỗi của đối tượng hiện hành. § Finalize (inherited from Object ): Cho phép một đối tượng cố gắng thử với mã nguồn mở và thực hiện các hoạt động trước khi đối tượng phản đối lại do tập hợp các dữ liệu vô nghĩa hoặc không tương thích. § MemberwiseClone (inherited from Object ): Tạo ra một bản sao của đối tượng hiện hành. 2.5.5 SetUpAttribute Lớp SetUpAttribute: Một phương thức trong một test fixture được đánh dấu với SetUpAttribute sẽ được thực hiện ngay lập tức trước mỗi test. Phương thức phải có kiểu “public void” Và nó phải không có bất kỳ tham số nào. Một số phương thức: § SetUpAttribute Constructor: Xây dựng một đối tượng SetUpAttribute. § TypeId (inherited from Attribute): Khi triển khai thực hiện trong một lớp bắt nguồn, lấy một định danh duy nhất cho Attribute (thuộc tính) này. § GetHashCode (inherited from Attribute): Trả về mã băm. § GetType (inherited from Object): Lấy kiểu của đối tượng hiện hành. § IsDefaultAttribute (inherited from Attribute): Khi ghi đè trong một lớp , trả lại một dấu hiệu cho dù giá trị này là giá trị mặc định cho các lớp bắt nguồn. § Match (inherited from Attribute): Khi ghi đè trong một lớp, trả lại một giá trị cho dù nó bằng một đối tượng xác định. § ToString (inherited from Object): Trả về một kiểu chuỗi của đối tượng hiện hành. § Finalize (inherited from Object ): Cho phép một đối tượng cố gắng thử với mã nguồn mở và thực hiện các hoạt động trước khi đối tượng phản đối lại do tập hợp các dữ liệu vô nghĩa hoặc không tương thích. § MemberwiseClone (inherited from Object ): Tạo ra một bản sao của đối tượng hiện hành. 2.5.6 TearDownAttribute Lớp TearDownAttribute: Một phương thức được đánh dấu với TearDownAttribute sẽ được gọi ngay lập tức sau khi thực hiện của mỗi kiểm thử đơn. Phương thức phải có kiểu “public void” Và không có bất kỳ tham số nào. Một số phương thức: § TearDownAttribute Constructor: Xây dựng một đối tượng TearDownAttribute § TypeId (inherited from Attribute): Khi triển khai thực hiện trong một lớp bắt nguồn, lấy một định danh duy nhất cho Attribute (thuộc tính) này. § GetHashCode (inherited from Attribute): Trả về mã băm. § GetType (inherited from Object): Lấy kiểu của đối tượng hiện hành. § IsDefaultAttribute (inherited from Attribute): Khi ghi đè trong một lớp , trả lại một dấu hiệu cho dù giá trị này là giá trị mặc định cho các lớp bắt nguồn. § Match (inherited from Attribute): Khi ghi đè trong một lớp, trả lại một giá trị cho dù nó bằng một đối tượng xác định. § ToString (inherited from Object): Trả về một kiểu chuỗi của đối tượng hiện hành. § Finalize (inherited from Object ): Cho phép một đối tượng cố gắng thử với mã nguồn mở và thực hiện các hoạt động trước khi đối tượng phản đối lại do tập hợp các dữ liệu vô nghĩa hoặc không tương thích. § MemberwiseClone (inherited from Object ): Tạo ra một bản sao của đối tượng hiện hành. 2.5.7 TestAttribute Lớp TestAttribute: Một phương thức được đánh dấu với TestAttribute sẽ được nhận dạng như một test bên trong một test fixture. Phương thức phải có kiểu “public void” Và nó không có bất kỳ tham số nào. Một số phương thức: § TestAttribute Constructor: Xây dựng một đối tượng TestAttribute . § Duration: Lấy thời gian thử nghiệm cần thiết để thực hiện § FailureReason: Lấy về một chuỗi với thông tin kiểu văn bản, lý do tại sao một thử nghiệm đã thất bại. § TypeId (inherited from Attribute): Khi triển khai thực hiện trong một lớp bắt nguồn, lấy một định danh duy nhất cho Attribute (thuộc tính) này. § GetHashCode (inherited from Attribute): Trả về mã băm. § GetType (inherited from Object): Lấy kiểu của đối tượng hiện hành. § IsDefaultAttribute (inherited from Attribute): Khi ghi đè trong một lớp , trả lại một dấu hiệu cho dù giá trị này là giá trị mặc định cho các lớp bắt nguồn. § Match (inherited from Attribute): Khi ghi đè trong một lớp, trả lại một giá trị cho dù nó bằng một đối tượng xác định. § ToString (inherited from Object): Trả về một kiểu chuỗi của đối tượng hiện hành. § Finalize (inherited from Object ): Cho phép một đối tượng cố gắng thử với mã nguồn mở và thực hiện các hoạt động trước khi đối tượng phản đối lại do tập hợp các dữ liệu vô nghĩa hoặc không tương thích. § MemberwiseClone (inherited from Object ): Tạo ra một bản sao của đối tượng hiện hành. 2.5.8 TestFailed Lớp TestFailed: TestFailed là một ngoại lệ sẽ được ném khi một test bị thất bại, đó là khi một khẳng định (Assert) bị thất bại. Ngược với một ngoại lệ TestError cho biết một lỗi như là một phép chia cho số không. Một số phương thức: § HelpLink (inherited from Exception): Lấy về hoặc đặt ra một liên kết để giúp đỡ các tập tin liên kết với các ngoại lệ này. §InnerException (inherited from Exception): Lấy về ngoại lệ hiện hành. § Message: Thiết lập một tin nhắn cho ngoại lệ. § Source (inherited from Exception): Lấy về hoặc đặt tên ứng dụng hoặc đối tượng mà gây ra lỗi. § StackTrace (inherited from Exception): Lấy về một chuỗi ký tự đại diện của các cuộc gọi trên khung stack tại thời điểm được ném ngoại lệ. § TargetSite (inherited from Exception): Lấy về phương thức ném ngoại lệ hiện hành. § Equals (inherited from Object): Xác định xem có chỉ định đối tượng là bằng đối tượng hiện hành § GetBaseException (inherited from Exception): Khi ghi đè trong một lớp, trả về giá trị các ngoại lệ là căn nguyên của một hoặc nhiều các trường hợp ngoại lệ. § GetHashCode (inherited from Object): Phục vụ như một hash chức năng cho một loại, thích hợp cho sử dụng trong các thuật toán hashing và dữ liệu cấu trúc giống như một bảng hash. § GetObjectData (inherited from Exception): Khi ghi đè trong một lớp, thiết lập bộ SerializationInfo với thông tin về các ngoại lệ. § GetType (inherited from Object): Lấy kiểu của đối tượng hiện hành. § ToString: Ghi đè từ lớp cơ sở. § HResult (inherited from Exception): Lấy về hay thiết lập bộ HRESULT, một giá trị mã số mà giá trị đó được phân công cụ thể một ngoại lệ. § Finalize (inherited from Object): Cho phép một đối tượng cố gắng thử với mã nguồn mở và thực hiện các hoạt động trước khi đối tượng phản đối lại do tập hợp các dữ liệu vô nghĩa hoặc không tương thích. § MemberwiseClone (inherited from Object): Tạo ra một bản sao của đối tượng hiện hành 2.5.9 TestFixtureAttribute Lớp TestFixtureAttribute: Một lớp public với TestFixtureAttribute sẽ được nhận dạng như một test fixture. Một số phương thức: § TestFixtureAttribute Constructor: Xây dựng một đối tượng TestFixtureAttribute § TypeId (inherited from Attribute): Khi triển khai thực hiện trong một lớp bắt nguồn, lấy một định danh duy nhất cho Attribute (thuộc tính) này. § GetHashCode (inherited from Attribute): Trả về mã băm. § GetType (inherited from Object): Lấy kiểu của đối tượng hiện hành. § IsDefaultAttribute (inherited from Attribute): Khi ghi đè trong một lớp , trả lại một dấu hiệu cho dù giá trị này là giá trị mặc định cho các lớp bắt nguồn. § Match (inherited from Attribute): Khi ghi đè trong một lớp, trả lại một giá trị cho dù nó bằng một đối tượng xác định. § ToString (inherited from Object): Trả về một kiểu chuỗi của đối tượng hiện hành. § Finalize (inherited from Object ): Cho phép một đối tượng cố gắng thử với mã nguồn mở và thực hiện các hoạt động trước khi đối tượng phản đối lại do tập hợp các dữ liệu vô nghĩa hoặc không tương thích. § MemberwiseClone (inherited from Object ): Tạo ra một bản sao của đối tượng hiện hành. CHƯƠNG 3: HƯỚNG DẪN SỬ DỤNG NUnit 3.1.Hướng dẫn dowload phần mềm Để dowload tool Nunit vào website: Hình 3.1: Trang web để dowload phần mềm 3.2.Hướng dẫn sử dụng phần mềm Sau khi tải, nhấn đúp để bắt đầu cài đặt. Làm theo các hướng dẫn. Có thể chọn Setup type là Typical hay Complete. Xác nhận việc cài đặt. Để xác nhận công việc cài đặt đã thực hiện thành công bằng cách chạy từ shortcut Nunit 2.5 từ màn hình và nạp dữ liệu từ thư mục net-1.1 hoặc net-2.0 từ thư mục cài đặt của phần mềm. Và tất cả các bài test đều vượt qua và không báo lỗi. Hình 3.2: Giao diện của Nunit sau khi cài đặt 3.3.Bắt đầu nhanh với NUnit Chúng ta viết một lớp thực hiên test các chức năng tính toán đơn giản bằng các phép cộng trừ nhân chia đơn giản như sau: Cụ thể ở đây lớp tính toán được đặt tên: tester_demo Sử dụng VisuaStudio 2008 tạo 1 class có mã nguồn như sau: using System; using System.Collections.Generic; using System.Text; using System.Xml; namespace tester_demo { public class Class1 { public int phepcong(int a, int b) { int c = a + b; return c; } public int pheptru(int a, int b) { int c = a - b; return c; } public int phepnhan(int a, int b) { int c = a * b; return c; } public int phepchia(int a, int b) { int c = a / b; return c; } } } Mã nguồn được viết trên .Net Sau khi viết xong lớp thực hiên các chức năng ta tiến hành biên dịch lớp này thành file có đuôi “.dll”. Cách làm như sau: Kích chuột phải lên Solution của dự án chon Build. Hình 3.3: Cách build bài toán thành file .dll Sau khi “ build “ ta sẽ có một file .dll ở trong thư mục “bin” của thư mục gốc của project. Xem hình sau: Hình 3.4: Thư mục chứa file .dll Tiếp theo ta tạo thêm 1 class mới trên VisuaStudio đặt tên cho tên cho lớp này là “Test_thu”. Trước khi ta viết mã nguồn để test các chức năng tính toán ở trên thi trong lớp “test_thu” này chúng ta phải Add vào thư viện nunit.framewok và file .dll mà ta tạo ra ở trên. Hộp thoại sau xuât hiện và làm theo hình sau: Tiếp theo ta lại Add thêm một lần nữa để add thư viện nunit.framework vào. Sau khi đã add thành công thi ta tiến hành viết code đế test bài toán của mình. Đoạn code được viết như sau: Sau khi đã viết xong chương trinh test trên ta tiến hành Build để biên dich nó thành file .exe. Và khởi động tool Nunit test để test bài toán mà ta vừa xây dựng xong. Vào File -> Open Project và tìm đến file ta vừa biên dịch. Ví dụ như hình sau: Chương trình test được hiển thị như sau: Tiến hành chạy chương trình test và hiển thị như sau: Chương trình test đã kiễm tra được lỗi của phép toán vì đầu vào và đầu ra của bài toán không đúng Bây giờ ta thay đổi thông tin đầu vào và đầu ra cho bài toán rồi Build lại và chạy lại chương trình. Được hiển thị như sau: Bài toán đã hết lỗi. Thông tin đầu vào đầu ra của bài toán được thay đổi ở đây. CHƯƠNG 4: TỔNG QUAN CHƯƠNG TRÌNH ỨNG DỤNG 4.1 Mô tả bài toán 4.1.1 Mục đích Xây dựng chương trình kiểm tra một tam giác là loại tam giác gì, hay không phải là tam giác để tiến hành sử dụng NUnit 2.5 kiểm thử. Kiểm tra chương trình ứng dụng đúng hay sai. 4.1.2 Phạm vi § Dự án nằm trong khuôn khổ luận văn tốt nghiệp, nhằm mục đích tìm hiểu làm quen với kiểm thử phần mềm, kiểm thử đơn vị, công cụ NUnit 2.5 và ngôn ngữ lập trình .Net. § Sản phẩm kết quả của dự án là chương trình kiểm tra tam giác nhằm phục vụ cho việc sử dụng công cụ NUnit 2.5 để tiến hành kiểm thử. § Các dữ liệu của chương trình bao gồm: Đầu vào của chương trình là độ dài của các cạnh AB, AC và BC của tam giác ABC. Đầu ra của chương trình sẽ đưa ra đó là loại tam giác gì. 4.2 Mô tả chương trình 4.2.1Tổng quan chương trình Chương trình kiểm tra tam giác được xây dựng nhằm phục vụ cho việc sử dụng công cụ NUnit 2.5 để tiến hành kiểm thử.Chương trình xây dựng phải đảm bảo có dữ liệu đầu vào và dữ liệu đầu ra. 4.2.2 Các hệ thống liên quan Chương trình xây dựng trên các công cụ và môi trường sau: § Môi trường cài đặt ứng dụng : Microsoft Windows XP. § Môi trường lập trình : Visual Studio 2008. 4.3 Các yêu cầu chung 4.3.1 Yêu cầu về kiến trúc chương trình Hệ thống phải đảm bảo: Ø Lợi ích của đối tượng người dùng: § Tính tiện dụng: Giao diện thân thiện, dễ sử dụng với người dùng windows. § Tính tiến hóa. § Tính tương thích: Thích hợp với các môi trường. § Tính hiệu quả : Hiệu suất cao, truy xuất nhanh. Ø Lợi ích của việc phát triển dự án: Các tham số của hệ thống được thiết kế động, dễ hiệu chỉnh. Tính dùng lại của code. 4.3.2 Các yêu cầu về thẩm mỹ Đảm bảo thống nhất form chữ trong tất cả các trường dữ liệu của chương trình. Có thể điều chỉnh kích cỡ màn hình. Đảm bảo các nút có cùng kích cỡ, hình dáng, form và cỡ chữ. 4.3.3 Các yêu cầu về sử dụng Chức năng của phím TAB được thực hiện theo đúng trình tự từ trên cùng bên trái sang dưới cùng bên phải Con trỏ phải được đặt vào trường thông tin cần phải nhập hoặc trường/nút điều khiển đầu tiên trên màn hình khi chức năng được kích hoạt Các trường giá trị ngầm định hoặc không được dùng đến phải được bỏ qua trong trình tự TAB Các trường giá trị ngầm định hoặc không được dùng đến phải được bỏ qua trong trình tự TAB Trạng thái ban đầu khi vào form: Tất cả các trường texbox phải được xóa trắng, các combobox phải ở trạng thái chưa lựa chọn. Tạo ra giao diện thân thiện với người dùng Các trường nhập vào kiểm tra nếu null thì mặc định là 0 Giá trị nhập vào phải là số không âm 4.4. Chương trình 4.4.1 Giao diện chương trình Chương trình kiểm tra tam giác có giao diện như hình 4.1: Hình 4.1 Giao diện chương trình kiểm tra tam giác 4.4.2 Mô tả các đối tượng Các đối tượng của chương trình kiểm tra tam giác được nêu rõ trong Bảng 4.1 Đối tượng Tên đối tượng Mô tả TextBox txtA Cạnh AB TextBox txtB Cạnh BC TextBox txtC Cạnh AC CheckBox cbA Căn bậc 2 của AB CheckBox cbB Căn bậc 2 của BC CheckBox cbC Căn bậc 2 của AC TextBox txtTamgiac Tam giác TextBox txtCV Chu vi TextBox txtS Diện tích Button btok Thực hiện Button bthuy Xóa Bảng 4.1 Các đối tượng của chương trình kiểm tra tam giác 4.4.2 Mã code của chương trình 4.4.2.1 Code giao diện using System; using System.Collections.Generic; using System.ComponentModel; using System.Data; using System.Drawing; using System.Text; using System.Windows.Forms; using ClassLibrary1; namespace WindowsApplication1 { public partial class Form1 : Form { public Form1() { InitializeComponent(); } private void Form1_Load(object sender, EventArgs e) { } private void btok_Click(object sender, EventArgs e) { if (txtA.Text == "") { txtA.Text = "0"; } if (txtB.Text == "") { txtB.Text = "0"; } if (txtC.Text == "") { txtC.Text = "0"; } double a = Convert.ToDouble(txtA.Text); double b = Convert.ToDouble(txtB.Text); double c = Convert.ToDouble(txtC.Text); if (cbA.Checked) { a = Math.Sqrt(a); } if (cbB.Checked) { b = Math.Sqrt(b); } if (cbC.Checked) { c = Math.Sqrt(c); } Class1 x = new Class1(); int d = x.phanloai(a, b, c); if (d==1) { txtTamgiac.Text = "Tam giác đều"; } else if (d==2) { txtTamgiac.Text = "Tam giác vuông cân"; } else if (d==3) { txtTamgiac.Text = "Tam giác cân"; } else if (d==4) { txtTamgiac.Text = "Tam giác vuông"; } else if (d==5) { txtTamgiac.Text = "tam giac thuong"; } else { txtTamgiac.Text = "Không phải tam giác"; } txtCV.Text = x.chuvi(a, b, c).ToString(); txtS.Text = x.dientich(a, b, c).ToString(); } private void bthuy_Click(object sender, EventArgs e) { txtA.Text = ""; txtB.Text = ""; txtC.Text = ""; txtTamgiac.Text = ""; txtCV.Text = ""; txtS.Text = ""; } private void txtA_KeyPress(object sender, KeyPressEventArgs e) { string decimalString = "."; char decimalChar = Convert.ToChar(decimalString); if (Char.IsDigit(e.KeyChar) || Char.IsControl(e.KeyChar)) { } else if (e.KeyChar == decimalChar && txtA.Text.IndexOf(decimalString) == -1) { } else { e.Handled = true; } } } } 4.4.2.2. Code của lớp kiểm tra tam giác using System; using System.Collections.Generic; using System.Text; namespace ClassLibrary1 { public class Class1 { public Boolean tamgiac(double a,double b,double c)// kiem tra la tam giac thuong { if ((a + b > c) && (b + c > a) && (a + c > b)) { return true; } return false; } public Boolean tamgiacvuong(double a, double b, double c)// kiem tra la tam giac vuong { if (tamgiac(a, b, c))// neu la tam giac thuong { if (a * a + b * b == c * c || a * a + c * c == b * b || b * b +c * c == a * a) return true; } return false; } public Boolean tamgiacvuongcan(double a, double b, double c)// kiem tra tam giac vuong can { if (tamgiacvuong(a, b, c)) { if (a == b || b == c || c == a) return true; } return false; } public Boolean tamgiaccan(double a, double b, double c)// kiem tra tam giac can { if (tamgiac(a, b, c)) { if (a == b || b == c || c == a) return true; } return false; } public Boolean tamgiacdeu(double a, double b, double c)// kiem tra tam giac deu { if (tamgiac(a, b, c)) { if (a == b && b == c && c == a) return true; } return false; } public double dientich(double a, double b, double c) { if (!tamgiac(a, b, c)) return 0; double p = (a + b + c)/2; return Math.Sqrt(p * (p - a) * (p - b) * (p - c)); } public double chuvi(double a, double b, double c) { if (!tamgiac(a, b, c)) return 0; return a + b + c; } public int phanloai(double a, double b,double c)// phan loai tam giac { if(tamgiacdeu(a, b, c)) return 1;// la 1 neu tam giac deu if(tamgiacvuongcan(a, b, c)) return 2;//... if(tamgiaccan(a, b, c)) return 3; if(tamgiacvuong(a,b,c)) return 4; if(tamgiac(a,b,c)) return 5; return 0;// la 0 neu ko la tam giac } } } CHƯƠNG 5: THIẾT KẾ KIỂM THỬ 5.1 Kiểm thử hộp đen Kiểm thử hộp đen là phương pháp tập trung vào yêu cầu về mặt chức năng của phần mềm. Sau đây chúng ta sẽ tạo ra một bộ các điều kiện input yêu cầu về giao diện để kiểm thử chức năng của ứng dụng kiểm tra tam giác. 5.1.1 Yêu cầu giao diện Ứng dụng kiểm tra tam giác được tạo ra với mục đích để minh họa cho quá trình kiểm thử đơn vị với công cụ kiểm thử NUnit version 2.5 cho nên yêu cầu về giao diện rất đơn giản. Bảng 5.1 dưới đây sẽ trình bày rõ các yêu cầu giao diện của ứng dụng TT Yêu cầu Test Yêu cầu kết quả 1 Các thông tin chương trình Chương trình bao gồm:   Các Label: Cạnh AB, Cạnh BC, Cạnh AC.   Ba Checkbox: Căn Bậc 2.   Các textbox: A, B, C, TamGiac.   Các button: Bắt đầu, Hủy. 2 Cho phép thực hiện kiểm tra tam giác. Click button “ Bắt đầu ” để tiến hành kiểm tra tam giác. 3 Cho phép nhập lại các thông tin đã nhập. Click button “ Hủy ” để tiến hành nhập lại các thông tin đã nhập. 4 Cho phép người dùng có thể chọn căn bậc hai của cạnh đã nhập Click checkbox “ Căn Bậc 2 ” để chọn căn bậc hai cho cạnh đã nhập 5 Người dùng không cần sử dụng chuột nhưng vẫn có thể thực hiện được chương trình. Sử dụng phím tab để di chuyển. 6 Cho phép người dùng có thể nhập độ dài của các cạnh. Các textbox: Cạnh AB, Cạnh AC, Cạnh BC được dùng cho phép người dùng có thể nhập độ dài các cạnh. 7 Cho phép xem đó là tam giác gì sau khi đã tiến hành kiểm tra. Texbox “ TamGiac” cho phép người dùng xem đó là tam giác gì sau khi đã tiến hành kiểm tra. Bảng 5.1 Yêu cầu giao diện 5.1.2 Mô tả các tình huống Test Bảng 5.2 sau đây trình bày các tình huống test dựa trên yêu cầu về giao diện trong bảng 5.1 ở trên TT Dữ liệu Test Yêu cầu kết quả 1 Nhập vào giá trị của ba cạnh tam giác và kích chọn button “Bắt đầu ”. Trên form chương trình sẽ hiện ra đó là loại tam giác gì. 2 Nhập vào giá trị của ba cạnh tam giác và kích chọn button “ Hủy ”. Chương trình sẽ xóa trắng các textbox để người dùng nhập dữ liệu mới. 3 Nhập vào giá trị của ba cạnh tam giác, kích chọn vào checkbox của một cạnh nào đó và kích button “ Hủy ”. Chương trình sẽ xóa trắng các textbox, checkbox để người dùng nhập dữ liệu mới. 4 Nhập dữ liệu các cạnh là ký tự. Trên form chương trình sẽ báo lỗi dữ liệu bị sai. 5 Không nhập dữ liệu các cạnh nhưng lại kích chọn button “Bắt đầu ”. Chương trình ngầm hiểu rằng các cạnh của tam giác lúc này là bằng không và vẫn tiến hành kiểm tra. 6 Nhập dữ liệu các cạnh có dạng phân số. Trên form chương trình sẽ báo lỗi dữ liệu bị sai. Bảng 5.2 Mô tả các tình huống test 5.2 Kiểm thử hộp trắng Trong kiểm thử hộp trắng,các trường hợp kiểm thử được thiết kế để xem xét trên cấu trúc nội bộ của module và cấu trúc điều kiện. Bảng 5.3 dưới đây đưa ra các tình huống test với dữ liệu đầu vào và kết quả đầu ra cho các trường hợp. TT Tình huống Dữ liệu đầu vào Kết quả đầu ra Dữ liệu đầu vào và kết quả đầu ra đều đúng. Cạnh AB: 3 Cạnh AC: 4 Cạnh BC: 5 Tam giác vuông Dữ liệu đầu vào và kết quả đầu ra đều đúng. Cạnh AB: 2 Cạnh AC: 2 Cạnh BC: Căn bậc hai của 8 Tam giác vuông cân Dữ liệu đầu vào đúng nhưng kết quả đầu ra sai. Cạnh AB: 2 Cạnh AC: 3 Cạnh BC: 4 Tam giác vuông Dữ liệu đầu vào và kết quả đầu ra đều đúng. Cạnh AB: Căn bậc hai của 9 Cạnh AC: 3 Cạnh BC: 5 Tam giác cân Dữ liệu đầu vào và kết quả đầu ra đều sai. Cạnh AB: 3/5 Cạnh AC: 3 Cạnh BC: 4 Không là tam giác Bảng 5.3 Dữ liệu kiểm thử. CHƯƠNG 6: TIẾN HÀNH KIỂM THỬ 6.1 Kiểm thử hộp đen 6.1.1 Kết quả kiểm thử giao diện Bảng 6.1 sau đây là kết quả đạt được sau khi tiến hành kiểm thử giao diện của chương trình ứng dụng TT Yêu cầu Test Yêu cầu kết quả Kết quả 1 Các thông tin chương trình Chương trình bao gồm:   Các Label: Cạnh AB, Cạnh BC, Cạnh AC, Tam Giác.   Ba Checkbox: Căn Bậc 2.   Các textbox: A, B, C, TamGiac.   Các button: Bắt đầu, Hủy. True 2 Cho phép thực hiện kiểm tra tam giác. Click button “ Bắt đầu ” để tiến hành kiểm tra tam giác. True 3 Cho phép nhập lại các thông tin đã nhập. Click button “ Hủy ” để tiến hành nhập lại các thông tin đã nhập. True 4 Cho phép người dùng có thể chọn căn bậc hai của cạnh đã nhập Click checkbox “ Căn Bậc 2 ” để chọn căn bậc hai cho cạnh đã nhập True 5 Người dùng không cần sử dụng chuột nhưng vẫn có thể thực hiện được chương trình. Sử dụng phím tab để di chuyển. True 6 Cho phép người dùng có thể nhập độ dài của các cạnh. Các textbox: A, B, C được dùng cho phép người dùng có thể nhập độ dài các cạnh. True 7 Cho phép xem đó là tam giác gì sau khi đã tiến hành kiểm tra. Texbox “ TamGiac” cho phép người dùng xem đó là tam giác gì sau khi đã tiến hành kiểm tra. True Bảng 6.1 Kết quả kiểm thử giao diện 6.1.2 Kết quả kiểm thử chức năng Kết quả của các tình huống test nêu ra ở chương 5 sẽ được trình bày ở Bảng 6.2 dưới đây TT Dữ liệu Test Yêu cầu kết quả Kết quả 1 Nhập vào giá trị của ba cạnh tam giác và kích chọn button “ Bắt đầu ”. Trên form chương trình sẽ hiện ra đó là loại tam giác gì. True 2 Nhập vào giá trị của ba cạnh tam giác và kích chọn button “ Hủy ”. Chương trình sẽ xóa trắng các textbox để người dùng nhập dữ liệu mới. True 3 Nhập vào giá trị của ba cạnh tam giác, kích chọn vào checkbox của một cạnh nào đó và kích button “ Hủy ”. Chương trình sẽ xóa trắng các textbox, checkbox để người dùng nhập dữ liệu mới. Faile 4 Nhập dữ liệu các cạnh là ký tự. Trên form chương trình sẽ báo lỗi dữ liệu bị sai. Faile 5 Không nhập dữ liệu các cạnh nhưng lại kích chọn button “ Bắt đầu ”. Chương trình ngầm hiểu rằng các cạnh của tam giác lúc này là bằng không và vẫn tiến hành kiểm tra. True 6 Nhập dữ liệu các cạnh có dạng phân số. Trên form chương trình sẽ báo lỗi dữ liệu bị sai. Faile Bảng 6.2 Kết quả kiểm thử các tình huống 6.2 Kiểm thử hộp trắng Để kiểm thử module của chương trình ứng dụng thì ta cần tạo một project trong Visul Studio 2008 với tên testUnitTamGiac. Sau đây là TestCase của chương trình với các trường hợp kiểm thử đã được thiết kế ở Bảng 5.3 using System; using System.Collections.Generic; using System.Linq; using System.Text; using NUnit.Framework; namespace checkTamGiac { [TestFixture] public class testUnitTamGiac { private ClassLibrary1.Class1 x; [TestFixtureSetUp] public void SetUp() { x = new ClassLibrary1.Class1(); } [TestFixtureTearDown] public void TearDown() { x = null; } [Test] public void TestTamGiac() { int a = x.phanloai(3, 4,5); Assert.AreEqual(a, 4); } } } Sau khi tiến hành kiểm thử, ta có kết quả trong Bảng 6.3 dưới đây: TT Tình huống Dữ liệu đầu vào Kết quả đầu ra Kết quả Hình 1 Dữ liệu đầu vào và kết quả đầu ra đều đúng. Cạnh AB: 3 Cạnh AC: 4 Cạnh BC: 5 Tam giác vuông Kết quả chấp nhận bộ dữ liệu vào và cho ra kết quả là tam giác vuông → kết quả test là đúng 6.1 2 Dữ liệu đầu vào và kết quả đầu ra đều đúng. Cạnh AB: 2 Cạnh AC: 2 Cạnh BC: Căn bậc hai của 8 Tam giác vuông cân Kết quả chấp nhận bộ dữ liệu vào và chương trình không báo lỗi → kết quả test là đúng 6.2 3 Dữ liệu đầu vào đúng nhưng kết quả đầu ra sai. Cạnh AB: 2 Cạnh AC: 3 Cạnh BC: 4 Tam giác vuông Kết quả chấp nhận bộ dữ liệu vào nhưng chương trình báo lỗi → kết quả test là đúng 6.3 4 Dữ liệu đầu vào và kết quả đầu ra đều đúng. Cạnh AB: Căn bậc hai của 9 Cạnh AC: 3 Cạnh BC: 5 Tam giác cân Kết quả chấp nhận bộ dữ liệu và chương trình không báo lỗi → kết quả test là đúng 6.4 5 Dữ liệu đầu vào và kết quả đầu ra đều sai. Cạnh AB: 3/5 Cạnh AC: 3 Cạnh BC: 4 Không là tam giác Kết quả chấp nhận bộ dữ liệu và chương trình không báo lỗi → kết quả test là sai. Dữ liệu Cạnh AB không được có dạng phân số. 6.5 Bảng 6.3 Kết quả kiểm thử hộp trắng. Kết quả kiểm thử lần 1 ở hình 6.1 cho thấy dữ liệu đầu vào và kết quả đầu ra là trùng với nhau (tam giác vuông),vậy kết quả test là đúng. Hình 6.1 Kết quả kiểm thử lần 1 Kết quả kiểm thử lần 2 ở hình 6.2 cho thấy dữ liệu đầu vào và kết quả đầu ra là trùng với nhau (tam giác vuông cân),vậy kết quả test là đúng. Hình 6.2 Kết quả kiểm thử lần 2 Kết quả kiểm thử lần 3 ở hình 6.3 cho thấy kết quả chấp nhận bộ dữ liệu đầu vào nhưng chương trình báo lỗi (dữ liệu đầu vào là tam giác thường nhưng kết quả đầu ra lại là tam giác vuông),vậy kết quả test là đúng. Hình 6.3 Kết quả kiểm thử lần 3 Kết quả kiểm thử lần 4 ở hình 6.4 cho thấy dữ liệu đầu vào và kết quả đầu ra là trùng với nhau (tam giác cân),vậy kết quả test là đúng. Hình 6.4 Kết quả kiểm thử lần 4 Kết quả kiểm thử lần 5 ở hình 6.5 cho thấy mặc dù dữ liệu đầu vào cho cạnh AC ở dạng phân số nhưng chương trình test vẫn chấp nhận dữ liệu này trong khi chương trình ứng dụng thì không, vậy kết quả test là sai. Hình 6.5 Kết quả kiểm thử lần 5 KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN Kết quả đạt được của đồ án là hiểu rõ và vận dụng được qui trình kiểm thử vào các sự án thực tế, nghiên cứu và vận dụng hiệu quả một số công cụ hỗ trợ kiểm thử tự động đặc biệt là công cụ kiểm thử NUnit thực hiện trên một số sản phẩm demo, từ đó đề xuất và ứng dụng kiểm thử cho các ứng dụng phức tạp hơn, thực hiện nhiều loại, nhiều giai đoạn kiểm thử. Việc kiểm thử bằng NUnit giúp tiết kiệm được thời gian và kiểm thử đơn vị hiệu quả. Trên cơ sở nghiên cứu các tư liệu và kết quả thực nghiệm cho thấy kiểm thử phần mềm là rất quan trọng, việc thực hiện kiểm thử tốt sẽ làm tăng chất lượng của sản phẩm. Tuy nhiên, để vận dụng và thực hiện một cách hiệu quả các qui trình, phương pháp và công cụ kiểm thử thì vẫn còn nhiều vấn đề đặt ra cần tiếp tục giải quyết. Có thể đề xuất những hướng nghiên cứu và triển khai tiếp theo của đồ án là: - Sử dụng công cụ kiểm thử NUnit để kiểm thử các đối tượng của website và hiệu suất của một website. - Nghiên cứu một số công cụ kiểm thử web, kiểm thử cơ sở dữ liệu, kiểm thử tải. Để nâng cao hiệu suất kiểm thử nhiều loại sản phẩm phần mềm khác nhau, ta cần nghiên cứu thêm nhiều công cụ kiểm thử tự động khác bởi vì mỗi một công cụ kiểm thử chỉ có thể thực hiện chuyên một số kiểm thử nào đó. TÀI LIỆU THAM KHẢO [1] B.Beizer,Software Testing Techniques.London: International Thompson Computer Press,1990. [2] A.Bertolino,”Chapter 5: Software Testing,” in IEEE SWEBOK Trial Version 1.00,May 2001 [3] B.W.Boehm, Software Engineering Economics. Englewood Cliffs, NJ: Prentice- Hall,Inc.,1981. [4] R.D.Craig and S.P.Jaskiel, Systematic Software Testing. Norwood,MA: Artech House Publishers,2004. [5]Roger S.Pressman (2005). Software Engineering: A Practitioner's Approach (6th ed.)