Cách chọn tài khoản email thử nghiệm cho QA

Tài khoản email thử nghiệm cho QA là gì?

Tài khoản email thử nghiệm, hay địa chỉ email thử nghiệm cho QA, là địa chỉ mà nhóm của bạn dùng để nhận và kiểm tra các email do chính ứng dụng của bạn gửi. Hãy dùng hộp thư tạm thời cho các bước kiểm tra đăng ký và OTP thủ công, không nhạy cảm. Chọn hộp thư của công ty khi cần lưu giữ tin nhắn, phản hồi hoặc tệp đính kèm, và dùng sandbox SMTP hoặc API hộp thư đến được lưu trữ khi các bài kiểm thử tự động phải kiểm tra email mà không có người tham gia.

Tmailor vận hành blog này, nên đây là chỗ nó phù hợp. Tmailor là dịch vụ email tạm thời miễn phí, chỉ nhận thư, có trên web, Android, iOS và bot Telegram. Nó phù hợp với trường hợp đầu tiên: một người mở hộp thư, kích hoạt đăng ký rồi đọc những gì nhận được. Với trường hợp cuối cùng, API riêng biệt Tmailor Temp Mail cho phép các bài kiểm thử tự động tạo địa chỉ chỉ nhận thư và đọc tin nhắn của chúng từ mã. Tin nhắn chỉ lưu khoảng 24 giờ kể từ khi đến, tệp đính kèm không được nhận, và địa chỉ không thể gửi hay trả lời. Nếu bạn mới làm quen với hộp thư tạm, hãy bắt đầu với cách hoạt động của email tạm thời.

• Không cần email nào đến (kiểm tra biểu mẫu, dữ liệu mẫu, kiểm thử đơn vị): hãy dùng một tên miền ví dụ dành riêng.
• Một người đọc email và không có gì trong đó là nhạy cảm: hộp thư tạm thời là lựa chọn nhanh nhất.
• Dữ liệu nhạy cảm, phản hồi, tệp đính kèm hoặc bằng chứng bạn phải lưu giữ: hãy dùng hộp thư do công ty kiểm soát đã được phê duyệt; chỉ thêm thẻ cộng nếu hệ thống thư và ứng dụng của bạn hỗ trợ.
• Không có người theo dõi: hãy dùng công cụ bắt SMTP nếu bạn kiểm soát được cài đặt thư đi của ứng dụng, hoặc API hộp thư đến được lưu trữ nếu ứng dụng phải gửi qua nhà cung cấp thông thường của nó.

Kiểm thử email thủ công và tự động: Cây quyết định

Bốn câu hỏi quyết định một bài kiểm tra cần loại tài khoản email thử nghiệm nào: email có cần đến hay không, người hay mã đọc nó, nó có chứa dữ liệu nhạy cảm hay không, và bạn có kiểm soát được nơi ứng dụng gửi thư đi hay không.

1. Bài kiểm tra có cần email đến không? Kiểm tra định dạng, trạng thái giao diện, dữ liệu mẫu và kiểm thử đơn vị thường không cần. Hãy dùng địa chỉ tại example.com, example.org hoặc example.net. Những tên miền đó được dành riêng cho tài liệu và ví dụ, nên không có gì đến được với người thật. Tránh tự bịa ra các tên miền ngẫu nhiên, vì có thể ai đó đang sở hữu chúng.
2. Trong quá trình kiểm tra, có người đọc tin nhắn không? Kiểm thử khói, UAT thủ công, bản demo và các buổi khám phá đều có con người tham gia. Các bộ kiểm thử hồi quy và tác vụ CI thì thường không.
3. Nếu có người đọc, trong đó có gì nhạy cảm không? Hồ sơ khách hàng thật, thông tin đăng nhập, dữ liệu được quản lý hoặc tin nhắn bạn phải giữ làm bằng chứng kiểm toán không nên nằm trong hộp thư tạm thời. Thay vào đó, hãy dùng hộp thư của công ty. Nếu câu trả lời là không, hộp thư tạm thời là đủ.
4. Nếu mã đọc tin nhắn, môi trường kiểm thử có thể gửi thư đến một máy chủ SMTP thử nghiệm không? Nếu có, công cụ bắt SMTP sẽ ghi lại mọi tin nhắn mà không chuyển đi. Nếu không, vì ứng dụng phải gửi qua nhà cung cấp email thông thường của nó, hãy dùng hộp thư đến được lưu trữ mà các bài kiểm thử của bạn đọc qua API.

