Kỹ thuật kiểm thử phần mềm

1. Kỹ thuật kiểm thử phần mềm GV: Th.s Nguyễn Quang Vũ

2. 1 PHẦN MỀM VÀ LỖI PHẦN MỀM 2 KỸ THUẬT KIỂM THỬ PHẦN MỀM 3 CHIẾN LƯỢC KIỂM THỬ PHẦN MỀM 4 QUY TRÌNH KIỂM THỬ PHẦN MỀM 5 KỸ THUẬT KIỂM THỬ ĐỘT BIẾN KỸ THUẬT KIỂM THỬ PHẦN MỀM 6 THỰC HÀNH: THIẾT KẾ TESTCASE

3. Chương 1. Phần mềm và lỗi phần mềm • Công nghệ phần mềm (CNPM) ? • Các tác vụ chủ yếu của CNPM: • Thiết kế • Xây dựng • Kiểm thử • Bảo trì • Mục tiêu của CNPM: • Tạo ra phần mềm tốt • Giảm thiểu sai sót trong quá trình vận hành • Thuận lợi trong bảo trì và nâng cấp

4. Chương 1. Phần mềm và lỗi phần mềm • Phần mềm ? • là một tập các đoạn mã hoặc câu lệnh viết ra để cài đặt trên máy tính nhằm thực hiện một hoặc một nhóm chức năng nào đó. • Các công việc để tạo ra một phần mềm: • Phân tích – Đặc tả yêu cầu • Thiết kế • Lập trình • Kiểm thử • Viết tài liệu • Bảo trì

5. Chương 1. Phần mềm và lỗi phần mềm • Có nhiều quy trình phần mềm khác nhau (Software Development Process – SEP) • Đóng vai trò quyết định chất lượng PM. • Các nhóm công việc được triển khai theo những cách khác nhau. • Có 4 nhóm công việc nền tảng: Đặc tả yêu cầu – Phát triển – Kiểm thử - Cài đặt và bảo trì • Một PM có thể dùng nhiều mô hình khác nhau. • Không phải tất cả các mô hình đều thích hợp cho mọi phần mềm ứng dụng

6. Chương 1. Phần mềm và lỗi phần mềm • Vì các yếu tố (đặc điểm) sau: • Đặc tính (Characteristics ). • Tính đáp ứng (responsiveness ) • Loại (Type)

7. Chương 1. Phần mềm và lỗi phần mềm • Các đặc tính của phần mềm: • Dữ liệu • Xử lý • Ràng buộc: Thứ tự trước – Thứ tự sau – Thời gian – Cấu trúc – Điều khiển – Suy diễn • Giao diện: Người sử dụng – Thủ công – Giao diện chuẩn hóa (Giao diện mạng LAN; Chuẩn OSI;…)

8. Chương 1. Phần mềm và lỗi phần mềm

9. Chương 1. Phần mềm và lỗi phần mềm

10. Chương 1. Phần mềm và lỗi phần mềm • Phân loại phần mềm:

11. Chương 1. Phần mềm và lỗi phần mềm • Có thể phân loại PM theo sự định hướng công việc: • Ứng dụng hướng giao dịch • Ứng dụng CSDL • Ứng dụng hỗ trợ quyết định • Hệ chuyên gia • Hệ thống nhúng

12. Chương 1. Phần mềm và lỗi phần mềm • Chất lượng phần mềm: Các nhân tố ảnh hưởng đến chất lượng PM có thể là • Nhân tố đo trực tiếp • Nhân tố đo gián tiếp

13. Chương 1. Phần mềm và lỗi phần mềm • Các tiêu chuẩn chất lượng phần mềm có thể thay đổi tùy theo: • Công dụng • Nhu cầu thực tế • Chuẩn quốc gia, quốc tế • Nền văn minh cộng đồng • Thời điểm • …

