Kĩ thuật lập trình - Bài 2: Qui trình kiểm thử

Đại học Sài Gòn*ThS Nguyễn Quốc Huy - ĐHSG*Bài 2 Qui trình kiểm thửQuy trình kiểm thử*ThS Nguyễn Quốc Huy - ĐHSG*Test Plans và Test CasesRegression và Kiểm thử chức năng mớiTiêu chuẩn bắt đầu/kết thúc kiểm thửKiểm soát Phiên bảnTheo vết lỗiQui trình kiểm thử*ThS Nguyễn Quốc Huy - ĐHSG*Test Plans và Test CasesKế hoạch kiểm thử là tài liệu mô tả các hoạt động kiểm thử theo kế hoạch. Đối với dự án lớn, có thể chia thành nhiều kế hoạch con.Test case là danh sách các bước để kiểm thử tình huống nào đó. Không nên dài quá 1 trang. Phải có phần pass/fail. Thông thường người ta dùng ma trận test case trong kế hoạch kiểm thử để xác định sự kết hợp/hoán vị các điều kiện sẽ được kiểm.Qui trình kiểm thử:Test Plans*ThS Nguyễn Quốc Huy - ĐHSG*Phần nhận dạng – Tên / Số hiệu Giới thiệu – Mô tả vắn tắt sản phẩm & chiến lược kiểm thử Các mục kiểm thử – Mô tả các mục được kiểm Chi tiết kiểm thử - Liệt kê Chi tiết không kiểm thử – Cần phải liệt kê, các giả định ngăn ngừa Hướng tiếp cận – Mô tả chiến lược kiểm thử Tiêu chuẩn pass/fail – Phải có tiêu chuẩn pass/fail criteria khi kiểm Tiêu chuẩn đình chỉ và các yêu cầu bắt đầu lại – (tiêu chuẩn Entry / Exit) Kết quả kiểm thử – Biểu đồ thực hiện, danh sách bug, biểu đồ bug Các công việc kiểm thử Cần môi trường gì – Thiết lập Lab Trách nhiệm – Xác định rõ & đồng thuận Yêu cầu nhân viên và huấn luyện – Huấn luyện tiếp, cho tương lai Lịch trình – Thời gian thực hiện test cases và thời gian phần mềm ổn định Rủi ro/điều không đoán trước – Xác định rủi ro trong thực tế Phê duyệt – Người quản lý, đội ngũ khách hàngQui trình kiểm thử: Test Plans*ThS Nguyễn Quốc Huy - ĐHSG*Mốc thực hiện: Duyệt kế hoạch kiểm thử Bắt đầu công việc Hoàn thành kịch bản Bắt đầu kiểm thử Kết thúc kiểm thử Kịch bản được chuyển giao để kiểm ngẩu nhiên.Qui trình kiểm thử: Test Plans*ThS Nguyễn Quốc Huy - ĐHSG*Qui trình kiểm thử: Test Plans*ThS Nguyễn Quốc Huy - ĐHSG*Ước lượng lịch trình là khó! Có lịch trình đích (thực hiện hết khả năng dựa trên kinh nghiệm trước đó) Khi 75% lịch trình trôi qua, chốt lại ngày hoàn thành kiểm thử, nhưng mà phải chú ý đến tiến trình. Lưu vết những điều xảy ra trong dự án, vì vậy ta có thể ước tính chính xác lịch trình cho dự án tiếp theo.Qui trình kiểm thử:Test Cases*ThS Nguyễn Quốc Huy - ĐHSG*Phần nhận dạng – Tên / Số hiệu Người sở hữu Test case – Ai viết? Ai chịu trách nhiệm cập nhật? Mục được kiểm – Mô tả Xác định đầu vào/ đầu ra Tiêu chuẩn pass/fail – Phải có tiêu chuẩn pass/fail cho test case Tự động hoá – Có thể tự động không? Phải tự động? Chỉ ra file.Công việc kiểm thử – dưới 1 trang Môi trường cần – Thiết lập Lab Yêu cầu thủ tục đặc biệt Các phụ thuộc Inter-case Độ ưu tiên Test case – có thể thay đổi, phụ thuộc nhiều yếu tố Lưu vết phiên bản mà test case này hợp lệ Lịch trình – Thời gian thực hiện test case – lưu vết thông tin này Bugs tìm được từ test case – cập nhật mỗi khi tìm thấy bug mớiQui trình kiểm thử: Test Cases*ThS Nguyễn Quốc Huy - ĐHSG*Bắt đầu công việc viết test cases khi lấy được yêu cầu.Đưa test cases cho người viết mã xem. Lấy nhận xét của họ. Giúp ngăn chặn bugs từ khi viết mã.Test cases nên đưa đầy đủ thông tin thực hiện kiểm thử, nhưng không quá chi tiết để cho mọi người có thể thực hiện. Nên có độ biến thiên và sự ngẩu nhiên trong test case.Qui trình kiểm thử: Test Cases*ThS Nguyễn Quốc Huy - ĐHSG*Test Cases dương: Thực hiện chức năng như yêu cầu.Test Cases âm:Trường hợp bị ngắtMạng: Disconnected, No Ports availableĐĩa lưu trữ: File not found, File in use, Disk Full, Invalid Path, CRC errorBộ nhớ: Not enough free memory, fragments too smallThực hiện testcases dương trước, sau đó thực hiện test cases âm.Qui trình kiểm thử*ThS Nguyễn Quốc Huy - ĐHSG*Test Plans và Test CasesRegression và Kiểm thử chức năng mớiTiêu chuẩn bắt đầu/kết thúc kiểm thửKiểm soát phiên bảnLưu vết lỗiQui trình kiểm thử*ThS Nguyễn Quốc Huy - ĐHSG*Kiểm chức năng mới: Kiểm chức năng mới được thêm vào so với chu kì trướcKiểm Regression: Kiểm lại chức năng “cũ” ngẫu nhiên để đảm bảo không có chức năng nào bị hỏngQui trình kiểm thử*ThS Nguyễn Quốc Huy - ĐHSG*Kiểm chức năng mới: Phần trăm khối lượng công việc thường ítKiểm Regression: Khối lượng công việc tăng khi mỗi chức năng mới thêm vào; dễ tiêu thụ hết nguồn lực kiểm thửQui trình kiểm thử Độ ưu tiên của kiểm Regression*ThS Nguyễn Quốc Huy - ĐHSG*Kiểm tra bug đó thực sự được sửa chưaKiểm tra các bug liên quanKiểm tra việc sửa là không ảnh hưởng cái gì khácTesting Computer Software, Kaner, Falk, NguyenQui trình kiểm thử*ThS Nguyễn Quốc Huy - ĐHSG*Test Plans và Test CasesRegression và Kiểm thử chức năng mớiTiêu chuẩn bắt đầu/kết thúc kiểm thửKiểm soát phiên bảnLưu vết lỗiQui trình kiểm thửTiêu chuẩn bắt đầu/kết thúc*ThS Nguyễn Quốc Huy - ĐHSG*Qui trình kiểm thử*ThS Nguyễn Quốc Huy - ĐHSG*Tiêu chuẩn bắt đầu kiểm thửDanh sách các chức năng đã định nghĩa & hoàn thànhHoàn thành kiểm tra mã, tài liệuViệc phân tích tĩnh hoàn thànhTài liệu người dùng bản nháp sẵn sàngHoàn thành Unit testXem chuẩn có đạt không? Nếu có, thì thực hiện đúng thời hạn. Nếu không, sẽ thực hiện trễ hạn.Đo số lượng và mức độ nghiêm trọng của bug tìm thấy từ khi bắt đầu:. Nếu bugs vượt quá giới hạn, thì sẽ trả lại sản phẩm, việc kiểm thử sẽ trễ hạn.Qui trình kiểm thử*ThS Nguyễn Quốc Huy - ĐHSG*Tiêu chuẩn kết thúcSản phẩn có an toàn cho người dùng, tính chất và dữ liệu? (“Đầu tiên, không gây hại”)Toàn bộ các thành viên trong đội test phải đồng ý?Kiểm thử: Ít nhất 1 chu kì kiểm thử đầy đủ có >75% tỷ lệ passKiểm Regression hoàn thành, >90% tỷ lệ passHoàn thành việc phân tích kiểm mã, >70% nắm bắt được mãKhông còn bug nào được mởHoàn thành việc kiểm tra cuối cùng bugs đã mởQui trình kiểm thử*ThS Nguyễn Quốc Huy - ĐHSG*Chuyển giao công việcKịch bản kiểm thử tự độngKế hoạch kiểm thử phiên bản cuối, test cases, test scriptsSố lượng lỗi, kết luậnXong các báo cáo kiểm traKiểm tra tài liệu hướng dẫn người dùngHuấn luyện hỗ trợ khách hàngQui trình kiểm thử*ThS Nguyễn Quốc Huy - ĐHSG*Một lời khuyênĐừng “đốt thời gian ban đầu” để chờ sản phẩm hoàn hảo, hoàn thành 100% mới kiểm. Bắt đầu ngay khi có thể.Bắt đầu viết mãViết mã xongBắt đầu kiểmKiểm xongBắt đầu kiểm chính thứcQui trình kiểm thử*ThS Nguyễn Quốc Huy - ĐHSG*Test Plans và Test CasesRegression và Kiểm thử chức năng mớiTiêu chuẩn bắt đầu/kết thúc kiểm thửKiểm soát phiên bảnLưu vết lỗiQui trình kiểm thử: Kiểm soát phiên bản*ThS Nguyễn Quốc Huy - ĐHSG*Kiểm soát phiên bản kiểm thử khi sản phẩm chưa xongKiểm thử tập trung vào một nguồn trung tâm cho sản phẩmKiểm soát phiên bản cho các kế hoạch kiểm, test cases, test scriptsLưu vết những gì đã kiểm trên bất kì phiên bản phần mềm & phần cứngQui trình kiểm thử: Kiểm soát phiên bản*ThS Nguyễn Quốc Huy - ĐHSG*CVS - Concurrent Versions SystemRCS - Revision Control SystemSubversionClearcase - Rational SoftwarePVCS - MerantQui trình kiểm thử*ThS Nguyễn Quốc Huy - ĐHSG*Test Plans và Test CasesRegression và Kiểm thử chức năng mớiTiêu chuẩn bắt đầu/kết thúc kiểm thửKiểm soát phiên bảnLưu vết lỗiLưu vết lỗi*ThS Nguyễn Quốc Huy - ĐHSG*Thoả thuận mức độ nghiêm trọng của bug, trước khi dự án bắt đầu.Chất lượng đặt hàng đầu – nếu có vấn đề gì, đó là trách nhiệm của bạn khi báo cáo bug.Có cuộc họp xét lại bug hàng tuần.Lưu vết lỗi*ThS Nguyễn Quốc Huy - ĐHSG*BugzillaGNATSDebian Bug Tracking SystemClear DDTS – Rational SoftwareSilkRadar – Segue Softwareáo cáo Bug*ThS Nguyễn Quốc Huy - ĐHSG*TênMức độ nghiêm trọngĐầu vàoKết quả mong chờKết quả thựcQuan sát các bất thườngThông tin bug: Error logs, debug tracesNgày và giờCác bước tìm ra bugMôi trườngNgười kiểmNgười giám sátPhiên bản cuối cho passBáo cáo Bug*ThS Nguyễn Quốc Huy - ĐHSG*Tên bug là quan trọng nhất khi báo cáo– phải rõ ràng và chính xác!Tìm cách bẩy lỗi đơn giản nhất cho bugTìm hệ quả nghiêm trọng nhất của bugCố gắng xác định nếu bug là phần nổi của tảng băngLuôn luôn cho người viết mã cơ hội debug trong thời gian thực – sẽ giúp ít tốn thời gian hơnThống kê*ThS Nguyễn Quốc Huy - ĐHSG*