Bảng dưới đây so sánh năm lựa chọn cạnh nhau.

Trường email nên chấp nhận hoặc từ chối những địa chỉ nào?

Hãy kiểm tra xác thực biểu mẫu tách biệt với việc gửi tin nhắn. Dùng một địa chỉ dành riêng như user@example.com cho trường hợp trông hợp lệ nhưng không bao giờ được gửi đi, thêm một địa chỉ có thẻ cộng và một địa chỉ có tên miền phụ, cùng các trường hợp sai định dạng như thiếu phần cục bộ hoặc thiếu tên miền. Giữ kết quả mong đợi khớp với bộ xác thực mà hệ thống sản xuất của bạn thực sự dùng.

Khi nào hộp thư tạm là đủ

Hộp thư tạm thời phù hợp khi một người kiểm tra từng luồng một và tin nhắn không chứa gì mà bạn thấy tiếc nếu mất sau một ngày. Đó là cách dùng email tạm kinh điển cho QA: bạn cần một địa chỉ email để kiểm tra biểu mẫu bằng tay, chứ không phải một tài khoản lâu dài. Các trường hợp điển hình là kiểm thử nhanh biểu mẫu đăng ký trước khi phát hành, một lượt UAT thủ công trên email onboarding mới, một buổi demo bán hàng về việc tạo tài khoản, hoặc một buổi khám phá nơi bạn thử những dữ liệu nhập lạ và xem ứng dụng gửi gì.

Điểm hấp dẫn là tốc độ. Không phải xin tài khoản từ IT và không có hộp thư dùng chung nào phải dọn dẹp. Cái giá phải đánh đổi là khả năng kiểm soát: bạn chỉ có một khoảng thời gian ngắn để nhận tin nhắn, không có tệp đính kèm, và hộp thư đến do người đọc chứ không phải mã đọc.

Khi nào bạn cần bộ bắt SMTP hoặc API hộp thư được lưu trữ

Khi các bài kiểm thử chạy không có người giám sát, hộp thư đến phải đọc được bằng mã. Hai nhóm công cụ đáp ứng nhu cầu đó, và chúng giải quyết những vấn đề khác nhau.

Các bộ bắt SMTP và sandbox thay thế máy chủ thư gửi đi của ứng dụng trong môi trường kiểm thử và giữ lại mọi tin nhắn để kiểm tra thay vì gửi đi.

• Mailpit là công cụ mã nguồn mở miễn phí do bạn tự vận hành. Nó bắt thư theo mặc định và cung cấp giao diện web cùng REST API để kiểm thử tích hợp.
• MailHog cũng hoạt động tương tự nhưng cũ hơn. Nhóm duy trì Mailpit cho biết nó không còn được duy trì nữa, vì vậy hãy kiểm tra tình trạng trước khi áp dụng.
• Mailtrap Email Sandbox là phiên bản lưu trữ (hosted) của cùng ý tưởng đó, có truy cập qua SMTP và API. Nó tách biệt với sản phẩm gửi email thật của Mailtrap.
• Ethereal là dịch vụ SMTP giả miễn phí, chủ yếu dùng với Nodemailer. Tin nhắn được giữ lại để xem trước và không bao giờ được giao đi.

API hộp thư lưu trữ cung cấp cho bài kiểm thử những địa chỉ thật trên tên miền của nhà cung cấp, nên ứng dụng của bạn gửi thư qua nhà cung cấp thông thường và bài kiểm thử đọc kết quả qua API. Temp Mail API của chính Tmailor hoạt động theo cách này, với SDK chính thức cho Python, Node.js và PHP.