14. Chương 1. Phần mềm và lỗi phần mềm • Các tiêu chuẩn phải đảm bảo những thuộc tính TỐI QUAN TRỌNG: • Khả năng bảo trì • Khả năng tin cậy • Độ hữu hiệu • Khả năng sử dụng

15. Lỗi phần mềm • Thế nào là phần mềm được gọi là đúng ? • Để đánh giá CẤP ĐỘ ĐÚNG của phần mềm, phải kiểm tra CHẤT LƯỢNG PHẦN MỀM

16. Lỗi phần mềm • Lỗi phần mềm xảy ra ở tất cả các công đoạn

17. Nguyên nhân khác Lập trình Thiết kế Đặc tả Lỗi phần mềm • Định nghĩa LỖI PHẦN MỀM? • Lỗi phần mềm là sự không khớp giữa chương trình và đặc tả của nó • Lỗi phần mềm xuất hiện nhiều nhất ở công đoạn nào ? • Đặc tả: ~ 70%

18. Lỗi phần mềm • Nguyên nhân làm đặc tả nhiều lỗi ? • Đặc tả không được viết ra • Đặc tả không đủ cẩn thận • Đặc tả thay đổi • Chưa phối hợp tốt trong nhóm

19. Lỗi phần mềm • Ví dụ: Bài toán phân số • Đặc tả phi hình thức: phân số là một cặp t/m, trong đó t là một số nguyên, m là một số tự nhiên lớn hơn 0; t được gọi là tử số, m được gọi là mẫu số của phân số • Đặc tả hình thức: là đặc tả trong đó sử dụng các ký hiệu toán học để mô tả. Phân số = {(t,m) | t  Z, m  N+} (*) Trong đó: N = {0, 1, 2, 3, …} N+ = {1, 2, 3, …} Z = {0, 1, 2, 3, …}

20. Lỗi phần mềm • Ví dụ (tt): Xét đặc tả phép chia hai phân số • (t1,m1):(t2,m2) = Reduce(t1 m2, t2  m1), trong đó Reduce(t, m) = (t/d, m/d) với d = gcd(t, m) • Hàm gcd là hàm tìm ước số chung lớn nhất của hai số tự nhiên. • Bây giờ, hãy thực hiện chia hai phân số: (1,3):(-2,5)?

21. Lỗi phần mềm • Ví dụ: Chia nhóm và mỗi nhóm tìm một bài toán (đặc tả phi hình thức, đặc tả hình thức, và một trường hợp có thể không đúng với đặc tả)

22. Các lỗi phần mềm thường gặp • Sản phẩm phần mềm được được xây dựng thiếu, sai, thừa so với đặc tả được xem là có lỗi. • Thậm chí, một phần mềm khó hiểu, khó sử dụng, thực thi chậm, … cũng được xem là lỗi.

23. Các lỗi phần mềm thường gặp • Lỗi chiến lược • Phân tích không đủ yêu cầu hoặc lệch lạc • Hiểu sau về chức năng • Vi phạm nguyên lý đối tượng • Nguyên lý đóng – mở • Nguyên lý nghịch đảo phụ thuộc • Nguyên lý thay thế Liskov • Nguyên lý phân tách Interface

24. Các lỗi phần mềm thường gặp (tt) • Lỗi các thủ tục chịu tải • Lỗi lây lan • Lỗi cú pháp • Lỗi hiệu ứng phụ

25. Các lỗi phần mềm thường gặp (tt) • Ví dụ: chương trình tính tiền lương được đặc tả cho từng nhân viên theo qui định làm tròn đến hàng đơn vị, với công thức (1.1) Lươngi = round(hsli*lcb(1- 0.06),0 ) (1.1) Nhưng khi lập trình: Lươngi = round(hsli *lcb(1- 0.06),-2 ) (1.2)

26. Các lỗi phần mềm thường gặp (tt) • Ví dụ: Như vậy dẫn đến sai số như sau

