Tôi đã triển khai nhiều luồng đăng ký hơn mức có thể đếm được. Và mỗi lần như vậy, giai đoạn kiểm thử xác minh email lại là câu chuyện cũ: hộp thư của tôi đầy ắp các tin nhắn kiểm thử, tôi bắt đầu mất dấu bài kiểm thử nào là bài nào, và đâu đó quanh lần đăng ký thứ bốn mươi tôi bắt đầu bỏ qua hoàn toàn các email. Tôi tự nhủ sẽ dọn dẹp chúng sau. Nhưng tôi không dọn. Sáu tháng sau khi ra mắt vẫn còn 200 email xác minh kiểm thử nằm trong hộp thư của tôi chẳng làm gì cả.

Đó là một thói quen thực sự xấu — không chỉ về mặt gọn gàng, mà cả về chất lượng của chính việc kiểm thử. Khi hộp thư của bạn đầy các email kiểm thử trước đó, việc xác minh rằng một bài kiểm thử cụ thể vừa kích hoạt một lần gửi cụ thể trở nên khó hơn nhiều. Bạn bắt đầu đưa ra giả định thay vì thực sự kiểm tra. Bạn bỏ sót những lỗi tinh vi. Và toàn bộ chuyện này hoàn toàn không cần thiết, bởi vì có một cách tiếp cận tốt hơn nhiều.

Bài viết này nói về việc dùng một email tạm thời như một phần cốt lõi của quy trình phát triển khi xây dựng và kiểm thử xác minh email. Nó làm cho quá trình nhanh hơn, sạch hơn, kỹ lưỡng hơn, và thành thật mà nói là dễ chịu hơn rất nhiều.

Xác minh email thực chất bao gồm những gì

Trước khi bàn về việc kiểm thử, đáng để nói chính xác điều chúng ta thực sự đang kiểm thử. Xác minh email không chỉ là "gửi một liên kết". Đó là một quá trình nhiều bước với vài thành phần có thể kiểm thử độc lập, và mỗi thành phần có thể lỗi theo những cách khác nhau và đôi khi tinh vi.

Bước một: tạo một mã thông báo an toàn về mặt mật mã. Bảng ghi nhớ Xác thực của OWASP nói rõ điều này: mã thông báo xác minh phải được tạo bằng bộ sinh số ngẫu nhiên an toàn về mặt mật mã, phải dài ít nhất 32 byte, và phải được lưu theo cách cho phép xác thực phía máy chủ mà không thể đảo ngược. Không phải một số nguyên tuần tự. Không phải một băm dễ đoán của ID người dùng. Một mã thông báo ngẫu nhiên đúng nghĩa.

Bước hai: lưu mã thông báo cùng với siêu dữ liệu phù hợp — nó thuộc về người dùng nào, được tạo khi nào, hết hạn khi nào, và đã được dùng hay chưa. Bước ba: dựng email. Điều này có nghĩa là dòng chủ đề, tên người gửi, phần thân, URL xác minh, và đảm bảo URL đó trỏ đến đúng môi trường (không phải sản phẩm thật từ máy chủ phát triển của bạn). Bước bốn: giao email qua SMTP. RFC 5321 định nghĩa đặc tả Giao thức Truyền Thư Đơn giản — hiểu ngay cả những điều cơ bản về cách SMTP hoạt động sẽ giúp bạn chẩn đoán các vấn đề giao nhận khi chúng xảy ra.

Bước năm: người dùng nhấp vào liên kết. Máy chủ của bạn xác thực mã thông báo: nó có tồn tại không? Nó đã hết hạn chưa? Nó đã được dùng trước đây chưa? Nếu tất cả các kiểm tra đều đạt, tài khoản được đánh dấu là đã xác minh và mã thông báo bị vô hiệu hóa. Nếu bất kỳ kiểm tra nào thất bại, người dùng nhận được một thông báo lỗi rõ ràng. Mỗi bước trong số này là một trường hợp kiểm thử. Mỗi bước có thể sai theo một cách khác nhau. Một quy trình kiểm thử kỹ lưỡng bao phủ tất cả chúng.

