Chuong08_kiem thu don vi

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