Cách kiểm thử ứng dụng được xây dựng bằng Vibe Coding
Bùi Tấn Lực - 103
- 12/10/2026
Vibe Coding đang giúp nhiều người xây dựng website, công cụ nội bộ và ứng dụng phần mềm bằng cách mô tả yêu cầu bằng ngôn ngữ tự nhiên, sau đó sử dụng AI để tạo mã nguồn. Phương pháp này rút ngắn thời gian phát triển, giúp người chưa có nhiều kinh nghiệm lập trình nhanh chóng biến ý tưởng thành sản phẩm có thể sử dụng.
Tuy nhiên, việc AI tạo ra một ứng dụng chạy được không đồng nghĩa với việc ứng dụng đó hoạt động chính xác, an toàn và ổn định. Một trang đăng nhập có thể hiển thị bình thường nhưng vẫn cho phép truy cập trái phép. Một chức năng thanh toán có thể hoàn thành trên giao diện nhưng ghi nhận sai dữ liệu. Một bản cập nhật nhỏ cũng có thể khiến những chức năng vốn hoạt động tốt trước đó bị lỗi.
Vì vậy, kiểm thử là bước không thể bỏ qua khi phát triển phần mềm bằng Vibe Coding. Mục tiêu không chỉ là tìm lỗi hiển thị mà còn phải xác minh ứng dụng có đáp ứng đúng yêu cầu, xử lý dữ liệu chính xác, bảo vệ thông tin và hoạt động ổn định trong những tình huống thực tế hay không.
Bài viết này hướng dẫn cách xây dựng quy trình kiểm thử ứng dụng Vibe Coding từ bước xác định yêu cầu, kiểm tra từng chức năng, đánh giá bảo mật đến kiểm thử hồi quy trước khi đưa sản phẩm vào sử dụng.
Vì sao ứng dụng tạo bằng Vibe Coding cần được kiểm thử kỹ?
Trong quy trình phát triển phần mềm truyền thống, lập trình viên thường phải hiểu tương đối rõ kiến trúc hệ thống, kiểu dữ liệu, luồng xử lý và các ràng buộc kỹ thuật. Với Vibe Coding, người dùng có thể yêu cầu AI thực hiện những thay đổi lớn mà không nhất thiết phải hiểu toàn bộ mã nguồn được tạo ra.
Điều này giúp tăng tốc độ phát triển nhưng cũng tạo ra một số rủi ro riêng. AI có thể đưa ra cách triển khai hợp lý về mặt hình thức nhưng chưa đáp ứng đầy đủ yêu cầu nghiệp vụ. Mã nguồn được sinh ra ở những lần yêu cầu khác nhau có thể thiếu nhất quán. Một thay đổi ở giao diện cũng có thể vô tình ảnh hưởng đến dữ liệu hoặc chức năng phía máy chủ.
Mã nguồn chạy được chưa chắc đã xử lý đúng nghiệp vụ
Giả sử bạn yêu cầu AI xây dựng một ứng dụng quản lý đơn hàng. Khi thử nghiệm, bạn thấy có thể thêm sản phẩm, nhập số lượng và nhấn nút lưu. Nhìn bề ngoài, chức năng có vẻ hoàn chỉnh.
Nhưng khi kiểm tra sâu hơn, bạn có thể phát hiện ứng dụng vẫn cho phép nhập số lượng âm, tính sai tổng tiền khi áp dụng mã giảm giá hoặc lưu đơn hàng dù dữ liệu khách hàng chưa đầy đủ. Nếu chỉ kiểm tra xem nút bấm có hoạt động hay không, những lỗi này rất dễ bị bỏ sót.
Kiểm thử đúng nghĩa phải xác minh kết quả có chính xác theo yêu cầu hay không, chứ không chỉ xác nhận rằng thao tác đã được thực hiện.
AI có thể sửa lỗi này nhưng vô tình tạo ra lỗi khác
Một tình huống thường gặp là ứng dụng đang hoạt động bình thường, nhưng sau khi yêu cầu AI sửa lỗi đăng nhập, chức năng ghi nhớ phiên đăng nhập hoặc phân quyền người dùng lại không còn hoạt động như trước.
Nguyên nhân có thể nằm ở việc AI thay đổi một hàm dùng chung, chỉnh sửa cấu trúc dữ liệu hoặc viết lại một phần logic có liên quan đến nhiều chức năng khác. Nếu chỉ kiểm tra đúng lỗi vừa sửa, bạn sẽ không phát hiện được những ảnh hưởng ngoài dự kiến.
Đó là lý do mỗi lần thay đổi mã nguồn cần có bước kiểm thử lại các chức năng liên quan, đặc biệt khi ứng dụng đã có nhiều thành phần phụ thuộc lẫn nhau.
Ứng dụng có thể tiềm ẩn lỗ hổng bảo mật
Mã nguồn do AI tạo ra không mặc nhiên an toàn. Những lỗi như kiểm tra quyền truy cập chưa đầy đủ, xử lý dữ liệu đầu vào không đúng cách, để lộ thông tin nhạy cảm hoặc sử dụng thư viện có lỗ hổng đều có thể xuất hiện nếu người phát triển không chủ động kiểm tra.
Ví dụ, một ứng dụng quản lý khách hàng có thể ẩn nút xem thông tin của người khác trên giao diện nhưng lại không kiểm tra quyền tương ứng ở phía máy chủ. Người dùng có thể tìm cách gọi trực tiếp API để truy cập dữ liệu không thuộc quyền của mình.
Với các ứng dụng xử lý thông tin cá nhân, dữ liệu kinh doanh, tài khoản người dùng hoặc thanh toán, kiểm thử bảo mật cần được xem là một phần bắt buộc của quá trình phát triển.
Xác định phạm vi kiểm thử trước khi bắt đầu
Không nên bắt đầu kiểm thử bằng cách mở ứng dụng rồi nhấn thử từng nút một cách ngẫu nhiên. Cách làm này có thể phát hiện một số lỗi dễ thấy nhưng khó bảo đảm các chức năng quan trọng đều được kiểm tra.
Trước tiên, hãy xác định ứng dụng được xây dựng để làm gì, ai sẽ sử dụng, dữ liệu nào được xử lý và những thao tác nào có thể gây hậu quả nếu xảy ra sai sót.
Lập danh sách chức năng cần kiểm tra
Hãy chia ứng dụng thành các nhóm chức năng. Chẳng hạn, với một website bán hàng được xây dựng bằng Vibe Coding, danh sách kiểm thử có thể bao gồm:
- Tài khoản: đăng ký, đăng nhập, đăng xuất, đổi mật khẩu và khôi phục tài khoản.
- Sản phẩm: hiển thị danh sách, tìm kiếm, lọc, xem chi tiết và quản lý thông tin sản phẩm.
- Giỏ hàng: thêm sản phẩm, thay đổi số lượng, xóa sản phẩm và tính tổng tiền.
- Đơn hàng: tạo đơn, lưu thông tin khách hàng, cập nhật trạng thái và tra cứu lịch sử.
- Quản trị: phân quyền, quản lý dữ liệu và giới hạn quyền truy cập.
- Tích hợp: gửi email, kết nối API, thanh toán hoặc đồng bộ dữ liệu với hệ thống bên ngoài nếu có.
- Giao diện: hiển thị trên máy tính, điện thoại, máy tính bảng và các trình duyệt cần hỗ trợ.
Danh sách này cần được điều chỉnh theo ứng dụng thực tế. Một công cụ quản lý công việc sẽ có các chức năng khác với website bán hàng, trong khi ứng dụng sử dụng AI để xử lý tài liệu sẽ cần kiểm tra thêm chất lượng kết quả, giới hạn dữ liệu đầu vào và cách xử lý khi dịch vụ AI không phản hồi.
Xác định kết quả đúng cho từng chức năng
Mỗi chức năng cần có tiêu chí đánh giá cụ thể. Nếu chỉ ghi chung chung rằng chức năng đăng nhập phải hoạt động, người kiểm thử sẽ khó xác định chính xác những trường hợp cần thử.
Với chức năng đăng nhập, các tiêu chí có thể gồm:
- Tài khoản hợp lệ và mật khẩu chính xác cho phép đăng nhập.
- Mật khẩu sai không được cấp quyền truy cập.
- Tài khoản không tồn tại không được tạo phiên đăng nhập hợp lệ.
- Trường dữ liệu trống được xử lý theo quy tắc đã xác định.
- Tài khoản bị khóa hoặc chưa được kích hoạt phải tuân theo chính sách của hệ thống.
- Người chưa đăng nhập không thể truy cập trực tiếp vào các trang yêu cầu xác thực.
- Người dùng thông thường không thể truy cập chức năng chỉ dành cho quản trị viên.
Khi tiêu chí đã rõ ràng, việc kiểm thử sẽ chuyển từ cảm nhận chủ quan sang quá trình đối chiếu kết quả thực tế với yêu cầu ban đầu.
Phân loại mức độ ưu tiên của lỗi
Không phải lỗi nào cũng có mức độ nghiêm trọng như nhau. Một lỗi lệch khoảng cách giữa hai nút thường ít rủi ro hơn lỗi làm mất dữ liệu hoặc cho phép người dùng truy cập trái phép.
Có thể chia lỗi thành ba nhóm để ưu tiên xử lý:
- Nghiêm trọng: có nguy cơ làm lộ dữ liệu, mất dữ liệu, truy cập trái phép, tính sai giao dịch hoặc khiến chức năng cốt lõi không thể sử dụng.
- Quan trọng: ảnh hưởng đến một chức năng thiết yếu, khiến người dùng không hoàn thành được một quy trình hoặc tạo ra kết quả không chính xác trong những trường hợp cụ thể.
- Thông thường: lỗi giao diện nhỏ, nội dung chưa rõ ràng hoặc vấn đề ít ảnh hưởng đến khả năng sử dụng và tính toàn vẹn của dữ liệu.
Thứ tự ưu tiên cần căn cứ vào tác động thực tế. Với ứng dụng tài chính, sai lệch số tiền có thể là lỗi nghiêm trọng. Với công cụ tạo nội dung, việc mất toàn bộ bản nháp chưa lưu cũng có thể ảnh hưởng đáng kể đến người dùng.
Các phương pháp kiểm thử cần áp dụng
Không có một phương pháp kiểm thử duy nhất phù hợp với mọi ứng dụng Vibe Coding. Cách tiếp cận hiệu quả là kết hợp kiểm thử chức năng, kiểm thử dữ liệu, kiểm thử tích hợp, kiểm thử giao diện, kiểm thử bảo mật và kiểm thử hồi quy theo quy mô của sản phẩm.
Kiểm thử chức năng
Kiểm thử chức năng nhằm xác minh mỗi tính năng có hoạt động theo yêu cầu hay không. Người kiểm thử thực hiện thao tác đầu vào, quan sát kết quả và đối chiếu với kết quả mong đợi.
Ví dụ, nếu ứng dụng có chức năng tính tổng tiền, hãy kiểm tra ít nhất các trường hợp sau:
- Chỉ có một sản phẩm với số lượng bằng một.
- Có nhiều sản phẩm với đơn giá khác nhau.
- Thay đổi số lượng sau khi thêm vào giỏ hàng.
- Xóa một sản phẩm khỏi giỏ hàng.
- Áp dụng mã giảm giá hợp lệ và không hợp lệ.
- Nhập dữ liệu số lượng không hợp lệ hoặc cố tình bỏ qua giới hạn của giao diện.
Điều quan trọng là phải kiểm tra kết quả cuối cùng. Tổng tiền hiển thị, tổng tiền được lưu và tổng tiền gửi sang hệ thống thanh toán phải nhất quán theo quy tắc nghiệp vụ đã xác định.
Kiểm thử dữ liệu đầu vào và trường hợp biên
AI thường tạo giao diện dựa trên các trường hợp sử dụng phổ biến. Vì vậy, người phát triển cần chủ động thử những dữ liệu bất thường để xác minh ứng dụng xử lý đúng các tình huống ít gặp.
Với một biểu mẫu nhập thông tin, có thể kiểm tra:
- Để trống trường bắt buộc.
- Nhập chuỗi rất dài hoặc có nhiều khoảng trắng.
- Nhập số âm, số thập phân hoặc số vượt quá giới hạn cho phép.
- Nhập ký tự Unicode, dấu tiếng Việt và các ký tự đặc biệt.
- Nhập ngày không hợp lệ hoặc ngày nằm ngoài phạm vi được chấp nhận.
- Gửi liên tiếp nhiều yêu cầu hoặc nhấn nút gửi nhiều lần.
Không nên chỉ dựa vào việc giao diện có thông báo lỗi hay không. Cần xác minh dữ liệu không hợp lệ có bị từ chối ở phía máy chủ và không làm thay đổi dữ liệu lưu trữ trái với quy tắc hay không.
Kiểm thử tích hợp
Một ứng dụng có thể gồm giao diện người dùng, máy chủ, cơ sở dữ liệu và nhiều dịch vụ bên ngoài. Mỗi thành phần có thể hoạt động riêng lẻ nhưng vẫn gặp lỗi khi kết nối với nhau.
Chẳng hạn, giao diện báo tạo đơn hàng thành công nhưng máy chủ chưa lưu dữ liệu. Hoặc máy chủ đã lưu đơn hàng nhưng việc gửi email xác nhận thất bại. Nếu không kiểm tra toàn bộ luồng xử lý, những vấn đề này có thể bị bỏ qua.
Hãy kiểm tra các luồng quan trọng từ đầu đến cuối, bao gồm cả tình huống API trả về lỗi, mất kết nối, phản hồi chậm hoặc dữ liệu trả về không đúng định dạng.
Kiểm thử giao diện và khả năng sử dụng
Kiểm thử giao diện không chỉ là xem website có đẹp hay không. Cần xác minh người dùng có thể hoàn thành công việc một cách rõ ràng, nhất quán và thuận tiện trên các thiết bị được hỗ trợ.
Những điểm cần kiểm tra gồm bố cục trên màn hình nhỏ, khả năng đọc nội dung, trạng thái tải dữ liệu, thông báo lỗi, trạng thái nút bấm và cách biểu mẫu hiển thị khi dữ liệu không hợp lệ.
Đối với ứng dụng sử dụng AI để tạo giao diện, cần chú ý những thành phần trông có vẻ hoàn chỉnh nhưng chưa có hành vi thực tế, chẳng hạn nút bấm không có sự kiện xử lý, liên kết dẫn đến trang không tồn tại hoặc biểu đồ sử dụng dữ liệu mẫu thay vì dữ liệu thật.
Kiểm thử bảo mật
Kiểm thử bảo mật tập trung vào việc xác minh ứng dụng có bảo vệ đúng dữ liệu và quyền truy cập hay không. Mức độ kiểm tra cần tương xứng với loại dữ liệu, đối tượng sử dụng và rủi ro của sản phẩm.
Các nội dung quan trọng gồm:
- Kiểm tra xác thực và phân quyền ở phía máy chủ.
- Thử truy cập tài nguyên của người dùng khác bằng cách thay đổi định danh trong yêu cầu.
- Kiểm tra cách xử lý dữ liệu đầu vào và truy vấn cơ sở dữ liệu.
- Xác minh thông tin bí mật như khóa API, mật khẩu và thông tin kết nối không bị đưa vào mã nguồn công khai hoặc gửi xuống trình duyệt.
- Kiểm tra việc quản lý phiên đăng nhập, đăng xuất và hết hạn phiên.
- Rà soát thư viện phụ thuộc, cấu hình máy chủ và thông báo lỗi có thể làm lộ thông tin nội bộ.
Việc kiểm thử phải được thực hiện trên môi trường và dữ liệu mà bạn được phép sử dụng. Không nên thử nghiệm xâm nhập trên hệ thống của người khác hoặc đưa dữ liệu khách hàng thật vào những công cụ kiểm thử không được phê duyệt.
Kiểm thử hồi quy
Kiểm thử hồi quy là quá trình chạy lại các bài kiểm thử đã có sau khi mã nguồn được thay đổi. Mục đích là phát hiện những chức năng trước đây hoạt động đúng nhưng bị ảnh hưởng bởi bản sửa lỗi hoặc tính năng mới.
Ví dụ, sau khi yêu cầu AI bổ sung chức năng lọc sản phẩm, hãy kiểm tra thêm tìm kiếm, phân trang, sắp xếp, hiển thị chi tiết sản phẩm và thao tác thêm vào giỏ hàng nếu các chức năng này dùng chung dữ liệu hoặc thành phần giao diện.
Với ứng dụng được cập nhật thường xuyên bằng Vibe Coding, việc duy trì một bộ kiểm thử hồi quy cơ bản có giá trị lớn hơn so với chỉ kiểm tra thủ công riêng lẻ sau mỗi lần thay đổi.
Quy trình kiểm thử ứng dụng Vibe Coding từ đầu đến cuối
Một quy trình rõ ràng giúp bạn kiểm soát chất lượng mà không cần kiểm tra mọi chi tiết một cách tùy hứng. Với ứng dụng nhỏ, có thể thực hiện nhiều bước bằng công cụ đơn giản. Với sản phẩm có người dùng thật, dữ liệu quan trọng hoặc nhiều tích hợp, nên bổ sung kiểm thử tự động và quy trình quản lý phiên bản.
Bước 1: Chuẩn bị môi trường kiểm thử riêng
Nếu có thể, hãy tạo môi trường kiểm thử tách biệt với môi trường đang phục vụ người dùng thật. Sử dụng cơ sở dữ liệu thử nghiệm, tài khoản thử nghiệm và thông tin cấu hình riêng.
Không nên thử các tình huống có thể xóa dữ liệu, gửi thông báo thật hoặc tạo giao dịch thật trực tiếp trên môi trường sản xuất. Nếu ứng dụng cần kết nối dịch vụ bên ngoài, hãy sử dụng chế độ thử nghiệm do nhà cung cấp hỗ trợ.
Bước 2: Kiểm tra mã nguồn trước khi chạy thử
Trước khi kiểm thử trên giao diện, hãy kiểm tra những vấn đề có thể phát hiện trực tiếp từ mã nguồn. Tùy công nghệ sử dụng, bạn có thể chạy trình kiểm tra cú pháp, bộ định dạng mã, công cụ phân tích tĩnh và trình kiểm tra các thư viện phụ thuộc.
Đối với dự án JavaScript hoặc TypeScript, có thể chạy các lệnh kiểm tra mà dự án đã cấu hình. Ví dụ dưới đây minh họa cách chạy các script kiểm tra thông dụng trong một dự án sử dụng npm.
npm run lint
npm run typecheck
npm test
Đây chỉ là ví dụ, không phải bộ lệnh bắt buộc cho mọi dự án. Tên script phải tồn tại trong tệp cấu hình của dự án. Nếu dự án không có script tương ứng, hãy kiểm tra các lệnh thực tế trước khi chạy hoặc yêu cầu AI thiết lập công cụ phù hợp.
Với dự án PHP, cần sử dụng công cụ kiểm tra cú pháp và các bộ kiểm thử tương thích với cấu trúc ứng dụng. Không nên áp dụng máy móc lệnh của JavaScript cho một dự án sử dụng công nghệ khác.
Bước 3: Kiểm thử các chức năng quan trọng nhất
Hãy bắt đầu bằng những chức năng ảnh hưởng trực tiếp đến khả năng sử dụng sản phẩm. Đăng nhập, lưu dữ liệu, tạo đơn hàng, phân quyền và các thao tác không thể dễ dàng khôi phục thường cần được ưu tiên.
Với mỗi chức năng, hãy thực hiện cả trường hợp hợp lệ và không hợp lệ. Sau khi thao tác, kiểm tra kết quả hiển thị, dữ liệu được lưu và phản hồi từ hệ thống. Không nên chỉ dựa vào thông báo thành công trên giao diện.
Bước 4: Kiểm tra luồng sử dụng hoàn chỉnh
Người dùng thường kết hợp nhiều chức năng trong cùng một quy trình. Vì vậy, hãy kiểm thử những hành trình quan trọng từ điểm bắt đầu đến kết quả cuối cùng.
Ví dụ, với một ứng dụng quản lý công việc, hãy thử tạo tài khoản, đăng nhập, tạo công việc, sửa nội dung, giao công việc cho thành viên khác, đánh dấu hoàn thành và đăng xuất. Sau đó đăng nhập lại để xác minh dữ liệu vẫn được lưu chính xác.
Cách kiểm tra này giúp phát hiện những lỗi chỉ xuất hiện khi nhiều chức năng được sử dụng liên tiếp.
Bước 5: Ghi nhận lỗi và yêu cầu AI sửa có kiểm soát
Khi phát hiện lỗi, hãy ghi lại các thông tin cần thiết trước khi yêu cầu AI chỉnh sửa. Một báo cáo lỗi tốt nên bao gồm thao tác tái hiện, kết quả mong đợi, kết quả thực tế, thông báo lỗi và những thông tin liên quan đến môi trường kiểm thử.
Tránh yêu cầu AI viết lại toàn bộ ứng dụng chỉ vì một chức năng nhỏ gặp vấn đề. Hãy yêu cầu xác định nguyên nhân, chỉ ra các tệp cần thay đổi, giải thích ảnh hưởng đến chức năng liên quan và đưa ra phương án sửa ít rủi ro nhất.
Bước 6: Kiểm thử lại sau khi sửa
Sau khi AI sửa mã nguồn, hãy chạy lại bài kiểm thử đã thất bại để xác nhận lỗi được khắc phục. Tiếp theo, kiểm tra những chức năng có liên quan và chạy lại các bài kiểm thử hồi quy quan trọng.
Nếu dự án sử dụng Git, hãy lưu các thay đổi theo từng bước và xem lại phần mã nguồn khác biệt trước khi chấp nhận. Điều này giúp xác định chính xác AI đã sửa những gì, đồng thời hỗ trợ khôi phục khi bản thay đổi gây ra vấn đề mới.
Bước 7: Đánh giá điều kiện trước khi triển khai
Trước khi đưa ứng dụng vào sử dụng thật, hãy xác minh các chức năng cốt lõi hoạt động đúng, dữ liệu được bảo toàn, quyền truy cập được kiểm soát và các lỗi nghiêm trọng đã được xử lý.
Đồng thời, cần kiểm tra cấu hình môi trường, sao lưu dữ liệu, khả năng khôi phục, nhật ký lỗi và phương án quay lại phiên bản trước nếu bản triển khai gặp sự cố.
Không nên coi ứng dụng đã sẵn sàng chỉ vì AI thông báo rằng mã nguồn đã hoàn thành hoặc các bài kiểm thử hiện có đều vượt qua. Quyết định triển khai cần dựa trên kết quả kiểm tra thực tế và mức độ rủi ro còn lại.
Sử dụng AI để hỗ trợ kiểm thử ứng dụng Vibe Coding
Một trong những lợi thế của Vibe Coding là bạn có thể tận dụng chính AI đã tham gia xây dựng ứng dụng để hỗ trợ quá trình kiểm thử. Thay vì tự viết toàn bộ kịch bản kiểm thử, bạn có thể yêu cầu AI phân tích yêu cầu, tìm các tình huống dễ phát sinh lỗi, tạo dữ liệu thử nghiệm và đề xuất cách kiểm tra từng chức năng.
Tuy nhiên, cần phân biệt rõ giữa việc AI đề xuất kiểm thử và việc ứng dụng thực sự vượt qua kiểm thử. Nếu AI chỉ đọc mã nguồn rồi khẳng định chức năng hoạt động đúng mà không thực thi bất kỳ bài kiểm thử nào, đó mới là nhận định dựa trên phân tích, chưa phải bằng chứng xác nhận hệ thống hoạt động chính xác.
Cách làm hiệu quả là sử dụng AI để xây dựng kế hoạch và tạo các bài kiểm thử có thể thực thi, sau đó chạy chúng trong môi trường phù hợp, xem kết quả và yêu cầu AI phân tích những lỗi được phát hiện.
Yêu cầu AI phân tích rủi ro trước khi viết test case
Trước khi yêu cầu AI tạo mã kiểm thử, hãy cung cấp thông tin về mục đích ứng dụng, công nghệ đang sử dụng, các chức năng chính và những quy tắc nghiệp vụ cần tuân thủ.
Thay vì chỉ yêu cầu AI kiểm tra toàn bộ ứng dụng, hãy yêu cầu phân tích từng chức năng theo các nhóm: trường hợp sử dụng bình thường, dữ liệu không hợp lệ, giới hạn dữ liệu, lỗi từ hệ thống bên ngoài, quyền truy cập và ảnh hưởng đến những chức năng liên quan.
Ví dụ, với chức năng tạo tài khoản, AI cần xem xét không chỉ trường hợp nhập đầy đủ thông tin mà còn cả tình huống email đã tồn tại, mật khẩu không đạt yêu cầu, dữ liệu bị thiếu, yêu cầu được gửi nhiều lần hoặc người dùng cố tình bỏ qua các giới hạn kiểm tra trên giao diện.
Việc phân tích rủi ro trước giúp tránh tình trạng AI tạo ra nhiều bài kiểm thử đơn giản nhưng bỏ qua những trường hợp có khả năng gây thiệt hại lớn.
Prompt yêu cầu AI tạo bộ kiểm thử chi tiết
Một prompt tốt cần nêu rõ phạm vi công việc, tiêu chí đầu ra và yêu cầu không tự ý thay đổi mã nguồn sản phẩm. Bạn có thể sử dụng mẫu sau rồi điều chỉnh theo dự án của mình.
Hãy phân tích chức năng [tên chức năng] trong dự án hiện tại
và xây dựng bộ kiểm thử chi tiết.
Yêu cầu:
1. Đọc mã nguồn liên quan trước khi đề xuất kiểm thử.
2. Xác định yêu cầu nghiệp vụ và kết quả mong đợi.
3. Liệt kê trường hợp thành công, thất bại và dữ liệu biên.
4. Kiểm tra dữ liệu không hợp lệ và quyền truy cập.
5. Xem xét các tình huống gửi yêu cầu lặp lại, mất kết nối
và lỗi từ dịch vụ phụ thuộc nếu phù hợp.
6. Với mỗi trường hợp, nêu dữ liệu đầu vào, thao tác,
kết quả mong đợi và mức độ ưu tiên.
7. Tạo mã kiểm thử tương thích với công nghệ và cấu trúc
hiện có của dự án.
8. Không sửa mã nguồn sản phẩm nếu chưa được yêu cầu.
9. Không tự tạo kết quả kiểm thử giả.
10. Nêu rõ những trường hợp chưa thể kiểm tra tự động
và những giả định cần xác nhận.
Sau khi tạo bộ kiểm thử, hãy hướng dẫn cách chạy,
cách đọc kết quả và cách xác minh lỗi được phát hiện.
Mẫu prompt này giúp AI tạo ra đầu ra có cấu trúc thay vì chỉ đưa ra một danh sách ý tưởng chung chung. Bạn cũng có thể yêu cầu AI xuất các test case thành bảng để thuận tiện theo dõi tiến độ.
Yêu cầu AI giải thích kết quả kiểm thử
Khi một bài kiểm thử thất bại, không nên vội yêu cầu AI sửa ngay. Trước tiên, hãy yêu cầu giải thích nguyên nhân dựa trên thông báo lỗi, mã nguồn và kết quả thực thi.
Cần xác định lỗi nằm ở mã nguồn sản phẩm, mã kiểm thử, dữ liệu thử nghiệm hay cấu hình môi trường. Một bài kiểm thử thất bại không phải lúc nào cũng chứng minh ứng dụng có lỗi; đôi khi chính bài kiểm thử đã đưa ra giả định không đúng về hành vi mong muốn.
Ngược lại, việc tất cả bài kiểm thử đều thành công cũng không bảo đảm ứng dụng không có lỗi. Nếu các bài kiểm thử được viết dựa trên cùng một giả định sai với mã nguồn, chúng có thể cùng xác nhận một hành vi không đúng.
Kiểm thử tự động bằng công cụ phù hợp
Kiểm thử thủ công rất hữu ích khi đánh giá giao diện, trải nghiệm người dùng và những tình huống cần phán đoán. Tuy nhiên, khi ứng dụng phát triển hoặc được cập nhật thường xuyên, việc lặp lại hàng chục thao tác bằng tay sẽ mất thời gian và dễ bỏ sót.
Kiểm thử tự động giúp thực hiện lại những bước đã xác định với dữ liệu đầu vào cụ thể, ghi nhận kết quả và phát hiện thay đổi ngoài dự kiến. Công cụ nên được lựa chọn dựa trên công nghệ của ứng dụng, độ phức tạp và khả năng bảo trì, không phải dựa trên số lượng tính năng mà công cụ quảng bá.
Kiểm thử đơn vị với các hàm xử lý độc lập
Kiểm thử đơn vị tập trung vào những thành phần nhỏ, chẳng hạn hàm tính tổng tiền, hàm kiểm tra dữ liệu hoặc hàm xác định quyền truy cập. Mục tiêu là xác minh thành phần đó trả về kết quả đúng với các đầu vào khác nhau.
Ví dụ, giả sử ứng dụng có một hàm tính thành tiền từ đơn giá và số lượng. Các trường hợp cần kiểm tra gồm số lượng hợp lệ, số lượng bằng không, số lượng âm và giá trị vượt quá giới hạn nghiệp vụ.
Đoạn mã dưới đây minh họa một hàm tính thành tiền bằng JavaScript. Trong một dự án thực tế, cần bổ sung quy tắc về tiền tệ, kiểu dữ liệu và giới hạn hợp lệ theo yêu cầu nghiệp vụ.
function calculateTotal(price, quantity) {
if (!Number.isFinite(price) || price < 0) {
throw new Error("Đơn giá không hợp lệ");
}
if (!Number.isInteger(quantity) || quantity < 0) {
throw new Error("Số lượng không hợp lệ");
}
return price * quantity;
}
Các bài kiểm thử nên xác minh rằng đầu vào hợp lệ tạo ra kết quả chính xác, còn đầu vào không hợp lệ được xử lý theo quy tắc đã định. Với hệ thống tài chính hoặc bán hàng, cần cân nhắc cách biểu diễn số tiền để tránh sai số dấu phẩy động, chẳng hạn sử dụng số nguyên theo đơn vị tiền nhỏ nhất hoặc thư viện xử lý số thập phân phù hợp.
Kiểm thử đơn vị không thay thế được kiểm thử tích hợp. Một hàm có thể hoạt động đúng khi được kiểm tra riêng nhưng vẫn gặp vấn đề khi nhận dữ liệu từ cơ sở dữ liệu hoặc kết hợp với các thành phần khác.
Kiểm thử API
Nếu ứng dụng có API, bạn cần kiểm tra trực tiếp các điểm cuối thay vì chỉ thao tác thông qua giao diện. Kiểm thử API giúp xác minh máy chủ nhận dữ liệu, kiểm tra quyền, xử lý nghiệp vụ và trả về phản hồi đúng định dạng.
Các trường hợp cần kiểm tra gồm:
- Yêu cầu hợp lệ trả về mã trạng thái và dữ liệu đúng theo thiết kế.
- Dữ liệu thiếu hoặc sai định dạng được xử lý phù hợp.
- Người chưa xác thực không thể gọi API yêu cầu đăng nhập.
- Người dùng không thể thực hiện thao tác vượt quá quyền được cấp.
- Đối tượng không tồn tại được xử lý nhất quán.
- Máy chủ không để lộ thông tin nhạy cảm trong phản hồi lỗi.
- Yêu cầu lặp lại không tạo ra các tác động ngoài dự kiến đối với những thao tác cần được kiểm soát.
Bạn có thể sử dụng công cụ gửi yêu cầu HTTP để kiểm tra API thủ công, sau đó chuyển các trường hợp quan trọng thành bộ kiểm thử tự động. Khi có thay đổi ở máy chủ, bộ kiểm thử này sẽ giúp phát hiện những sai lệch trong hành vi của API.
Đối với API có chức năng tạo đơn hàng, chuyển tiền hoặc ghi nhận giao dịch, cần kiểm tra kỹ việc xử lý yêu cầu lặp lại và các tình huống mất kết nối sau khi máy chủ đã thực hiện thao tác nhưng trước khi phía người dùng nhận được phản hồi.
Kiểm thử cơ sở dữ liệu
Một ứng dụng có thể hiển thị thông báo thành công nhưng dữ liệu lưu trữ vẫn sai. Vì vậy, những chức năng tạo, cập nhật và xóa dữ liệu cần được kiểm tra ở cả tầng ứng dụng lẫn cơ sở dữ liệu.
Hãy xác minh bản ghi được tạo đúng, các trường quan trọng không bị thiếu, mối quan hệ giữa các bảng được duy trì và dữ liệu không bị thay đổi ngoài dự kiến.
Ví dụ, sau khi tạo một đơn hàng, hãy kiểm tra đơn hàng có được lưu đúng khách hàng hay không, chi tiết sản phẩm có khớp với nội dung đơn hàng không và tổng tiền có được tính theo quy tắc nghiệp vụ hay không.
Đồng thời, cần thử các tình huống cập nhật thất bại giữa chừng. Nếu một quy trình gồm nhiều thao tác phụ thuộc nhau, hệ thống phải có cách xử lý phù hợp để tránh dữ liệu ở trạng thái dở dang.
Khi kiểm thử chức năng xóa dữ liệu, nên sử dụng dữ liệu thử nghiệm và xác định rõ quy tắc xóa mềm, xóa cứng hoặc lưu trữ lịch sử. Không thực hiện thao tác phá hủy dữ liệu thật chỉ để kiểm tra khả năng xử lý lỗi.
Kiểm thử giao diện bằng trình duyệt tự động
Với ứng dụng web, kiểm thử trình duyệt tự động có thể mô phỏng thao tác của người dùng như mở trang, điền biểu mẫu, nhấn nút, chuyển trang và xác minh kết quả hiển thị.
Các công cụ như Playwright có thể hỗ trợ kiểm thử luồng sử dụng trên trình duyệt. Ví dụ, bạn có thể tạo một bài kiểm thử tự động để mở trang đăng nhập, nhập tài khoản thử nghiệm và xác minh rằng người dùng được chuyển đến đúng trang sau khi đăng nhập thành công.
Trong quá trình triển khai, cần sử dụng bộ chọn phần tử ổn định, dữ liệu thử nghiệm có thể kiểm soát và điều kiện chờ phù hợp. Không nên dựa quá nhiều vào vị trí tuyệt đối của phần tử hoặc thời gian chờ cố định vì những cách này dễ khiến bài kiểm thử không ổn định khi giao diện thay đổi.
Kiểm thử trình duyệt cũng cần xác minh các trường hợp lỗi, chẳng hạn thông tin đăng nhập không hợp lệ, máy chủ phản hồi chậm hoặc biểu mẫu không được gửi khi thiếu trường bắt buộc.
Kiểm thử trên nhiều trình duyệt và thiết bị
Một ứng dụng hoạt động tốt trên máy tính của người tạo chưa chắc hoạt động tương tự trên điện thoại hoặc một trình duyệt khác. Sự khác biệt về kích thước màn hình, cách xử lý sự kiện, phông chữ và bộ nhớ có thể làm lộ ra các lỗi khó phát hiện trong môi trường phát triển.
Hãy xác định những trình duyệt và kích thước màn hình mà ứng dụng cần hỗ trợ. Sau đó, ưu tiên kiểm tra các luồng cốt lõi trên từng môi trường, thay vì cố gắng thử mọi tổ hợp thiết bị một cách thiếu trọng tâm.
Ngoài việc quan sát giao diện, cần thử thao tác bằng bàn phím, kiểm tra biểu mẫu, liên kết và các thành phần tương tác. Nếu sản phẩm hướng đến người dùng cần công nghệ hỗ trợ, hãy bổ sung kiểm tra khả năng tiếp cận phù hợp.
Kiểm thử ứng dụng Vibe Coding theo từng tầng
Để tránh bỏ sót những lỗi quan trọng, bạn nên tổ chức kiểm thử theo từng tầng. Mỗi tầng tập trung vào một nhóm vấn đề khác nhau và bổ sung cho các tầng còn lại.
| Tầng kiểm thử | Mục tiêu | Ví dụ |
|---|---|---|
| Đơn vị | Kiểm tra logic của thành phần nhỏ | Hàm tính tiền, kiểm tra dữ liệu |
| Tích hợp | Kiểm tra các thành phần phối hợp | Máy chủ lưu dữ liệu vào cơ sở dữ liệu |
| API | Kiểm tra giao tiếp và phản hồi của máy chủ | Đăng nhập, tạo đơn hàng, cập nhật hồ sơ |
| Giao diện | Kiểm tra thao tác và kết quả hiển thị | Biểu mẫu, tìm kiếm, phân trang |
| Đầu cuối | Kiểm tra toàn bộ quy trình người dùng | Đăng nhập, tạo dữ liệu, cập nhật và tra cứu |
| Bảo mật | Phát hiện lỗi liên quan đến quyền và dữ liệu | Truy cập trái phép, lộ khóa API |
| Hồi quy | Phát hiện lỗi phát sinh sau khi sửa đổi | Kiểm tra lại chức năng cũ sau khi thêm tính năng |
Không nhất thiết phải xây dựng một hệ thống kiểm thử phức tạp ngay từ đầu. Với ứng dụng nhỏ, bạn có thể bắt đầu bằng các bài kiểm thử đơn vị cho logic quan trọng, kiểm thử API cho các chức năng chính và một số bài kiểm thử đầu cuối cho những luồng người dùng thiết yếu.
Khi ứng dụng phát triển, hãy bổ sung kiểm thử ở những khu vực thường xuyên thay đổi hoặc có rủi ro cao. Cách tiếp cận này giúp kiểm soát chi phí mà vẫn cải thiện chất lượng theo thời gian.
Kiểm thử những thay đổi do AI tạo ra
Trong Vibe Coding, AI thường chỉnh sửa mã nguồn dựa trên yêu cầu được cung cấp qua nhiều lượt trao đổi. Vì vậy, kiểm thử không nên chỉ tập trung vào kết quả cuối cùng mà còn cần xem xét phạm vi thay đổi, các thành phần bị ảnh hưởng và khả năng tái hiện kết quả.
Xem lại phần mã nguồn đã thay đổi
Trước khi chấp nhận một bản sửa do AI tạo ra, hãy xem những tệp nào đã được thêm, xóa hoặc chỉnh sửa. Kiểm tra xem AI có tự ý thay đổi cấu hình, thư viện phụ thuộc, cấu trúc dữ liệu hoặc những chức năng nằm ngoài phạm vi yêu cầu hay không.
Nếu AI sửa quá nhiều phần không liên quan, hãy yêu cầu giải thích lý do và thu hẹp phạm vi thay đổi khi có thể. Những thay đổi nhỏ, có mục đích rõ ràng thường dễ kiểm tra và khôi phục hơn.
Không chấp nhận bài kiểm thử chỉ vì AI báo thành công
Một số môi trường phát triển có thể cho phép AI đọc mã nguồn, viết bài kiểm thử và chạy lệnh trực tiếp. Điều này hữu ích nhưng vẫn cần xác minh cách thực hiện.
Hãy kiểm tra xem bài kiểm thử có thực sự được chạy hay không, có bị bỏ qua không, có thất bại nhưng bị che giấu không và có đang sử dụng dữ liệu giả không phản ánh hành vi thực tế hay không.
Nếu AI báo rằng mọi bài kiểm thử đều vượt qua, hãy xem kết quả thực thi, số lượng bài kiểm thử đã chạy và những phần chưa được bao phủ. Một báo cáo ngắn gọn nhưng có bằng chứng đáng tin cậy có giá trị hơn lời khẳng định chung rằng ứng dụng đã hoàn toàn chính xác.
Yêu cầu AI không sửa bài kiểm thử để che giấu lỗi
Khi một bài kiểm thử thất bại, AI có thể đề xuất thay đổi mã sản phẩm, điều chỉnh bài kiểm thử hoặc sửa cả hai. Không phải thay đổi nào cũng hợp lý.
Nếu bài kiểm thử đang phản ánh đúng yêu cầu nghiệp vụ, việc sửa bài kiểm thử chỉ để kết quả chuyển sang thành công sẽ khiến lỗi thật bị che giấu. Ngược lại, nếu yêu cầu nghiệp vụ đã thay đổi, bài kiểm thử cũ có thể cần được cập nhật sau khi có xác nhận rõ ràng.
Vì vậy, hãy yêu cầu AI giải thích tại sao bài kiểm thử thất bại, xác định kết quả mong đợi dựa trên yêu cầu nào và nêu rõ lý do nếu đề xuất thay đổi bài kiểm thử.
Những sai lầm thường gặp khi kiểm thử ứng dụng tạo bằng AI
Chỉ thử những trường hợp thuận lợi
Nếu chỉ nhập dữ liệu hợp lệ và kiểm tra thao tác thành công, bạn sẽ bỏ lỡ nhiều lỗi có thể xuất hiện khi người dùng nhập sai, gửi yêu cầu lặp lại hoặc gặp sự cố kết nối.
Hãy bổ sung các tình huống bất thường có khả năng xảy ra trong thực tế, đặc biệt ở những chức năng xử lý dữ liệu quan trọng.
Chỉ kiểm tra giao diện mà bỏ qua dữ liệu thực tế
Thông báo thành công hoặc giao diện đẹp không chứng minh dữ liệu đã được xử lý chính xác. Với các chức năng lưu trữ, thanh toán hoặc quản lý hồ sơ, cần xác minh kết quả ở phía máy chủ và cơ sở dữ liệu.
Sửa lỗi liên tục mà không lưu phiên bản ổn định
Nếu để AI thay đổi mã nguồn liên tục mà không lưu các mốc ổn định, việc tìm nguyên nhân khi ứng dụng gặp lỗi sẽ khó khăn hơn. Hãy sử dụng hệ thống quản lý phiên bản, tạo các mốc thay đổi có ý nghĩa và kiểm tra phần mã nguồn khác biệt trước khi triển khai.
Cho rằng kiểm thử tự động có thể thay thế hoàn toàn con người
Kiểm thử tự động rất hiệu quả với các quy tắc có thể xác định rõ, nhưng không phải lúc nào cũng đánh giá tốt trải nghiệm người dùng, mức độ dễ hiểu của giao diện hoặc sự phù hợp với nhu cầu thực tế.
Đối với những ứng dụng có quy trình nghiệp vụ phức tạp, người có chuyên môn vẫn cần xem xét các tiêu chí nghiệp vụ, tình huống ngoại lệ và mức độ chấp nhận rủi ro.
Đưa ứng dụng lên môi trường thật ngay sau khi AI sửa lỗi
Một bản sửa có thể giải quyết được lỗi trước mắt nhưng đồng thời gây ra vấn đề mới. Trước khi triển khai, hãy chạy lại các bài kiểm thử liên quan, kiểm tra cấu hình và xác nhận có phương án khôi phục nếu phát sinh sự cố.
Đối với ứng dụng đã có người dùng thật, nên áp dụng quy trình triển khai có kiểm soát thay vì để AI tự ý thay đổi trực tiếp hệ thống đang hoạt động.
Kiểm thử bảo mật chuyên sâu cho ứng dụng Vibe Coding
Ứng dụng được tạo bằng Vibe Coding có thể xử lý thông tin tài khoản, dữ liệu khách hàng, tài liệu nội bộ hoặc giao dịch kinh doanh. Nếu chỉ kiểm tra chức năng mà không đánh giá bảo mật, bạn có thể đưa vào sử dụng một sản phẩm hoạt động bình thường nhưng vẫn tồn tại những lỗ hổng nghiêm trọng.
Kiểm thử bảo mật cần được thực hiện trên toàn bộ hệ thống, bao gồm giao diện, máy chủ, API, cơ sở dữ liệu, thư viện phụ thuộc và cấu hình triển khai. Đặc biệt, không nên mặc định rằng mã nguồn do AI tạo ra đã tuân thủ các nguyên tắc bảo mật chỉ vì AI khẳng định đã xử lý an toàn.
Kiểm tra xác thực và phân quyền
Xác thực và phân quyền là hai vấn đề khác nhau. Xác thực nhằm xác định người đang sử dụng hệ thống là ai, còn phân quyền xác định người đó được phép thực hiện những hành động nào.
Hãy tạo các tài khoản thử nghiệm với vai trò khác nhau, chẳng hạn khách truy cập, người dùng thông thường và quản trị viên. Sau đó, kiểm tra xem mỗi tài khoản có thể thực hiện đúng những thao tác được phép hay không.
Những trường hợp cần kiểm tra gồm:
- Truy cập trực tiếp vào trang yêu cầu đăng nhập khi chưa xác thực.
- Thay đổi mã định danh tài nguyên trong yêu cầu để thử truy cập dữ liệu của người dùng khác.
- Gọi trực tiếp API quản trị bằng tài khoản thông thường.
- Tiếp tục sử dụng phiên đăng nhập sau khi đăng xuất hoặc sau khi phiên hết hạn.
- Thử sử dụng lại mã xác thực hoặc liên kết khôi phục tài khoản đã hết hiệu lực.
- Kiểm tra quyền truy cập sau khi tài khoản bị khóa hoặc vai trò người dùng thay đổi.
Không nên chỉ kiểm tra việc ẩn hoặc hiện nút trên giao diện. Các quyền quan trọng phải được xác minh ở phía máy chủ vì người dùng có thể gửi yêu cầu trực tiếp mà không cần thông qua giao diện ứng dụng.
Kiểm tra việc quản lý khóa API và thông tin bí mật
Khi xây dựng ứng dụng bằng AI, người phát triển có thể cung cấp thông tin cấu hình hoặc yêu cầu AI tích hợp dịch vụ bên ngoài. Nếu xử lý không đúng, khóa API, mật khẩu cơ sở dữ liệu hoặc thông tin xác thực có thể bị đưa vào mã nguồn phía trình duyệt, kho mã công khai hoặc nhật ký hệ thống.
Hãy rà soát mã nguồn, tệp cấu hình, lịch sử thay đổi và các tệp được đưa vào gói triển khai để tìm thông tin nhạy cảm. Khóa bí mật cần được lưu trữ trong hệ thống quản lý cấu hình phù hợp hoặc kho bí mật chuyên dụng, tùy môi trường triển khai.
Không đưa khóa bí mật trực tiếp vào mã JavaScript chạy trên trình duyệt. Nếu ứng dụng cần gọi một dịch vụ yêu cầu khóa riêng, hãy thiết kế luồng xử lý phía máy chủ hoặc cơ chế trung gian phù hợp để bảo vệ thông tin xác thực.
Nếu phát hiện khóa bí mật đã bị công khai, chỉ xóa khóa khỏi mã nguồn hiện tại là chưa đủ. Cần thu hồi hoặc thay thế khóa, kiểm tra lịch sử và đánh giá liệu khóa đó đã bị sử dụng trái phép hay chưa.
Kiểm tra dữ liệu đầu vào và các lỗi bảo mật phổ biến
Dữ liệu do người dùng cung cấp phải được xem là không đáng tin cậy, kể cả khi dữ liệu được nhập qua một biểu mẫu có kiểm tra ở giao diện.
Hãy đánh giá cách ứng dụng xử lý dữ liệu trong các chức năng tìm kiếm, nhập nội dung, tải tệp, tạo báo cáo và gửi yêu cầu đến API. Cần kiểm tra khả năng phát sinh lỗi khi dữ liệu chứa ký tự đặc biệt, nội dung quá dài hoặc cấu trúc không đúng như dự kiến.
Đối với ứng dụng web, các vấn đề cần quan tâm có thể bao gồm:
- SQL Injection: dữ liệu đầu vào làm thay đổi ngoài ý muốn cấu trúc truy vấn cơ sở dữ liệu.
- Cross-Site Scripting (XSS): nội dung không an toàn được đưa vào trang và có thể thực thi dưới dạng mã trong trình duyệt.
- Cross-Site Request Forgery (CSRF): người dùng đã đăng nhập bị lợi dụng để thực hiện hành động ngoài ý muốn trong những điều kiện phù hợp với lỗ hổng.
- Broken Access Control: người dùng truy cập dữ liệu hoặc thực hiện hành động vượt quá quyền hạn.
- File Upload Vulnerabilities: chức năng tải tệp không kiểm soát đúng loại tệp, nội dung, kích thước hoặc vị trí lưu trữ.
- Information Disclosure: thông báo lỗi, phản hồi API hoặc tệp cấu hình làm lộ thông tin nội bộ.
Cách xử lý cụ thể phụ thuộc vào công nghệ và kiến trúc ứng dụng. Chẳng hạn, khi truy vấn cơ sở dữ liệu, nên sử dụng truy vấn tham số hóa thay vì ghép trực tiếp dữ liệu người dùng vào câu lệnh SQL. Khi hiển thị nội dung do người dùng nhập, cần mã hóa đầu ra phù hợp với ngữ cảnh và có cơ chế xử lý HTML an toàn nếu ứng dụng cho phép nội dung định dạng.
Đối với chức năng tải tệp, việc chỉ kiểm tra phần mở rộng không đủ để bảo đảm an toàn. Cần xem xét loại nội dung thực tế, giới hạn kích thước, quyền truy cập và cách lưu trữ tệp. Các bài kiểm thử phải sử dụng môi trường được phép kiểm soát, không tải mã độc hoặc thực hiện hành vi gây ảnh hưởng đến hệ thống bên ngoài.
Kiểm thử ứng dụng có tích hợp AI
Nếu ứng dụng Vibe Coding sử dụng API của mô hình AI để trò chuyện, phân tích tài liệu, tạo nội dung hoặc xử lý hình ảnh, cần kiểm thử thêm những rủi ro đặc thù của hệ thống AI.
Đầu tiên, hãy kiểm tra cách ứng dụng xử lý đầu vào không phù hợp, yêu cầu quá dài, dữ liệu không đúng định dạng và phản hồi lỗi từ nhà cung cấp. Hệ thống cần có giới hạn hợp lý để tránh tiêu tốn tài nguyên không kiểm soát.
Tiếp theo, kiểm tra khả năng bảo vệ dữ liệu. Tài liệu người dùng tải lên, nội dung hội thoại, thông tin cá nhân và dữ liệu nội bộ chỉ nên được gửi đến dịch vụ bên ngoài theo đúng chính sách đã xác định. Không nên đưa toàn bộ dữ liệu trong cơ sở dữ liệu vào prompt nếu tác vụ chỉ cần một phần thông tin.
Một rủi ro khác là prompt injection, trong đó nội dung đầu vào chứa chỉ dẫn nhằm khiến mô hình bỏ qua mục tiêu ban đầu hoặc tác động đến các công cụ được cấp quyền. Ví dụ, một tài liệu được tải lên có thể chứa chỉ dẫn yêu cầu hệ thống tiết lộ thông tin không liên quan đến nhiệm vụ phân tích.
Để giảm rủi ro, cần phân biệt dữ liệu được phân tích với chỉ dẫn điều khiển hệ thống, giới hạn quyền của công cụ mà AI có thể gọi và yêu cầu xác nhận trước các hành động nhạy cảm. Không nên xem nội dung do mô hình trả về là dữ liệu đáng tin cậy tuyệt đối.
Nếu AI có quyền thực hiện hành động như gửi email, cập nhật dữ liệu hoặc gọi API nội bộ, hãy kiểm tra các trường hợp mô hình đưa ra yêu cầu sai, sử dụng tham số không hợp lệ hoặc cố gắng thực hiện thao tác ngoài phạm vi cho phép. Những giới hạn quan trọng phải được thực thi ở tầng ứng dụng, không chỉ dựa vào prompt.
Kiểm thử hiệu năng và khả năng chịu tải
Một ứng dụng hoạt động tốt khi chỉ có một người sử dụng chưa chắc đáp ứng được nhu cầu khi có nhiều người truy cập cùng lúc. Kiểm thử hiệu năng giúp đánh giá tốc độ phản hồi, mức tiêu thụ tài nguyên và khả năng duy trì hoạt động trong điều kiện sử dụng dự kiến.
Không phải mọi dự án Vibe Coding đều cần kiểm thử tải ở quy mô lớn ngay từ đầu. Tuy nhiên, nếu ứng dụng phục vụ khách hàng, có nhiều yêu cầu đồng thời hoặc phụ thuộc vào cơ sở dữ liệu và API bên ngoài, bạn nên xác định các chỉ số hiệu năng cơ bản trước khi triển khai.
Đo thời gian phản hồi của các chức năng quan trọng
Hãy lựa chọn những thao tác người dùng thực hiện thường xuyên, chẳng hạn mở trang chủ, tìm kiếm, đăng nhập, tải danh sách dữ liệu hoặc tạo báo cáo. Đo thời gian phản hồi trong điều kiện thử nghiệm được kiểm soát và ghi lại kết quả làm mốc so sánh.
Không nên chỉ dựa vào một lần chạy thử. Thời gian phản hồi có thể thay đổi do bộ nhớ đệm, tốc độ mạng, tải của máy chủ hoặc dịch vụ bên ngoài. Cần thực hiện nhiều lần để có cái nhìn đáng tin cậy hơn.
Ngoài thời gian phản hồi trung bình, nên xem xét các phân vị như p95, tức ngưỡng thời gian mà khoảng 95% yêu cầu hoàn thành trong điều kiện đo cụ thể. Chỉ số này giúp nhận biết những yêu cầu chậm bất thường mà giá trị trung bình có thể che khuất.
Kiểm tra khi có nhiều người dùng đồng thời
Kiểm thử tải mô phỏng số lượng yêu cầu đồng thời để đánh giá khả năng xử lý của ứng dụng. Bạn nên bắt đầu với mức tải gần với nhu cầu dự kiến, sau đó tăng dần trong môi trường được phép thử nghiệm.
Trong quá trình đo, cần theo dõi tỷ lệ yêu cầu thất bại, thời gian phản hồi, mức sử dụng CPU, bộ nhớ, kết nối cơ sở dữ liệu và giới hạn của các dịch vụ phụ thuộc.
Không nên tự ý tạo lượng truy cập lớn trên hệ thống đang phục vụ khách hàng hoặc dịch vụ bên ngoài. Việc kiểm thử phải có kế hoạch, giới hạn tải rõ ràng và được thực hiện trong môi trường phù hợp.
Kiểm tra lỗi khi dịch vụ phụ thuộc gặp sự cố
Ứng dụng Vibe Coding thường sử dụng thư viện, API hoặc dịch vụ bên ngoài. Nếu một dịch vụ chậm hoặc ngừng phản hồi, ứng dụng cần có cách xử lý phù hợp thay vì khiến toàn bộ hệ thống bị treo.
Hãy thử những tình huống như API trả về lỗi, kết nối bị ngắt, yêu cầu vượt quá thời gian chờ hoặc dịch vụ tạm thời không khả dụng. Xác minh rằng ứng dụng hiển thị thông báo dễ hiểu, không làm mất dữ liệu ngoài dự kiến và có thể tiếp tục hoạt động khi điều kiện được khôi phục.
Tùy nghiệp vụ, có thể cần thiết lập thời gian chờ, giới hạn số lần thử lại, cơ chế trì hoãn giữa các lần thử và giới hạn số yêu cầu đồng thời. Không nên thử lại vô hạn vì điều đó có thể làm tình trạng quá tải trở nên nghiêm trọng hơn.
Ví dụ thực tế: Kiểm thử ứng dụng quản lý công việc do AI tạo ra
Để hình dung cách áp dụng các phương pháp trên, hãy xem xét một ứng dụng quản lý công việc được xây dựng bằng Vibe Coding. Người dùng có thể đăng nhập, tạo công việc, giao nhiệm vụ cho thành viên khác, cập nhật trạng thái và theo dõi tiến độ.
Giả sử giao diện đã hoàn thành và các thao tác cơ bản có vẻ hoạt động tốt. Trước khi đưa ứng dụng vào sử dụng, bạn nên kiểm tra lần lượt những nhóm chức năng sau.
Kiểm thử đăng nhập và phân quyền
Tạo ít nhất hai tài khoản thử nghiệm thuộc hai người dùng khác nhau. Đăng nhập bằng từng tài khoản và tạo công việc riêng để xác minh dữ liệu được gắn đúng người sở hữu.
Tiếp theo, thử mở trực tiếp đường dẫn hoặc gọi API với mã công việc thuộc tài khoản còn lại. Nếu hệ thống không cho phép chia sẻ công việc giữa các tài khoản, người dùng không được xem hoặc sửa dữ liệu đó. Nếu ứng dụng có chức năng chia sẻ, cần kiểm tra đúng quy tắc chia sẻ đã thiết kế.
Mục tiêu là xác minh quyền được thực thi ở phía máy chủ, không chỉ dựa vào việc giao diện có ẩn công việc hay không.
Kiểm thử chức năng tạo và cập nhật công việc
Tạo công việc với tiêu đề hợp lệ, sau đó thử lưu khi tiêu đề bị bỏ trống, nội dung quá dài hoặc ngày đến hạn không hợp lệ. Kiểm tra thông báo phản hồi và xác minh dữ liệu không hợp lệ không được lưu ngoài ý muốn.
Sau đó, cập nhật tiêu đề, thay đổi người được giao nhiệm vụ và chuyển trạng thái công việc. Tải lại trang hoặc đăng xuất rồi đăng nhập lại để xác nhận thay đổi được lưu chính xác.
Nếu ứng dụng có lịch sử hoạt động, hãy kiểm tra người thực hiện, thời điểm và nội dung thay đổi có được ghi nhận theo đúng yêu cầu hay không.
Kiểm thử tình huống nhiều thao tác liên tiếp
Thử tạo một công việc, sửa nội dung, giao cho thành viên khác rồi chuyển sang trạng thái hoàn thành. Sau đó, sử dụng chức năng tìm kiếm và bộ lọc để xác minh công việc xuất hiện đúng vị trí.
Nếu hai người cùng cập nhật một công việc, hãy kiểm tra cách ứng dụng xử lý xung đột dữ liệu. Tùy yêu cầu, hệ thống có thể cần phát hiện phiên bản đã thay đổi, thông báo cho người dùng hoặc áp dụng một quy tắc cập nhật nhất quán.
Kiểm thử khả năng khôi phục dữ liệu
Trong môi trường thử nghiệm, hãy xác minh dữ liệu vẫn tồn tại sau khi khởi động lại ứng dụng hoặc triển khai một phiên bản mới. Nếu hệ thống hỗ trợ sao lưu và khôi phục, cần thử quy trình khôi phục trên bản sao dữ liệu thử nghiệm.
Đừng mặc định rằng có tệp sao lưu nghĩa là có thể khôi phục thành công. Quy trình chỉ thực sự đáng tin cậy khi việc khôi phục đã được kiểm tra và dữ liệu sau khôi phục được xác minh.
Checklist kiểm thử trước khi đưa ứng dụng vào sử dụng
Trước khi triển khai ứng dụng được xây dựng bằng Vibe Coding, hãy sử dụng danh sách dưới đây để kiểm tra những yêu cầu quan trọng. Có thể bổ sung hoặc loại bỏ mục tùy theo tính chất và mức độ rủi ro của sản phẩm.
- Yêu cầu: các chức năng chính có tiêu chí chấp nhận rõ ràng.
- Mã nguồn: đã kiểm tra cú pháp, cấu hình và những thay đổi quan trọng do AI tạo ra.
- Chức năng: các luồng sử dụng cốt lõi hoạt động đúng với dữ liệu hợp lệ và không hợp lệ.
- Dữ liệu: dữ liệu được tạo, cập nhật, xóa và truy xuất theo đúng quy tắc nghiệp vụ.
- API: phản hồi thành công và thất bại được xử lý đúng.
- Phân quyền: người dùng không thể thực hiện thao tác vượt quá quyền hạn.
- Bảo mật: đã rà soát thông tin bí mật, dữ liệu đầu vào và những rủi ro phù hợp với ứng dụng.
- Giao diện: các trang quan trọng hoạt động trên thiết bị và trình duyệt cần hỗ trợ.
- Hiệu năng: tốc độ phản hồi đáp ứng yêu cầu sử dụng dự kiến.
- Hồi quy: các chức năng liên quan đã được kiểm tra lại sau khi sửa lỗi.
- Khôi phục: có phương án sao lưu và khôi phục phù hợp với mức độ quan trọng của dữ liệu.
- Giám sát: có cách ghi nhận lỗi và theo dõi tình trạng ứng dụng sau triển khai.
- Triển khai: cấu hình môi trường, quyền truy cập và phương án quay lại phiên bản ổn định đã được xem xét.
Không nhất thiết mọi ứng dụng đều phải có cùng mức độ kiểm thử. Một công cụ cá nhân chạy trên máy tính có thể chỉ cần quy trình đơn giản. Ngược lại, ứng dụng phục vụ nhiều khách hàng, lưu dữ liệu nhạy cảm hoặc xử lý giao dịch cần được đánh giá nghiêm ngặt hơn.
Khi nào ứng dụng Vibe Coding đủ điều kiện triển khai?
Không thể xác định mức độ sẵn sàng của một ứng dụng chỉ bằng số lượng bài kiểm thử đã chạy hoặc việc không còn thông báo lỗi trên màn hình. Quyết định triển khai cần dựa trên yêu cầu nghiệp vụ, kết quả kiểm thử, mức độ nghiêm trọng của lỗi còn tồn tại và khả năng kiểm soát rủi ro.
Một ứng dụng có thể được xem xét triển khai khi những chức năng cốt lõi đã đáp ứng tiêu chí chấp nhận, các lỗi nghiêm trọng đã được xử lý, dữ liệu được bảo vệ phù hợp và những luồng quan trọng đã được kiểm tra trong môi trường gần với thực tế.
Đối với ứng dụng có mức độ rủi ro cao, cần bổ sung đánh giá bảo mật chuyên sâu, kiểm thử hiệu năng, kiểm tra quy trình khôi phục và sự xem xét của người có chuyên môn phù hợp.
Không đồng nhất việc vượt qua kiểm thử với việc không còn lỗi
Ngay cả phần mềm được phát triển theo quy trình chuyên nghiệp cũng có thể còn lỗi chưa được phát hiện. Kiểm thử giúp giảm rủi ro bằng cách tìm kiếm vấn đề theo những phương pháp có hệ thống, nhưng không thể chứng minh tuyệt đối rằng mọi tình huống đều hoạt động hoàn hảo.
Vì vậy, sau khi triển khai, bạn vẫn cần theo dõi nhật ký lỗi, phản hồi người dùng và các chỉ số hoạt động. Khi phát hiện vấn đề mới, hãy tái hiện lỗi, xác định nguyên nhân, sửa đổi có kiểm soát và bổ sung bài kiểm thử để tránh lặp lại.
Cách duy trì chất lượng khi tiếp tục phát triển bằng Vibe Coding
Điểm khác biệt của Vibe Coding là việc chỉnh sửa ứng dụng có thể diễn ra liên tục thông qua các yêu cầu bằng ngôn ngữ tự nhiên. Một sản phẩm được kiểm thử kỹ hôm nay vẫn có thể phát sinh lỗi vào ngày mai nếu AI thay đổi những thành phần quan trọng.
Do đó, kiểm thử cần trở thành một phần của vòng lặp phát triển, thay vì chỉ thực hiện một lần trước khi đưa ứng dụng vào sử dụng.
Mỗi khi bổ sung chức năng, hãy cập nhật tiêu chí chấp nhận, viết thêm bài kiểm thử cho logic mới và xác định những chức năng cũ có khả năng bị ảnh hưởng. Khi sửa lỗi, hãy lưu lại tình huống gây ra lỗi để có thể tái hiện và kiểm tra tự động trong những lần sau.
Nếu dự án có nhiều người cùng tham gia, nên thống nhất quy trình xem xét mã nguồn, chạy kiểm thử và phê duyệt thay đổi. Với dự án sử dụng Git, có thể thiết lập quy trình tích hợp liên tục để tự động chạy các bài kiểm thử cần thiết khi mã nguồn được cập nhật.
Đồng thời, hãy yêu cầu AI giải thích các thay đổi có ảnh hưởng lớn, ghi nhận những giả định chưa được xác minh và không tự động chấp nhận các chỉnh sửa liên quan đến bảo mật, dữ liệu hoặc cấu hình sản xuất mà chưa có sự kiểm tra phù hợp.
Về lâu dài, chất lượng của một ứng dụng Vibe Coding không chỉ phụ thuộc vào khả năng tạo mã của AI mà còn nằm ở cách người phát triển kiểm soát yêu cầu, đánh giá kết quả và quản lý những thay đổi phát sinh.
Kết luận
Kiểm thử ứng dụng được xây dựng bằng Vibe Coding là quá trình xác minh toàn diện từ logic nghiệp vụ, dữ liệu, API và giao diện đến bảo mật, hiệu năng và khả năng khôi phục. Việc ứng dụng có thể chạy hoặc AI báo đã hoàn thành không đủ để chứng minh sản phẩm đã sẵn sàng phục vụ người dùng.
Để bắt đầu hiệu quả, hãy xác định các chức năng quan trọng, xây dựng tiêu chí kiểm thử rõ ràng, kiểm tra những tình huống bất thường và sử dụng AI để hỗ trợ tạo test case. Sau đó, chạy các bài kiểm thử thực tế, xem xét mã nguồn sau mỗi lần chỉnh sửa và kiểm tra hồi quy trước khi triển khai.
Với ứng dụng nhỏ, bạn có thể bắt đầu bằng quy trình thủ công có hệ thống kết hợp một số bài kiểm thử tự động. Khi sản phẩm phát triển, hãy mở rộng phạm vi kiểm thử dựa trên rủi ro và mức độ quan trọng của dữ liệu.
Vibe Coding giúp rút ngắn con đường từ ý tưởng đến phần mềm, nhưng để biến một sản phẩm được AI tạo ra thành ứng dụng đáng tin cậy, bạn vẫn cần kiểm thử có phương pháp, đánh giá có bằng chứng và duy trì chất lượng trong suốt vòng đời phát triển.
- 0 Bình luận
Email, Điện thoại của bạn sẽ không được hiển thị công khai. Các trường bắt buộc được đánh dấu *