Tại sao kiểm thử bằng email thật của bạn là một ý tồi

Dùng địa chỉ email thật của bạn cho việc kiểm thử phát triển có vài vấn đề cụ thể chồng chất trong suốt một dự án. Rõ ràng nhất là sự bừa bộn — sau một trăm lần đăng ký kiểm thử, hộp thư của bạn đầy các email xác minh giờ đã vô dụng. Tìm một kết quả kiểm thử cụ thể trong đống nhiễu đó thực sự khó khăn. Bạn có thể bắt đầu lọc bỏ những email này một cách tự động, nghĩa là bạn ngừng thực sự đọc chúng, nghĩa là bạn ngừng bắt được các lỗi hiển thị và lỗi nội dung trong các mẫu của mình.

Còn có một vấn đề căn bản hơn: bạn không thể mô phỏng một "người dùng mới chưa từng được thấy trước đây" bằng địa chỉ email thật của mình. Địa chỉ của bạn đã tồn tại trong cơ sở dữ liệu của bạn. Để kiểm thử một lần đăng ký mới, bạn phải xóa tài khoản và đăng ký lại — điều này phiền phức và nghĩa là bạn không thể giữ lại bất kỳ trạng thái kiểm thử nào trước đó. Với một địa chỉ tạm thời, mỗi bài kiểm thử thực sự là một người dùng mới với một hộp thư mới thực sự.

Ngoài ra, một số nhà cung cấp email bắt đầu lọc các tin nhắn tương tự lặp lại thành thư rác khi chúng đến từ cùng một tên miền gửi trong một khoảng thời gian ngắn. Các lần gửi kiểm thử của bạn có thể ngừng đến hộp thư hoàn toàn, khiến bạn nghĩ rằng đường ống giao nhận của mình bị hỏng trong khi thực ra không phải. Và bạn đơn giản là không thể kiểm thử các lần đăng ký đồng thời — nếu bạn cần xác minh điều gì xảy ra khi ba người dùng đăng ký cùng lúc, bạn không thể làm điều đó với một địa chỉ email thật.

Giải pháp email tạm thời — Từng bước một

Đây chính xác là cách tôi dùng temp-email.ai trong quy trình phát triển của mình. Mở temp mail trong một tab trình duyệt bên cạnh môi trường phát triển của bạn. Một địa chỉ độc nhất đang chờ bạn ngay lập tức — không cần thiết lập, không cần tạo tài khoản. Sao chép nó bằng một cú nhấp.

Chuyển sang ứng dụng của bạn. Đi đến trang đăng ký. Dán địa chỉ tạm thời vào ô email và điền phần còn lại của biểu mẫu. Gửi đi. Chuyển trở lại tab temp-email.ai. Nếu việc giao nhận email của bạn được cấu hình đúng, email xác minh sẽ đến trong vòng 2 đến 5 giây. Bạn sẽ thấy dòng chủ đề, tên người gửi, và toàn bộ phần thân email hiển thị chính xác như nó sẽ xuất hiện trong bất kỳ ứng dụng email thật nào.

Nhấp vào liên kết xác minh trực tiếp từ hộp thư tạm thời. Ứng dụng của bạn nên xử lý nó đúng cách — chuyển hướng đến đúng trang, hiển thị trạng thái thành công, và đánh dấu tài khoản là đã xác minh. Bạn vừa hoàn thành một bài kiểm thử đầu-cuối đầy đủ cho luồng xác minh của mình. Giờ mở một tab thứ hai và làm lại với một địa chỉ mới để kiểm thử một lần đăng ký đồng thời. Toàn bộ quá trình từ "cần kiểm thử" đến "kiểm thử xong" mất khoảng hai phút.

Cần kiểm thử những gì trong luồng xác minh của bạn

Đây là danh sách kiểm tra toàn diện mà tôi làm theo khi kiểm thử một triển khai xác minh email:

• Giao nhận cơ bản: Email có đến không? Kiểm thử điều này với nhiều tình huống gửi — điều gì xảy ra khi bạn đăng ký trên một môi trường cục bộ mới so với môi trường thử nghiệm so với môi trường sản phẩm? Các vấn đề giao nhận thường đặc thù theo môi trường.
• Tính đúng đắn của liên kết: URL xác minh trong email có trỏ đến đúng môi trường không? Rất dễ một cách đáng xấu hổ khi mã hóa cứng một URL sản phẩm trong một mẫu rồi được dùng trong quá trình phát triển. Liên kết nên được dựng động từ cấu hình URL cơ sở của bạn.
• Bảo mật mã thông báo: Mã thông báo có dài ít nhất 32 ký tự và thực sự ngẫu nhiên không? Kiểm tra mã thông báo trong URL — nó nên trông giống một chuỗi ngẫu nhiên gồm chữ cái và chữ số, không phải một khuôn mẫu dễ đoán. Tham khảo Bảng ghi nhớ Xác thực của OWASP để có hướng dẫn cụ thể về việc tạo mã thông báo.
• Hết hạn mã thông báo: Điều gì xảy ra khi bạn để một liên kết xác minh nằm đó lâu hơn cửa sổ hết hạn của bạn rồi mới nhấp vào? Ứng dụng của bạn nên xử lý điều này một cách nhẹ nhàng — một thông báo rõ ràng cho người dùng biết liên kết đã hết hạn và một lời nhắc yêu cầu liên kết mới. Không phải một lỗi 500 chung chung.
• Thực thi dùng một lần: Cùng một liên kết xác minh có thể được dùng hai lần không? Sau khi bạn đã xác minh một lần, nhấp vào liên kết lần nữa không nên thành công. Nó nên báo cho người dùng biết tài khoản của họ đã được xác minh, hoặc rằng liên kết không hợp lệ. Kiểm thử điều này một cách rõ ràng.
• Đăng ký lại trước khi xác minh: Điều gì xảy ra nếu một người dùng đăng ký, không xác minh email của họ, rồi cố đăng ký lại với cùng một địa chỉ? Ứng dụng của bạn có xử lý điều này đúng cách không — hoặc gửi lại xác minh hoặc bảo họ kiểm tra hộp thư?
• Chức năng gửi lại: Nút "gửi lại email xác minh" có hoạt động không? Nhấp vào nó có vô hiệu hóa mã thông báo trước đó và gửi một mã mới không? Kiểm thử bằng cách nhấp vào nó nhiều lần thật nhanh — điều gì xảy ra nếu ai đó nhấp gửi lại mười lần?
• Hiển thị HTML: Mẫu email của bạn có hiển thị đúng trong một hộp thư thật không? Trong trình xem của temp-email.ai, hãy kiểm tra: các nút có thực sự nhấp được không? Hình ảnh có tải không? Bố cục có nguyên vẹn trên cả bản xem trước máy tính và di động không? Văn bản có tràn ra chỗ nào không?
• Dòng chủ đề và tên người gửi: Dòng chủ đề có rõ ràng, chuyên nghiệp, và không dễ kích hoạt bộ lọc thư rác không? Tên người gửi có phải là tên thương hiệu của bạn, không phải tên của một nhà cung cấp dịch vụ chung chung không? Những điều này quan trọng cho khả năng giao nhận và độ tin cậy của người dùng.
• Cá nhân hóa: Tên hoặc tên người dùng có được điền vào đúng chỗ nó nên xuất hiện trong phần thân email không? Đây là một lỗi mẫu thường gặp — việc thay thế biến âm thầm thất bại và bạn rốt cuộc gửi "Chào {{firstName}}" thay vì "Chào Sarah."

Kiểm thử qua các tình huống khác nhau

