Tiêu chí bao phủ lộ trình định nghĩa sử dụng được ký hiệu all-du-path yêu cầu mỗi định nghĩa biến đạt đến được tất cả các sử dụng có thể thông qua tất cả các du- path có thể, một cách hình thức hơn đối với mỗi tạp các du-path thuộc du(ni,nj,v) tất cả các du-path phải được bao phủ.
Quy trở lại ví dụ hàm f00, áp dụng tiue chí all-du-paths đói với biến s, cần bao phủ bối du-path:
[n0,n1,n2,n4,n5]
[n0,n1,n3,n4,n5]
[n0,n1,n2,n4,n6]
Có thể chọn các dữ liệu thử tương ứng DT1 = {A=5,B=2,C=1}
DT2 = {A=2,B=5,C=1}
DT3 = {A=5,B=2,C=5}
DT4 = {A=2,B=5,C=5}
Chúng ta có thể dễ dàng nhần thấy rằng tiêu chí bao phủ lộ trình định nghĩa sử dụng được thoả mãn dược tiêu chí bao phủ sử dụng cũng được thỏa mãn.
Quan quan hệ giữa các tiêu chí bao phủ dựtrên đồ thị
Các kỹ thuật kiểm thử cấu trúc dựa trên đồ thị nhằm phát hiện các lỗi của lập trình viên và thường chỉ áp dụng cho hoại động kiểm thử đơn vị. Các kỹ thuật kiểm thử này có thể được tự động hóa, nghĩa là xây dựng công cụ hỗ trợ.
Kiểm thử dựa trên đồ thị luồng điều khiển và kiếm thử dựa trên đồ thị luồng dữ liệu bổ sung cho nhau và nhằm phát hiện các lớp lỗi khác nhau. Chẳng hạn. Xem xét câu lệnh sau:
if (a>b) a=a-b;
else b = b - a;
Nếu lập trình viên phạm lỗi trong phần else (ví dụ, nên viết là a=a-b) khi đó, kiểm thử dựa trên đồ thị luồng dữ liệu có thể phát hiện dựa trên đồ thị luồng dữ liệu có thể phát hiện được lỗi định nghĩa sai này. Ngược lại nếu lập trình viên phạm lỗi rẻ nhánh (ví dụ nên viết là if (a<b) thì kiểm thử dựa trên đồ thị luồng điểm khiển có khả năng phát hiện lỗi này cao hơn.
Các tiêu chí bao phủ dựa trên đồ thị có mỗi quan hệ phụ thuộc được trình bày trong hình 4.18 trong đó chúng ta ký hiệu A->B: tiêu chí A mạnh hơn tiêu chí B nghĩa là, nếu tiêu chí A được thoải mãn thì tiêu chí B sẽ cũng được thỏa mãn, người lại có thể không tồn tại quan hệ giữa hai tiêu chí, chúng ta nói chung không thể so sánh được
Hình 3.26 quan hệ giữa các tiêu chí bao phủ
Chúng ta có thểđặt câu hỏi ở đây: Tại sao phải định nghĩa các tiêu chí bao phủ "yếu" trong khi các tiêu chi bao phủ "mạnh" khác đã kéo theo chúng? Chẳng hạn. Khi tiêu chi bao phủ lộ trình độc lập thỏa mãn thì kéo theo tiêu chí bao phủ cũng thỏa mãn. Vậy, lợi ích của tiêu chí bao phủ cung là gì ? Thực ra, các tiêu chí càng mạnh, nghĩa là có độ tin cậy càng cao. Thì yêu cầu tập các ca kiểm thử càng lớn. Nghĩa là yêu cầu chi phí kiểm thử càng cao.
Khi kiểm thử, tiêu chí nào tốt nhất để lựa chọn ? Để trả lời câu hỏi này, cần xem xét nhiều yêu tố khác nhau. Trước hết, yếu tố thứ nhất liên quan đến mức độ tin cậy mà nhóm kiểm thử muốn đạt được Chẳng hạn đối với một số ứng dụng quan trọng, tính an toàn của phần mềm được yêu cầu cao. Khi đó một tiêu chí mạnh nên được chọn, vì yếu tố chi phí trở nên thứ yếu. Yểu tố thứ hai liên quan đến loại lỗi mà chúng ta muốn phát hiện. Chẳng hạn, chúng ta muốn phát hiện các lỗi liên quan đến điều khiển hay các lỗi liên quan đến dữ liệu. Yếu tố thứba liên quan đến độ hiệu quá của tiêu chí bao phủ độ hiệu quả của tiêu chí bao phủ có thể xem là quan hệ giữa độ tin cậy của tiêu chí và độ phức tạp của tiêu chí. Tiêu chí càng mạnh thì độ tin cậy của tiêu chí càng cao. Trong khi độ phức tạp của tiêu chí biểu diễn số lộ trình cần thực thi để thoả mãn tiêu chí.
Ngoài các kỹ thuật kiểm thử câu trúc dựa trên đồ thị, còn có nhiều kỹ thuật kiểm thử cấu trúc khác. Trong phạm vi của tài liệu này, chúng tôi trình bày thêm một kĩ thuật kiểm thửđược ứng dụng rất rộng rải: Kiểm thửđột biến (mutation testing).