kiểm tra phần mềm nguyễn văn hiệp chương08 kiểm thu module ( on vi) sinhvienzone com

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 Zo ne C om ƒ en 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 : nh Vi Khơng việc module có thoả mãn ₫ầy ₫ủ ₫ặc tả chức ? Si 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 : SinhVienZone.com https://fb.com/sinhvienzonevn ƒ 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 om Áp dụng kỹ thuật kiểm thử hộp ₫en vào ₫ặc tả module ₫ể bổ sung thêm testcase khác .C 8.3 Kiểm thử khơng tăng tiến ne Để thực qui trình kiểm thử module, ₫ể ý ₫iểm : Zo Làm thiết kế ₫ược tập testcase hiệu en 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ử ? nh Vi Coding kiểm thử module theo thứ tự ? Chi phí tạo testcase ? Chi phí debug ₫ể tìm sửa lỗi ? Si 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 SinhVienZone.com https://fb.com/sinhvienzonevn 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 Zo ne C om Để kiểm thử module ₫ộc lập, ta cần viết Driver nhiều Stub cho en Driver module có nhiệm vụ kích hoạt testcase ₫ể kiểm thử module ₫ang cần kiềm thử Si nh Vi Stub thực mức ₫ộ tối thiểu ₫ó cho module chức ₫ược dùng module ₫ang cần kiểm thử SinhVienZone.com https://fb.com/sinhvienzonevn om C 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 ? Si nh Vi en Zo ne ƒ Một số ý quan sát : ƒ SinhVienZone.com Kiểm thử tăng tiến cần nhiều công sức kiểm thử không tăng tiến https://fb.com/sinhvienzonevn 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 .C om ƒ 8.4 Kiểm thử từ xuống (top-down) ne Gồm bước theo thứ tự : Zo Bắt ₫ầu từ module gốc cấu trúc chương trình Vi Module phải ₫ược dùng trực tiếp module ₫ược kiểm thử nh en Sau kiểm thử xong module hành, ta chọn module theo ý tưởng : 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 Si à SinhVienZone.com 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 https://fb.com/sinhvienzonevn om C ne 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 en 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 Vi Si nh ƒ Zo Tạo testcase cho module A ? ƒ 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 SinhVienZone.com https://fb.com/sinhvienzonevn ne C om Sau kiểm thử xong module hành, ta chọn Stub thay module thật kiểm thử module thật : Si nh Vi en Zo 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 SinhVienZone.com 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 https://fb.com/sinhvienzonevn ne C om 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 Si nh Vi en Zo ƒ SinhVienZone.com https://fb.com/sinhvienzonevn om Ư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 Vi en Zo ne C ƒ 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ĩ Si ƒ nh Khuyết ₫iểm phương pháp top-down ƒ 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ử SinhVienZone.com https://fb.com/sinhvienzonevn 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 Si nh Vi en Zo ne C om ƒ 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 SinhVienZone.com https://fb.com/sinhvienzonevn 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 Vi en Zo ne C om Các module E, J, G, K, L I ₫ược kiểm thử trước Si nh Để 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 : SinhVienZone.com https://fb.com/sinhvienzonevn om Ưu & khuyết ₫iểm phương pháp bottom-up C ƒ Ư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 Zo ne ƒ ƒ Vi en 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 Si nh ƒ 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 SinhVienZone.com https://fb.com/sinhvienzonevn ... 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 SinhVienZone. com https://fb .com/ sinhvienzonevn Các bước kiểm thử không tăng tiến : Kiểm thử module. .. dùng module ₫ang cần kiểm thử SinhVienZone. com https://fb .com/ sinhvienzonevn om C 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. .. ₫ượ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 SinhVienZone. com https://fb .com/ sinhvienzonevn Sau kiểm thử xong module