Đăng ký tiêu chuẩn không phải là luồng duy nhất gửi những tin nhắn kiểu xác minh email. Nếu ứng dụng của bạn hỗ trợ đăng nhập bằng mạng xã hội — "Đăng ký bằng Google" hoặc OAuth qua các nhà cung cấp tương tự — hầu hết các triển khai vẫn gửi một email chào mừng hoặc xác nhận tạo tài khoản. Hãy kiểm thử luồng đó nữa. Mở một hộp thư tạm thời, dùng nó làm email liên kết cho bài kiểm thử OAuth của bạn, và xác minh email chào mừng đến và trông đúng.

Các luồng đặt lại mật khẩu về mặt cấu trúc gần như giống hệt xác minh email: tạo một mã thông báo an toàn, gửi email một liên kết, xác thực khi nhấp, vô hiệu hóa sau khi dùng. Mọi mục trong danh sách kiểm tra kiểm thử ở trên đều áp dụng như nhau cho việc đặt lại mật khẩu. Việc xác minh thay đổi địa chỉ email cũng vậy — khi một người dùng cập nhật email của họ trong cài đặt, bạn cần xác minh địa chỉ mới trước khi thực hiện chuyển đổi. Đó là một luồng email hoàn chỉnh khác cần kiểm thử độc lập.

Email mời — nơi một người dùng mời một đồng nghiệp tham gia — thêm một chiều nữa: hộp thư của người được mời. Với các địa chỉ email tạm thời, bạn có thể kiểm thử cả hai phía của một luồng mời trong cùng một phiên trình duyệt. Gửi từ tài khoản kiểm thử chính của bạn, nhận trên một địa chỉ tạm thời, chấp nhận, và xác minh trạng thái sau khi chấp nhận. Gọn gàng, đầy đủ, và nhanh chóng.

Nhiều người dùng đồng thời

Đây là một trong những lợi thế lớn nhất của các địa chỉ email tạm thời cho việc kiểm thử phát triển, và đó là điều đơn giản là không thể làm được với một tài khoản email thật duy nhất. Mỗi tab trình duyệt trên temp-email.ai là một hộp thư hoàn toàn độc lập. Bạn có thể mở năm tab cùng lúc, mỗi tab với một địa chỉ khác nhau, đăng ký năm tài khoản trong ứng dụng của bạn cùng một thời điểm, và xem năm email xác minh độc lập đến trong thời gian thực ở năm hộp thư riêng biệt.

Loại kiểm thử đồng thời này bắt được cả một lớp lỗi mà việc kiểm thử tuần tự một người dùng sẽ không bao giờ bắt được: điều kiện tranh chấp trong việc tạo mã thông báo, khóa chết cơ sở dữ liệu khi kiểm tra ràng buộc độc nhất, độ trễ xử lý hàng đợi khiến một số email xác minh đến muộn hơn nhiều so với những email khác, và những tương tác bất ngờ giữa các phiên đồng thời. Nếu bạn đang xây dựng một sản phẩm kỳ vọng có hơn một nhúm người dùng, việc kiểm thử đăng ký đồng thời không phải là tùy chọn — nó là thiết yếu. Các địa chỉ tạm thời làm cho việc đó dễ đến mức tầm thường.

Ngoài xác minh — Các email giao dịch khác cần kiểm thử

Khi bạn đã có một quy trình email tạm thời đang chạy, hãy áp dụng nó cho mọi email giao dịch mà ứng dụng của bạn gửi. Mỗi email trong số này xứng đáng có một lượt kiểm thử riêng chuyên biệt:

