Kỹ thuật · kiểm thử

Kiểm thử code
do AI viết
tránh test luôn xanh

Khi AI viết cả code lẫn test, test dễ chỉ xác nhận chính cái code. Câu hỏi đúng không phải "test có xanh không" mà là "code sai thì test có đỏ không".

Viết từ đặc tảThấy đỏ trướcTự phá codeBảng giá trị biên
500.000 có giảm giá không?
test xanh vẫn có thể sai
Ba ý chính

Test luôn xanh, nói gọn

1Xanh chưa đủ. Độ phủ 100% vẫn có thể bắt rất ít lỗi.
2Viết từ đặc tả, thấy đỏ trước. Test chưa từng đỏ thì chưa biết nó có bắt được gì.
3Tự phá code một chút. Test vẫn xanh nghĩa là có chỗ test không kiểm.

Tóm lại: bắt đầu bằng cách rẻ nhất, phá code bằng tay.
Lưu ý: ví dụ mã dựng lại. Con số 4% lấy từ bản tóm tắt một bài báo, mình chưa đọc toàn văn. Chưa chạy các công cụ nêu tên.

Từ khó, nói dễ

Sáu từ để theo dõi bài

Thuật ngữNói dễ hiểu
Độ phủTỷ lệ dòng code mà test chạy qua. Không nói test kiểm có đúng không
Kiểm thử đột biếnCố ý làm hỏng code một chút xem test có đỏ không
Điểm đột biếnTỷ lệ phiên bản bị phá mà test bắt được
Kiểm thử theo thuộc tínhMô tả một quy tắc luôn đúng, để công cụ thử nhiều đầu vào
Giá trị biênGiá trị nằm đúng trên vạch của quy tắc, như đúng 500 nghìn
Test luôn xanhTest không bao giờ đỏ, kể cả khi code sai
Ví dụ

Giảm 10% từ 500 nghìn trở lên

Yêu cầu

Đơn từ 500 nghìn trở lên được giảm 10%. Đúng 500.000 cũng được giảm.

Code AI viết

total > 500000. Hai test: 600.000 được giảm, 100.000 không. Cả hai xanh, độ phủ 100%.

Code sai: đúng 500.000 không được giảm, mà không test nào đỏ.
Tự phá code

Đổi > thành >= mà test vẫn xanh

Phiên bản codeTest 600.000Test 100.000Đúng 500.000
total > 500000 (sai)XanhXanhKhông giảm: sai
total >= 500000 (đúng)XanhXanhCó giảm: đúng
Thêm test đúng 500.000Đỏ với bản saiXanh với bản đúngĐây là test có giá trị
Bảy cách, phần một

Bốn cách đầu

1

Viết từ đặc tả

Nhìn yêu cầu, không nhìn code. Cho AI cả đặc tả và ví dụ.

2

Thấy đỏ trước

Viết test trước, chạy, thấy đỏ đúng lý do, rồi sửa.

3

Tự phá code

Đổi > thành >=, đổi 0.9 thành 0.8, bỏ một điều kiện.

4

Kiểm thử đột biến tự động

Công cụ tạo nhiều bản bị phá. Chậm, nên dùng ở phần lõi.

Bảy cách, phần hai

Ba cách còn lại

5

Theo thuộc tính

Quy tắc luôn đúng: kết quả không bao giờ lớn hơn tổng ban đầu.

6

Bảng giá trị biên

Ngay dưới, đúng bằng, ngay trên vạch. Cộng 0, số âm, rất lớn.

7

Chạy thật một lần

Mở ra bấm thử. Có lỗi chỉ mắt mới thấy.

Bảng giá trị biên

Ba giá trị cho mỗi ngưỡng

Đầu vàoKết quả mong đợi
499.999499.999, không giảm
500.000450.000, có giảm
500.001450.000,9, có giảm
0, số âm, rất lớn, trốngChỉ rõ cách xử lý từng trường hợp
Mùi test yếu

Dấu hiệu khi duyệt test do AI viết

Dấu hiệuVì sao yếu
Không có phép kiểmChỉ chạy qua dòng, không so kết quả
Mock mọi thứKiểm cái mock, không kiểm hành vi
Chụp đầu ra hiện tại làm đáp ánMọi lỗi sẵn có thành "đúng"
Bắt lỗi rồi nuốtChe mất thất bại
Giá trị mong đợi tính bằng chính công thức của codeCùng sai thì cùng đạt
Độ phủ

Độ phủ cao không chứng minh gì nhiều

Điều dễ tin

"Test chạy qua 100% dòng, vậy là an toàn."

Điều bài báo gợi ý

Bài MutGen (2025) cho rằng độ phủ là chỉ báo yếu về khả năng bắt lỗi, và nhắc một bộ test phủ 100% nhưng điểm đột biến khoảng 4% (theo bản tóm tắt).

Mình chưa đọc toàn văn bài báo.
Danh sách kiểm

Sáu câu hỏi khi duyệt test

1

Từ đặc tả hay từ code?

Test viết dựa vào đâu.

2

Đã thấy đỏ chưa?

Ít nhất một lần.

3

Phá code có đỏ không?

Thử một chỗ quan trọng.

4

Có bảng giá trị biên?

Cho mọi ngưỡng.

5

Phép kiểm thật, ít mock?

Không chỉ chạy qua.

6

Đã chạy thật chưa?

Đường chính của ứng dụng.

Nhờ AI viết test

Đổi cách nhờ

Thay vìThử viết
"Viết test cho hàm này""Đây là đặc tả và ba ví dụ. Viết test từ đặc tả, không từ code hiện có."
(không nói về biên)"Gồm giá trị ngay dưới, đúng bằng, ngay trên mỗi ngưỡng."
(không tự kiểm)"Rồi cố ý phá code ba cách và cho biết test nào đỏ."
Cân bằng

Bài này cũng có giới hạn

Điều nên nhớ
  • Ví dụ mã và con số được dựng lại
  • Con số 4% lấy từ bản tóm tắt
  • Công cụ chỉ nêu tên, chưa chạy
Đừng hiểu nhầm
  • Kiểm thử đột biến chậm
  • Đừng chạy theo điểm 100%
  • Test không thay việc chạy thật

Dùng có chọn lọc ở phần lõi quan trọng, và bắt đầu bằng cách phá code bằng tay.

Việc làm ngay

Chọn một hàm có ngưỡng trong dự án, đổi một dấu so sánh và chạy test.

Nếu test vẫn xanh, bạn vừa tìm được chỗ test không kiểm.