Viết test case cho form nhập liệu: giá trị biên, định dạng, tiếng Việt có dấu, XSS và số điện thoại +84

Form là nơi người dùng đưa dữ liệu vào hệ thống, nên cũng là nơi bug hay nằm nhất. Một form đăng ký chỉ có 5 trường nhưng nếu test kỹ thì dễ ra 40-50 test case. Bài này chia sẻ cách mình nghĩ test case cho từng trường một cách có hệ thống, để không phụ thuộc vào "cảm hứng" hôm đó.

1. Bắt đầu từ đặc tả của từng trường

Trước khi viết bất kỳ test case nào, hãy ghi lại cho mỗi trường 4 thông tin:

Nếu đặc tả không nói rõ (ví dụ: "họ tên có cho phép số không?"), đó là câu hỏi cần hỏi BA/PO trước khi test, không phải sau khi log bug. Bảng này cũng chính là input cho mọi kỹ thuật bên dưới.

2. Nhóm test case chung cho mọi trường

Trường nào cũng nên có ít nhất các case sau:

• Hợp lệ: giá trị bình thường, phải được lưu đúng.
• Để trống: trường bắt buộc phải báo lỗi; trường không bắt buộc phải cho submit.
• Chỉ khoảng trắng (" "): rất nhiều hệ thống chỉ kiểm tra value !== '' nên lọt qua. Kỳ vọng: coi như trống.
• Khoảng trắng đầu/cuối (" An "): nên được trim trước khi lưu, nếu không sẽ gây lỗi khi đăng nhập hoặc tìm kiếm sau này.
• Copy/paste: một số form chặn paste ở trường xác nhận mật khẩu, kiểm tra xem có đúng yêu cầu không.

3. Phân vùng tương đương và giá trị biên

Với ràng buộc độ dài 2-50 ký tự, không cần thử tất cả độ dài. Chia thành 3 vùng: < 2 (sai), 2..50 (đúng), > 50 (sai), rồi lấy giá trị ở biên, vì lập trình viên hay nhầm < với <=:

Với trường số (Tuổi 18-60) cũng vậy: 17, 18, 60, 61. Thêm các giá trị "không phải số" mà người dùng thật hay nhập: abc, 1e5, -0, 12,5. Đặc biệt 12,5 vs 12.5: người Việt quen dùng dấu phẩy thập phân, hệ thống phải xử lý nhất quán.

Một mẹo nhỏ: khi kiểm tra max, hãy kiểm tra cả frontend lẫn API. Ô input có maxlength="50" không có nghĩa là backend chặn; gửi thẳng request 51 ký tự bằng Postman hoặc DevTools để chắc chắn.

4. Tiếng Việt có dấu: chỗ hay bị bỏ quên

Nếu sản phẩm cho người Việt, đây là nhóm case không thể thiếu:

• Nguyễn Thị Ngọc Ánh: lưu xong mở lại có bị thành Nguy?n hay mất dấu không? (lỗi encoding/collation của DB)
• Độ dài tính theo gì? Chữ ễ có thể là 1 ký tự (NFC) hoặc 2 code point (NFD, khi gõ bằng một số bộ gõ hoặc copy từ macOS). Một tên 50 ký tự có dấu có thể bị đếm thành 60+ và báo lỗi sai.
• Tìm kiếm: tìm nguyen có ra Nguyễn không, có đúng yêu cầu không?
• Sắp xếp: Á nằm sau Z là dấu hiệu sort theo byte thay vì theo locale.
• Emoji 😀: một số DB cấu hình utf8 (3 byte) của MySQL sẽ báo lỗi hoặc cắt chuỗi, cần utf8mb4.

5. Ký tự đặc biệt và XSS cơ bản

Tester không cần là chuyên gia bảo mật, nhưng nên thử vài giá trị kinh điển ở mọi trường text, sau đó kiểm tra nơi dữ liệu được hiển thị lại (trang profile, danh sách admin, email thông báo):

<script>alert(1)</script>
"><img src=x onerror=alert(1)>
' OR '1'='1
O'Brien
Tên; DROP TABLE users;--