• Mailosaur cung cấp địa chỉ email kiểm thử, API và thư viện client tương thích với các framework như Cypress, Playwright và Selenium. Dịch vụ này cũng hỗ trợ mã SMS.
• MailSlurp tạo hộp thư theo yêu cầu thông qua API và SDK. Bài kiểm thử có thể chờ tin nhắn rồi trích xuất mã, liên kết và tệp đính kèm.

Tính năng và gói dịch vụ của nhà cung cấp thay đổi, nên hãy xác nhận thông tin hiện tại trên trang chính thức của từng bên trước khi gắn bộ kiểm thử của bạn vào một dịch vụ.

Khi nào hộp thư công ty có thẻ cộng là lựa chọn tốt hơn

Thẻ cộng cho phép một hộp thư công ty nhận nhiều biến thể địa chỉ. Thư gửi tới qa+signup hoặc qa+reset tại tên miền công ty sẽ vào hộp thư qa, nơi bạn có thể lọc theo thẻ. Google Workspace hỗ trợ tính năng này, và tài liệu của Microsoft cho biết địa chỉ cộng trong Exchange Online mặc định được bật trừ khi quản trị viên tắt đi.

Hãy dùng cách này khi một luồng xử lý dữ liệu khách hàng thật, kéo dài hơn một ngày, cần phản hồi hoặc tệp đính kèm, hoặc tạo ra bằng chứng mà kiểm toán viên có thể yêu cầu. Hãy lưu ý các giới hạn. Thẻ chỉ là biến thể của một hộp thư, không phải các hộp thư riêng biệt, nên các bài kiểm thử chạy song song có thể đọc được tin nhắn của nhau. Một số biểu mẫu đăng ký từ chối dấu cộng, và một số ứng dụng coi các biến thể gắn thẻ là cùng một tài khoản. Cả hai hành vi này đều đáng có một ca kiểm thử riêng.

Cách chạy bài kiểm thử đăng ký thủ công với hộp thư tạm thời

Một bài kiểm thử đăng ký thủ công dùng email tạm thời để kiểm thử cần ba thứ: một địa chỉ mới, bản build bạn đang kiểm thử, và một nơi bên ngoài hộp thư để ghi lại những gì đã đến. Chỉ chạy nó với những hệ thống bạn sở hữu hoặc được phép kiểm thử.

1. Mở hộp thư. Tạo hộp thư tạm miễn phí trên web, hoặc dùng ứng dụng Tmailor hay bot Telegram, rồi sao chép địa chỉ. Trên máy tính để bàn, tiện ích mở rộng trình duyệt Tmailor cũng có thể điền địa chỉ đó vào trường email của bản build kiểm thử.
2. Đăng Đăng ký trên bản build kiểm thử. Dùng địa chỉ đó trong môi trường staging hoặc QA và ghi lại thời điểm bạn gửi biểu mẫu.
3. Theo dõi email. Kiểm tra xem tin nhắn nào đã đến, tên người gửi và địa chỉ From, tiêu đề, và mất bao lâu.
4. Hoàn tất bước này. Nhấp vào liên kết hoặc nhập mã. Xác nhận tài khoản chỉ đổi trạng thái một lần và việc dùng lại cùng liên kết sẽ thất bại với thông báo rõ ràng.
5. Ghi lại bằng chứng ở nơi khác. Sao chép liên kết, mã, dấu thời gian và ảnh chụp màn hình vào ca kiểm thử của bạn. Tin nhắn chỉ tồn tại khoảng 24 giờ kể từ khi đến, nên hộp thư không phải là bản ghi kiểm thử của bạn.
6. Lưu Lưu Access Token nếu bạn sẽ kiểm thử lại. Token này mở lại đúng địa chỉ đó về sau, ví dụ để chạy lại bước đặt lại mật khẩu. Nó không khôi phục những tin nhắn đã hết hạn, và token bị mất thì không thể lấy lại.

