Kiểm thử đột biến cho mã nguồn do Agent viết

Các bộ kiểm thử (test suites) do LLM tạo ra có thể đạt mức độ bao phủ dòng (line coverage) và nhánh (branch coverage) lên tới 100%, nhưng một nghiên cứu gần đây cho thấy chúng chỉ đạt 4% trong kiểm thử đột biến, làm lộ ra một lỗ hổng về độ tin cậy mà các nhà phát triển có thể bỏ lỡ trong các buổi sprint review.

Các nhà nghiên cứu đã đánh giá các bộ kiểm thử được tạo ra bởi các coding agent dựa trên mô hình ngôn ngữ lớn trên bộ chuẩn HumanEval-Java. Một bộ kiểm thử đã bao phủ mọi dòng mã và thực thi mọi nhánh điều kiện. Tuy nhiên, khi chính bộ kiểm thử đó đối mặt với kiểm thử đột biến — một kỹ thuật chèn các lỗi nhỏ để xem liệu các bài kiểm tra có phát hiện được chúng hay không — nó chỉ bắt được một phần rất nhỏ các lỗi đã được chèn vào.

Độ bao phủ trông có vẻ tốt, nhưng ý nghĩa thực sự là gì?

Các chỉ số bao phủ truyền thống chỉ đếm xem có bao nhiêu câu lệnh hoặc nhánh mà một bài kiểm tra thực hiện. Các nhóm phát triển thường rất thích những con số ấn tượng trong các buổi sprint demo. Tuy nhiên, chỉ số này không cho biết liệu các bài kiểm tra có thất bại hay không nếu mã nguồn bị sai. Kiểm thử đột biến lấp đầy khoảng trống đó bằng cách cố tình đưa vào các lỗi (mutants) và đo lường tỷ lệ phần trăm các đột biến đó gây ra lỗi kiểm thử — gọi là "điểm đột biến" (mutation score).

Trong nghiên cứu, bộ kiểm thử có độ bao phủ 100% đã bỏ lỡ hầu hết mọi đột biến, bao gồm cả các lỗi logic đơn giản như xử lý sai ngày năm nhuận. Điểm đột biến 4% có nghĩa là bộ kiểm thử này sẽ chỉ phát hiện được một số rất ít lỗi thực tế.

Tại sao điều này lại quan trọng đối với phát triển phần mềm với sự hỗ trợ của AI

  • Sự tự tin giả tạo: các nhà phát triển có thể tin tưởng vào một bộ kiểm thử trông có vẻ hoàn hảo trên lý thuyết.
  • Khuyết tật tiềm ẩn: nhiều lỗi lọt qua mà không được chú ý.
  • Chi phí khắc phục: việc sửa lỗi sau này tốn kém hơn nhiều so với việc phát hiện chúng sớm.

Quan điểm ngược lại: độ bao phủ không phải là vô dụng

Độ bao phủ vẫn cho bạn biết liệu các đường dẫn mã có được thực thi hay không, nhưng nó không đảm bảo việc phát hiện lỗi.

Những điều cần lưu ý tiếp theo

  • Tích hợp công cụ: nhúng kiểm thử đột biến vào các pipeline CI.
  • Cải tiến LLM: huấn luyện các agent tạo ra các bài kiểm thử có khả năng "tiêu diệt" (kill) các đột biến.
  • Hướng dẫn trong ngành: áp dụng các tiêu chuẩn kết hợp độ bao phủ với điểm đột biến.

Bài học rút ra: Các con số độ bao phủ cao từ các bài kiểm thử do AI tạo ra không còn là minh chứng đầy đủ cho chất lượng; điểm đột biến thấp báo hiệu rằng các bài kiểm thử có thể không bắt được lỗi thực tế, thúc giục các nhà phát triển áp dụng kiểm thử đột biến như một mạng lưới an toàn.