Kỳ vọng đúng: dữ liệu được lưu hoặc từ chối rõ ràng, khi hiển thị thì được escape (thấy đúng chuỗi ký tự, không có popup), và không có trang lỗi 500. Lưu ý O'Brien là tên hợp lệ: hệ thống chặn dấu nháy đơn một cách "thô bạo" cũng là bug.

6. Email

• Hợp lệ: an@example.com, an.nguyen+test@example.com.vn
• Sai: an@, @example.com, an@@example.com, an example@mail.com
• Hoa/thường: An@Example.com và an@example.com có bị coi là 2 tài khoản khác nhau không?
• Trùng email đã đăng ký: thông báo nên rõ ràng, nhưng ở form đăng nhập/quên mật khẩu thì không nên tiết lộ email có tồn tại hay không.

7. Số điện thoại Việt Nam

Đây là trường mà form "copy từ template nước ngoài" hay sai nhất:

Điểm quan trọng nhất là chuẩn hóa: nếu lưu cả 0912… và +84912… như 2 giá trị khác nhau, một người có thể đăng ký 2 tài khoản với cùng số, hoặc không đăng nhập được bằng OTP.

8. Hành vi của cả form

Sau khi test từng trường, đừng quên test form như một khối:

• Bấm Submit liên tục (double click, mạng chậm): có tạo bản ghi trùng không? Nút có bị disable trong lúc gửi không?
• Submit lỗi xong, dữ liệu đã nhập có được giữ lại không? (trừ mật khẩu)
• Tab đi đúng thứ tự, Enter gửi được form.
• Thông báo lỗi hiển thị cạnh trường bị lỗi, nội dung dễ hiểu, không phải Validation failed: 422.
• Bấm Back sau khi submit thành công có gửi lại form không?

9. Tự động sinh danh sách case để khỏi gõ tay

Viết tay các case trên cho từng form khá mất thời gian và dễ sót. Mình làm một công cụ nhỏ chạy hoàn toàn trên trình duyệt (không gửi dữ liệu đi đâu) để sinh khung test case từ đặc tả:

👉 https://qakit-vn.surge.sh/tao-test-case.html

Mỗi dòng là một trường theo cú pháp Tên | kiểu | bắt buộc | min | max, kiểu gồm text, email, phone, number, password:

Họ tên | text | có | 2 | 50
Email | email | có
Số điện thoại | phone | có
Tuổi | number | không | 18 | 60
Mật khẩu | password | có | 8 | 32

Công cụ sinh ra các case về trống, khoảng trắng, biên, tiếng Việt, ký tự đặc biệt, định dạng email/số điện thoại VN... rồi xuất CSV để mở bằng Excel hoặc import vào công cụ quản lý test. Bạn vẫn cần đọc lại và bổ sung case nghiệp vụ, vì công cụ không biết logic riêng của sản phẩm.

10. Checklist để tick trước khi release

Mình cũng để một checklist 27 mục cho form và đăng nhập ở dạng Markdown, có thể copy thẳng vào ticket Jira/PR để tick:

👉 https://github.com/qakit-vn/checklist-kiem-thu-web

Thấy thiếu case nào hay gặp ở dự án của bạn thì cứ mở Issue/PR, mình sẽ bổ sung.

Tóm lại

1. Lập bảng đặc tả cho từng trường trước khi viết case.
2. Áp dụng phân vùng tương đương + giá trị biên, kiểm tra cả frontend và API.
3. Với sản phẩm Việt: luôn có case tiếng Việt có dấu, emoji và số điện thoại +84.
4. Thử vài payload XSS/ký tự đặc biệt và kiểm tra chỗ hiển thị lại.
5. Test hành vi của cả form: submit trùng, giữ dữ liệu, thông báo lỗi.

Bạn hay gặp bug form nào "kinh điển" nhất? Chia sẻ dưới comment nhé.

Công khai: mình (Siêng Studio) là người làm QA Kit tiếng Việt, bộ checklist 110 mục, repo Playwright và file Excel test case có trả phí. Công cụ và checklist trong bài là miễn phí, dùng không cần mua gì. Bài gốc liên quan: Cách viết test case bằng Excel.