Khi một phiên cần nhiều vai cùng lúc, chẳng hạn người dùng miễn phí, người dùng dùng thử và một đồng đội được mời, chế độ xem nhiều hộp thư đến sẽ giữ tối đa năm địa chỉ cạnh nhau trong một tab trình duyệt. Mỗi vai có địa chỉ riêng, nên bạn có thể thấy email nào thuộc tài khoản nào.

Chế độ xem này vẫn mang tính thủ công. Các hộp thư đến do người dùng tạo trong trình duyệt, không được cấp phát bằng mã, nên nó không thay thế API hộp thư đến được lưu trữ cho các lần chạy song song không giám sát.

Một hộp thư đến hay một địa chỉ cho mỗi bài kiểm tra?

Một hộp thư dùng chung thì ổn cho một lần kiểm tra nhanh, nhưng sẽ nhanh chóng trở nên lộn xộn. Khi nhiều bài kiểm thử chạy cùng lúc, các dòng tiêu đề giống nhau khiến việc xác định email nào thuộc về script nào trở nên khó khăn, và việc gỡ lỗi biến thành phỏng đoán.

Một địa chỉ cho mỗi trường hợp kiểm thử sẽ giải quyết vấn đề đó. Nhật ký, ảnh chụp màn hình và email khớp với nhau, và một tin nhắn bị thiếu sẽ chỉ ra một kịch bản thay vì tất cả. Hướng dẫn về về cách chạy nhiều hộp thư tạm sẽ trình bày chi tiết hơn về quy trình đó.

Một số hành trình cần lại đúng địa chỉ đó sau vài ngày, chẳng hạn một bản dùng thử chuyển sang trả phí hoặc một người dùng quay lại sau khi rời bỏ. Một Địa chỉ email tạm thời có thể tái sử dụng giữ cho địa chỉ luôn khả dụng qua Access Token, nhưng không giữ lại thư. Hãy lưu các liên kết và mã bạn cần khi mỗi bước chạy, và chuyển bất kỳ bước nào phụ thuộc vào các tin nhắn cũ sang hộp thư công ty. Nếu người thử nghiệm đăng nhập vào tài khoản Tmailor miễn phí trước khi tạo các địa chỉ persona, mỗi địa chỉ sẽ được lưu trong mục Email Đã Tạo, nên mất token không còn đồng nghĩa với mất địa chỉ.

Cần kiểm tra gì trong email đăng ký và onboarding

Hãy bắt đầu bằng việc liệt kê mọi email mà hành trình có thể gửi, rồi quyết định mỗi bài kiểm tra nên khẳng định điều gì. Các nhóm thường chỉ phát hiện thêm email khi chúng xuất hiện giữa bài kiểm tra, sau khi một thử nghiệm tăng trưởng hoặc một thay đổi bảo mật thêm vào một email mà không ai ghi lại.

Các email trong một hành trình đăng ký điển hình

• Liên kết xác minh hoặc mã dùng một lần
• Email chào mừng và mọi chuỗi hướng dẫn khởi đầu nhanh
• Đăng nhập bằng magic link
• Đặt lại mật khẩu
• Thay đổi địa chỉ email, gửi đến cả địa chỉ cũ và địa chỉ mới
• Cảnh báo bảo mật khi có thiết bị mới hoặc vị trí mới
• Nhắc nhở cho những lượt đăng ký chưa bao giờ hoàn tất

Với mỗi trường hợp, hãy ghi lại yếu tố kích hoạt, thời điểm dự kiến và các điều kiện làm thay đổi nó, chẳng hạn như gói dịch vụ, khu vực hoặc ngôn ngữ. Hãy đặt khung thời gian gửi cho phép dựa trên yêu cầu đã được ghi trong tài liệu của sản phẩm thay vì giả định một ngưỡng chung; một tin nhắn xác minh tức thì và một chuỗi chào mừng theo lịch cần những kỳ vọng khác nhau. Khi đã có những kỳ vọng đó, mỗi bài kiểm tra đều có điều cụ thể để đối chiếu.

Cần khẳng định những gì trong mỗi email thử nghiệm

