Kiểm thử đột biến và khả năng phát hiện lỗi biên

1. Độ bao phủ cao có phát hiện lỗi ở biên?

Xét hàm quyết định có chấp nhận sĩ số đăng ký học phần. Đặc tả chấp nhận mọi số nguyên từ 15 đến 45. Một ca kiểm thử với sĩ số 25 đã thực thi câu lệnh trả về, nhưng kết quả đó vẫn đúng nếu lập trình viên vô tình loại giá trị 15 hoặc nhận nhầm 46. Kiểm thử đột biến cho phép kiểm tra trực tiếp độ nhạy của bộ ca với những sai lệch được mô hình hóa bằng các thay đổi nhỏ trong chương trình.

Để tránh sao chép logic triển khai vào oracle, mã ví dụ dùng bảng kỳ vọng do người thiết kế ca lập từ đặc tả. Một đột biến bị phát hiện khi có ít nhất một ca cho kết quả khác bảng này. Mọi biến thể đều dùng cùng bảng kỳ vọng và chỉ thay một hành vi mỗi lần. Thiết kế này giúp quy sự khác biệt quan sát được cho ca thử hoặc cho đột biến cụ thể.

2. Chọn đột biến và xác định mẫu số

M1 đổi điều kiện dưới thành nghiêm ngặt nên loại nhầm 15. M2 làm tương tự ở đầu trên và loại nhầm 45. M3 mở rộng biên trên thêm một đơn vị, chấp nhận nhầm 46. M4 xóa hẳn giới hạn trên. M5 thay n <= 45 bằng n < 46. Hai biểu thức của M5 tương đương trên miền số nguyên vì không có số nguyên nào nằm giữa 45 và 46. Kết luận này phụ thuộc vào đặc tả kiểu dữ liệu.

Mẫu số minh họa gồm bốn đột biến khác hành vi. Trong dự án thực, một đột biến sống có thể do ca chưa chạy tới đoạn bị sửa, do dữ liệu chưa kích hoạt sai lệch, hoặc do bộ kiểm thử quan sát sai đại lượng. Lỗi biên dịch và hết thời gian cũng cần được báo riêng. Việc phân loại đó cho phép người đọc tái tạo mẫu số và tránh nhầm kết quả chạy công cụ với bằng chứng về đặc tả.

3. Đọc kết quả theo từng đột biến

Chạy bằng Python 3. Bộ ca tập trung vào giữa miền phát hiện M4 nhờ giá trị 50, đạt 1/4. Bộ ca bao quanh hai biên phát hiện cả bốn, đạt 4/4. Giá trị 46 cùng lúc phát hiện M3 và M4, nên xóa 50 khỏi bộ thứ hai vẫn giữ khả năng phát hiện bốn đột biến đã chọn. Phân tích ma trận ca–đột biến giải thích được giá trị bổ sung của từng ca và phát hiện ca dư trong thiết kế này.

"""Đo khả năng phát hiện lỗi của hai bộ ca kiểm thử sĩ số nguyên."""

MUTANTS = {
    "M1 loại nhầm 15": lambda x: 15 < x <= 45,
    "M2 loại nhầm 45": lambda x: 15 <= x < 45,
    "M3 nhận nhầm 46": lambda x: 15 <= x <= 46,
    "M4 bỏ giới hạn trên": lambda x: x >= 15,
    "M5 tương đương trên miền số nguyên": lambda x: x in range(15, 46),
}
EQUIVALENT = {"M5 tương đương trên miền số nguyên"}


def report(cases):
    killed = {name: [x for x, expected in cases if implementation(x) != expected]
              for name, implementation in MUTANTS.items()}
    numerator = sum(bool(killed[name]) for name in MUTANTS.keys() - EQUIVALENT)
    return numerator, len(MUTANTS) - len(EQUIVALENT), killed


if __name__ == "__main__":
    central = [(30, True), (50, False)]
    boundary = [(14, False), (15, True), (45, True), (46, False)]
    for label, cases in [("Giữa miền", central), ("Qua hai biên", boundary)]:
        hit, total, detail = report(cases)
        print(label, f"{hit}/{total}", detail)
    assert report(central)[:2] == (1, 4)
    assert report(boundary)[:2] == (4, 4)

4. Chuyển ví dụ thành thí nghiệm

Chọn một tập hàm có ràng buộc số lượng, ngày giờ và trạng thái. Chuẩn bị hai bộ kiểm thử có cùng ngân sách thời gian. Một bộ dùng thiết kế biên theo đặc tả, bộ kia dùng bộ ca hiện hành. Giữ nguyên phiên bản công cụ và tập toán tử, công bố báo cáo sống/chết theo từng mô-đun và ghi lại cách xử lý đột biến tương đương. Với các đột biến sống, phân tích một mẫu thủ công trước khi đề nghị mở rộng toàn bộ bộ ca.

Câu hỏi tiếp theo là mức cải thiện có đi cùng khả năng bắt lỗi đã xảy ra trong lịch sử hay không. Có thể giữ riêng các lỗi đã sửa để đánh giá hai bộ ca trên cùng tập lỗi, sau khi thiết kế xong. Điểm 4/4 trong ví dụ chỉ mô tả tập đột biến được công bố. Đọc thêm khảo sát của Jia và Harman về kiểm thử đột biến.