Kiem tra phan mem
- 1. KIỂM TRA PHẦN MỀM LÀ GÌ? “Chạy thử" PM hay một chức năng của PM, xem nó "chạy" đúng như mong muốn hay không Có thể thực hiện từng chặng, sau mỗi chức năng hoặc module được phát triển, hoặc thực hiện sau cùng, khi PM đã được phát triển hoàn tất(PM nhỏ) Bước đệm giữa giai đoạn xây dựng PM và sử dụng PM, trước khi giao sản phẩm hoàn chỉnh cho khách hàng
- 2. Các hình thức kiểm tra PM
- 3. Test case & Test Script • Testcase: Một tình huống kiểm tra, được thiết kế để kiểm tra một đối tượng có thỏa mãn yêu cầu đặt ra hay không – Mô tả: Đặc tả các điều kiện cần có để tiến hành kiểm tra – Input: Dữ liệu đầu vào – Output: Kết quả trả về mong muốn
- 4. Test case & Test Script • Test Script: Một nhóm mã lệnh tự động hóa một trình tự kiểm tra, giúp cho việc kiểm tra nhanh hơn, hoặc cho những trường hợp mà kiểm tra bằng tay sẽ rất khó khăn hoặc không khả thi. – Các Test Script có thể tạo thủ công hoặc tạo tự động dùng công cụ kiểm tra tự động.
- 5. Unit Test – Kiểm tra mức đơn vị • Unit: Một thành phần PM nhỏ nhất mà ta có thể kiểm tra được: Function, Procedure, Class, Method... • Do lập trình viên thực hiện và càng sớm càng tốt trong giai đoạn viết code và xuyên suốt chu kỳ PTPM • Unit Test đòi hỏi phải chuẩn bị trước các test case hoặc test script, trong đó chỉ định rõ dữ liệu vào, các bước thực hiện và dữ liệu mong chờ sẽ xuất ra
- 6. Unit Test – Kiểm tra mức đơn vị • Mục đích: Bảo đảm thông tin được xử lý và xuất (khỏi Unit) là chính xác • Thời gian tốn cho Unit Test sẽ được đền bù bằng việc tiết kiệm rất nhiều thời gian và chi phí cho việc kiểm tra và sửa lỗi ở các mức kiểm tra sau đó
- 7. Integration Test – Kiểm tra tích hợp • Kết hợp các thành phần của một ứng dụng và kiểm tra như một ứng dụng đã hoàn thành • Kết hợp các thành phần lại với nhau và kiểm tra sự giao tiếp giữa chúng • Mục tiêu: – Phát hiện lỗi giao tiếp xảy ra giữa các Unit – chuẩn bị cho kiểm tra ở mức hệ thống (System Test).
- 8. Integration Test – Kiểm tra tích hợp • Mọi giao tiếp liên quan đến Unit thật sự được kiểm tra đầy đủ khi các Unit tích hợp với nhau trong khi thực hiện Integration Test • Chỉ nên thực hiện trên những Unit đã được kiểm tra cẩn thận trước đó bằng Unit Test, và tất cả các lỗi mức Unit đã được sửa chữa
- 9. Integration Test – Kiểm tra tích hợp • Nên tích hợp dần từng Unit. Một Unit tại một thời điểm được tích hợp vào một nhóm các Unit khác đã tích hợp trước đó và đã hoàn tất các đợt Integration Test trước đó
- 10. Integration Test – Kiểm tra tích hợp • Các loại: – Kiểm tra cấu trúc: (Tương tự White Box Test) • Nhằm bảo đảm các thành phần bên trong của một chương trình chạy đúng • Chú trọng đến hoạt động của các thành phần cấu trúc của chương trình chẳng hạn các lệnh và nhánh bên trong – Kiểm tra chức năng (Tương tự Black Box Test ) • Kiểm tra chỉ chú trọng đến chức năng của chương trình, không quan tâm đến cấu trúc bên trong • Chỉ khảo sát chức năng của chương trình theo yêu cầu kỹ thuật. – Kiểm tra hiệu năng (Performance): Kiểm tra việc vận hành của hệ thống – Kiểm tra khả năng chịu tải(stress):Kiểm tra các giới hạn của hệ thống
- 11. System Test - Kiểm tra mức hệ thống • Kiểm tra thiết kế và toàn bộ hệ thống (sau khi tích hợp) có thỏa mãn yêu cầu đặt ra hay không • Bắt đầu khi tất cả các bộ phận của PM đã được tích hợp thành công • Các hình thức (không nhất thiết phải thực hiện tất cả các hình thức) – Kiểm tra chức năng (Functional Test) – Kiểm tra khả năng vận hành (Performance Test) – Kiểm tra khả năng chịu tải (Stress Test hay Load Test) – Kiểm tra cấu hình (Configuration Test) – Kiểm tra khả năng bảo mật (Security Test) – Kiểm tra khả năng phục hồi (Recovery Test)
- 12. System Test - Kiểm tra mức hệ thống • Kiểm tra chức năng (Functional Test) – Bảo đảm các hành vi của hệ thống thỏa mãn đúng yêu cầu thiết kế • Kiểm tra khả năng vận hành – Bảo đảm tối ưu việc phân bổ tài nguyên hệ thống (ví dụ bộ nhớ) nhằm đạt các chỉ tiêu như thời gian xử lý hay đáp ứng câu truy vấn • Kiểm tra khả năng chịu tải (Stress Test hay Load Test) – bảo đảm hệ thống vận hành đúng dưới áp lực cao – tập trung vào các trạng thái tới hạn, các "điểm chết", các tình huống bất thường
- 13. System Test - Kiểm tra mức hệ thống • Kiểm tra cấu hình (Configuration Test) – Bảo đảm tính toàn vẹn, bảo mật của dữ liệu và của hệ thống. • Kiểm tra khả năng bảo mật • Kiểm tra khả năng phục hồi – Bảo đảm hệ thống có khả năng khôi phục trạng thái ổn định trước đó trong tình huống mất tài nguyên hoặc dữ liệu; – Đặc biệt quan trọng đối với các hệ thống giao dịch như ngân hàng trực tuyến
- 14. Acceptance Test - Kiểm tra nhận sản phẩm • Khách hàng thực hiện (hoặc ủy quyền cho một nhóm thứ ba thực hiện). • Mục đích: chứng minh PM thỏa mãn tất cả yêu cầu của khách hàng và khách hàng chấp nhận sản phẩm.
- 15. Quy trình test PM
- 16. Lập kế hoạch kiểm tra • Mục đích: Chỉ định và mô tả các loại kiểm tra sẽ được triển khai và thực hiện. • Thời diểm:Khi các yêu cầu đã tương đối đầy đủ, các chức năng và luồng dữ liệu chính đã được mô tả
- 17. Lập kế hoạch kiểm tra • Kết quả : Tài liệu kế hoạch KTPM (master test plan) – Chi tiết từ các loại kiểm tra – Chiến lược kiểm tra – Thời gian và phân bổ kiểm tra viên • Các bản kế hoạch chi tiết lần lượt được thiết kế theo trình tự thời gian phát triển của dự án
- 18. Lập kế hoạch kiểm tra
- 19. Các bước lập kế hoạch • Xác định yêu cầu kiểm tra: – Bộ phận, thành phần của PM cần kiểm tra – Phạm vi hoặc giới hạn của việc kiểm tra – Xác định nhu cầu nhân lực • Khảo sát rủi ro – Rủi ro xảy ra làm chậm hoặc cản trở quá trình cũng như chất lượng kiểm tra(kỹ năng và kinh nghiệm của kiểm tra viên ) • Chiến lược kiểm tra – Phương pháp tiếp cận để thực hiện việc kiểm tra trên PM – Kỹ thuật và công cụ hỗ trợ kiểm tra – Phương pháp dùng để đánh giá chất lượng kiểm tra cũng như điều kiện để xác định thời gian kiểm tra
- 20. Các bước lập kế hoạch • Xác định nguồn lực – kỹ năng, kinh nghiệm của kiểm tra viên – phần cứng, phần mềm, công cụ, thiết bị giả lập • Lập kế hoạch chi tiết – Ước lượng thời gian, khối lượng công việc – Xác định chi tiết các phần công việc, người thực hiện – Thời gian tất cả các điểm mốc của quá trình kiểm tra.
- 21. Các bước lập kế hoạch • Tổng hợp và tạo các bản kế hoạch kiểm tra: – kế hoạch chung và kế hoạch chi tiết. • Xem xét các kế hoạch kiểm tra – Có sự tham gia của tất cả những người có liên quan – Bảo đảm các kế hoạch là khả thi, phát hiện và sữa chữa các sai sót trong các bản kế hoạch
- 22. Thiết kế Test • Mục đích: – Chỉ định các Test Case và các bước kiểm tra chi tiết cho mỗi phiên bản PM – Bảo đảm tất cả các tình huống kiểm tra “quét” hết tất cả yêu cầu cần kiểm tra • Sửa chữa, cập nhật, thêm hoặc bớt xuyên suốt chu kỳ PTPM, vào bất cứ lúc nào có sự thay đổi yêu cầu, hoặc sau khi phân tích thấy cần được sửa chữa hoặc bổ sung
- 23. Các bước thiết kế test • Xác định và mô tả Test Case – Xác định các điều kiện cần thiết lập trước và trong lúc kiểm tra – Mô tả đối tượng hoặc dữ liệu đầu vào – Mô tả các kết quả mong chờ sau khi kiểm tra • Mô tả các bước chi tiết để kiểm tra – mô tả chi tiết để hoàn thành một Test Case – chỉ định các loại dữ liệu nào cần có để thực thi các Test Case (trực tiếp, gián tiếp, trung gian, hệ thống…)
- 24. Các bước thiết kế test • Xem xét và khảo sát độ bao phủ của việc kiểm tra – xác định việc kiểm tra đã hoàn thành hay chưa? – bao nhiêu phần trăm PM đã được kiểm tra => căn cứ trên yêu cầu của phần mềm hoặc căn cứ trên số lượng code đã viết • Xem xét Test Case và các bước kiểm tra – có sự tham gia của tất cả những người có liên quan, kể cả trưởng dự án nhằm bảo đảm các Test Case và dữ liệu yêu cầu là đủ và phản ánh đúng các yêu cầu cần kiểm tra, độ bao phủ đạt yêu cầu, cũng như để phát hiện (và sữa chữa) các sai sót
- 25. Các bước thiết kế test
- 26. Phát triển Test Script • Mục đích: Tạo ra các Test Script có khả năng chạy trên máy tính giúp tự động hóa việc thực thi các bước kiểm tra đã định nghĩa ở bước thiết kế test • Không bắt buộc trong
- 27. Các bước phát triển Test Script • Tạo Test Script – thủ công – công cụ hỗ trợ để phát sinh script một cách tự động – có khả năng tái sử dụng càng nhiều càng tốt để tối ưu hóa công việc • Chỉnh sửa – chỉnh sửa từ test script có sẳn hoặc sinh bằng công cụ
- 28. Các bước phát triển Test Script • Thành lập các bộ dữ liệu ngoài dành cho các Test Script – bộ dữ liệu này sẽ được các Test Script sử dụng khi thực hiện kiểm tra tự động – Việc tách riêng dữ liệu cho phép dễ dàng thay đổi dữ liệu khi kiểm tra, cũng như giúp việc chỉnh sửa hoặc tái sử dụng các script sau này
- 29. Các bước phát triển Test Script • Kiểm tra Test script – bảo đảm các Test Script hoạt động đúng yêu cầu – thể hiện đúng ý đồ của các bước kiểm tra • Xem xét và khảo sát độ bao phủ của việc kiểm tra – bảo đảm các Test Script được tạo ra bao phủ toàn bộ các bước kiểm tra theo yêu cầu
- 30. Thực hiện kiểm tra • Cách thức : – Thủ công – Test Script • Đánh giá quá trình kiểm tra: – giám sát quá trình kiểm tra suôn sẻ – bổ sung hay sữa chữa để quá trình kiểm tra được tốt hơn – Nếu quá trình diễn ra trơn tru, kiểm tra viên hoàn thành chu kỳ kiểm tra và chuyển qua bước “Thẩm định kết quả kiểm tra” – Nếu quá trình bị treo hoặc dừng giữa chừng, kiểm tra viên cần phân tích để xác định nguyên nhân lỗi, khắc phục lỗi và lập lại quá trình kiểm tra.
- 31. Thực hiện kiểm tra • Thẩm định kết quả kiểm tra • Xem xét để bảo đảm kết quả nhận được là đáng tin cậy • Những lỗi xảy ra không phải do PM mà do dữ liệu dùng để kiểm tra, môi trường kiểm tra hoặc các bước kiểm tra (hoặc Test Script) • Lỗi xảy ra do quá trình kiểm tra, cần phải sửa chữa và kiểm tra lại từ đầu
- 32. Đánh giá quá trình kiểm tra • Mục đích: Đánh giá toàn bộ quá trình kiểm tra – xem xét và đánh giá kết quả kiểm tra – liệt kê lỗi, – chỉ định các yêu cầu thay đổi, – tính toán các số liệu liên quan đến quá trình kiểm tra • Đánh giá kết quả kiểm tra toàn cục, nhằm vào bản thân giá trị của các kết quả kiểm tra