Vibe coding giúp người làm sản phẩm có thể mô tả yêu cầu bằng ngôn ngữ tự nhiên rồi sử dụng AI để tạo, sửa hoặc mở rộng code nhanh hơn. Tuy nhiên, một ứng dụng “chạy được” sau vài vòng prompt chưa đồng nghĩa với việc nó đã sẵn sàng cho người dùng thật.
Trước khi phát hành sản phẩm vibe coding, cần kiểm thử ít nhất 5 nhóm: chức năng chính, dữ liệu đầu vào bất thường, bảo mật, hiệu năng và hồi quy sau mỗi lần AI sửa code. Ngoài ra, nên kiểm tra dependency, API key, quyền truy cập và những đoạn code do AI tạo nhưng chưa được người phát triển hiểu rõ.
Mục tiêu của kiểm thử không phải chứng minh AI viết code tốt hay xấu. Mục tiêu là xác định sản phẩm có hoạt động đúng, an toàn và ổn định trong những tình huống mà người dùng thực tế có thể tạo ra.
Vì sao sản phẩm vibe coding vẫn cần kiểm thử kỹ?
AI có thể tạo code rất nhanh, nhưng tốc độ sinh code không thay thế được quá trình kiểm chứng.
Một đoạn code có thể chạy đúng trong tình huống demo nhưng lỗi khi người dùng nhập dữ liệu khác dự kiến. Một tính năng mới cũng có thể vô tình làm hỏng tính năng đã hoạt động trước đó.
Với vibe coding, rủi ro còn xuất hiện khi người dùng chấp nhận code do AI sinh ra mà chưa hiểu đầy đủ logic bên trong. AI có thể tạo thêm dependency, thay đổi cấu trúc dữ liệu hoặc xử lý lỗi theo cách không phù hợp với toàn bộ hệ thống.
Vì vậy, sau mỗi giai đoạn phát triển, cần đặt câu hỏi: “Tôi đã kiểm tra sản phẩm này bằng những tình huống khác với tình huống demo chưa?”
1. Kiểm thử chức năng chính trước
Bắt đầu từ những hành động quan trọng nhất mà người dùng phải thực hiện.
Ví dụ, với một ứng dụng quản lý công việc, luồng chính có thể gồm:
- Tạo tài khoản hoặc đăng nhập.
- Tạo công việc.
- Chỉnh sửa nội dung.
- Thay đổi trạng thái.
- Xóa công việc.
- Đăng xuất và đăng nhập lại.
Không nên chỉ kiểm tra mỗi việc nút có bấm được hay không. Hãy kiểm tra cả kết quả sau hành động.
Nếu người dùng tạo một bản ghi mới, dữ liệu có thực sự được lưu không? Sau khi tải lại trang, bản ghi có còn tồn tại không? Nếu xóa, dữ liệu có biến mất đúng nơi cần thiết không?
Một cách đơn giản là viết danh sách theo cấu trúc:
Hành động → Kết quả mong đợi → Kết quả thực tế.
Cách này giúp phát hiện những lỗi dễ bị bỏ qua khi chỉ thử sản phẩm theo cảm giác.
2. Kiểm tra dữ liệu sai và tình huống biên
Sản phẩm thường dễ hoạt động khi người dùng nhập đúng như người phát triển dự kiến. Lỗi thường xuất hiện khi dữ liệu không đẹp như vậy.
Hãy thử các trường hợp như:
- Bỏ trống trường bắt buộc.
- Nhập chuỗi quá dài.
- Nhập ký tự đặc biệt.
- Nhập sai định dạng email.
- Gửi form nhiều lần liên tiếp.
- Tải file sai loại.
- Nhập số âm vào trường chỉ chấp nhận số dương.
- Mất kết nối giữa lúc gửi dữ liệu.
Mục tiêu là kiểm tra hệ thống có phản hồi rõ ràng hay bị crash, treo hoặc lưu dữ liệu sai.
Với code do AI tạo, phần validation rất dễ bị bỏ sót nếu prompt ban đầu chỉ yêu cầu “xây chức năng”. Vì vậy, sau khi chức năng hoạt động, nên yêu cầu kiểm tra riêng các trường hợp input không hợp lệ thay vì mặc định code đã xử lý đầy đủ.
3. Kiểm tra bảo mật trước khi đưa sản phẩm ra ngoài
Một sản phẩm dùng nội bộ trên máy cá nhân và một sản phẩm được mở cho người dùng thật có mức rủi ro khác nhau.
Trước khi phát hành, cần kiểm tra ít nhất các điểm cơ bản.
Không để secret trong code công khai
API key, token, mật khẩu database hoặc thông tin xác thực không nên được đặt trực tiếp trong repository công khai hoặc frontend.
Nếu AI từng sinh code có chứa key thật, cần thay đổi key đó và chuyển thông tin nhạy cảm sang cơ chế quản lý phù hợp như environment variable.
Kiểm tra authentication và quyền truy cập
Đăng nhập thành công chưa đủ. Hãy kiểm tra một người dùng có thể truy cập dữ liệu của người khác hay không.
Ví dụ, nếu thay một ID trong URL hoặc request API, hệ thống có trả về dữ liệu không thuộc quyền của tài khoản hiện tại không?
Quyền truy cập nên được kiểm tra ở backend thay vì chỉ ẩn nút trên giao diện.
Kiểm tra input từ người dùng
Không nên mặc định dữ liệu gửi từ browser là đáng tin cậy.
Backend cần kiểm tra dữ liệu nhận được trước khi lưu hoặc sử dụng. Các trường đầu vào, upload file và tham số API đều cần được xem xét phù hợp với loại ứng dụng.
Kiểm tra dependency
Code do AI tạo có thể thêm thư viện mới để giải quyết nhanh một yêu cầu.
Hãy kiểm tra:
- Thư viện đó có thực sự cần thiết không?
- Có đang dùng phiên bản quá cũ không?
- Dependency có được khai báo đúng không?
- Có thể loại bỏ package không dùng nữa không?
Các nguyên tắc kiểm thử bảo mật nên được đối chiếu thêm với tài liệu chính thức như OWASP khi bước sang môi trường thật. Bài này không tự gán checklist OWASP cụ thể do RESEARCH=NO.
4. Kiểm tra hiệu năng trong tình huống gần thực tế
Một ứng dụng phản hồi nhanh với 5 bản ghi chưa chắc vẫn ổn khi có hàng nghìn bản ghi.
Không cần triển khai hệ thống benchmark phức tạp ngay từ đầu. Với sản phẩm nhỏ, có thể bắt đầu bằng những kiểm tra thực tế:
- Trang có chậm đáng kể khi dữ liệu tăng không?
- Một thao tác có tạo quá nhiều request không?
- API AI có bị gọi lại không cần thiết không?
- Upload file lớn có làm ứng dụng đứng không?
- Người dùng bấm nút liên tục có tạo nhiều bản ghi giống nhau không?
Nếu sản phẩm dùng AI API, cần chú ý thêm thời gian phản hồi và số lần gọi model.
Một chức năng chạy được nhưng mỗi thao tác tạo nhiều request AI dư thừa có thể làm tăng độ trễ và chi phí khi số lượng người dùng tăng.
Hiệu năng vì vậy không chỉ là tốc độ giao diện. Nó còn liên quan tới cách ứng dụng sử dụng database, API và tài nguyên bên ngoài.
5. Luôn kiểm thử hồi quy sau khi AI sửa code
Đây là bước đặc biệt quan trọng trong vibe coding.
Bạn có thể yêu cầu AI sửa lỗi đăng nhập và nhận lại một thay đổi lớn hơn dự kiến. Lỗi cũ được sửa nhưng một chức năng khác có thể bị ảnh hưởng.
Sau mỗi thay đổi đáng kể, hãy chạy lại những luồng quan trọng đã từng hoạt động.
Ví dụ, sau khi sửa tính năng authentication, nên kiểm tra lại:
- Đăng ký.
- Đăng nhập.
- Đăng xuất.
- Khôi phục phiên làm việc.
- Quyền truy cập.
- Các trang yêu cầu đăng nhập.
Không nên chỉ test đúng lỗi vừa sửa.
Nếu có điều kiện, hãy tự động hóa các test quan trọng. Unit test và integration test giúp phát hiện nhanh khi một thay đổi mới phá vỡ hành vi cũ.
Tìm hiểu chương trình Vibe Coding tại FUNiX
Checklist kiểm thử sản phẩm vibe coding trước khi phát hành
Chức năng
- Các luồng quan trọng hoạt động từ đầu đến cuối.
- Dữ liệu được lưu và đọc lại đúng.
- Các nút và form thực hiện đúng hành động.
- Thông báo lỗi đủ rõ để người dùng hiểu.
Dữ liệu lỗi
- Trường bắt buộc không thể bỏ trống.
- Input sai định dạng được xử lý.
- Dữ liệu quá dài hoặc bất thường không làm ứng dụng crash.
- Request lặp không tạo dữ liệu ngoài ý muốn.
Bảo mật
- Không có API key hoặc mật khẩu trong repository public.
- Authentication hoạt động đúng.
- Người dùng không truy cập được dữ liệu ngoài quyền.
- Backend kiểm tra dữ liệu đầu vào.
- Dependency không cần thiết đã được loại bỏ.
Hiệu năng
- Các trang chính tải ở mức chấp nhận được.
- Không có request API lặp không cần thiết.
- Dữ liệu lớn hơn mức demo không làm ứng dụng hỏng.
- Lỗi từ dịch vụ bên ngoài được xử lý.
Hồi quy
- Sau thay đổi mới, các luồng cũ vẫn hoạt động.
- Lỗi đã sửa không xuất hiện trở lại.
- Những chức năng quan trọng có test lặp lại.
- Có thể quay lại phiên bản trước nếu bản mới gặp lỗi nghiêm trọng.
Kiểm tra riêng phần code do AI tạo
Với vibe coding, không nên bỏ qua bước đọc lại code quan trọng chỉ vì ứng dụng đang chạy.
Hãy ưu tiên kiểm tra những phần có liên quan tới:
- Authentication.
- Phân quyền.
- Database.
- Thanh toán nếu có.
- File upload.
- API bên ngoài.
- Dữ liệu cá nhân.
- Các thao tác xóa hoặc sửa dữ liệu.
Nếu không hiểu một đoạn code, có thể yêu cầu AI giải thích từng phần, nhưng phần giải thích cũng cần được đối chiếu với code thực tế.
Một nguyên tắc hữu ích là: đoạn code càng có khả năng gây mất dữ liệu, lộ dữ liệu hoặc thay đổi quyền truy cập thì càng cần được kiểm tra thủ công kỹ hơn.
Quy trình kiểm thử thực tế có thể làm theo 6 bước
Để tránh test theo cảm giác, có thể sử dụng quy trình ngắn sau:
Bước 1: Liệt kê luồng quan trọng
Viết ra những hành động mà nếu chúng hỏng thì sản phẩm gần như không thể sử dụng.
Bước 2: Test happy path
Thử các tình huống người dùng nhập đúng dữ liệu và thao tác theo dự kiến.
Bước 3: Test lỗi và edge case
Cố tình nhập sai, thiếu dữ liệu hoặc thực hiện thao tác ngoài dự kiến.
Bước 4: Kiểm tra bảo mật cơ bản
Rà lại secret, quyền truy cập, dữ liệu đầu vào và dependency.
Bước 5: Chạy lại các chức năng cũ
Sau khi sửa lỗi, kiểm thử hồi quy để đảm bảo thay đổi mới không phá chức năng khác.
Bước 6: Cho người khác sử dụng thử
Người phát triển thường thao tác theo đúng cách mình đã hình dung. Một người chưa từng dùng sản phẩm có thể nhanh chóng phát hiện những vấn đề về luồng sử dụng, thông báo lỗi hoặc tình huống bạn chưa nghĩ tới.
Những lỗi thường gặp khi test sản phẩm vibe coding
Chỉ kiểm tra xem ứng dụng có chạy hay không
“Không báo lỗi” không đồng nghĩa với “hoạt động đúng”.
Cần kiểm tra dữ liệu đầu ra, trạng thái hệ thống và những tác động sau mỗi hành động.
Sửa lỗi bằng AI rồi không test lại phần khác
Đây là cách lỗi hồi quy dễ lọt vào sản phẩm.
Sau một thay đổi lớn, luôn chạy lại các luồng quan trọng.
Tin rằng AI đã xử lý bảo mật
AI có thể đề xuất các biện pháp bảo mật, nhưng không nên mặc định code sinh ra đã an toàn.
Bảo mật cần được kiểm tra như một hạng mục riêng.
Chỉ dùng dữ liệu demo đẹp
Người dùng thật sẽ nhập sai, bấm hai lần, refresh trang hoặc sử dụng sản phẩm theo những cách không dự kiến.
Test nên phản ánh những hành vi đó.
Khi nào sản phẩm vibe coding có thể đưa cho người dùng?
Không có phần mềm nào hoàn toàn không có lỗi. Mục tiêu trước khi phát hành là giảm những lỗi có tác động lớn xuống mức có thể kiểm soát.
Một sản phẩm có thể tiến gần tới trạng thái sẵn sàng khi:
- Luồng chính hoạt động ổn định.
- Dữ liệu sai được xử lý hợp lý.
- Không phát hiện vấn đề bảo mật nghiêm trọng.
- Các tính năng quan trọng đã được test lại sau thay đổi.
- Ứng dụng có cách ghi nhận và xử lý lỗi.
- Có phương án khôi phục nếu bản phát hành gặp vấn đề.
Vibe coding có thể rút ngắn thời gian từ ý tưởng tới phiên bản chạy được. Nhưng khoảng cách từ “chạy được” đến “dùng được một cách đáng tin cậy” vẫn cần testing, review và tư duy kỹ thuật của con người.
Bình luận (0
)