Bài giảng Kiểm tra phần mềm - Chương 8: Kiểm thử module (đơn vị)

Nội dung text: Bài giảng Kiểm tra phần mềm - Chương 8: Kiểm thử module (đơn vị)

1. ƒ Khi kiểm thử phần tử ngày càng lớn hơn thì kỹ thuật kiểm thử hộp trắng ít khả thi hơn. ƒ Việc kiểm thử sau ₫ó thường hướng ₫ến việc tìm ra các kiểu lỗi (lỗi phân tích, lỗi nắm bắt yêu cầu phần mềm). Thủ tục thiết kế testcase Phân tích luận lý của module dựa vào 1 trong các kỹ thuật kiểm thử hộp trắng. Áp dụng các kỹ thuật kiểm thử hộp ₫en vào ₫ặc tả của module ₫ể bổ sung thêm các testcase khác. 8.3 Kiểm thử không tăng tiến Để thực hiện qui trình kiểm thử các module, hãy ₫ể ý 2 ₫iểm chính : 1. Làm sao thiết kế ₫ược 1 tập các testcase hiệu quả. 2. Cách thức và thứ tự tích hợp các module lại ₫ể tạo ra phần mềm chức năng : à Viết testcase cho module nào ? à Dùng loại tiện ích nào cho kiểm thử ? à Coding và kiểm thử các module theo thứ tự nào ? à Chi phí tạo ra các testcase ? à Chi phí debug ₫ể tìm và sửa lỗi ? Có 2 phương án ₫ể kiểm thử các module : 1. Kiểm thử không tăng tiến hay kiểm thử ₫ộc lập (Non- incremental testing) : kiểm thử các module chức năng ₫ộc lập nhau, sau ₫ó kết hợp chúng lại ₫ể tạo ra chương trình. 2. Kiểm thử tăng tiến (Incremental testing) : kết hợp module cần kiểm thử vào bộ phận ₫ã kiểm thử (lúc ₫ầu là null) ₫ể kiểm thử module cần kiểm thử trong ngữ cảnh.
2. Các ý tưởng kiểm thử tăng tiến : ƒ Trước khi kiểm thử module mới, ta tích hợp nó vào tập các module ₫ã kiểm thử rồi. ƒ Tích hợp các module theo thứ tự nào ? Từ trên xuống (top- down) hay từ dưới lên (bottom-up). ƒ Có phải kiểm thử tăng tiến tốt hơn kiểm thử không tăng tiến ? Một số ý quan sát : ƒ Kiểm thử tăng tiến cần nhiều công sức hơn kiểm thử không tăng tiến.
3. Kiểm thử module A trước. Để kiểm thử module A, ta cần phải xây dựng các Stub cho 3 module mà A phụ thuộc trực tiếp là B, C, D. Tạo các testcase cho module A như thế nào ? ƒ Các Stubs sẽ có nhiệm vụ cung cấp dữ liệu cho module cần kiểm thử : à B–cung cấp thông tin tổng kết về giao tác. à C–xác ₫ịnh trạng thái hàng tuần có thỏa quota không? à D–tạo báo cáo tổng kết hàng tuần. ƒ Như vậy 1 testcase cho A là tổng kết giao tác từ B gởi về, Stub D có thể chứa các lệnh ₫ể xuất dữ liệu ra máy in ₫ể ta có thể xem xét kết quả của mỗi test case. Nếu module A gọi module B chỉ 1 lần, làm sao cung cấp nhiều dữ liệu test khác nhau cho A ? ƒ Viết nhiều version khác nhau cho Stub B, mỗi version cung cấp 1 dữ liệu test xác ₫ịnh cho A. ƒ Đặt dữ liệu test ở file bên ngoài B, Stub B ₫ọc vào và return cho A.
4. Nếu module J và I thực hiện nhập/xuất dữ liệu, còn module G là critical, ta nên chọn thứ tự kiểm thử tăng tiến sau ₫ây : Một khi ₫ã kiểm thử ₫ến trạng thái như hình dưới ₫ây : ƒ Việc miêu tả các testcase và việc thanh tra kết quả sẽ ₫ơn giản. ƒ Ta ₫ã có 1 version chạy ₫ược của chương trình, nó thực hiện ₫ược các hoạt ₫ộng nhập/xuất dữ liệu. ƒ Ta có cảm giác chương trình hoàn chỉnh ₫ến rất gần rồi.
5. ƒ Quan sát kết quả kiểm thử sẽ gặp khó khăn : Tương tự, xem xét sự tương quan dữ liệu xuất của 1 module và dữ liệu nhập tạo dữ liệu xuất này (nhưng ở trong module có khoảng cách khá xa) sẽ rất khó khăn. ƒ Nó làm ta nghĩ rằng việc thiết kế và kiểm thử có cùng thứ tự thực hiện : ta sẽ cảm nhận rằng hoạt ₫ộng kiểm thử và hoạt ₫ộng thiết kế gối ₫ầu nhau : thiết kế tới ₫âu thì kiểm thử tới ₫ó. Điều này thật nguy hiểm vì nếu ta tiến hành thiết kế và kiểm thử gối ₫ầu nhau như vậy thì khi kiểm thử tới các module phía dưới mà ₫òi hỏi hiệu chỉnh bản thiết kế của module phía trên thì sẽ gây lãng phí rất lớn (vì phải huỷ bỏ kết quả ₫ã có và thiết kế lại từ ₫ầumodule phía trên). ƒ Nó trì hoản việc kiểm thử 1 số module. ƒ Nó làm ta dễ quên hiện thực module chức năng vì ₫ã có Stub thay thế. ƒ Khó lòng kiểm thử ₫ầy ₫ủ module cần kiểm thử trước khi tiến hành kiểm thử module khác. Điều này là do 2 lý do chính sau ₫ây : à Các module Stub khó lòng tạo ₫ược tất cả dữ liệu thật mà module thực sự tương ứng sẽ tạo ra. à Các module cấp trên của cấu trúc chương trình thường chứa các ₫oạn code tạo, thiết lập trạng thái ₫ầu của các tài nguyên mà sẽ ₫ược dùng trong các module phía dưới, nhưng hiện nay module phía dưới chưa ₫ược kiểm thử nên không thể kiểm thử các ₫oạn code thiết lập tài nguyên này ₫ược. 8.5 Kiểm thử từ dưới lên (bottom-up) Gồm các bước theo thứ tự : 1. Bắt ₫ầu từ 1 hay nhiều module lá : module mà không gọi module nào khác.
6. Ưu & khuyết ₫iểm của phương pháp bottom-up ƒ Ưu : ƒ Nếu các lỗi xảy ra có khuynh hướng nằm trong các module mức thấp thì phương pháp bottom-up sẽ giúp phát hiện sớm chúng. ƒ Việc tạo các ₫iều kiện kiểm thử sẽ dễ dàng hơn. ƒ Việc quan sát các kết quả kiểm thử cũng dễ dàng hơn. ƒ Khuyết : ƒ Phải viết các module driver, mặc dù việc viết các module này khá dễ dàng. ƒ Chương trình khung sườn chưa tồn tại 1 thời gian dài cho ₫ến khi module cuối cùng ₫ược tích hợp vào hệ thống. 8.6 Kết chương Chương này ₫ã trình bày các vấn ₫ề cơ bản về hoạt ₫ộng kiểm thử ₫ơn vị, hay còn gọi là kiểm thử module. Chúng ta cũng ₫ã trình bày các kỹ thuật kiểm thử ₫ơn vị thường dùng như kỹ thuật kiểm thử không tăng tiến, kỹ thuật kiểm thử tăng tiến từ trên xuống, kỹ thuật kiểm thử tăng tiến từ dưới lên cùng các ưu/khuyết ₫iểm của từng kỹ thuật.