Kiểm thử code do AI tạo: danh sách kiểm tra trước khi deploy

Bạn vừa dùng AI để tạo một tính năng cho website, chạy thử thấy ổn và đang muốn deploy ngay? Khoan đã nhé! Một màn hình chạy được mới chỉ chứng minh một happy path, chưa chứng minh code đó xử lý đúng dữ liệu xấu, quyền truy cập, tốc độ tải hay lỗi tích hợp.

Kiểm thử code do AI tạo cần nhiều lớp độc lập: hiểu yêu cầu, kiểm tra chức năng, kiểm tra tích hợp, security, accessibility, performance, staging và rollback. Mình sẽ đưa checklist theo thứ tự thực thi để bạn có thể dùng cho một website doanh nghiệp hoặc công cụ nội bộ mà không biến QA thành một quy trình quá nặng.

Vì sao cần kiểm thử code do AI tạo?

Code do AI tạo cần được xem như đầu vào chưa được xác minh, giống một pull request từ người mới vào team. Nó có thể đúng ở ví dụ bạn đưa ra nhưng vẫn bỏ sót điều kiện biên, quy tắc nghiệp vụ hoặc ràng buộc có trong phần khác của hệ thống.

Điểm khó là AI thường tạo cả code lẫn test khá nhanh. Nếu cùng một giả định sai được dùng để viết hai phần, test có thể pass trong khi hành vi thực tế vẫn sai. OWASP khuyến cáo không xem test suite do AI sinh ra hoặc tỷ lệ test pass là bằng chứng đủ về bảo mật; các luồng authentication, authorization, input validation và cryptography cần được kiểm tra độc lập bởi con người [1].

Một nghiên cứu enterprise công bố tháng 7/2026 cũng ghi nhận tải review trên mỗi reviewer tăng khoảng gấp đôi trong case study có áp dụng AI coding ở quy mô lớn [2]. Con số này không phải benchmark cho mọi doanh nghiệp, nhưng cho thấy bottleneck có thể chuyển từ viết code sang review và validation. Thú vị nhỉ! Vì vậy, checklist tốt phải giúp reviewer tập trung vào rủi ro quan trọng thay vì đọc thủ công từng dòng.

Checklist chức năng: code có làm đúng việc không?

Trước khi chạy test, hãy viết rõ đầu vào, đầu ra và điều kiện chấp nhận của tính năng. Đây là bước giúp bạn phát hiện việc AI hiểu sai yêu cầu, thay vì chỉ xác nhận rằng code chạy mà không báo lỗi.

Với một form liên hệ, chẳng hạn, acceptance criteria không chỉ là “gửi form thành công”. Bạn nên ghi rõ email hợp lệ, trường bắt buộc, giới hạn độ dài, ký tự đặc biệt, trạng thái gửi lại, thông báo lỗi, chống gửi trùng và cách lưu dữ liệu. Nếu yêu cầu chưa đủ cụ thể, AI có thể tự chọn hành vi mà bạn không hề muốn.

Hãy kiểm tra theo ba nhóm sau:

• Happy path: dữ liệu hợp lệ, quyền đúng, dịch vụ phụ thuộc đang hoạt động.
• Boundary cases: chuỗi rỗng, giá trị biên, file lớn, ký tự Unicode, timeout và dữ liệu trùng.
• Failure path: API lỗi, database mất kết nối, người dùng refresh, request gửi lặp hoặc job chạy hai lần.

Ở lớp unit test, ưu tiên các hàm có logic nghiệp vụ và kết quả xác định. Đừng chỉ kiểm tra số lượng dòng code hoặc chạy một ví dụ mẫu. Một test đáng tin phải thất bại nếu bạn cố tình đổi quy tắc nghiệp vụ thành sai.

// Kiểm tra dữ liệu không hợp lệ phải bị từ chối
test('từ chối email rỗng', () => {
  const result = validateContactForm({ email: '' });
  expect(result.valid).toBe(false);
  expect(result.errors.email).toBe('Email là bắt buộc');
});

Đây cũng là lúc bạn yêu cầu AI giải thích từng test: test đang bảo vệ quy tắc nào, còn thiếu trường hợp nào và vì sao expected result là đúng. Nếu AI không trả lời rõ, reviewer nên xem lại cả code lẫn test.

