Professional Documents
Culture Documents
CuuDuongThanCong.com https://fb.com/tailieudientucntt
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).
CuuDuongThanCong.com https://fb.com/tailieudientucntt
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ó.
CuuDuongThanCong.com https://fb.com/tailieudientucntt
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 ?
CuuDuongThanCong.com https://fb.com/tailieudientucntt
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.
CuuDuongThanCong.com https://fb.com/tailieudientucntt
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.
CuuDuongThanCong.com https://fb.com/tailieudientucntt
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. ...
CuuDuongThanCong.com https://fb.com/tailieudientucntt
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.
CuuDuongThanCong.com https://fb.com/tailieudientucntt
Ư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.
CuuDuongThanCong.com https://fb.com/tailieudientucntt
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.
CuuDuongThanCong.com https://fb.com/tailieudientucntt
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.
CuuDuongThanCong.com https://fb.com/tailieudientucntt
Ư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.
CuuDuongThanCong.com https://fb.com/tailieudientucntt