• Người gửi và người nhận: tên và địa chỉ người gửi, Reply-To, và địa chỉ To chính xác.
• Tiêu đề và nội dung: cả phiên bản HTML và văn bản thuần, với tên, chi tiết gói dịch vụ và ngôn ngữ chính xác.
• Liên kết: đích đến và liệu nó có trỏ đến đúng môi trường hay không. Một email staging liên kết đến môi trường production là một lỗi thực sự.
• Mã: định dạng, độ dài, nội dung về thời hạn, và liệu thời hạn được nêu có khớp với điều máy chủ thực thi hay không.
• Thời Thời gian: tin nhắn mất bao lâu để đến sau khi kích hoạt.
• Tệp đính kèm: nếu một luồng gửi PDF hoặc hóa đơn, hãy kiểm tra trong hộp thư công ty hoặc công cụ kiểm thử. Tmailor không nhận tệp đính kèm.

Một lưu ý về hiển thị. Hộp thư tạm cho thấy cách một trình xem web hiển thị HTML của bạn. Nó không cho bạn biết cùng email đó trông thế nào trong Gmail, Outlook, Apple Mail, chế độ tối hay trên màn hình điện thoại nhỏ, vì vậy hãy lên kế hoạch kiểm tra hiển thị riêng nếu những điều đó quan trọng.

Quy trình thay đổi email và khôi phục tài khoản

Các quy trình khôi phục hỏng theo những cách kín đáo hơn so với đăng ký. Hãy kiểm tra rằng việc thay đổi email gửi xác nhận đến địa chỉ mới và thông báo đến địa chỉ cũ, rằng một liên kết đặt lại đã dùng không thể dùng lại, rằng liên kết đặt lại cũ ngừng hoạt động sau khi gửi liên kết mới hơn, và rằng liên kết mở trên thiết bị thứ hai đưa người dùng vào một trạng thái hợp lý. Các luồng OTP cần một lần đánh giá rủi ro riêng; danh sách kiểm tra rủi ro OTP cho QA và UAT bao gồm các chỉ số, khung thời gian gửi lại và quyền sở hữu.

Cách kiểm tra các trường hợp biên của OTP và xác minh

Hãy kiểm tra các luồng OTP và xác minh với tình huống gửi chậm, gửi lại, mã hết hạn và mã sai, cùng các liên kết mở trên thiết bị khác. Mỗi trường hợp nên kiểm tra cả kết quả phía máy chủ lẫn thông báo hiển thị cho người dùng. Chỉ chạy những bài kiểm tra này trên các hệ thống bạn sở hữu hoặc được phép kiểm tra. Những bài kiểm tra OTP tốt cố tình phá vỡ luồng:

• Đến chậm: chờ trước khi kiểm tra hộp thư đến và xác nhận giao diện giải thích rõ điều gì đang xảy ra và đưa ra cách rõ ràng để gửi lại.
• Hành vi gửi lại: yêu cầu mã thứ hai và kiểm tra xem mã đầu tiên bị vô hiệu hóa hay vẫn được chấp nhận.
• Hết hạn: nhập mã sau thời hạn được nêu và xác nhận thông báo lỗi khớp với điều đã xảy ra.
• Mã Mã sai: hãy xác nhận giới hạn số lần thử và thông báo thời gian chờ đọc có hợp lý với người dùng không.
• Liên kết ma thuật đa thiết bị: yêu cầu một liên kết trên laptop, mở nó trên điện thoại và kiểm tra xem người dùng kết thúc ở đâu.

Để có cái nhìn tổng quát hơn về những mã nào đến được hộp thư tạm thời và mã nào không, hãy xem hướng dẫn này về email tạm thời cho mã OTP.

Nếu sản phẩm của bạn cố ý từ chối các tên miền email tạm, hãy kiểm thử trực tiếp luồng đó. Xác nhận rằng thông báo từ chối rõ ràng và một địa chỉ thật hoặc do công ty kiểm soát vẫn hoàn tất được đăng ký. Đừng lần lượt thử các tên miền tạm khác để vượt qua chặn, trên sản phẩm của bạn hay của bất kỳ ai. Xác nhận rằng chặn hoạt động chính là bài kiểm thử; vượt qua nó thì không phải. Bài giải thích về này về lý do tại sao các trang web chặn tên miền email tạm thời sẽ trình bày lý do đằng sau những bộ lọc đó.

