Kiểm thử Mini App dùng AI: checklist chức năng, dữ liệu và bảo mật

Một Mini App có giao diện đẹp vẫn có thể lưu sai dữ liệu, mất nội dung sau khi tải lại hoặc cho người dùng xem thông tin của người khác. Khi xây ứng dụng với AI, tốc độ tạo tính năng thường nhanh hơn tốc độ hiểu sản phẩm. Kiểm thử giúp thu hẹp khoảng cách đó bằng những thao tác có thể lặp lại và kết quả mong đợi rõ ràng.

Bài viết này dùng ví dụ một ứng dụng quản lý bài tập nhóm. Sinh viên tạo công việc, chọn người phụ trách, đặt hạn và đánh dấu hoàn thành. Bạn có thể thay bằng ứng dụng đặt lịch, theo dõi chi tiêu mô phỏng hoặc thư viện tài liệu. Đây là hướng dẫn thực hành, không phải bộ tiêu chí chấm chính thức của cuộc thi.

1. Xác định điều gì tuyệt đối không được sai

Trước khi mở ứng dụng, hãy viết ba lời hứa quan trọng nhất của sản phẩm. Với ứng dụng bài tập nhóm, chúng có thể là: công việc được lưu đúng; thành viên chỉ thao tác trong nhóm của mình; trạng thái hoàn thành được hiển thị nhất quán. Ba lời hứa này giúp đội ưu tiên kiểm tra thay vì bấm ngẫu nhiên mọi nút.

2. Viết ca kiểm thử trước khi sửa giao diện

Một ca kiểm thử đơn giản cần bốn thành phần: điều kiện ban đầu, các bước thực hiện, kết quả mong đợi và kết quả thực tế. Tạo một bảng dùng chung hoặc ghi thành danh sách. Mỗi ca chỉ tập trung vào một hành vi chính để khi thất bại, đội biết cần điều tra ở đâu.

Ví dụ: điều kiện là đang đăng nhập bằng tài khoản thử A; bước làm là tạo công việc không có tên; kết quả mong đợi là biểu mẫu báo lỗi dễ hiểu và không tạo bản ghi rỗng. Một ca khác kiểm tra tên có khoảng trắng ở đầu và cuối. Hai tình huống gần nhau nhưng phát hiện những vấn đề khác nhau.

• Ghi mã ca kiểm thử, chẳng hạn TASK-01.
• Ghi phiên bản hoặc thời điểm đang kiểm tra.
• Đính kèm ảnh lỗi nếu ảnh giúp tái hiện tình huống.
• Ghi rõ đã kiểm tra lại sau khi sửa hay chưa.

3. Kiểm tra cả dữ liệu hợp lệ và dữ liệu sai

Dữ liệu mẫu đẹp chỉ chứng minh ứng dụng xử lý được tình huống dễ nhất. Hãy thử trường rỗng, chuỗi rất dài, ký tự tiếng Việt, dấu nháy, xuống dòng, số âm và ngày không hợp lệ. Chọn các trường hợp liên quan đến chức năng thực tế, tránh thêm kiểm tra không có mục đích.

Với hạn công việc, hãy quyết định rõ có cho phép ngày trong quá khứ hay không. Nếu có, giao diện phải giải thích được trạng thái quá hạn. Nếu không, ứng dụng cần từ chối nhất quán. Với số lượng thành viên, thử ranh giới ngay dưới, đúng bằng và ngay trên giới hạn mà đội đã đặt ra.

4. Kiểm tra việc lưu và khôi phục trạng thái

Hãy tạo một bản ghi, chuyển trang rồi quay lại. Tiếp tục tải lại trình duyệt, đăng xuất và đăng nhập lại. Những bước đơn giản này giúp phân biệt dữ liệu đang tồn tại tạm trong giao diện với dữ liệu đã được lưu bền vững.

5. Kiểm tra đăng nhập và phân quyền bằng hai tài khoản

Đăng nhập xác định người đang dùng ứng dụng; phân quyền quyết định họ được làm gì. Hai việc này cần kiểm tra riêng. Tài khoản A có thể đăng nhập thành công nhưng vẫn không được phép sửa nhóm của tài khoản B.

