Software Testing and Quality Assurance - Lecture 2: Test Case - Đào Nam Anh

1Software Testing and Quality Assurance Test Case Dr. Dao Nam Anh Faculty of Information Technology University of Technology and Management 2Resources ► Pressman, Software Engineering, McGraw Hill (chapter 18 & 19) ► Sommerville, Software Engineering, Addison-Wesley (chapter 22 & 23) ► Software Testing and QA Theory and Practics, Chapter 7, WILEY Publish ► Foundations Of Software Testing, Istqb Certification, Dorothy Graham, Erik Van Veenendaal, Isabel Evans, Rex Black ► Jovanović, Irena, Software Testing Methods and Techniques ► Lâm Quang Vũ, 3Nội dung ► Failure, Error, Fault ► Tài liệu kiểm thử ► Ca kiểm thử (test case) ► Nội dung của test case ► Các tính chất của Test case ► Bốn giai đoạn thường có trong kiểm thử ► Quy trình kiểm thử phần mềm ► Test Cycle ► AUT, Test case ► QC vs QA ► Ba chủ đề phổ biến ► Black Box vs White Box Testing ► Problem Report ► Document Testing 4Tổng Quan Failure, Error, Fault ►Fault là thể hiện của lỗi. ►Error là có gì sai sót trong phần mềm. ►Failure là có gì sai trong hành vi của phần mềm (sai lệch yêu cầu). ►Không có fix failure. Error và fault còn gọi là Bug. Có fix bug. Tỉ lệ lỗi ở phần đã kiểm tra thường tương tự phần chưa kiểm tra. 5Tổng Quan Tài liệu kiểm thử: ► Test plan: phương thức tổng quát để kiểm tra sản phẩm qua mục tiêu chất lượng, nhu cầu tài nguyên, lịch trình, nhiệm vụ, phương pháp. Test plan có thể là sản phẩm hoặc là công cụ. ► Test case: các mục sẽ được kiểm tra và chi tiết từng bước, thường phải bao gồm luôn kết quả mong đợi. Test case phải được viết cho cả trường hợp hợp lệ và không hợp lệ. ► Bug report: mô tả các lỗi tìm thấy và gợi ý cách sửa lỗi. ► Công cụ kiểm tra hay kỹ thuật tự động. ► Các ma trận, thống kê và bản tóm tắt quy trình kiểm thử. 6Tổng Quan Ca kiểm thử (Test Case) Ca kiểm thử: dữ liệu để kiểm tra hoạt động của chương trình Ca kiểm thử tốt − được thiết kế để phát hiện một lỗi của chương trình Kiểm thử thành công: phát hiện ra lỗi Mục đích: − Chứng minh được sự tồn tại của lỗi − Không chứng minh được sự không có lỗi 7Tổng Quan Nội dung của Test case Tên mô đun/chức năng muốn kiểm thử dữ liệu vào − dữ liệu thông thường: số, xâu kí tự, file,... − môi trường thử nghiệm: phần cứng, OS,... − thứ tự thao tác (khi kiểm thử giao diện) Kết quả mong muốn − thông thường: số, xâu kí tự, file,... − màn hình, thời gian phản hồi Kết quả thực tế 8Tổng Quan Các tính chất của Test case Test case tốt: chính xác, tiết kiệm, có thể dùng lại, có thể truy vết, phù hợp (với môi trường kiểm tra, tester), độc lập với người viết, dễ hiểu. Khung của test case: + Phát biểu mục đích, cái gì được kiểm thử. + Phương thức, cách sẽ được kiểm thử. + Cơ cấu, môi trường dữ liệu. + Các bước, hành động và kết quả mong đợi (trong bảng hoặc ma trận). + Chứng cứ, tập tin, bản in, báo cáo, chụp màn hình. 9Tổng Quan Các tính chất của Test case Bảy lỗi phổ biến: + Làm test case quá dài (step-by-step chỉ cần 10-15 bước). + Setup khó hiểu, không chính xác hoặc không hoàn chỉnh. + Bỏ mất 1 bước. + Đặt tên field đã thay đổi hoặc không tồn tại. + Không rõ hành động của tester hoặc hệ thống. + Không rõ kết quả là pass hay fail. + Không clean-up được. 10 Tổng Quan Các tính chất của Test case 3 dạng test case thường dùng: step-by-step, matrix, automated script. Lợi ích của test case ngắn: + Tốn ít thời gian để kiểm thử mỗi bước. + Tester ít khi mắc lỗi hay cần trợ giúp. + Test manager có thể ước lượng chính xác thời gian cần test. + Kết quả dễ theo dõi. 11 Tổng Quan Bốn giai đoạn thường có trong kiểm thử 1. Mô hình hóa môi trường phần mềm 2. Chọn kịch bản test 3. Chạy và đánh giá kịch bản test 4. Đánh giá tiến trình kiểm thử 12 Tổng Quan Quy trình kiểm thử phần mềm Test case Test data Test results Test reports Design test cases Prepare test data Run program with test data Compare results to test cases 13 Tổng Quan Test Cycle 1. Nhận sản phẩm 2. Clean-up hệ thống 3. Kiểm tra khả năng test 4. Xem xét các thay đổi và các phần mới 5. Xem xét những gì đã được sửa 6. Kiểm tra các phần đã được sửa 7. Kiểm tra các phần thay đổi hay các phần mới 8. Thực hiện kiểm tra hồi quy 9. Báo cáo kết quả 14 Tổng Quan AUT, Test case Khi có vấn đề: ►Lỗi ở AUT & bug ►Lỗi ở test case ►Lỗi trong quá trình thực thi 15 Tổng Quan QC vs QA ► Những hoạt động, những kỹ thuật nhằm đảm bảo chất lượng sản phẩm. ► Xác định vấn đề, phân tích vấn đề, sửa lỗi vấn đế, phản hồi cho QA. ► Sản phẩm -> phản ứng -> tìm lỗi ► Kiểm duyệt, kiểm thử, thanh tra, kiểm tra lại. ► Những kế hoạch, những hoạt động mang tính hệ thống nhằm đảm bảo quá trình sản xuất sẽ tạo ra những sản phẩm có chất lượng. ► Thu thập dữ liệu, phân tích hướng vấn đề, xác định vấn đề, phân tích vấn đề, cải tiến quy trình. ► Tiến trình -> ước tính -> ngăn ngừa ► Đảm bảo chất lượng, định nghĩa tiến trình, chọn lựa công cụ, huấn luyện. 16 Tổng Quan Ba chủ đề phổ biến: 1. Đánh giá chất lượng 2. Quản lý rủi ro 3. Cải tiến quy trình kiểm thử 17 Tổng Quan Black Box vs White Box Testing ►Black Box Testing: xem phần mềm như hộp đen, không thể kiểm tra chính xác hoàn toàn, đưa ra giả định về phần cài đặt, thường dùng khi test tính tương thích giữa các thành phần, có thể test giao diện và hành vi. 18 Tổng Quan Black Box vs White Box Testing 19 Tổng Quan Black Box vs White Box Testing ►White Box Testing: kiểm tra cấu trúc nội tại của chương trình, cũng không đảm bảo chính xác hoàn toàn, cần bản đặc tả, cần kiến thức tốt về phần cài đặt, thường dùng để kiểm tra từng chức năng, có thể kiểm tra phần cài đặt và thiết kế. 20 Tổng Quan Các cấp độ test ►Unit test ►Module test ► Function test ► System test + Facility test + Volume test + Usability test + Security test + Performance test 21 Tổng Quan Problem Report Ngay khi gặp vấn đề trong phần mềm cần điền vào bản báo cáo vấn đề ngay. Nội dung của bản báo cáo vấn đề: + Mã số, tên chương trình, mã số phiên bản. + loại báo cáo: coding error, design issue, suggestion, documentation, hardware, query. + Mức độ nghiêm trọng: minor, serious, fatal. + Tài liệu đính kèm, tổng quát vấn đề. + Khả năng tái hiện lỗi: có, không hoặc thỉnh thoảng. + Giải thích lỗi và cách tái hiện lỗi (nếu có). + Đề xuất cách sửa (nếu có), người lập báo cáo, ngày tháng, phần chức năng. + Nhóm hoặc người quản lý phụ trách vấn đề. + Người nhận, ghi chú. + Trạng thái: mở, được sửa, đóng. + Độ ưu tiên: sửa ngay, sửa càng sớm càng tốt, sửa trước giai đoạn kế, sửa trước khi kết thúc, sửa nếu có thể, không bắt buộc sửa. + Trạng thái hiện tại của vấn đề: chưa quyết định, đã sửa, không thể tái hiện, hoãn lại, không phải lỗi, người viết lấy lại, cần thêm thông tin, không đồng ý với đề xuất, bản sao. + Phiên bản phần mềm chứa thay đổi. + Ký tên, được xem xét hay hoãn lại. 22 Tổng Quan Problem Report Đặc điểm: đơn giản, dễ hiểu, có thể tái sử dụng, rõ ràng, không mang tính phán quyết. Mục tiêu: + Tìm hậu quả nghiêm trọng nhất. + Tìm các điều kiện đơn giản nhất và tổng quát nhất. + Tìm hướng phụ cho cùng vấn đề. + Tìm vấn đề liên quan. 23 Tổng Quan Document Testing Bao gồm: đóng gói, tập tin readme, thẻ tham khảo nhanh, trợ giúp trực tuyến. Mục đích: cải thiện tính tiện dụng, tính tin cậy, tăng khả năng kinh doanh, hạ chi phí hỗ trợ khách hàng, giảm bớt trách nhiệm pháp lý. Lợi ích: tìm nhiều lỗi hơn, test case thực tế hơn, lỗi tìm thấy dễ sửa hơn 24 Q & A