• Email đặt lại mật khẩu: Cùng những cân nhắc về bảo mật mã thông báo và hết hạn như xác minh. Kiểm thử các tình huống liên-kết-hết-hạn và đã-dùng-rồi một cách rõ ràng.
• Email mời: Người được mời nhận cái này, không phải người dùng hiện tại — trường hợp sử dụng hoàn hảo cho một hộp thư tạm thời mới.
• Email xác nhận đơn hàng và biên nhận: Kiểm tra rằng tất cả chi tiết mặt hàng, giá cả và liên kết đều đúng. Một xác nhận đơn hàng bị lỗi là cơn ác mộng của dịch vụ khách hàng.
• Email thông báo hoạt động: Bản tóm tắt tổng hợp, thông báo được nhắc đến, luồng hoạt động. Kiểm thử rằng chúng chỉ gửi khi hoạt động liên quan thực sự đã xảy ra.
• Email xác nhận hủy đăng ký: Khi một người dùng hủy đăng ký tiếp thị, họ có nhận được một xác nhận không? Tiêu đề hủy đăng ký một-cú-nhấp (bắt buộc với người gửi hàng loạt) có hiện diện không?
• Xác nhận xóa tài khoản: Nếu ứng dụng của bạn gửi một xác nhận cuối cùng khi một người dùng xóa tài khoản của họ, hãy xác minh điều này hoạt động và rằng bạn thực sự có thể đọc email trong một hộp thư tạm thời trước khi tài khoản biến mất.

Cần tìm gì trong các email kiểm thử của bạn

Khi bạn nhận được một email kiểm thử trong hộp thư tạm thời, đừng chỉ nhấp vào liên kết rồi bỏ qua. Hãy dành mười lăm giây để thực sự xem xét email cho đúng cách. Kiểm tra các tiêu đề nếu hộp thư tạm thời của bạn phơi bày chúng — SPF và DKIM có đạt không? Điều đó quan trọng cho khả năng giao nhận với người nhận thật. Nếu tên miền gửi của bạn không được cấu hình đúng cho DKIM, email của bạn có thể rơi vào thư rác đối với người dùng thật ngay cả khi vẫn hoạt động tốt trong môi trường kiểm thử.

Hãy nhìn vào phần hiển thị HTML. Một mẫu có thể trông hoàn hảo trong công cụ xem trước email cục bộ của bạn rồi hỏng trong một hộp thư thật vì các ứng dụng email khác nhau xử lý CSS theo những cách hết sức khác biệt. Xem nó trong một hộp thư thật — kể cả một hộp thư tạm — bắt được những vấn đề mà công cụ xem trước bỏ sót. Kiểm tra các nút, kiểm tra việc tải hình ảnh, kiểm tra rằng không có văn bản nào bị cắt xén hoặc tràn ra khỏi khung chứa của nó. Nếu bạn có thể xem cả phần hiển thị di động, hãy làm — một tỷ lệ không cân xứng lượng email được mở trên di động.

Kiểm tra thời gian giao nhận. Với một thiết lập thư giao dịch được cấu hình đúng, việc giao nhận đến một hộp thư tạm thời không nên mất quá 2 đến 5 giây kể từ khoảnh khắc bạn kích hoạt lần gửi. Những độ trễ nhất quán lâu hơn thế — chẳng hạn 20 đến 30 giây — cho thấy một vấn đề xử lý hàng đợi hoặc một độ trễ phân giải DNS trong cấu hình gửi của bạn đáng để điều tra trước khi người dùng thật của bạn gặp phải nó.

Biến điều này thành thói quen

Thay đổi quy trình làm việc thực sự nhỏ. Thay vì gõ địa chỉ email thật của bạn vào một biểu mẫu đăng ký kiểm thử, bạn dành năm giây để mở temp mail trong một tab mới và sao chép địa chỉ từ đó. Đó là toàn bộ thay đổi. Nhưng hiệu ứng xuôi dòng lên chất lượng kiểm thử là đáng kể.

Bạn kiểm thử kỹ lưỡng hơn vì việc kiểm tra không có ma sát. Bạn bắt được nhiều lỗi hiển thị hơn vì bạn đang nhìn vào phần hiển thị hộp thư thật mỗi lần. Bạn có thể kiểm thử các tình huống đồng thời mà trước đây không thực tế. Hộp thư thật của bạn giữ được sạch sẽ. Và bạn xây dựng thói quen đối xử với email như một bề mặt kiểm thử hạng nhất thay vì một thứ nghĩ đến sau — đó là mô hình tư duy đúng đắn để xây dựng những sản phẩm mà mọi người thực sự tin tưởng.