27. Các lỗi phần mềm thường gặp (tt) • Đặc tả thiếu: Một yêu cầu đã được đặc tả nhưng lại không có trong sản phẩm được xây dựng. Ví dụ: Chương trình quản lý tính vốn vay, khi ngân hàng cho vay vốn thì việc tính lãi được qui định theo hai phương thức là tính lãi đơn và tính lãi kép. Nhưng khi thiết kế thì chương trình chỉ tính lãi đơn không tính lãi kép. Do vậy, chương trình không đưa vào ứng dụng ngay được mà phải sửa chữa cập nhật lại.

28. Các lỗi phần mềm thường gặp (tt) • Đặc tả thừa: Một yêu cầu được đưa vào sản phẩm mà không có trong đặc tả. Cũng có trường hợp yêu cầu này có thể là một thuộc tính sẽ được người dùng chấp nhận nhưng khác với đặc tả nên vẫn coi là có lỗi. Ví dụ: ????

29. Chi phí cho việc sửa lỗi phần mềm • Kiểm thử và sửa lỗi có thể được thực hiện tại bất kỳ giai đoạn nào của vòng đời phần mềm • Chi phí cho việc tìm và sửa lỗi tăng một cách đáng kể theo quá trình phát triển: • Không đáng kể khi thay đổi yêu cầu ở lần duyệt yêu cầu đầu tiên • Tăng lên gấp bội khi thay đổi yêu cầu lúc đã lập trình • Không đáng kể nếu lập trình viên tự phát hiện lỗi của mình

30. Chi phí cho việc sửa lỗi phần mềm • “Sửa một lỗi trước khi phát hành một phần mềm sẽ tốn chi phí ít hơn rất nhiều so với việc khắc phục nó sau khi đã phát hành. ” • Lỗi được phát hiện càng muộn thì chi phí cho việc sữa lỗi càng lớn

31. Chi phí để sữa lỗi Đặc tả Thiết kế lập trình Kiểm thử Phát hành Chi phí cho việc sửa lỗi phần mềm

32. Chi phí cho việc sửa lỗi phần mềm • Ví dụ: Sự cố Y2K.

33. Đảm bảo chất lượng phần mềm • Mục đích của nhóm phát triển PM là có PM chất lượng cao • Hạn chế thấp nhất việc phát sinh lỗi • Đảm bảo chất lượng phần mềm là một hoạt động có hệ thống và kế hoạch

34. Đảm bảo chất lượng phần mềm • Đảm bảo chất lượng phần mềm gồm nhiều nhiệm vụ liên kết và các hoạt động chính sau: • Áp dụng các phương pháp kỹ thuật, • Tiến hành các cuộc xét duyệt kỹ thuật chính thức, • Kiểm thử phần mềm, • Buộc tôn trọng các chuẩn, • Kiểm soát thay đổi, • Đo chất lượng, • Báo cáo, lưu giữ kết quả.

35. Đảm bảo chất lượng phần mềm • Đảm bảo chất lượng phần mềm là một hoạt động BẢN CHẤT cho bất kỳ nhóm phát triển PM nào. • Có hai kỹ thuật để tăng độ tin cậy của phần mềm: • Tránh lỗi • Thứ lỗi

36. Đảm bảo chất lượng phần mềm • Tránh lỗi • Đặc tả hệ thống chính xác • Tăng cường duyệt và thẩm định • Chấp nhận triết lý chất lượng tổ chức: chất lượng là bánh lái của quá trình phát triển phần mềm. • Lập kế hoạch cẩn thẩn cho việc thử nghiệm hệ thống

37. Đảm bảo chất lượng phần mềm • Thứ lỗi • Một hệ vô lỗi thì vẫn cần một tiện ích thứ lỗi: đó là vì có thể có các lỗi đặc tả • Một tiện ích thứ lỗi là cần thiết cho một hệ thống đáng tin cậy