Điều gì thay đổi khi kiểm thử email chạy không giám sát

Khi không có ai theo dõi, bài kiểm thử cần một hộp thư mà nó có thể đọc bằng mã. Điều đó có nghĩa là API của SMTP catcher hoặc API hộp thư được lưu trữ. Hộp thư web Tmailor không phải công cụ đó, nhưng API Tmailor Temp Mail thì có: các bài kiểm thử có thể tạo địa chỉ chỉ nhận, liệt kê và đọc tin nhắn, và lấy mã một lần hoặc liên kết xác minh mà API tìm thấy. Một máy chủ MCP cho phép các agent AI như Claude, Cursor hoặc VS Code Copilot làm điều tương tự cho các luồng đăng ký mà bạn sở hữu hoặc được phép kiểm thử.

Một vài thói quen giúp các bài kiểm thử email không giám sát ổn định, dù bạn chọn công cụ nào:

• Cấp cho mỗi lần chạy thử một địa chỉ riêng và một ID tương quan, để một email đến muộn từ lần chạy trước không thể làm thỏa mãn nhầm một khẳng định.
• Dùng một cơ chế chờ riêng cho việc email đến với thời gian lùi hợp lý, tách biệt với thời gian chờ tổng thể của bài kiểm thử, và ghi lại mỗi tin nhắn mất bao lâu.
• Khớp chính xác tin nhắn theo người nhận và chủ đề thay vì đọc "email mới nhất".
• Che mã và liên kết ma thuật trong nhật ký CI, vì nhật ký thường tồn tại lâu hơn hộp thư.

Cũng cần rõ ràng về những gì một bài kiểm thử đạt chứng minh. "Ứng dụng đã tạo và chuyển giao email", "một tên miền thử nghiệm được lưu trữ đã nhận nó qua hạ tầng email công khai" và "Gmail đã đặt nó vào hộp thư đến, không phải thư rác" là ba sự thật khác nhau. Một SMTP catcher chứng minh điều thứ nhất, một API hộp thư được lưu trữ chứng minh hai điều đầu, và cả hai đều không chứng minh điều thứ ba. Để thiết lập pipeline trên GitHub Actions, GitLab CI và CircleCI, hãy xem hướng dẫn về kiểm thử email trong pipeline CI/CD.

Giữ an toàn cho dữ liệu kiểm thử và tuân thủ các quy định

Sử dụng danh tính tổng hợp và nội dung không nhạy cảm trong hộp thư thử nghiệm tạm thời, và chỉ chạy kiểm thử đăng ký với các hệ thống bạn sở hữu hoặc được phép đánh giá. Giữ các tài khoản QA ngoài phân tích sản xuất, tôn trọng giới hạn tốc độ, và chuyển dữ liệu được quản lý, thông tin đăng nhập, tệp đính kèm và bằng chứng lưu giữ sang các hệ thống do công ty kiểm soát được phê duyệt.

