Nghiệm thu lỗi nhập liệu biểu mẫu cần thử cả lúc nhập sai lẫn sau khi sửa đúng. Đừng chỉ để trống toàn bộ rồi bấm gửi: cách đó không cho biết trường tùy chọn có bị ép nhập, giới hạn độ dài có hợp lý hay thông báo có giúp người dùng hoàn thành yêu cầu hay không.
Bài này dành cho người thuê làm website muốn giao một bộ tình huống rõ ràng cho nhà cung cấp. Phạm vi là kiểm tra dữ liệu đầu vào và trải nghiệm sửa lỗi; không phải kiểm toán bảo mật, chứng nhận tiếp cận hay xác nhận một biểu mẫu cụ thể đã hoạt động tốt. Nếu chưa chốt phạm vi dự án, bắt đầu từ checklist thuê dịch vụ thiết kế website.
1. Thống nhất quy tắc trước khi chấm đạt hay lỗi
Lập danh sách từng ô gồm tên hiển thị, bắt buộc hay tùy chọn, định dạng và giới hạn nếu có. Hỏi nhà cung cấp quy tắc nào xuất phát từ nhu cầu xử lý thực tế. Không mặc định mọi ô đều phải nhập, hoặc số điện thoại nào cũng cần cùng một kiểu trình bày.
Ví dụ giả định: biểu mẫu hỏi báo giá cần địa chỉ email để trả lời, có ô ghi chú tùy chọn và giới hạn độ dài mô tả do hai bên thống nhất. Khi đó, để trống ghi chú phải khác với để trống email. Nếu chưa thống nhất giới hạn mô tả thì chưa thể kết luận một đoạn dài bị từ chối là đúng hay sai yêu cầu.
Theo hướng dẫn kiểm tra dữ liệu biểu mẫu của MDN, trình duyệt có thể kiểm tra trường bắt buộc, kiểu dữ liệu, độ dài và miền giá trị. Những ràng buộc này giúp phản hồi sớm, nhưng kiểm tra tại trình duyệt không thay thế việc kiểm tra trên máy chủ. Chủ website có thể nghiệm thu luồng sử dụng; phần xác minh kỹ thuật phía máy chủ cần người có chuyên môn thực hiện trong phạm vi được phép.
2. Chuẩn bị môi trường và bộ dữ liệu thử
Dùng môi trường thử đã được hai bên chấp thuận, với hộp thư nhận thử do người kiểm tra kiểm soát. Không dùng thông tin khách hàng thật, không gửi đến hộp thư người khác và không tạo yêu cầu dịch vụ thật chỉ để xem một dòng thông báo.
Ghi URL, phiên bản bản dựng, trình duyệt và kích thước màn hình. Nếu biểu mẫu có thao tác đặt lịch hoặc thanh toán, thống nhất cơ chế thử riêng trước khi gửi. Trường hợp chỉ được phép xem giao diện, ghi rõ “chưa thử gửi” thay vì đánh dấu toàn bộ luồng đã đạt.
Chuẩn bị một bộ dữ liệu hợp lệ làm mốc. Mỗi lần thử chỉ thay đổi một trường rồi ghi kết quả; sau đó mới thử nhiều lỗi cùng lúc. Cách này giúp biết quy tắc nào gây chặn, thay vì nhận một thông báo chung và phải đoán nguyên nhân.
3. Sáu tình huống cần thử và bằng chứng cần giữ
Trường bắt buộc để trống
Giữ các trường khác hợp lệ, bỏ trống một trường bắt buộc rồi gửi. Mong đợi là biểu mẫu chỉ rõ trường cần bổ sung và chưa báo đã nhận yêu cầu. Sau khi điền, thử lại để kiểm tra thông báo cũ không còn chặn vô lý.
Trường tùy chọn không có dữ liệu
Để trống ô tùy chọn nhưng điền đủ những ô bắt buộc. Nếu biểu mẫu vẫn yêu cầu nhập, đối chiếu lại danh sách quy tắc. Đừng chữa bằng cách đổi mọi nhãn thành “bắt buộc”: phải quyết định dữ liệu đó có thực sự cần hay không.
Dữ liệu sai định dạng đã công bố
Với ô email, có thể thử chuỗi thiếu dấu @ rồi thay bằng địa chỉ thử hợp lệ của mình. Thông báo nên nói cần sửa gì, chẳng hạn “Nhập địa chỉ email có dạng tên@tên-miền”, thay vì chỉ hiện “Có lỗi”. Đây là kiểm tra hình thức địa chỉ, không chứng minh hộp thư tồn tại hoặc thư đã được phát đến nơi.
Với số điện thoại, ngày tháng hoặc mã hồ sơ, thử theo định dạng thực sự được công bố. Nếu hướng dẫn cho phép khoảng trắng nhưng biểu mẫu lại từ chối, ghi đó là sự không nhất quán cần giải quyết; không tự đặt thêm quy tắc ngoài phạm vi.
Độ dài ở sát giới hạn
Khi có giới hạn, chuẩn bị nội dung ngay dưới, đúng và trên giới hạn đã thống nhất. Thử bằng thao tác gõ hoặc dán như người dùng, không chỉ dựa vào dữ liệu được mã thử tự gán. MDN lưu ý ràng buộc độ dài có khác biệt với giá trị được thiết lập bằng lập trình.
Quan sát cả trường hợp ô không cho nhập thêm: người dùng có biết giới hạn ở đâu không, và phần đang nhập có bị cắt khiến họ tưởng nội dung vẫn đầy đủ không? Nếu dùng tiếng Việt, thử một đoạn có dấu và đề nghị đội kỹ thuật giải thích cách đếm khi kết quả không khớp kỳ vọng. Không áp một quy tắc đếm ký tự cho mọi hệ thống.
Nhiều trường sai cùng lúc
Tạo hai lỗi độc lập, chẳng hạn thiếu email và mô tả vượt giới hạn. Sửa một lỗi rồi gửi lại. Kiểm tra người dùng có tìm được lỗi còn lại và những dữ liệu hợp lệ có còn được giữ trong các ô thông thường hay không. Không yêu cầu giữ lại mật khẩu hoặc dữ liệu nhạy cảm chỉ vì muốn tránh nhập lại.
Dữ liệu đã sửa đúng
Sau mỗi tình huống lỗi, đưa dữ liệu về trạng thái hợp lệ và thử đến bước kết thúc trong môi trường cho phép. Việc thông báo đỏ biến mất chưa chứng minh yêu cầu đã được lưu. Người nghiệm thu cần phân biệt “đã qua kiểm tra đầu vào” với “đã nhận yêu cầu”, và đối chiếu bản ghi thử ở nơi tiếp nhận nếu phạm vi bàn giao có bao gồm bước đó.
Phần chọn người nhận và loại yêu cầu thuộc thiết kế biểu mẫu phân luồng nhu cầu. Hai phép thử bổ sung cho nhau: dữ liệu hợp lệ vẫn có thể được chuyển sai bộ phận.
4. Ghi lỗi theo chuỗi nhập → thông báo → sửa → kết quả
Một bản ghi hữu ích có thể ngắn nhưng cần đủ để người khác tái hiện:
- Vị trí: URL và tên biểu mẫu, ô đang kiểm tra.
- Quy tắc đã chốt: bắt buộc, định dạng hoặc giới hạn nào.
- Dữ liệu thử: giá trị giả hoặc mô tả cách tạo; không chụp thông tin cá nhân thật.
- Thao tác: nhập gì, bấm nút nào, sửa thành gì và thử lại ra sao.
- Mong đợi và thực tế: mô tả riêng, kèm ảnh hoặc video cần thiết.
- Thử lại: bản dựng sau sửa, người thử, kết quả và phần chưa kiểm tra.
Ví dụ giả định: “Ô ghi chú được ghi là tùy chọn. Để trống và gửi bộ dữ liệu hợp lệ thì xuất hiện yêu cầu nhập ghi chú; điền một ký tự mới gửi được. Mong đợi: có thể bỏ trống theo brief.” Bản ghi này có ích hơn nhận xét “form khó dùng” vì chỉ ra được sự lệch giữa thiết kế và hành vi.
Đồng thời, đọc thông báo bằng mắt và thử đi tới chỗ cần sửa. Không chỉ dùng màu đỏ để người đọc tự đoán. Có thể kết hợp kiểm tra website bằng bàn phím để xem người dùng có trở lại được ô lỗi mà không cần chuột. Đánh giá với công nghệ hỗ trợ là một hạng mục riêng nếu dự án có cam kết đó.
5. Khi nào có thể đóng hạng mục nghiệm thu?
Đóng từng tình huống sau khi đã thử lại trên bản sửa, không chỉ vì nhà cung cấp báo “đã xử lý”. Chạy lại bộ dữ liệu hợp lệ ban đầu để chắc việc sửa một lỗi không làm chặn cả trường hợp đúng.
Biên bản cần ghi những giới hạn còn lại: chưa kiểm tra trình duyệt nào, chưa đối chiếu email nhận thử, hay chưa đánh giá kiểm tra phía máy chủ. Không chuyển một kết quả thử giao diện thành kết luận “biểu mẫu an toàn tuyệt đối”. Với vấn đề ngoài phạm vi, thống nhất người xử lý và bước tiếp theo thay vì đánh dấu đạt để hoàn tất giấy tờ.
Câu hỏi thường gặp
Có cần thông báo lỗi giống nhau trên mọi trình duyệt?
Không nhất thiết. MDN cho biết trình duyệt có thể hiển thị thông báo mặc định tùy loại lỗi. Hãy nghiệm thu khả năng hiểu và sửa lỗi trong các trình duyệt đã thỏa thuận, thay vì chỉ so từng chữ giữa các hộp thông báo mặc định.
Nhập email đúng định dạng nghĩa là đã gửi thư thành công?
Không. Định dạng, việc lưu yêu cầu và việc chuyển thư là những bước khác nhau. Muốn xác nhận email đến nơi cần kiểm tra hộp thư thử và trạng thái xử lý phù hợp, không chỉ dựa vào ô nhập đã hết báo lỗi.
Nên sửa bài hướng dẫn hay sửa biểu mẫu khi hai bên khác nhau?
Đối chiếu nhu cầu thật và quy tắc đã chốt trước. Nếu hướng dẫn sai thì sửa hướng dẫn; nếu biểu mẫu lệch yêu cầu thì sửa hành vi. Không âm thầm nới hoặc siết điều kiện chỉ để một bộ test vượt qua.
Phát triển thư viện hướng dẫn dịch vụ với DichVuHay.vn
DichVuHay.vn đang được rao bán, hiện cung cấp nội dung tham khảo và không nhận nghiệm thu hay sửa website. Tên miền có thể phù hợp với dự án hướng dẫn lựa chọn dịch vụ, bộ mẫu brief và tài liệu bàn giao do người mua phát triển thực tế.
Anh/chị quan tâm sở hữu DichVuHay.vn có thể liên hệ 0945 279 268 để trao đổi. Đây là liên hệ mua bán tên miền, không phải đầu mối tiếp nhận lỗi kỹ thuật; quyền sở hữu tên miền không tự bảo đảm thứ hạng tìm kiếm hay khách hàng.