38. Đảm bảo chất lượng phần mềm • 4 hoạt động cần tiến hành để THỨ LỖI • Phát hiện lỗi • Định ra mức độ thiệt hại • Hồi phục sau khi gặp lỗi: Hồi phục tiến hoặc Hồi phục lùi • Chữa lỗi. (Lưu ý các lỗi “tàng hình”)

39. Xác minh và Thẩm định • V&V – Verification and Validation • Là một quá trình liên tục xuyên suốt mọi giai đoạn của tiến trình phát triển phần mềm • là từ chung cho các quá trình kiểm thử • Có hai mục tiêu: • Phát hiện các khuyết tật trong hệ thống. • Đánh giá xem hệ thống liệu có dùng được hay không?

40. Xác minh và Thẩm định • Sự khác nhau giữa xác minh và thẩm định: • Xác minh: Are we building the product right? • Thẩm định: Are we buiding the right product ?

41. Phân tích yêu cầu Thiết kế Mã hoá và kiểm thử đơn vị Tích hợp và kiểm thử hệ thống Cài đặt và bảo trì Hình 1.1–Mô hình WaterFall Mô hình phát triển phần mềm

42. Mô hình phát triển phần mềm • Ưu điểm của mô hình này: - chuỗi các hoạt động xây dựng phần mềm theo trình tự, rõ ràng. • Nhược điểm của mô hình này: - Đòi hỏi tất cả yêu cầu phần mềm phải được xác định rõ ràng ngay từ đầu dự án. - Sự quay lui là nhu cầu tự nhiên. - Ẩn chứa nhiều rủi ro mà chỉ có thể phát hiện ở giai đoạn cuối cùng - Chi phí để sửa chữa có thể rất cao.

43. Các hoạt động đồng thời Đặc tả (Specification) Phiên bản đầu tiên Phát triển (Development, design, coding) Yêu lược ban đầu Phiên bản trung gian Kiểm thử (Testing) Phiên bản Cuối cùng Hình 1.2–Mô hình tiến hóa Mô hình phát triển phần mềm

44. Mô hình phát triển phần mềm • Ưu điểm của mô hình này: - Chú trọng việc tái sử dụng mẫu - Một phần của hệ thống có thể được phát triển ngay trong các giai đoạn phân tích phát triển yêu cầu và thiết kế - Cho phép thay đổi yêu cầu và khuyến khích người sử dụng tham gia trong suốt chu kỳ của dự án • Nhược điểm của mô hình này: - chậm quá trình phát triển yêu cầu - tính chặt chẽ, minh bạch của qui trình phát triển phần mềm kém

45. Mô hình phát triển phần mềm

46. Mô hình phát triển phần mềm • Trong mô hình này: - Một khi sai sót được phát hiện trong một giai đoạn kiểm thử thì giai đoạn phân tích hay thiết kế tương ứng được xem xét lại và chu trình bắt đầu lại từ đó

47. Mô hình phát triển phần mềm

48. Mô hình phát triển phần mềm • Ưu điểm của mô hình này: - Phân tích đánh giá rủi ro để tăng thêm mức độ tin cậy của dự án - Kết hợp được những ưu điểm của mô hình thác nước và mô hình tiến hóa - cho phép thay đổi tùy theo điều kiện thực tế dự án • Nhược điểm của mô hình này: - Phức tạp và không phù hợp cho dự án nhỏ với ít rủi ro - Cần có kỹ năng tốt về phân tích rủi ro

49. Chương 2. Kiểm thử phần mềm

50. Chương 2. Kiểm thử phần mềm • Đóng vai trò tối quan trọng, quyết định đến việc đánh giá chất lượng phần mềm • Là quá trình tìm lỗi • Mục đích của kiểm thử là đảm bảo rằng tất cả các thành phần của phần mềm ăn khớp, vận hành như mong đợi và phù hợp các tiêu chuẩn thiết kế.