• Không có dữ liệu thật trong hộp thư tạm thời. Không bao giờ chuyển hồ sơ khách hàng thật, thông tin đăng nhập, khóa API hoặc dữ liệu được quản lý đến một địa chỉ email tạm thời. Dùng người dùng tổng hợp với những cái tên giả rõ ràng.
• Chỉ kiểm thử những gì bạn được phép kiểm thử. Chạy kiểm thử đăng ký với sản phẩm của bạn hoặc một hệ thống mà bạn được phép kiểm thử, và tôn trọng giới hạn tốc độ cùng điều khoản của dịch vụ đó. Không dùng email tạm để tạo tài khoản hàng loạt trên các trang web bên thứ ba. Kiểm thử khối lượng và tải thuộc về môi trường staging riêng của bạn, với một SMTP catcher hoặc một API hộp thư được lưu trữ.
• Giữ lưu lượng QA ngoài các con số sản xuất. Gắn nhãn rõ ràng cho các tài khoản thử nghiệm và loại chúng khỏi phân tích và bảng điều khiển tăng trưởng. Tránh gửi khối lượng lớn thư thử nghiệm từ tên miền gửi sản xuất của bạn, nơi thư trả lại và khiếu nại có thể làm tổn hại uy tín của nó.
• Viết chính sách ra giấy. Nêu rõ luồng nào được dùng hộp thư tạm thời, luồng nào cần hộp thư công ty, dữ liệu kiểm thử được lưu bao lâu và ai có quyền truy cập. Các đợt đánh giá an ninh và tuân thủ diễn ra nhanh hơn khi ranh giới đã được ghi rõ trên giấy.

Khi bộ phận bảo mật hỏi nhà cung cấp xử lý dữ liệu như thế nào, hãy xem họ thu thập gì, lưu tin nhắn bao lâu và cách truy cập hoạt động. Tổng quan về email tạm thời và quyền riêng tư trực tuyến này đề cập đến những câu hỏi từ phía người dùng. Quyết định về luồng nào có thể sử dụng hộp thư dùng một lần vẫn thuộc về các nhóm pháp lý, quyền riêng tư và bảo mật của bạn.

Những giới hạn cần lưu ý khi lên kế hoạch

Hộp thư web Tmailor phù hợp cho những kiểm tra thủ công ngắn với email đến không nhạy cảm (tự động hóa là việc của API Temp Mail). Trước khi chọn, hãy xác định xem quy trình có cần thao tác gửi đi, tệp đính kèm, bằng chứng lưu lâu dài hay khả năng khôi phục địa chỉ bền vững hay không. Bất kỳ yêu cầu nào trong số đó đều cần một hộp thư do công ty kiểm soát hoặc một công cụ kiểm thử chuyên dụng; danh sách kiểm tra dưới đây giải thích lý do.

• Tmailor chỉ nhận thư. Nó có thể kiểm tra email đăng ký, xác minh và OTP gửi đến, nhưng không kiểm tra được luồng trả lời hay bất cứ thứ gì gửi đi từ địa chỉ đó.
• Tmailor không nhận tệp đính kèm, vì vậy email hóa đơn, hợp đồng hoặc gửi tài liệu cần một hộp thư công ty hoặc một công cụ kiểm thử.
• Tin nhắn chỉ lưu khoảng 24 giờ kể từ khi đến. Hãy xuất các liên kết, mã và dấu thời gian mà một cuộc điều tra dài hơn sẽ cần.
• Access Token mở lại địa chỉ, chứ không mở lại thư đã hết hạn, và token bị mất thì không thể khôi phục.
• Hộp thư web do người đọc. Việc đọc hộp thư không có người giám sát cần một SMTP catcher hoặc API hộp thư được lưu trữ, chẳng hạn như API Tmailor Temp Mail.
• Một số dịch vụ chặn tên miền email tạm. Nếu một luồng bạn kiểm thử cố ý làm điều này, hãy xác thực nó bằng địa chỉ thật hoặc do công ty kiểm soát.

Chọn hộp thư kiểm tra phù hợp

Hãy chọn hộp thư dựa trên điều mà bài kiểm tra cần chứng minh. Dùng một miền ví dụ được dành riêng khi không cần gửi thật, hộp thư tạm thời cho các kiểm tra thủ công không nhạy cảm, hộp thư công ty cho các luồng cần lưu giữ hoặc nhạy cảm, bộ bắt SMTP khi bạn kiểm soát cấu hình gửi đi, và API hộp thư đến được lưu trữ cho các bài kiểm tra đầu cuối không giám sát.

Đối với các trường hợp thủ công, hãy mở hộp thư tạm thời và bắt đầu với luồng đăng ký mà bạn sẽ triển khai tiếp theo. Email tạm thời có rất nhiều ứng dụng thực tế ngoài QA.