Kiểm thử integration và E2E như thế nào?

Integration test kiểm tra các thành phần có phối hợp đúng không, còn E2E kiểm tra hành trình người dùng từ đầu đến cuối. Hai lớp này bắt những lỗi mà unit test thường không thấy, đặc biệt ở API, database, authentication và cấu hình môi trường.

Hãy dựng một ma trận nhỏ trước khi chạy:

• Frontend gửi request đúng schema và xử lý đúng mã lỗi API chưa?
• API có ghi dữ liệu đúng transaction, timezone và encoding không?
• Người dùng chưa đăng nhập có bị chặn ở cả giao diện lẫn server không?
• Quyền của user thường, editor và admin có khác nhau đúng như yêu cầu không?
• Webhook, email, thanh toán hoặc dịch vụ bên thứ ba timeout thì hệ thống hiển thị gì?

Với E2E, chỉ cần chọn những flow mang giá trị kinh doanh cao: đăng nhập, gửi form, tạo đơn, thanh toán giả lập, cập nhật nội dung hoặc quy trình mà khách hàng dùng hàng ngày. Chạy E2E cho mọi chi tiết nhỏ có thể làm pipeline chậm và khó bảo trì.

Bạn có thể dùng dữ liệu giả lập, database riêng và service mock ở CI. Tuy nhiên, trước production vẫn cần một lần smoke test với cấu hình gần thật trên staging. Đừng đưa secret production vào test runner chỉ để làm cho bài test “giống thật” hơn.

Security và accessibility: hai lớp dễ bị bỏ quên

Security test phải kiểm tra cả dữ liệu xấu và quyền sai; accessibility test phải kiểm tra khả năng sử dụng, không chỉ điểm số từ một công cụ tự động. Đây là hai lớp không nên giao hoàn toàn cho AI vì lỗi thường nằm ở ngữ cảnh hệ thống.

Checklist security tối thiểu cho một website gồm:

• Không có API key, mật khẩu hoặc token hardcode trong source, log và file build.
• Input được validate ở server; output được escape đúng ngữ cảnh.
• Endpoint yêu cầu authentication và authorization riêng, không chỉ ẩn nút trên giao diện.
• Upload file có giới hạn loại, kích thước, tên file và vị trí lưu.
• Dependency được scan, lock version hợp lý và rà lại permission của package.
• Rate limit, CSRF, session, CORS và error message được kiểm tra theo kiến trúc thực tế.

OWASP Top 10 bản phát hành hiện tại là 2025 [3]. Bạn có thể dùng tài liệu này như khung rà soát rủi ro web, nhưng đừng biến nó thành một checklist máy móc. Nếu tính năng xử lý dữ liệu cá nhân, thanh toán hoặc quyền admin, nên có security review độc lập.

Với accessibility, hãy chạy công cụ tự động để tìm lỗi cơ bản rồi kiểm tra thủ công bằng bàn phím: focus có nhìn thấy không, thứ tự tab có hợp lý không, form có label rõ không, thông báo lỗi có được đọc không. WCAG 2.2 nhóm yêu cầu theo bốn nguyên tắc perceivable, operable, understandable và robust, với các success criteria có thể kiểm thử ở mức A, AA và AAA [4].

Performance, staging và rollback cần kiểm tra gì?

Một tính năng đúng nhưng làm website chậm hoặc không thể rollback vẫn chưa sẵn sàng để deploy. Performance test nên bắt đầu từ hành trình quan trọng, dữ liệu gần thật và thiết bị mà khách hàng thực sự sử dụng.

Với website, bạn có thể theo dõi Core Web Vitals: LCP cho tốc độ hiển thị nội dung lớn, INP cho khả năng phản hồi và CLS cho độ ổn định bố cục. Ngưỡng khuyến nghị hiện tại ở percentile 75 là LCP không quá 2,5 giây, INP không quá 200 mili giây và CLS không quá 0,1 [5]. Đây là mục tiêu đo lường trải nghiệm, không phải lời hứa rằng mọi người dùng sẽ luôn đạt điểm đó.