Tạo hai tài khoản thử với dữ liệu tách biệt. Sao chép đường dẫn đến một công việc của A rồi mở bằng B. Nếu sản phẩm thiết kế công việc là riêng tư, B phải bị từ chối. Tiếp tục thử truy cập khi đã đăng xuất. Không xem việc ẩn nút “Sửa” là bằng chứng phân quyền đã hoạt động ở phía máy chủ.

6. Kiểm tra trải nghiệm khi mọi thứ không thuận lợi

Một bài demo thường diễn ra trên máy quen thuộc và đường truyền tốt. Người dùng thật có thể mở bằng điện thoại nhỏ, mạng chậm hoặc bàn phím che mất nút gửi. Hãy kiểm tra ít nhất một màn hình hẹp và một màn hình rộng, đồng thời phóng to chữ để xem nội dung có bị cắt không.

7. Dùng AI hỗ trợ kiểm thử mà vẫn tự kiểm chứng

Bạn có thể yêu cầu AI đề xuất ca kiểm thử từ mô tả tính năng. Một lời nhắc hữu ích là: “Với chức năng tạo công việc nhóm, hãy liệt kê tình huống hợp lệ, dữ liệu sai, ranh giới và lỗi phân quyền. Mỗi tình huống phải có kết quả mong đợi quan sát được”. Sau đó loại những ca không liên quan đến thiết kế của đội.

Khi gặp lỗi, cung cấp các bước tái hiện, thông báo lỗi đã loại bỏ thông tin riêng tư và kết quả mong đợi. Yêu cầu AI giải thích nguyên nhân dự kiến trước khi sửa. Sau thay đổi, chạy lại ca lỗi và một vài ca gần đó để phát hiện tác động phụ.

8. Phân loại lỗi và quyết định trước khi nộp

Chia lỗi thành nhóm theo tác động. Lỗi làm lộ dữ liệu, mất bản ghi hoặc không hoàn thành được chức năng cốt lõi cần xử lý trước. Lỗi căn lề, khoảng cách hoặc hiệu ứng có thể được xếp sau nếu không cản trở sử dụng. Mức ưu tiên cần dựa trên hậu quả với người dùng, không dựa trên việc lỗi nào dễ sửa hơn.

Lập một danh sách trước khi nộp: luồng chính hoàn thành được; đăng xuất chặn truy cập riêng tư; dữ liệu còn sau tải lại; biểu mẫu báo lỗi rõ; liên kết mở được bằng cửa sổ mới; không có khóa truy cập trong mã công khai; dữ liệu trình diễn là dữ liệu giả lập. Ghi những hạn chế còn tồn tại để người demo không vô tình hứa quá khả năng sản phẩm.

9. Câu hỏi thường gặp và bài tập cho đội

Cần bao nhiêu ca kiểm thử mới đủ?

Không có con số chung cho mọi Mini App. Hãy bắt đầu từ mỗi lời hứa cốt lõi, bổ sung tình huống sai và phân quyền có liên quan. Khi phát hiện một lỗi thật, lưu lại ca tái hiện để lần sửa sau không làm lỗi quay lại.

Kiểm thử thủ công có còn giá trị khi đã có kiểm thử tự động?

Có. Kiểm tra tự động hữu ích với quy tắc lặp lại, còn thao tác thực tế giúp phát hiện thông báo khó hiểu, thứ tự luồng bất hợp lý và vấn đề trên thiết bị khác. Đội nên chọn cách kiểm tra theo rủi ro của tính năng.

Bài tập trong buổi làm việc tiếp theo

Dành một phiên để một thành viên chưa xây chức năng dùng thử ứng dụng. Người còn lại quan sát và ghi lại lúc họ dừng, hỏi lại hoặc thao tác sai. Không hướng dẫn ngay từ đầu. Sau đó chọn ba vấn đề ảnh hưởng rõ nhất, sửa từng vấn đề và kiểm tra lại bằng cùng nhiệm vụ. Kết quả của buổi này nên là bằng chứng cụ thể về trải nghiệm đã tốt hơn, thay vì một danh sách nhận xét chung chung.