Email ảo để kiểm thử: địa chỉ an toàn cho biểu mẫu đăng ký
Nếu bạn làm hoặc kiểm thử website, bạn gõ địa chỉ email vào biểu mẫu suốt ngày. Điều duy nhất không được phép xảy ra là một thư kiểm thử rơi vào hộp thư thật của người lạ. Trang này chỉ ra nên dùng email ảo nào cho từng kiểu kiểm thử — và khi nào thư thật sự phải đến nơi.
Trước tiên, quyết định thư có cần đến nơi không
Chỉ một câu hỏi này quyết định mọi thứ, và nên đặt nó ra rõ ràng, vì câu trả lời «không» xuất hiện nhiều hơn người ta nghĩ.
| Bạn đang kiểm thử gì | Thư có cần đến nơi? | Dùng |
|---|---|---|
| Kiểm tra hợp lệ, lưu trữ, hiển thị một địa chỉ | không | một tên miền dành riêng — xem bên dưới |
| Luồng xác nhận, làm thủ công | có | một hộp thư ở đây |
| Luồng xác nhận, tự động | có, và mã phải đọc được | một dịch vụ có API |
| Kiểm thử tải hoặc khối lượng | không — và không được phép | luôn là tên miền dành riêng |
Khi thư không được đến nơi: dùng tên dành riêng
Có những tên miền sinh ra đúng cho việc này và được bảo đảm không bao giờ thuộc về ai: example.com cùng các anh em example.net và example.org, được dành riêng theo RFC 2606, cộng với toàn bộ đuôi .test.
Địa chỉ trên các tên miền này là lựa chọn đúng cho dữ liệu mẫu, dữ liệu khởi tạo và kiểm thử tải. Không thứ gì bạn gửi có thể đến tay một người, vì ở đó không có ai — theo thỏa thuận quốc tế, không phải nhờ may mắn.
test@mycompanytest.com khá thường là tên miền thật của ai đó, và một lần kiểm thử tải nhắm vào nó không khác gì một cuộc tấn công. Tên dành riêng chẳng tốn gì và loại bỏ hẳn kiểu sự cố này.Khi thư phải đến nơi, làm thủ công
Lấy một địa chỉ ở đây, chạy luồng và đọc xem ứng dụng của bạn thật sự gửi gì — tiêu đề, đường liên kết, và lá thư trông thế nào khi không phải chương trình email của chính bạn hiển thị. Có hai điều cách này phát hiện được mà một công cụ bắt thư cục bộ không thấy:
- Việc giao thư thật. Thư đi qua một đường thư thật, nên bên gửi cấu hình sai sẽ hỏng ở đây chứ không phải trên môi trường chạy thật.
- Người lạ nhìn thấy gì. Đường liên kết chỉ chạy trong phiên của bạn, ảnh không bao giờ tải, liên kết hủy đăng ký trỏ về localhost — thấy ngay lập tức.
Nếu ứng dụng của bạn gửi tệp, hãy để ý cả cảnh báo tệp đính kèm: đó cũng chính là cảnh báo người dùng của bạn sẽ thấy.
Khi phải tự động hóa
Thay vào đó mà đi cào dữ liệu trang là một cuộc đổi chác tồi, kể cả khi nó chạy: dễ vỡ, không có tài liệu, và đúng kiểu lưu lượng sớm muộn cũng bị chặn.
Kiểm thử các trường hợp bị từ chối
Những lỗi đáng chú ý không phải là «một địa chỉ hợp lệ thì chạy». Nên bao quát:
- Một địa chỉ trên tên miền không có bản ghi MX — việc giao thư thất bại dù địa chỉ được viết đúng. Mã của bạn nên phân biệt được hai trường hợp. Kiểm tra xem cái nào là cái nào.
- Một tên miền quốc tế hóa, ở cả dạng Unicode lẫn dạng
xn--. Phần lớn bộ kiểm tra từ chối dạng này và nhận dạng kia, mà thường là ngược đời — bộ chuyển đổi. - Biến thể Gmail có dấu chấm và dấu cộng. Nếu bước kiểm tra trùng của bạn so chuỗi nguyên văn, một người có thể tạo vô số tài khoản. Chuẩn hóa trước — trang đó làm đúng việc mà bước kiểm tra của bạn nên làm.
- Phần trước @ rất dài. Tiêu chuẩn cho phép 64 ký tự; nhiều biểu mẫu lặng lẽ cắt ở 20 và lưu lại một thứ không còn dẫn tới đâu.
Thứ cần xây, không phải để kiểm thử
Nếu sản phẩm của bạn không nhận địa chỉ email ảo, hãy từ chối rõ ràng. «Email không hợp lệ» cho một địa chỉ hoàn toàn hợp lệ là lỗi gây bối rối nhất trong loại này: người dùng kiểm tra chính tả, gõ lại và nhận đúng thông báo cũ. «Chúng tôi không nhận địa chỉ email ảo» chiếm cùng chỗ và chấm dứt sự bối rối.