Hãy đo trước và sau thay đổi, đồng thời kiểm tra:

• Thời gian phản hồi API ở tải bình thường và khi có nhiều request đồng thời.
• Truy vấn database có bị lặp, thiếu index hoặc kéo quá nhiều bản ghi không?
• JavaScript, ảnh và font mới có làm tăng kích thước trang không?
• Job nền có bị chạy lặp hoặc chiếm hết tài nguyên khi dữ liệu tăng không?

Trên staging, chạy smoke test sau build và migration. Kiểm tra biến môi trường, domain callback, cron, cache, email sandbox và quyền truy cập. Sau đó diễn tập rollback: biết chính xác lệnh hoặc artifact nào đưa hệ thống về phiên bản trước, database migration có đảo ngược được không và ai là người quyết định dừng release.

Quy trình CI trước khi deploy website thật

Hãy biến checklist thành cổng tự động trong CI, nhưng giữ human sign-off cho thay đổi có rủi ro. GitHub Docs liệt kê lint, security checks, code coverage và functional tests là những loại kiểm tra có thể chạy trong CI, với kết quả hiển thị trên pull request [6].

Một pipeline gọn có thể đi theo thứ tự:

1. Kiểm tra format, lint, type và dependency lockfile.
2. Chạy unit test và kiểm tra coverage của phần logic quan trọng.
3. Chạy integration/E2E với database và service mock.
4. Chạy secret scan, dependency scan và security smoke test.
5. Build artifact, deploy lên staging rồi chạy smoke test.
6. Đo performance cơ bản và rà accessibility bằng công cụ cộng với kiểm tra thủ công.
7. Reviewer xác nhận acceptance criteria, migration, log, backup và rollback.
8. Chỉ deploy production khi mọi gate bắt buộc đều pass.

AI có thể giúp viết test case, sinh dữ liệu giả, giải thích lỗi hoặc đề xuất test còn thiếu. Nhưng người chịu trách nhiệm vẫn phải đọc các test quan trọng và đối chiếu với yêu cầu. Nếu test fail, đừng bảo AI tự sửa liên tục cho đến khi pipeline xanh mà không đọc diff; đó là cách biến “green build” thành ảo giác an toàn.

Bạn đang đọc bài viết thuộc chuyên mục Lập trình của VietnamTutor — nơi mình chia sẻ các workflow công nghệ có thể áp dụng vào website và hệ thống doanh nghiệp. Nếu cần thiết lập pipeline, bạn có thể xem thêm bài GitHub Actions CI/CD cho website.

Bạn nên dùng checklist này như thế nào?

Đừng áp dụng cùng một mức kiểm thử cho mọi thay đổi; hãy tăng độ nghiêm ngặt theo mức ảnh hưởng. Một chỉnh sửa màu nút có thể chỉ cần visual smoke test, còn thay đổi auth, thanh toán, dữ liệu khách hàng hoặc database cần đầy đủ security review, staging và rollback drill.

Mình khuyên bạn lưu checklist cùng pull request và ghi lại bằng chứng: link CI run, kết quả scan, screenshot staging, người review và phương án rollback. Cách này giúp chủ doanh nghiệp biết release đang dựa trên bằng chứng nào, thay vì dựa vào câu “AI đã kiểm tra rồi”. Với phần web, bạn có thể đối chiếu thêm checklist WCAG 2.2 và hướng dẫn Core Web Vitals.

Tóm lại, kiểm thử code do AI tạo không phải một bước cuối cùng. Đó là hệ thống nhiều lớp để kiểm tra code có đúng yêu cầu, phối hợp đúng, an toàn, accessible, đủ nhanh và có thể phục hồi khi gặp sự cố. Bạn đã có gate nào trong quy trình deploy của mình chưa? Chia sẻ kinh nghiệm nhé!

Nguồn tham khảo

1. OWASP Secure Coding with AI Cheat Sheet
2. AI Writes Faster Than Humans Can Review, arXiv 2607.01904
3. OWASP Top 10
4. W3C Web Content Accessibility Guidelines
5. web.dev Core Web Vitals
6. GitHub Docs: Continuous integration
7. GitHub Docs: Continuous deployment