1.3.1. Vòng đời của lỗi
Một lỗi trong phần mềm là một cái gì đó mà gây ra cho phần mềm chạy theo cách mà nó không nhất quán với những yêu cầu hay sự cần thiết của khách hàng hay những chuẩn liên quan.
Vòng đời của lỗi:
Một lỗi được tìm thấy và phải được ghi lại trong DMS bởi một một nhân viên. Lỗi được vào trong DMS với trạng thái “Error” và thông tin khác.
Lãnh đạo dự án phải xem lại dữ liệu của một lỗi (như là dạng lỗi, nguồn gốc,tính nguy hại,..), sửa nó và giao cho người sửa lỗi. Thông thường thành viên được giao là tác giả của văn bản hay đoạn mã nguồn mà lỗi được tìm thấy trong đó. Trạng thái của lỗi được thay đổi thành “Assigned”.
Sau khi sửa lỗi, tác giả đổi trạng thái lỗi thành thành “Pending”
Người kiểm thử kiểm thử lại lỗi chưa giải quyết và cập nhật trạng thái thành “Tested” nếu lỗi được sửa một cách hài lòng, hay thành “Error”.
Nếu một lỗi với trạng thái “Error” có thể được chấp nhận mà không có một hành động hiệu chỉnh nào, lãnh đạo dự án cần đổi trạng thái thành “Accepted”.
Hình 1.17 Quá trình bắt lỗi 1.3.2. Dạng của lỗi
Một số dạng chung của lỗi:
# Dạng lỗi Ví dụ
1 Functionality Chức năng được chỉ ra không làm việc Requirement misunderstanding Những yêu cầu đầu vào không được hiểu rõ Feature missing Một phần của đặc tính hay đặc tính không hoàn
Coding logic Kỹ năng kỹ thuật, đánh giá dữ liệu... hay những lý do khác không được xác định như là vấn đề viết code
Business logic không theo luồng công việc 2 User Interface Lỗi trong giao diện, bố cục
3 Performance tôc độ xử lý chậm hay lỗi hệ thống do cấu hình; vấn đề bộ 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
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ử:
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.
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