Bài giảng Kiểm thử phần mềm - Chương 8: Kiểm thử module (Đơn vị) - Nguyễn Văn Hiệp

 Chương 8
 Kiểm thử module (₫ơn vị)
8.1 Giới thiệu 
 Kiểm thử module (hay kiểm thử ₫ơn vị) là quá trình kiểm thử 
từng chương trình con, từng thủ tục nhỏ trong chương trình. Một số 
₫ộng cơ của việc kiểm thử ₫ơn vị : 
 ƒ Kiểm thử ₫ơn vị là 1 cách quản lý nhiều phần tử cần kiểm 
 thử, bắt ₫ầu tập trung chú ý trên từng phần tử nhỏ của 
 chương trình. 
 ƒ Kiểm thử ₫ơn vị giúp dễ dàng việc debug chương trình. 
 ƒ Kiểm thử ₫ơn vị tạo cơ hội tốt nhất cho ta thực hiện kiểm 
 thử ₫ồng thời bởi nhiều người. 
 Mục ₫ích của kiểm thử ₫ơn vị : so sánh chức năng thực tế của 
từng module với ₫ặc tả chức năng hay ₫ặc tả interface của module 
₫ó. Sự so sánh này có tính chất : 
 1. Không chỉ ra việc module có thoả mãn ₫ầy ₫ủ ₫ặc tả chức 
 năng ? 
 2. Mà chỉ ra việc module có làm ₫iều khác biệt gì so với ₫ặc 
 tả của module. 
8.2 Thiết kế testcase 
 Hai tài nguyên thiết yếu sau sẽ cần thiết cho việc thiết kế các 
testcase : 
 ƒ Đặc tả chức năng module : nêu rõ các thông số ₫ầu vào, 
 ₫ầu ra và các chức năng cụ thể chi tiết của module. 
 ƒ Mã nguồn của module. 
 Tính chất các testcase là dựa chủ yếu vào kỹ thuật kiểm thử 
hợp trắng : 
 ƒ 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. 
 Các bước kiểm thử không tăng tiến : 
 1. Kiểm thử từng module chức năng 1 cách ₫ộc lập. 
 2. Tích hợp chúng lại thành chương trình. 
 3. Để kiểm thử 1 module ₫ộc lập, ta cần viết 1 Driver và 
 nhiều Stub cho nó. 
 Driver là module có nhiệm vụ kích hoạt các testcase ₫ể kiểm 
thử module ₫ang cần kiềm thử. 
 Stub là một hiện thực ở mức ₫ộ tối thiểu nào ₫ó cho 1 module 
chức năng ₫ược dùng bởi module ₫ang cần kiểm thử. 
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. 
 ƒ Các lỗi liên quan ₫ến giao tiếp giữa các module sẽ ₫ược 
 phát hiện sớn hơn vì việc tích hợp các module xảy ra sớm 
 hơn so với kiểm thử không tăng tiến. 
 ƒ Kiểm thử tăng tiến cũng sẽ giúp debug dễ dàng hơn. 
 ƒ Kiểm thử tăng tiến sẽ hiệu quả hơn. 
 ƒ Kiểm thử không tăng tiến dùng ít thời gian máy hơn (vì chỉ 
 tiến hành trên từng module ₫ộc lập). 
 ƒ Ở ₫ầu chu kỳ kiểm thử module, kiểm thử không tăng tiến 
 tạo cơ hội tốt cho việc kiểm thử ₫ồng thời trên nhiều 
 module khác nhau. 
8.4 Kiểm thử từ trên xuống (top-down) 
 Gồm các bước theo thứ tự : 
 1. Bắt ₫ầu từ module gốc ở trên cùng của cây cấu trúc 
 chương trình. 
 2. Sau khi kiểm thử xong module hiện hành, ta chọn module 
 kế tiếp theo ý tưởng : 
 à Module kế tiếp phải ₫ược dùng trực tiếp bởi module 
 ₫ược kiểm thử rồi. 
 à Vì có nhiều module cùng thỏa mãn ₫iều kiện trên, nên 
 ta chọn module thực hiện nhiều hoạt ₫ộng I/O trước. 
 à Rồi chọn module "critical", là module dùng thuật giải 
 phức tạp, tiềm ẩn nhiều lỗi và/hoặc lỗi nặng nhất. 
 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. 
 Sau khi kiểm thử xong module hiện hành, ta chọn 1 trong các 
Stub và thay thế nó bằng module thật rồi kiểm thử module thật này 
: 
 Có nhiều thứ tự kiểm thử khác nhau có thể ₫ược chọn như dưới 
₫ây, và nếu cần kiểm thử ₫ồng thời, cũng có nhiều thứ tự khác 
nữa. 
1. A B C D E F G H I J K L 
2. A B E F J C G K D H L I 
3. A D H I K L C G B F J E 
4. A B F J D I E C G K H L 
5. ... 
 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. 
Ưu ₫iểm của phương pháp top-down 
 ƒ Nếu các lỗi xảy ra có khuynh hướng nằm trong các module 
 mức cao thì phương pháp top-down sẽ giúp phát hiện sớm 
 chúng. 
 ƒ Một khi các hoạt ₫ộng nhập/xuất dữ liệu ₫ã ₫ược thêm vào 
 hệ thống thì việc miêu tả các test case sẽ dễ dàng hơn. 
 ƒ Chương trình khung sườn sớm hình thành ₫ể demo và tiếp 
 thêm sức mạnh tinh thần cho những người phát triển phần 
 mềm. 
Khuyết ₫iểm của phương pháp top-down 
 ƒ Phải viết các Stub ₫ể kiểm thử module dùng chúng, và viết 
 Stub thường phức tạp hơn nhiều so với suy nghĩ của chúng 
 ta. 
 ƒ Trước khi các hoạt ₫ộng nhập/xuất ₫ược tích hợp vào hệ 
 thống, việc miêu tả các testcase trong các Stub có thể gặp 
 khó khăn. 
 ƒ Việc tạo ra ₫iều kiện kiểm thử sẽ rất khó và nhiều lúc là 
 không khả thi : Do có khoảng cách khá xa giữa module 
 cần test và module nhập dữ liệu cung cấp cho module cần 
 test nên rất khó ₫ể cung cấp dữ liệu gì ₫ể có thể kiểm thử 
 1 tình huống xác ₫ịnh của module cần kiểm thử. 
 ƒ 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. 
 2. Sau khi kiểm thử xong module hiện hành, ta chọn module 
 kế tiếp theo ý tưởng : 
 à Module kế tiếp phải dùng trực tiếp 1 hay nhiều module 
 ₫ược kiểm thử rồi. 
 à Vì có nhiều module cùng thỏa mãn ₫iều kiện trên, nên 
 ta chọn module thực hiện nhiều hoạt ₫ộng I/O trước. 
 à Rồi chọn module "critical", là module dùng thuật giải 
 phức tạp, tiềm ẩn nhiều lỗi và/hoặc lỗi nặng nhất. 
 Các module E, J, G, K, L và I ₫ược kiểm thử trước. 
 Để kiểm thử 1 module, ta phải viết driver cho nó. Không cần 
phải viết nhiều driver khác nhau cho cùng 1 module. Trong ₫ại ₫a 
số trường hợp, viết driver dễ hơn nhiều so với viết Stub. 
 Nếu D và F là 2 module critical nhất, thì ta nên kiểm thử theo 
trình tự của hình vẽ dưới ₫ây : 
Ư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.