Giáo trình Công nghệ phần mềm - Chương 8: Kiểm thử phần mềm

Nội dung text: Giáo trình Công nghệ phần mềm - Chương 8: Kiểm thử phần mềm

1. Chương 8 KIỂM THỬ PHẦN MỀM 1
2. Mục đích  Sau buổi học sinh viên phải nắm được: — Hiểu các khái niệm: verification, valdation, và testing — Nắm được các nguyên lý về kiểm thử — Hiểu khái niệm ca kiểm thử (test case) — Các phương pháp thiết kế test case — Làm thế nào để kiểm thử chương trình — Làm thế nào để kiểm thử hệ thống 2
3. Nội dung  Giới thiệu — Verification,Validation, và Testing  Các nguyên lý về kiểm thử  Ca kiểm thử (test case)  Các kỹ thuật kiểm thử chương trình — Kiểm thử chức năng — Kiểm thử cấu trúc  Các giai đoạn và chiến lược kiểm thử 3
4. Tài liệu  Pressman, Software Engineering, McGraw Hill (chapter 18 & 19)  Sommerville, Software Engineering, Addison-Wesley (chapter 22 & 23)  Giáo trình kỹ nghệ phần mềm (chương 5)  Các tài liệu điện tử khác 4
5. Verification,Validation, và Testing  Verification –Kiểm chứng: "Are we building the product right": Chúng ta có xây dựng phần mềm một cách đúng đắn hay không?  Validation – Thẩm định: "Are we building the right product": Chúng ta có xây dựng đúng phần mềm được yêu cầu hay không? 5
6. Verification,Validation, và Testing  Kiểm chứng (Verification) — có đúng đặc tả không, có đúng thiết kế không — phát hiện lỗi lập trình  Thẩm định (Validation) — có đáp ứng nhu cầu người dùng không — có hoạt động hiệu quả không — phát hiện lỗi phân tích, lỗi thiết kế (lỗi mức cao)  V&V = Verification and Validation — mục tiêu là phát hiện và sửa lỗi PM, đánh giá tính dùng được của PM, tạo sự tự tin về phần mềm đạt được mục tiêu đề ra  Thứ tự thực hiện: Verification -> Validation 6
7. Kiểm chứng/Thẩm định tĩnh và động • Kiểm chứng, thẩm định tĩnh — không thực hiện chương trình — xét duyệt yêu cầu, thiết kế, mã nguồn — tiến hành ở mọi công đoạn phát triển — khó đánh giá tính hiệu quả của sản phẩm  Kiểm chứng/Thẩm định động (kiểm thử - Testing) — thực hiện chương trình — cần có mã nguồn — phát hiện lỗi lập trình — đánh giá tính hiệu quả phần mềm — là cách duy nhất để kiểm tra yêu cầu phi chức năng 7
8. Mô hình phát triển “V” Đặc tả Đặc tả hệ Thiết kế hệ Thiết kế chi yêu cầu thống thống tiết Kế Kế hoạch Kế hoạch Mã hóa mô hoạch kiểm thử kiểm thử tích đun & kiểm kiểm thử tích hợp hợp HT con thử mô đun chấp HT nhận Kiểm thử tích Kiểm thử Kiểm thử tích Dịch hợp các hệ chấp nhận hợp hệ thống vụ thống con 8
9. Kiểm thử phần mềm (Testing)  Tập các hoạt động với mục đích khám phá các lỗi và khiếm khuyết  KTPM là quá trình thực thi một hệ thống phần mềm để xác định xem phần mềm đó có đúng với đặc tả không và thực hiện trong môi trường mong đợi không  KTPM thực hiện: - 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 phần mềm đã phát triển hoàn tất 9
10. Kiểm thử phần mềm (Testing)  Mục đích của kiểm thử: — Thiết kế các ca kiểm thử (test cases) với khả năng tìm kiếm các lỗi/khuyết tật — Thực hiện chương trình với mục đích tìm các lỗi/khuyết tật  Mỗi phép kiểm thử chỉ thành công khi — một lỗi được phát hiện — một kết quả chỉ ra sự thất bại của thủ tục kiểm thử được trả lại 10
11. Yêu cầu đối với kiểm thử  Tính lặp lại — kiểm thử phải lặp lại được (kiểm tra xem lỗi đã được sửa hay chưa) — dữ liệu/trạng thái phải mô tả được  Tính hệ thống — đảm bảo kiểm tra hết các trường hợp  Được lập tài liệu — kiểm soát tiến trình/kết quả 10
12. Các nguyên lý kiểm thử PM  Các phép kiểm thử phải tương ứng với các yêu cầu của HT  Mỗi phép kiểm thử nên được lập kế hoạch từ rất sớm trước khi tiến hành kiểm thử 12
13. 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 13
14. Kiểm thử và gỡ rối  Kiểm thử và gỡ rối là hai công việc phân biệt  Kiểm thử nhằm phát hiện sự tồn tại của lỗi  Gỡ rối nhằm định vị và sửa chữa mã gây lỗi  Gỡ rối bao gồm việc sinh ra các giả thiết về hoạt động của chương trình và kiểm thử chương trình để tìm lỗi 14
15. 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ế 15
16. Các kỹ thuật kiểm thử chương trình  Kiểm thử chức năng (functional testing)/ Kiểm thử hộp đen — Dựa trên đặc tả chức năng — Phát hiện các sai sót về chức năng — Không quan tâm đến cách cài đặt  Kiểm thử cấu trúc (structured testing)/kiểm thử hộp trắng — Kiểm thử có nghiên cứu mã nguồn — Phân tích thứ tự thực hiện các lệnh 16
17. Các kỹ thuật kiểm thử chương trình 17
18. Kiểm thử hôp đen (Black box Testing) Người kiểm thử không quan tâm dến cấu trúc bên trong của chương trình Chỉ quan tâm tới dữ liệu đầu vào – đầu ra sau khi được xử lý Chỉ tập trung vào kiểm tra chức năng phần mềm Không quan tâm đến mã lệnh Black box testing Căn cứ vào tài liều đặc tả, phân tích thiết kế để Test Thường do các Tester thực hiện 18
19. Kiểm thử hôp đen (Black box Testing) So sánh với kết quả mong đợi xem chương trình có đáp ứng yêu cầu không 19
20. Kiểm thử hôp trắng (White box Testing) 20
21. Kiểm thử hôp trắng (White box Testing) Khi thiết kế test case và test, các tester truy cập thẳng vào bên trong source code, cấu trúc và thuật toán của chương trình đề xác định xem đơn vị PM thực hiện như thế nào? Người kiểm thử phải có kỹ năng nhất định để thông hiểu chi tiết về đoạn code cần kiểm thử Kỹ thuật này chủ yếu được dùng để kiểm thử ở mức đơn vị 21
22. Kiểm thử hôp trắng (White box Testing)  Có những lỗi xảy ra trong quá trình gõ sai phím, hiểu sai,cú pháp NNLT chưa đúng nên bắt buộc phải kiểm thử hộp trắng  Thường được các Dev thực hiện trong quá trình viết code ở giai đoạn kiểm thử đơn vị Nguyên nhân: Khi hệ thống được tích hợp hoàn chỉnh việc kiểm thử hộp trắng rất phức tạp và mất thời gian Chú ý: Không phải dev nào cũng đồng ý cho phép tester join vào cấu trúc dữ liệu để test 22
23. Kiểm thử hôp xám (Gray box Testing)  Là kỹ thuật kiểm thử kết hợp giữa kiểm thử hộp đen và kiểm thử hộp trắng Chúng ta quan tâm đến dữ liệu đầu vào và đầu ra song đòi hỏi có sự truy cập tới cấu trúc dữ liệu Mục đích: Nhằm tìm ra tối đa số lỗi về cấu trúc dữ liệu của hộp trắng cũng như lỗi chức năng của hộp đen. 23
24. Kiểm thử hôp xám (Gray box Testing) 24
25. Phân biệt kiểm thử Alpha và Beta Kiểm thử Alpha  Thực hiện ngay từ khi phần mềm được xây dựng  Khi một phần ềm nào đó phát triển sắp hoàn thiện nhưng có sự thay đổi dù là nhỏ trong thiết kế cũng có thể phát sinh lỗi  Do đó kiểm thử Alpha rất quan trọng nhằm hoàn thện PM trước khi bàn giao cho khách hàng  Thường do Tester đảm nhiệm kiểm thử 25
26. Phân biệt kiểm thử Alpha và Beta Kiểm thử Beta  Là bước kiểm thử mà về cơ bản các bước phát triển cũng như kiểm thử trước đó đã hoàn thành  Quá trình tiến hành thử lần cuối nhằm tìm ra lỗi cũng như kiểm chứng các ràng buộc trước khi công bố và tiến hành phân phối sản phẩm  Thường do khách hàng kiểm thử để nghiệm thu sản phâm( có thể tester ghi nhận lỗi phát sinh để dev xử lý) 26
27. Khái niệm Bug 27
28. Khái niệm Bug  Trong phần mềm, Bug dùng để chỉ một lỗi nhỏ (lớn) trong quá trình kiểm thử phần mềm  Việc tìm ra bug khiến cho PM càng được hoàn chỉnh, tránh sai sót tối đa khi đưa PM ứng dụng vào thực tế  Bug phát hiện được cần phải liên hệ và phân công cho Dev chịu trách nhiệm sửa lỗi này 28
29. Khái niệm Bug Khi Bug lỗi cần:  Thông tin đầy đủ để Dev có thể hiểu được lỗi  Tester cho ý kiến về mức độ dự án để xác định mức độ nghiêm trọng của lỗi để fix lỗi  Xác định được lỗi ở chỗ nào  Có thể tái hiện lỗi khi cần  Mô tả các bước cần để tái hiện bug 29
30. Khái niệm Bug Bug là một khiếm khuyết trong một thành phần hoặc hệ thống mà nó có thể làm cho thành phần hoặc hệ thống này không thực hiện đúng chức năng yêu cầu của nó Ví dụ: Thông báo sai hoặc định nghĩa dữ liệu không đúng. 30
31. Khái niệm Bug Ví dụ minh họa 31
32. Khái niệm Bug Việc phát hiện ra Bug có thể xảy ra theo các trường hợp sau: Phần mềm không thực hiện một số việc giống như mô tả trong bản đặc tả phần mềm Ví dụ: Khách hàng muốn PM thực hiện công việc phân loại hồ sơ ( Mới tạo, chờ xét duyệt, Đã duyệt) Phần mềm thực hiện một số việc mà bản đặc tả yêu cầu nó không được thực hiện Ví dụ: Khách hàng khống muốn PM thực hiện công việc xác nhận chữ ký xét duyệt hồ sơ đã hoàn thành) Phần mềm thực hiện một số chức năng mà bản đặc tả không đề cập tới Khó với người sử dụng 32
33. Các giai đoạn kiểm thử 33
34. Kiểm thử đơn vị (Unit testing) • Một Unit là một thành phần nhỏ nhất của phần mềm mà ta có thể kiểm tra được - Lớp - Các hàm - Thủ tục - Phương thức > thực hiện các câu lệnh trong phần mềm -Người thực hiện: Lập trình viên 34
35. Yêu cầu của Unit test  Đòi hỏi tất cả các nhánh bên trong Unit đều phải được kiểm tra để phát hiện lỗi phát sinh  Phải chuẩn bị trước các tình huống kiểm thử trong đó chỉ định rõ dữ liệu vào, các bước thực hiện và dữ liệu mong chờ xuất ra 35
36. Kiểm thử tích hợp (Intergration testing) Kiểm thử tích hợp các unit lại để ra một trường hợp kiểm thử Ví dụ: Có các chức năng A, B, C, D. Hỏi có bao nhiêu trường hợp có thể kiểm thử? (15 trường hợp) A, B, C, D, AB, AC, AD, BC, BD, CD, ABC, ABD, BCD, ACD, ABCD Khi kiểm thử phải quét hết tất cả các trường hợp 36
37. Kiểm thử tích hợp (Intergration testing) Intergrationg test có 2 mục tiêu chính: - Phát hiện lỗi giao tiếp xảy ra giữa các unit không? - Tích hợp các Unit đơn lẻ thành các hệ thống nhỏ và cuối cùng là hoàn chỉnh hệ thống để chuẩn bị cho kiểm tra ở mức độ hệ thống 37
38. Kiểm thử tích hợp Intergration testing Ví dụ: Kết hợp 2 thao tác 38
39. Kiểm thử tích hợp Intergration testing •Tại sao nên tích hợp dần từng Unit? Một Unit khi được tích hợp vào một nhóm Unit khác đã tích hợp trước đó thì lúc này, chỉ kiểm tra giao tiếp của Unit mới thêm vào với nhóm các Unit đã được tích hợp trước đó • Người thực hiện tích hợp: Lập trình viên 39
40. Kiểm thử tích hợp Intergration Testing •Có 4 loại kiểm tra trong Intergration Test 40
41. Kiểm thử tích hợp (Intergration Testing) •Có 4 loại kiểm tra trong Intergration Test 1. Kiểm tra cấu trúc – Structure •Tương tự như White Box Testing •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 thành phần cấu trúc của chương trình 1. Kiểm tra chức năng – functional •Tương tự Black Box Testing • Kiểm tra chỉ chú trọng đến chức năng chương trình 41
42. Kiểm thử tích hợp (Intergration Testing) • Có 4 loại kiểm tra trong Intergration Test 1. Kiểm tra hiệu năng ( Performance Test) - Kiểm tra các giới hạn ( sử dụng tài nguyên) của hệ thống - Cách kiểm tra: Click chuột phải vào thanh công cụ Task Manager 2. Kiểm tra khả năng chịu tải ( Stress Test) Là kiểm tra vận hành của hệ thống. Ngưỡng tối đa là bao nhiêu, thường kiểm tra hệ thống web. 42
43. Kiểm thử hệ thống (System Testing) Mục đích là 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? Phải thực hiện Unit Test và Integration Test để đảm bảo mọi Unit và sự tương tác giữa chúng hoạt động chính xác trước khi thực hiện System Test 43
44. Kiểm thử hệ thống (System Testing)  Đặc điểm kiểm tra hệ thống - Tốn rất nhiều công sức - Mất nhiều thời gian Bởi vì trọng tâm là đánh giá về hoạt động, thao tác, sự tin cậy và các yêu cầu khác liên quan đến chất lượng củ toàn hệ thống. 44
45. Kiểm thử hệ thống (System Testing) Ví dụ: Hệ thống quản lý thông tin sinh viên trường đại học có các chức năng chính sau: 1. Nhập dữ liệu sinh viên trúng tuyển vào hệ thống 2. Gọi nhập học và phân lớp 3. Quản lý thông tin sinh viên, kết quả học tập, điểm thi 4. Xét tốt nghiệp 1=>2=>3=>4. Test từng chức năng, sau đó kiểm tra theo luồng xem có lỗi không và lặp lại quá trình đó. 45
46. Kiểm thử hệ thống (System Testing) Sự khác nhau giữa Integration Test và System Test •System Test: Chú trọng các hành vi và phát sinh lỗi trên toàn hệ thống •Integration Test: Chú trọng sự giao tiếp giữa các đơn thể (Unit) khi chúng làm việc cùng nhau - Người thực hiện test hệ thống thường là kiểm thử viên - Một hoặc nhóm kiểm thử viên test hoàn toàn độc lập so với nhóm phát triển dự án. 46
47. Kiểm thử hệ thống (System Testing) Các hoạt động kiểm thử hệ thống -Kiểm tra chức năng -Kiểm tra hiệu năng -Kiểm tra khả năng chịu tải -Kiểm tra cấu hình -Kiểm tra khả năng bảo mật -Kiểm tra khả năng phục hồi Sau giải đoạn System Test, PM thường đã sẵn sàng cho khách hàng hoặc người dùng cuối cùng kiểm tra để chấp nhận sản phầm 47
48. Kiểm thử hệ thống (System Testing) Lưu ý: Không nhất thiết thực hiện kiểm tra tất cả các loại nêu trên mà sẽ o Tùy yêu cầu và đặc trưng của từng hệ thống o Tùy khả năng và thời gian cho phép của dự án, khi lập kế hoạch, trưởng dự án sẽ quyết định áp dụng những loại kiểm tra nào. 48
49. Kiểm thử chấp nhận (Acceptance Testing)  Còn gọi là kiểm thử nghiệm thu  Thường được khách hàng thực hiện hoặc ủy quyền cho một nhóm thứ 3 có nghiệp vụ thực hiện Lưu ý: Một phần mềm đã thực hiện tốt qua các phép kiểm tra sau cùng vẫn thất vọng vì - Bố cục màn hình nghèo nàn - Thao tác không tự nhiên - Không theo tập quán sử dụng của khách hàng 49