CHƯƠNG 1. TỔNG QUAN VỀ KIỂM THỬ phần mềm đặc trưng cho “độ tốt, độ tuyệt hảo” của phần mềm, và gồm có các yếu tố về chất lượng như: tính đúng đắn (hành vi đúng như đặc tả), tính hiệu quả (tiết kiệm thời gian và tiền bạc), độ tin cậy, tính khả kiểm thử (kiểm thử được và dễ dàng), dễ học, dễ sử dụng, dễ bảo trì, v. Như vậy, độ tin cậy chỉ là một yếu tố để đánh giá chất lượng của một sản phẩm phần mềm. Trong thực tế, người kiểm thử nói riêng và người phát triển nói chung thường hay nhầm lẫn độ tin cậy với chất lượng.
Khi kiểm thử đạt tới mức phần mềm chạy ổn định, có thể tin và dựa vào nó được (theo thuật ngữ công nghệ phần mềm là có thể phụ thuộc vào nó), người kiểm thử thường cho rằng phần mềm đã đạt chất lượng cao. Các yếu tố về mặt chất lượng mà liên quan trực tiếp đến việc phát triển phần mềm được gọi là các tiêu chuẩn chất luợng như tính có cấu trúc, tính đơn thể, tính khả kiểm thử, v. Độ tin cậy của phần mềm là xác suất để phần mềm chạy không có thất bại trong một khoảng thời gian nhất định. Nó được xem là một yếu tố quan trọng của chất lượng phần mềm.
Ngoài ra, thời gian trung bình cho việc khắc phục một sự cố cũng là một thông số quan trọng trong việc đánh giá độ tin cậy của sản phẩm phần mềm. Kiểm thử: Rõ ràng việc kiểm thử liên quan đến các khái niệm trên: lỗi, sai, thất bại và sự cố. Có hai đích của một phép thử: tìm thất bại hoặc chứng tỏ việc tiến hành của phần mềm là đúng đắn. Vai trò của kiểm thử phần mềm: Kiểm thử phần mềm đóng vai trò quan trọng trong việc đánh giá chất lượng và là hoạt động chủ chốt trong việc đảm bảo chất lượng cao của sản phẩm phần mềm trong quá trình phát triển.
Thông qua chu trình “kiểm thử - tìm lỗi - sửa lỗi” ta hy vọng chất lượng của sản phẩm phần mềm sẽ được cải tiến. Mặt khác, thông qua việc tiến hành kiểm thử mức hệ thống trước khi cho lưu hành sản phẩm, ta biết được sản phẩm của ta tốt ở mức nào. Vì thế, nhiều tác giả đã mô tả việc kiểm thử 1. CÁC KHÁI NIỆM CƠ BẢN VỀ KIỂM THỬ 5 phần mềm là một quy trình kiểm chứng để đánh giá và tăng cường chất lượng của sản phẩm phần mềm.
Quy trình này gồm hai công việc chính là phân tích động và phân tích tĩnh. • Phân tích tĩnh: Việc phân tích tĩnh được làm dựa trên việc khảo sát các tài liệu được xây dựng trong quá trình phát triển sản phẩm như tài liệu đặc tả nhu cầu người dùng, mô hình phần mềm, hồ sơ thiết kế và mã nguồn phần mềm. Các phương pháp phân tích tĩnh truyền thống bao gồm việc khảo sát đặc tả và mã nguồn cùng các tài liệu thiết kế. Các kỹ thuật khảo sát này sẽ được giới thiệu trong chương 4.
Chúng ta cũng có thể dùng các kỹ thuật phân tích hình thức như kiểm chứng mô hình (model checking) và chứng minh định lý (theorem proving) để chứng minh tính đúng đắn của thiết kế và mã nguồn. Các kỹ thuật này tương đối phức tạp và nằm ngoài khuôn khổ của cuốn giáo trình này. Công việc này không liên quan trực tiếp đến việc thực thi chương trình mà chỉ duyệt và lý giải về tất cả các hành vi có thể của chương trình khi được thực thi. Tối ưu hóa các chương trình dịch là các ví dụ về phân tích tĩnh.
• Phân tích động: Phân tích động liên quan đến việc thực thi chương trình để phát hiện những thất bại có thể có của chương trình, hoặc quan sát các tính chất nào đó về hành vi và hiệu năng (performance). Vì gần như không thể thực thi chương trình trên tất cả các dữ liệu vào có thể, ta chỉ có thể chọn một tập con các dữ liệu vào để thực thi, gọi là các “ca kiểm thử”. Chọn như thế nào để được các bộ dữ liệu vào hiệu quả (tức là các bộ dữ liệu có xác suất phát hiện thất bại (nếu có) cao hơn là công việc cần suy nghĩ và là nội dung cơ bản của giáo trình này. TỔNG QUAN VỀ KIỂM THỬ Hình 1.1: Một vòng đời của việc kiểm thử.
Bằng việc phân tích tĩnh và động, người kiểm thử muốn phát hiện nhiều lỗi nhất có thể được để chúng có thể được sửa ở giai đoạn sớm nhất trong quá trình phát triển. Phân tích tĩnh và động là hai kỹ thuật bổ sung cho nhau và cần được làm lặp đi lặp lại nhiều trong quá trình kiểm thử. Ca kiểm thử: Mỗi ca kiểm thử có một tên (định danh) và được liên kết với một hành vi của chương trình. Ca kiểm thử gồm một tập các dữ liệu đầu vào và một xâu các giá trị đầu ra mong đợi đối với phần mềm.1 mô tả vòng đời của việc kiểm thử.
Lưu ý rằng trong giai đoạn phát triển phần mềm, có ba cơ hội mắc lỗi và tạo ra những sai lan truyền sang phần còn lại của quá trình phát triển là lúc đặc tả, lúc thiết kế và lúc lập trình. Một nhà kiểm thử lỗi lạc đã tóm tắt vòng đời này như sau: Ba giai đoạn đầu là “đưa lỗi vào”, giai đoạn kiểm thử là để tìm lỗi, và ba giai đoạn cuối là “khử lỗi đi” [Pos90]. Bước sửa sai lại là cơ hội mới cho việc đưa vào lỗi (và các sai mới). Việc sửa sai có thể làm cho phần mềm từ đúng trở thành sai.
Trong trường hợp này, việc sửa sai đó là không đầy đủ. CA KIỂM THỬ 7 Phương pháp kiểm thử hồi quy được xem là giải pháp hữu hiệu để giải quyết vấn đề này. Phương pháp này sẽ được giới thiệu chi tiết trong chương 10. Các khái niệm mô tả các thuật ngữ trên đây cho thấy các ca kiểm thử chiếm vị trí trung tâm trong việc kiểm thử dựa trên phân tích động.
Quá trình kiểm thử dựa trên phân tích động được chia thành các buớc sau: lập kế hoạch kiểm thử, phát triển ca kiểm thử, chạy các ca kiểm thử, và đánh giá kết quả kiểm thử. Tiêu điểm của cuốn giáo trình này là việc xác định tập hữu ích các ca kiểm thử, tức là các ca kiểm thử giúp ta cải tiến tốt hơn chất lượng của sản phẩm phần mềm.2 Ca kiểm thử Cốt lõi của kiểm thử phần mềm dựa trên phân tích động là việc xác định tập các ca kiểm thử sao cho chúng có khả năng phát hiện nhiều nhất các lỗi (có thể có) của hệ thống cần kiểm thử. Vậy cái gì cần đưa vào các ca kiểm thử? Rõ ràng thông tin đầu tiên là đầu vào. Đầu vào có hai kiểu: tiền điều kiện (pre-condition) - tức là điều kiện cần thỏa mãn trước khi tiến hành ca kiểm thử - và dữ liệu đầu vào thực sự được xác định bởi phương pháp kiểm thử.
Thông tin tiếp theo cần đưa vào là đầu ra mong đợi. Cũng có hai loại đầu ra: hậu điều kiện (post-condition) và dữ liệu đầu ra thực sự. Phần đầu ra của ca kiểm thử thường hay bị bỏ quên vì nó là phần khó xác định. Giả sử ta cần kiểm thử phần mềm tìm đường đi tối ưu cho máy bay khi cho trước các ràng buộc về hành lang bay và dữ liệu về thời tiết trong ngày của chuyến bay.
Đường đi tối ưu thực sự là gì? Có nhiều câu trả lời cho câu hỏi này. Câu trả lời lý thuyết là giả thiết về sự tồn tại của một cây đũa thần (oracle) biết được tất cả các câu trả lời. Câu trả lời thực tế, được gọi là kiểm thử tham chiếu, là hệ thống được kiểm thử dưới sự giám sát của các chuyên gia về lĩnh vực ứng dụng của phần mềm, người có thể phán xét 8 CHƯƠNG 1. TỔNG QUAN VỀ KIỂM THỬ xem liệu các dữ liệu đầu ra đối với việc tiến hành trên các dữ liệu đầu vào của ca kiểm thử có chấp nhận được hay không.
Hoạt động kiểm thử dẫn đến việc thiết lập các tiền điều kiện cần thiết, việc cung cấp các ca kiểm thử, quan sát dữ liệu đầu ra và so sánh chúng với các đầu ra mong đợi để phát hiện các lỗi/khiếm khuyết của sản phẩm phần mềm.2: Thông tin về một ca kiểm thử tiêu biểu.2 mô tả các thông tin cơ bản trong một ca kiểm thử được phát triển đầy đủ, chủ yếu là để trợ giúp việc quản lí. Các ca kiểm thử cần phải định danh bằng tên/chỉ số và lý do tồn tại (chẳng hạn đặc tả nhu cầu tương ứng là một lý do). Chúng ta cũng nên bổ sung thêm lịch sử tiến hành của một ca kiểm thử bao gồm cả việc chúng được chạy bởi ai và chạy khi nào, kết quả của mỗi lần chạy ra sao, thành công hay thất bại và được chạy trên phiên bản nào của phần mềm. Với các ca kiểm thử cho các hoạt động kiểm thử giao diện người dùng, ngoài thông tin về đầu vào, chúng ta cần bổ sung thêm các thông tin về trình tự nhập các đầu vào cho giao diện.
Tóm lại, ta cần nhận thức rằng ca kiểm thử ít nhất cũng quan trọng như mã 1. MÔ TẢ BÀI TOÁN KIỂM THỬ QUA BIỂU ĐỒ VENN 9 nguồn. Các ca kiểm thử cần được phát triển, phân tích đánh giá, sử dụng, quản lý và lưu trữ một cách khoa học.3 Mô tả bài toán kiểm thử qua biểu đồ Venn Kiểm thử chủ yếu liên quan tới hành vi của chương trình nơi mà hành vi phản ánh quan điểm về cấu trúc phổ biến đối với các nhà phát triển hệ thống hoặc phần mềm. Sự khác biệt là quan điểm cấu trúc tập trung vào “là cái gì”, còn quan điểm hành vi lại tập trung vào “làm gì”.
Một trong những nguyên nhân gây khó cho người kiểm thử là các tài liệu cơ sở thường được viết bởi và viết cho người phát triển. Kết quả là các tài liệu này thường thiên về thông tin cấu trúc và coi nhẹ thông tin về hành vi của chương trình cần kiểm thử. Trong mục này, chúng ta sẽ phát triển một biểu đồ Venn đơn giản nhằm làm sáng tỏ một số vấn đề về kiểm thử. Chi tiết về biểu đồ Venn sẽ được trình bày trong chương 3.3: Các hành vi được cài đặt và được đặc tả.
Xét một vũ trụ của hành vi chương trình cần kiểm thử, lưu ý rằng chúng ta đang quan tâm đến bản chất của việc kiểm thử. Cho trước một chương trình cùng đặc tả của nó. Gọi S là tập các hành vi được đặc tả và P là tập các hành vi của chương trình.
