Để 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.
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).
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.
