Bài giảng Công nghệ phần mềm - Chương 6: Kiểm thử phần mềm - Dương Thành Phết

Nội dung text: Bài giảng Công nghệ phần mềm - Chương 6: Kiểm thử phần mềm - Dương Thành Phết

1. TRƢỜNG ĐẠI HỌC NGUYỄN TẤT THÀNH KHOA CÔNG NGHỆ THÔNG TIN CÔNG NGHỆ PHẦN MỀM Chƣơng 6: KIỂM THỬ PHẦN MỀM Thời gian: 6 tiết Giảng viên: ThS. Dƣơng Thành Phết Email: phetcm@gmail.com Website: Tel: 0918158670 – facebook com/DuongThanhPhet 1
2. NỘI DUNG 1. Mục đích 2. Nguyên tắc kiểm thử 3. Kiểm thử theo đường cơ bản 4. Kiểm thử theo phân vùng tương đương 5. Kiểm thử theo giá trị biên 6. Các mức độ kiểm thử 2
3. 1. MỤC ĐÍCH (TESTING OBJECTIVES)  Kiểm thử phần mềm là hoạt động khảo sát thực tiễn sản phẩm phần mềm trong môi trường dự định sẽ được triển khai  Nhằm cung cấp cho người có lợi ích liên quan những thông tin về chất lượng của sản phẩm hay dịch vụ phần mềm đó.  Mục đích của kiểm thử phần mềm là tìm ra các lỗi hay khiếm khuyết phần mềm nhằm đảm bảo hiệu quả hoạt động tối ưu của phần mềm. 3
4. 2. NGUYÊN TẮC KIỂM THỬ  Kiểm thử không phải là gỡ rối (Debugging)  Kiểm thử không thể phát hiện hoàn toàn 100% lỗi  Mục đích của kiểm thử là tìm ra lỗi chứ không phải nguyên nhân gây ra lỗi. 4
5. 3. KIỂM THỬ THEO ĐƢỜNG CƠ BẢN  Các đường dẫn được xác định bằng việc xây dựng đồ thị chương trình.  Mỗi trường hợp kiểm thử sẽ tương ứng với một đường dẫn.  Ta có thể gặp vấn đề đối với các đường dẫn không thể thực hiện được. 5
6. 3. KIỂM THỬ THEO ĐƢỜNG CƠ BẢN Đồ thị chƣơng trình  Đồ thị chương trình là một đồ thị có hướng trong đó: + Các đỉnh của đồ thị biểu diễn các câu lệnh + Các cạnh biểu diễn luồng điều khiển  Nghĩa là, có một cạnh từ đỉnh i đến đỉnh j nếu câu lệnh tương ứng với đỉnh j có thể được thực thi ngay lập tức sau câu lệnh tương ứng với đỉnh i. 6
7. 3. KIỂM THỬ THEO ĐƢỜNG CƠ BẢN Đồ thị chương trình của bài toán tam giác: 7
8. 3. KIỂM THỬ THEO ĐƢỜNG CƠ BẢN Một số định nghĩa Chuỗi: là một đường dẫn mà trong đó đỉnh bắt đầu và đỉnh kết thúc là khác nhau, và các đỉnh ở bên trong có bậc vào =1 và bậc ra =1 8
9. 3. KIỂM THỬ THEO ĐƢỜNG CƠ BẢN Các bƣớc thực hiện:  Xây dựng đồ thị chương trình/đồ thị đường dẫn quyết định từ mã nguồn  Tính độ phức tạp của đồ thị  Xác định một tập hợp các đường dẫn cơ bản  Thiết kế một trường hợp kiểm thử tương ứng với mỗi đường dẫn cơ bản Thực thi các trường hợp kiểm thử 9
10. 3. KIỂM THỬ THEO ĐƢỜNG CƠ BẢN  Một đường dẫn cơ bản là đường dẫn nối từ đỉnh bắt đầu đến đỉnh kết thúc.  Số lượng các đường dẫn độc lập cần được kiểm thử bằng giá trị V(G) = e-n+2*p .  Trong đó:  G là đồ thị đường dẫn quyết định  V(G) là độ phức tạp của đồ thị G  e là số cạnh, n là số đỉnh, p là số thành phần 10
11. 3. KIỂM THỬ THEO ĐƢỜNG CƠ BẢN Cách xác định các đƣờng dẫn cơ bản  Chọn một đường dẫn cơ bản ban đầu tương ứng với một sự thực thi chương trình bình thường (đường dẫn cơ bản này nên có càng nhiều đỉnh quyết định càng tốt)  Để tìm các đường dẫn cơ bản khác, dò tìm ngược/xuôi trên đường dẫn ban đầu cho đến khi gặp một đỉnh quyết định.  Thay đổi quyết định tại đỉnh này, và tiếp tục tìm đường dẫn khả thi cho đến đỉnh kết thúc 11
12. 3. KIỂM THỬ THEO ĐƢỜNG CƠ BẢN  Lặp lại bước trên cho đến khi tất cả các quyết định đều đã được thay đổi với nhánh đúng và sai 12
13. 3. KIỂM THỬ THEO ĐƢỜNG CƠ BẢN Các đường dẫn cơ bản trong bài toán tam giác 13
14. 3. KIỂM THỬ THEO ĐƢỜNG CƠ BẢN Các đường dẫn cơ bản khả thi 14
15. 3. KIỂM THỬ THEO ĐƢỜNG CƠ BẢN  Kiểm thử theo đường dẫn cơ bản dựa vào phương pháp của Tom McCabe.  Sử dụng đồ thị chương trình để xác định các trường hợp kiểm thử.  Kiểm thử theo đường dẫn cơ bản được sử dụng cho cấp độ kiểm thử đơn vị.  Có nhược điểm là người kiểm thử phải có kỹ năng lập trình đủ tốt để có thể hiểu được mã nguồn và luồng điều khiển trong chương trình 15
16. 4. KIỂM THỬ THEO PHÂN VÙNG TƢƠNG ĐƢƠNG  Xem xét về miền giá trị của các biến để chia thành các phạm vi tương đương  Bao gồm cả miền dữ liệu không đúng  Không quan tâm đến sự trùng lặp Ví dụ: Hãy xem xét một hàm F với các biến đầu vào x1, x2 có giá trị được giới hạn và nằm trong các khoảng sau:  a d and x2 g 16
17. 4. KIỂM THỬ THEO PHÂN VÙNG TƢƠNG ĐƢƠNG Các kiểu kiểm thử theo lớp tương đương:  Kiểm thử theo lớp tương đương- lỗi đơn  Kiểm thử theo lớp tương đương- lỗi kết hợp  Kiểm thử theo lớp tương đương- lỗi đơn đầy đủ  Kiểm thử theo lớp tương đương- lỗi kết hợp đầy đủ 17
18. 4. KIỂM THỬ THEO PHÂN VÙNG TƢƠNG ĐƢƠNG 4.1. Kiểm thử theo lớp tƣơng đƣơng- lỗi đơn  Sử dụng một biến từ mỗi lớp tương đương (hay một khoảng giá trị) trong một trường hợp kiểm thử  Dựa trên giả thiết lỗi đơn  Số lượng trường hợp kiểm thử bằng số lượng nhiều nhất các khoảng giá trị đúng mà một biến có thể nhận 18
19. 4. KIỂM THỬ THEO PHÂN VÙNG TƢƠNG ĐƢƠNG 4.2. Kiểm thử theo lớp tƣơng đƣơng- lỗi kết hợp  Không sử dụng giả thiết lỗi đơn  Mỗi trường hợp kiểm thử tương ứng với một phần tử của tích Đề các của các lớp tương đương 19
20. 4. KIỂM THỬ THEO PHÂN VÙNG TƢƠNG ĐƢƠNG 4.3. Kiểm thử theo lớp tƣơng đƣơng- lỗi đơn đầy đủ  Xem xét cả các giá trị không đúng với giả thiết lỗi đơn 20
21. 4. KIỂM THỬ THEO PHÂN VÙNG TƢƠNG ĐƢƠNG 4.4. Kiểm thử theo lớp tƣơng đƣơng- lỗi kết hợp đầy đủ  Xem xét cả các giá trị không đúng không sử dụng giả thiết lỗi đơn 21
22. 5. KIỂM THỬ THEO GIÁ TRỊ BIÊN  Khi một hàm chức năng F với hai biến x1 và x2 được cài đặt trong chương trình, các biến đầu vào x1 và x2 sẽ có các giới hạn: . a<=x1<=b . c<=x2<=d  Các đoạn [a,b] và [c,d] được gọi là các miền giá trị của x1 và x2  Giả thiết lỗi đơn  Các lỗi của chương trình ít khi được gây ra bởi hai hay nhiều biến cùng một lúc 22
23. 5. KIỂM THỬ THEO GIÁ TRỊ BIÊN  Ý tưởng chính của kiểm thử theo giá trị biên là sử dụng giá trị của biến đầu vào tại giá trị nhỏ nhất, lớn hơn giá trị nhỏ nhất, giá trị thông thường, giá trị lớn nhất, và nhỏ hơn giá trị lớn nhất  Kiểm thử theo giá trị biên với một biến:  Kiểm thử theo giá trị biên với hai biến: 23
24. 5. KIỂM THỬ THEO GIÁ TRỊ BIÊN Kiểm thử theo giá trị biên đầy đủ:  Là một mở rộng của kiểm thử theo giá trị biên bao gồm các giá trị nhỏ hơn giá trị nhỏ nhất và lớn hơn giá trị lớn nhất (cho phép vượt quá miền giá trị)  Là một hình thức kiểm thử với lỗi để biết được chương trình sẽ thực hiện như thế nào nếu dữ liệu vào có lỗi  Có thể không được áp dụng với một số ngôn ngữ lập 24 trình có ràng buộc kiểu
25. 5. KIỂM THỬ THEO GIÁ TRỊ BIÊN  Kiểm thử theo giá trị biên đầy đủ  Kiểm thử theo giá trị biên đầy đủ với hai biến 25
26. 5. KIỂM THỬ THEO GIÁ TRỊ BIÊN Kiểm thử theo giá trị biên xấu nhất (hai biến) Loại bỏ giả thiết chỉ có một lỗi đơn Cho phép các giá trị đầu vào có thể cùng nhận giá trị biên Số lượng trường hợp kiểm thử Kiểm thử theo giá trị biên: 4n+1 Kiểm thử theo giá trị biên đầy đủ: 6n+1 Kiểm thử theo giá trị biên xấu nhất: 5n Với n là số lượng các biến Nhược điểm của kiểm thử theo giá trị biên Các biến phải độc lập với nhau 26 Không áp dụng được cho các biến thuộc kiểu logic
27. 6. CÁC MỨC ĐỘ KIỂM THỬ  Các cấp độ của kiểm thử phản ánh cấp độ trong mô hình thác nước của vòng đời phát triển phần mềm.  Ba cấp độ: Đặc tả, Thiết kế cơ bản, Thiết kế chi tiết tương ứng với ba cấp độ của kiểm thử: kiểm thử đơn vị, kiểm thử tích hợp và kiểm thử hệ thống.  Thông thường, kiểm thử theo cấu trúc tương ứng với mức độ đơn vị, kiểm thử theo chức năng tương ứng với mức độ hệ thống 27
28. 6. CÁC MỨC ĐỘ KIỂM THỬ 6.1. Unit Test – Kiểm tra mức đơn vị  Một Unit là một thành phần phần mềm nhỏ nhất mà ta có thể kiểm tra được. Theo định nghĩa này, các hàm (Function), thủ tục (Procedure), lớp (Class), hoặc các phương thức (Method) đều có thể được xem là Unit.  Unit Test thường do lập trình viên thực hiện.  Công đoạn này được thực hiện càng sớm càng tốt trong giai đoạn viết code và xuyên suốt chu kỳ phát triển phần mềm.  Thông thường, Unit Test đòi hỏi kiểm tra viên có kiến thức về thiết kế và code của chương trình. 28
29. 6. CÁC MỨC ĐỘ KIỂM THỬ  Mục đích của Unit Test là bảo đảm thông tin được xử lý và xuất (khỏi Unit) là chính xác, trong mối tương quan với dữ liệu nhập và chức năng của Unit.  Điều này thường đò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 nhánh phát sinh lỗi.  Một nhánh thường là một chuỗi các lệnh được thực thi trong một Unit. Ví dụ: chuỗi các lệnh sau điều kiện If và nằm giữa then else là một nhánh. 29
30. 6. CÁC MỨC ĐỘ KIỂM THỬ  Thực tế việc chọn lựa các nhánh để đơn giản hóa việc kiểm tra và quét hết Unit đòi hỏi phải có kỹ thuật, đôi khi phải dùng thuật toán để chọn lựa.  Cũng như các mức kiểm tra khác, Unit Test cũng đòi hỏi phải chuẩn bị trước các tình huống (test case) hoặc kịch bản (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.  Các test case và script này nên được giữ lại để tái sử dụng 30
31. 6. CÁC MỨC ĐỘ KIỂM THỬ 6.2. Integration Test – Kiểm tra tích hợp  Integration test 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.  Trong khi Unit Test kiểm tra các thành phần và Unit riêng lẻ thì Intgration Test kết hợp chúng lại với nhau và kiểm tra sự giao tiếp giữa chúng.  Integration 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. . Tích hợp các Unit đơn lẻ thành các hệ thống nhỏ (subsystem) và cuối cùng là nguyên hệ thống hoàn chỉnh (system) chuẩn bị cho kiểm tra ở mức hệ thống (System Test). 31
32. 6. CÁC MỨC ĐỘ KIỂM THỬ  Trong Unit Test, lập trình viên cố gắng phát hiện lỗi liên quan đến chức năng và cấu trúc nội tại của Unit.  Có một số phép kiểm tra đơn giản trên giao tiếp giữa Unit với các thành phần liên quan khác, tuy nhiên 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.  Trừ một số ít ngoại lệ, 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. 32
33. 6. CÁC MỨC ĐỘ KIỂM THỬ  Một số người hiểu sai rằng Unit một khi đã qua giai đoạn Unit Test với các giao tiếp giả lập thì không cần phải thực hiện Integration Test nữa.  Thực tế việc tích hợp giữa các Unit dẫn đến những tình huống hoàn toàn khác.  Một chiến lược cần quan tâm trong Integration Test là 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 (passed) các đợt Integration Test trước đó.  Lúc này, ta chỉ cần kiểm tra giao tiếp của Unit mới thêm vào với hệ thống các Unit đã tích hợp trước đó, điều này làm cho số lượng kiểm tra sẽ giảm đi rất 33 nhiều, sai sót sẽ giảm đáng kể.
34. 6. CÁC MỨC ĐỘ KIỂM THỬ Có 4 loại kiểm tra trong Integration Test:  Kiểm tra cấu trúc (structure): Tương tự White Box Test (kiểm tra 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 nội tại 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 (functional): Tương tự Black Box Test (kiểm tra 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 34 hạn của hệ thống.
35. 6. CÁC MỨC ĐỘ KIỂM THỬ 6.3. System Test - Kiểm tra mức hệ thống  Mục đích System Test 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.  System Test bắt đầu khi tất cả các bộ phận của phần mềm đã được tích hợp thành công.  Thông thường loại kiểm tra này tốn rất nhiều công sức và thời gian.  Trong nhiều trường hợp, việc kiểm tra đòi hỏi một số thiết bị phụ trợ, phần mềm hoặc phần cứng đặc thù, đặc biệt là các ứng dụng thời gian thực, hệ thống phân bố, hoặc hệ thống nhúng. 35
36. 6. CÁC MỨC ĐỘ KIỂM THỬ  Ở mức độ hệ thống, người kiểm tra cũng tìm kiếm các lỗi, nhưng 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ủa toàn hệ thống.  Điểm khác nhau then chốt giữa Integration Test và System Test là System Test chú trọng các hành vi và lỗi trên toàn hệ thống, còn Integration Test chú trọng sự giao tiếp giữa các đơn thể hoặc đối tượng khi chúng làm việc cùng nhau.  Thông thường ta phải thực hiện Unit Test và Integration Test để bảo đảm 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. 36
37. 6. CÁC MỨC ĐỘ KIỂM THỬ  Sau khi hoàn thành Integration Test, một hệ thống phần mềm đã được hình thành cùng với các thành phần đã được kiểm tra đầy đủ.  Tại thời điểm này, lập trình viên hoặc kiểm tra viên (tester) bắt đầu kiểm tra phần mềm như một hệ thống hoàn chỉnh.  Việc lập kế hoạch cho System Test nên bắt đầu từ giai đoạn hình thành và phân tích các yêu cầu. 37
38. 6. CÁC MỨC ĐỘ KIỂM THỬ  System Test kiểm tra các hành vi chức năng của phần mềm lẫn các yêu cầu về chất lượng như độ tin cậy, tính tiện lợi khi sử dụng, hiệu năng và bảo mật.  Mức kiểm tra này thích hợp cho việc phát hiện lỗi giao tiếp với phần mềm hoặc phần cứng bên ngoài, như lỗi “tắc nghẽn” (deadlock) hoặc chiếm dụng bộ nhớ.  Sau giai đoạn System Test, phần mềm đã sẵn sàng cho khách hàng kiểm tra để chấp nhận (Acceptance Test) hoặc dùng thử (Alpha/Beta Test).  Đòi hỏi nhiều công sức, thời gian và tính chính xác, khách quan, System Test thường được thực hiện bởi một nhóm kiểm tra viên hoàn toàn độc lập với nhóm phát triển dự án 38
39. 6. CÁC MỨC ĐỘ KIỂM THỬ Bản thân System Test lại gồm nhiều loại kiểm tra khác nhau, phổ biến gồm:  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 (Performance Test): 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 39
40. 6. CÁC MỨC ĐỘ KIỂM THỬ  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 (ví dụ nhiều người truy xuất cùng lúc). 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  Kiểm tra cấu hình (Configuration Test)  Kiểm tra khả năng bảo mật (Security 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 phục hồi (Recovery Test): 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 40
41. 6. CÁC MỨC ĐỘ KIỂM THỬ Acceptance Test - Kiểm tra chấp nhận sản phẩm  Thông thường, sau giai đoạn System Test là Acceptance Test, được 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 của Acceptance Test là để chứng minh phần mềm 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 (và trả tiền thanh toán hợp đồng). 41
42. 6. CÁC MỨC ĐỘ KIỂM THỬ Regression Test - Kiểm tra hồi quy  Regression Test kiểm tra lại phần mềm sau khi có một sự thay đổi xảy ra, để bảo đảm phiên bản phần mềm mới thực hiện tốt các chức năng như phiên bản cũ và sự thay đổi không gây ra lỗi mới trên những chức năng vốn đã làm việc tốt.  Regression test có thể thực hiện tại mọi mức kiểm tra 42
43. BÀI TẬP 1. Trình bày phương pháp kiểm thử theo giá trị biên 2. Trình bày phương pháp kiểm thử theo phân vùng tương đương 3. Trình bày phương pháp kiểm thử theo đường cơ bản 43 43