چگونه یک حساب ایمیل آزمایشی برای تضمین کیفیت انتخاب کنیم
یک صندوق ورودی موقت، ثبتنام دستی و بررسی‌های OTP را پوشش می‌دهد. تستهایی که بدون حضور فرد اجرا میشوند، به دادههای واقعی مشتری دست می‌زنند یا به پاسخ و پیوست نیاز دارند، به نوع دیگری از صندوق ورودی آزمایشی نیاز دارند. در ادامه می‌بینید چگونه برای هر تست گزینه مناسب را انتخاب کنید.
دسترسی سریع
حساب ایمیل آزمایشی برای تضمین کیفیت چیست؟
حساب ایمیل آزمایشی یا آدرس ایمیل تست برای تضمین کیفیت، آدرسی است که تیم شما برای دریافت و بررسی ایمیل‌هایی که برنامه خودتان ارسال میکند به کار می‌برد. برای بررسی‌های دستی و غیرحساس ثبتنام و OTP از صندوق ورودی موقت استفاده کنید. برای پیام‌های نگهداری‌شده، پاسخها یا پیوستها صندوق پستی شرکت را انتخاب کنید و زمانی که تستهای خودکار باید بدون حضور شخص ایمیل را بررسی کنند، از سندباکس SMTP یا API صندوق ورودی میزبانیشده استفاده کنید.
تمایلور این وبلاگ را اداره می کند، پس اینجا جای آن قرار می گیرد. Tmailor یک سرویس رایگان و فقط دریافت ایمیل موقت در وب، اندروید، iOS و یک ربات تلگرام است. این برای حالت اول مناسب است: فردی صندوق ورودی را باز می کند، ثبت نام را فعال می کند و آنچه می رسد را می خواند. برای آخرین حالت، API جداگانه Tmailor Temp Mail به تستهای خودکار اجازه می‌دهد آدرسهای فقط‌دریافتی بسازند و پیام‌هایشان را از کد بخوانند. پیامها حدود ۲۴ ساعت پس از رسیدن باقی می‌مانند، پیوستها دریافت نمی‌شوند و آدرس نمی‌تواند ارسال یا پاسخ دهد. اگر با صندوق‌های ورودی موقت آشنا نیستید، با نحوه کار ایمیل موقت شروع کنید.
- لازم نیست ایمیلی برسد (اعتبارسنجی فرم، فیکسچرها، تستهای واحد): از دامنه نمونه رزروشده استفاده کنید.
- یک نفر ایمیل را میخواند و هیچ چیز حساسی در آن نیست: صندوق ورودی موقت سریع‌ترین گزینه است.
- دادههای حساس، پاسخها، پیوستها یا شواهدی که باید نگه دارید: از صندوق پستی تأییدشده تحت کنترل شرکت استفاده کنید؛ برچسب‌های پلاس را فقط اگر سیستم ایمیل و برنامه شما از آنها پشتیبانی می‌کنند اضافه کنید.
- بدون نظارت شخص: اگر تنظیمات ایمیل خروجی برنامه را کنترل می‌کنید، از گیرنده SMTP استفاده کنید، یا اگر برنامه باید از طریق ارائهدهنده معمول خود ارسال کند، از API صندوق ورودی میزبانیشده استفاده کنید.
تست دستی در برابر تست خودکار ایمیل: درخت تصمیم
چهار پرسش تعیین میکند که یک بررسی به کدام حساب ایمیل آزمایشی نیاز دارد: آیا اصلاً باید ایمیلی برسد، آیا شخص یا کد آن را میخواند، آیا داده حساسی در آن است و آیا شما کنترل می‌کنید که برنامه ایمیلهای خروجی خود را کجا بفرستد.
- آیا تست نیاز دارد ایمیلی برسد؟ بررسی‌های قالب، وضعیت‌های رابط کاربری، فیکسچرها و تستهای واحد معمولاً نیازی ندارند. از آدرسهایی در example.com، example.org یا example.net استفاده کنید. این دامنه‌ها برای مستندسازی و مثال رزرو شدهاند، بنابراین چیزی به فرد واقعی نمی‌رسد. از ساختن دامنههای تصادفی بپرهیزید، چون ممکن است مالک داشته باشند.
- آیا در طول تست شخصی پیام را میخواند؟ تستهای دود، UAT دستی، دموها و جلسات اکتشافی انسانی در حلقه دارند. مجموعه‌های رگرسیون و کارهای CI معمولاً ندارند.
- اگر شخصی آن را میخواند، آیا چیزی در آن حساس است؟ سوابق واقعی مشتریان، اعتبارنامه‌ها، دادههای تحت مقررات یا پیامهایی که باید به‌عنوان شواهد حسابرسی نگه دارید، جایشان در صندوق ورودی موقت نیست. به‌جای آن از صندوق پستی شرکت استفاده کنید. اگر پاسخ منفی است، صندوق ورودی موقت کافی است.
- اگر کد آن را میخواند، آیا محیط تست میتواند ایمیلش را به سرور SMTP آزمایشی بفرستد؟ اگر بله، گیرنده SMTP هر پیام را بدون تحویل آن ضبط میکند. اگر نه، چون برنامه باید از طریق ارائهدهنده ایمیل معمول خود ارسال کند، از صندوق ورودی میزبانی‌شده‌ای استفاده کنید که تستهای شما از طریق API آن را می‌خوانند.
جدول پنج گزینه را کنار هم مقایسه میکند.
| گزینه | مناسب برای | نحوه خواندن ایمیل | نکات احتیاطی |
|---|---|---|---|
| دامنه نمونه رزروشده | اعتبارسنجی، فیکسچرها، تستهای منفی | تحویل داده نشد | نمی‌توان ورود، زمان‌بندی یا محتوا را تست کرد |
| صندوق ورودی موقت (مانند Tmailor) | تست دود، UAT دستی، دموها، بررسی‌های اکتشافی | یک نفر در مرورگر یا اپلیکیشن | حدود ۲۴ ساعت پیام، فقط دریافت، بدون پیوست، نه برای دادههای حساس |
| صندوق پستی تحت کنترل شرکت، در صورت تمایل با برچسب‌های پلاس | جریانهای حساس یا بلندمدت، پاسخها، پیوستها، شواهد حسابرسی | یک شخص، یا دسترسی صندوق پستی که تیم فناوری اطلاعات شما تأیید میکند | آدرسهای برچسب‌خورده یک صندوق پستی مشترک دارند، بنابراین تستهای موازی میتوانند ایمیل یکدیگر را ببینند. |
| گیرنده SMTP یا سندباکس | محیط توسعه، استیجینگ و CI که تنظیمات ایمیل خروجی را کنترل می‌کنید | رابط کاربری وب و API | تحویل از طریق DNS عمومی و MX یا قرارگیری در صندوق ورودی را اثبات نمی‌کند |
| API صندوق ورودی میزبانیشده | تستهای انتها به انتها از مسیر ارسال واقعی شما | API و SDKهای REST | محدودیت‌های طرح، نگهداری، دامنه‌ها و همزمانی بسته به فروشنده متفاوت است |
یک فیلد ایمیل باید کدام آدرس‌ها را بپذیرد یا رد کند؟
اعتبارسنجی فرم را جدا از تحویل پیام تست کنید. برای یک مورد معتبرنما که هرگز تحویل داده نمی‌شود از آدرس رزروشده‌ای مانند user@example.com استفاده کنید، یک آدرس با برچسب پلاس و یک آدرس با زیردامنه اضافه کنید و موارد بدشکل مانند بخش محلی گمشده یا دامنه گمشده را هم بگنجانید. نتایج مورد انتظار را با همان اعتبارسنجی‌ای هماهنگ نگه دارید که سیستم تولیدی شما واقعاً استفاده میکند.
چه زمانی یک صندوق ورودی موقت کافی است
صندوق ورودی موقت زمانی کافی است که یک نفر در هر لحظه فقط یک جریان را بررسی کند و پیام چیزی نداشته باشد که از دست دادنش پس از یک روز اهمیتی نداشته باشد. این همان کاربرد کلاسیک ایمیل موقت برای تضمین کیفیت است: برای تست دستی یک فرم به یک آدرس ایمیل نیاز دارید، نه یک حساب بلندمدت. موارد معمول عبارتاند از تست دود پیش از انتشار فرم ثبتنام، یک دور UAT دستی روی ایمیل جدید خوش‌آمدگویی، دموی فروش از ایجاد حساب کاربری، یا یک جلسه اکتشافی که در آن ورودی‌های عجیب را امتحان می‌کنید و می‌بینید اپلیکیشن چه می‌فرستد.
جذابیتش سرعت است. نه حسابی هست که از IT درخواست کنید و نه صندوق پستی مشترکی که تمیز کنید. اما بهایش از دست دادن کنترل است: پنجره پیام کوتاه، بدون پیوست، و صندوق ورودی‌ای که یک نفر آن را میخواند نه کد.
چه زمانی به یک گیرنده SMTP یا API صندوق ورودی میزبانیشده نیاز دارید
وقتی تستها بدون نظارت اجرا میشوند، صندوق ورودی باید برای کد قابل خواندن باشد. دو دسته ابزار این نیاز را پوشش می‌دهند و هر کدام مسئله متفاوتی را حل می‌کنند.
گیرنده‌ها و سندباکس‌های SMTP سرور ایمیل خروجی اپلیکیشن شما را در محیط تست جایگزین می‌کنند و به‌جای تحویل، هر پیام را برای بازرسی نگه می‌دارند.
- Mailpit یک ابزار رایگان و متن‌باز است که خودتان اجرا می‌کنید. این ابزار به‌طور پیش‌فرض ایمیلها را ضبط میکند و یک رابط کاربری وب و یک API REST برای تستهای یکپارچه‌سازی ارائه می‌دهد.
- MailHog هم به همین شکل کار میکند اما قدیمی‌تر است. نگهدارندگان Mailpit می‌گویند دیگر نگهداری نمی‌شود، بنابراین پیش از پذیرش آن وضعیتش را بررسی کنید.
- Mailtrap Email Sandbox نسخه‌ای میزبانیشده از همین ایده است که دسترسی SMTP و API دارد. این محصول از محصول ارسال تولیدی Mailtrap جداست.
- Ethereal یک سرویس SMTP جعلی رایگان است که عمدتاً با Nodemailer استفاده میشود. پیامها برای پیش‌نمایش دریافت میشوند و هرگز تحویل داده نمی‌شوند.
APIهای صندوق ورودی میزبانیشده به تستها آدرسهای واقعی روی دامنههای فروشنده می‌دهند، بنابراین برنامه شما ایمیل را از طریق ارائهدهنده معمولی خود ارسال میکند و تست نتیجه را از طریق API میخواند. API Temp Mail خود Tmailor به همین شکل کار میکند، با SDKهای رسمی برای Python، Node.js و PHP.
- Mailosaur آدرسهای ایمیل آزمایشی، یک API و کتابخانه‌های کلاینت ارائه می‌دهد که با فریم‌ورک‌هایی مانند Cypress، Playwright و Selenium کار می‌کنند. همچنین کدهای پیامکی را پوشش می‌دهد.
- MailSlurp صندوق‌های ورودی را به‌صورت درخواستی از طریق API و SDKهای خود ایجاد میکند. تستها میتوانند منتظر یک پیام بمانند و سپس کدها، لینک‌ها و پیوستها را استخراج کنند.
ویژگی‌ها و طرح‌های فروشندگان تغییر میکند، پس پیش از آنکه مجموعه تستی را به یک فروشنده بسپارید، جزئیات فعلی را در وب‌سایت رسمی هرکدام بررسی کنید.
وقتی صندوق پستی شرکتی با برچسب‌های پلاس انتخاب بهتری است
برچسب‌های پلاس به یک صندوق پستی شرکتی اجازه می‌دهند تا تنوع‌های زیادی از آدرس را بپذیرد. ایمیلی که به qa+signup یا qa+reset در دامنه شرکت شما فرستاده شود در صندوق qa فرود می‌آید، جایی که میتوانید آن را بر اساس برچسب فیلتر کنید. Google Workspace از این قابلیت پشتیبانی میکند و مایکروسافت مستند کرده است که آدرسدهی پلاس در Exchange Online به‌طور پیش‌فرض فعال است مگر اینکه مدیر آن را خاموش کند.
از این مسیر زمانی استفاده کنید که یک جریان داده واقعی مشتری را حمل میکند، بیش از یک روز طول می‌کشد، به پاسخ یا پیوست نیاز دارد، یا شواهدی تولید میکند که ممکن است حسابرس درخواست کند. محدودیت‌ها را در نظر داشته باشید. برچسب‌ها تنوع‌هایی از یک صندوق پستی هستند، نه صندوق‌های ورودی جداگانه، بنابراین تستهای موازی میتوانند پیام‌های یکدیگر را بخوانند. برخی فرم‌های ثبتنام علامت جمع را رد می‌کنند و برخی اپلیکیشن‌ها نسخه‌های برچسب‌خورده را همان حساب یکسان در نظر می‌گیرند. هر دو رفتار ارزش یک مورد تست جداگانه را دارند.
چگونه یک تست ثبتنام دستی با صندوق ورودی موقت اجرا کنیم
یک تست ثبتنام دستی که از ایمیل موقت برای تست استفاده میکند به سه چیز نیاز دارد: یک آدرس تازه، نسخه‌ای که تست می‌کنید و جایی خارج از صندوق ورودی برای ثبت آنچه رسیده است. آن را فقط روی سیستم‌هایی اجرا کنید که مالک آنها هستید یا مجاز به تست آنها هستید.
- یک صندوق ورودی باز کنید. یک صندوق ورودی موقت رایگان در وب ایجاد را در وب باز کنید، یا از اپلیکیشن Tmailor یا ربات تلگرام استفاده کنید و آدرس را کپی کنید. روی دسکتاپ، افزونه مرورگر Tmailor همچنین میتواند آن را در فیلد ایمیل نسخه آزمایشی شما پر کند.
- در نسخه آزمایشی خود ثبتنام کنید. آدرس را در محیط staging یا QA خود استفاده کنید و زمان ارسال فرم را یادداشت کنید.
- منتظر ایمیل باشید. بررسی کنید کدام پیام رسیده است، نام فرستنده و آدرس From، موضوع، و اینکه چقدر طول کشیده است.
- مرحله را کامل کنید. روی لینک کلیک کنید یا کد را وارد کنید. تأیید کنید که حساب یک بار تغییر وضعیت می‌دهد و استفاده مجدد از همان لینک با پیامی واضح شکست میخورد.
- شواهد را جای دیگری ثبت کنید. لینک، کد، زمان‌ها و یک اسکرین‌شات را در مورد تست خود کپی کنید. پیامها حدود ۲۴ ساعت پس از رسیدن باقی می‌مانند، بنابراین صندوق ورودی سابقه تست شما نیست.
- اگر می‌خواهید دوباره تست کنید، access token را ذخیره کنید. این token همان آدرس را بعداً باز میکند، مثلاً برای اجرای دوباره بازنشانی رمز عبور. پیامهایی را که قبلاً منقضی شدهاند بازیابی نمی‌کند و token گمشده قابل بازیابی نیست.
وقتی یک جلسه به چند پرسونا به‌طور همزمان نیاز دارد، مانند یک کاربر رایگان، یک کاربر آزمایشی و یک هم‌تیمی دعوت‌شده، نمای صندوق ورودی چندگانه تا پنج آدرس را کنار هم در یک تب مرورگر نگه میدارد. هر پرسونا آدرس مخصوص خودش را دارد، بنابراین میتوانید ببینید کدام ایمیل متعلق به کدام حساب است.
این نما همچنان دستی است. صندوق‌های ورودی توسط یک فرد در مرورگر ایجاد میشوند، نه با کد، بنابراین جایگزین API صندوق ورودی میزبانیشده برای اجراهای موازی و بدون نظارت نمی‌شود.
یک صندوق ورودی یا یک آدرس برای هر تست؟
یک صندوق ورودی مشترک برای یک بررسی سریع مناسب است، اما خیلی زود شلوغ و پر سر و صدا میشود. وقتی چند تست همزمان اجرا میشوند، موضوع‌های مشابه تشخیص اینکه کدام ایمیل متعلق به کدام اسکریپت است را دشوار میکند و اشکالزدایی به حدس و گمان تبدیل میشود.
یک آدرس برای هر مورد تست این مشکل را حل میکند. لاگها، اسکرینشاتها و ایمیلها با هم هماهنگ میشوند و یک پیام گمشده به یک سناریو اشاره میکند نه همه آنها. راهنمای اجرای چند صندوق ورودی موقت این روند را با جزئیات بیشتری پوشش می‌دهد.
برخی مسیرها چند روز بعد دوباره به همان آدرس نیاز دارند، مثل دوره آزمایشی که به اشتراک پولی تبدیل میشود یا کاربری که پس از ترک سرویس دوباره برمی‌گردد. یک آدرس ایمیل موقت قابل استفاده مجدد آدرس را از طریق access token خود در دسترس نگه میدارد، اما ایمیلها را نه. لینک‌ها و کدهای مورد نیاز را در هر مرحله ذخیره کنید و هر مرحله‌ای که به پیام‌های قدیمی‌تر وابسته است را به صندوق پستی شرکت منتقل کنید. اگر یک تستر پیش از ایجاد آدرسهای پرسونا وارد یک حساب رایگان Tmailor شود، هر کدام در بخش ایمیلهای ایجادشده ذخیره میشوند، بنابراین از دست رفتن token دیگر به معنای از دست رفتن آدرس نیست.
| الگو | بهترین کاربرد | ریسک اصلی |
|---|---|---|
| صندوق ورودی مشترک | بررسی‌های سریع و جلسات کوتاه دستی | وقتی اجراها هم‌پوشانی دارند، تطبیق پیامها با تستها سخت است |
| آدرس اختصاصی هر تست | موارد ثبتنام و شروع به کار چندمرحله‌ای | آدرسهای بیشتر برای پیگیری و کنار گذاشتن |
| آدرس پرسونای قابل استفاده مجدد | تبدیل دوره آزمایشی به اشتراک پولی، فعال‌سازی مجدد و بازگشت‌های بعدی | پیامها همچنان پس از حدود ۲۴ ساعت منقضی میشوند؛ از دست رفتن token به معنای از دست رفتن آدرس است مگر اینکه آدرس در حساب Tmailor ذخیره شده باشد |
چه مواردی را باید در ایمیلهای ثبتنام و شروع به کار بررسی کرد
با فهرستی از همه ایمیل‌هایی که این مسیر میتواند ارسال کند شروع کنید، سپس تصمیم بگیرید هر تست چه چیزی را باید بررسی کند. تیم‌ها اغلب ایمیلهای اضافی را فقط زمانی کشف می‌کنند که وسط آزمایش ظاهر شوند، پس از یک آزمایش رشد یا تغییر امنیتی که کسی آن را ثبت نکرده است.
ایمیلها در یک مسیر ثبتنام معمولی
- لینک تأیید یا کد یکبارمصرف
- ایمیل خوش‌آمدگویی و هر توالی شروع سریع
- ورود با لینک جادویی
- بازنشانی رمز عبور
- تغییر آدرس ایمیل، ارسالشده به هر دو آدرس قدیمی و جدید
- هشدار امنیتی دستگاه جدید یا موقعیت مکانی جدید
- یادآوری‌هایی برای ثبت‌نام‌هایی که هرگز تکمیل نشده‌اند
برای هر کدام، محرک، زمان‌بندی مورد انتظار و شرایطی که آن را تغییر می‌دهند، مانند طرح، منطقه یا زبان، را یادداشت کنید. بازه مجاز تحویل را از نیاز مستند محصول خود تعیین کنید، نه با فرض یک آستانه جهانی؛ یک پیام تأیید فوری و یک توالی خوش‌آمدگویی زمان‌بندی‌شده انتظارات متفاوتی دارند. وقتی این انتظارات وجود داشته باشد، هر تست چیزی مشخص برای بررسی دارد.
چه مواردی را در هر ایمیل آزمایشی باید بررسی کرد
- فرستنده و گیرنده: نام و آدرس فرستنده، Reply-To و آدرس دقیق To.
- موضوع و متن پیام: هر دو نسخه HTML و متن ساده، با نامهای درست، جزئیات طرح و زبان صحیح.
- لینک‌ها: مقصد لینک و اینکه آیا به محیط درست اشاره میکند یا نه. ایمیلی در محیط staging که به محیط production لینک می‌دهد، واقعاً یک باگ است.
- کدها: قالب، طول، متن مربوط به انقضا و اینکه آیا انقضای اعلام‌شده با آنچه سرور اعمال میکند مطابقت دارد یا نه.
- زمان‌بندی: اینکه پیام چه مدت پس از رویداد محرک رسیده است.
- پیوستها: اگر جریانی یک PDF یا فاکتور ارسال میکند، آن را در یک صندوق پستی شرکتی یا ابزار تست بررسی کنید. Tmailor پیوست دریافت نمی‌کند.
یک هشدار درباره نمایش ایمیل. صندوق ورودی موقت فقط نشان می‌دهد که یک نمایشگر وب چگونه HTML شما را نمایش می‌دهد. این موضوع به شما نمی‌گوید همان ایمیل در جیمیل، اوت‌لوک، اپل میل، حالت تاریک یا صفحه کوچک گوشی چگونه دیده میشود؛ پس اگر این موارد مهم هستند، بررسی‌های جداگانه‌ای برای نمایش ایمیل در نظر بگیرید.
جریانهای تغییر ایمیل و بازیابی حساب
جریانهای بازیابی به شکلی آرام‌تر از ثبتنام خراب میشوند. بررسی کنید که تغییر ایمیل، تأییدیه‌ای به آدرس جدید و اطلاعیه‌ای به آدرس قدیمی بفرستد؛ لینک بازیابی استفاده‌شده قابل استفاده مجدد نباشد؛ لینک بازیابی قدیمی پس از ارسال لینک جدید از کار بیفتد؛ و لینکی که روی دستگاه دوم باز میشود، کاربر را در وضعیت معقولی قرار دهد. جریانهای OTP شایسته بازبینی جداگانه ریسک هستند؛ چک لیست ریسک OTP برای QA و UAT معیارها، بازه‌های ارسال مجدد و مالکیت را پوشش می‌دهد.
چگونه OTP و موارد لبه‌ای تأیید را آزمایش کنیم
جریانهای OTP و تأیید را در برابر تحویل با تأخیر، ارسال مجدد، کدهای منقضی و نادرست، و لینک‌هایی که روی دستگاه دیگری باز میشوند آزمایش کنید. هر مورد باید هم نتیجه سمت سرور و هم پیامی که به کاربر نمایش داده میشود را بررسی کند. این تستها را فقط روی سیستم‌هایی اجرا کنید که مالک آنها هستید یا مجاز به تست آنها هستید. تستهای خوب OTP عمداً جریان را مختل می‌کنند:
- رسیدن با تأخیر: پیش از بررسی صندوق ورودی صبر کنید و مطمئن شوید رابط کاربری توضیح می‌دهد چه اتفاقی افتاده و راه روشنی برای ارسال مجدد ارائه می‌دهد.
- رفتار ارسال مجدد: کد دوم را درخواست کنید و بررسی کنید که کد اول باطل شده یا هنوز پذیرفته میشود.
- انقضا: کدی را پس از پایان عمر اعلام‌شده وارد کنید و مطمئن شوید پیام خطا با آنچه رخ داده مطابقت دارد.
- کد نادرست: محدودیت تعداد تلاش و متن مربوط به زمان انتظار را بررسی کنید و ببینید آیا برای یک کاربر منطقی به نظر می‌رسد.
- لینک‌های جادویی بین دستگاه‌ها: لینکی را روی لپ‌تاپ درخواست کنید، آن را روی گوشی باز کنید و بررسی کنید کاربر در نهایت به کجا می‌رسد.
برای دیدی گسترده‌تر از اینکه کدام کدها به صندوق ورودی موقت میرسند و کدام نمی‌رسند، این راهنما را ببینید: کدهای OTP در ایمیل موقت مراجعه کنید.
اگر محصول شما عمداً دامنههای ایمیل موقت را رد میکند، همان مسیر را مستقیماً آزمایش کنید. تأیید کنید که پیام رد واضح است و یک آدرس واقعی یا تحت کنترل شرکت همچنان ثبتنام را کامل میکند. برای عبور از این مسدودسازی، چه در محصول خودتان و چه در محصول دیگران، دامنههای موقت دیگر را امتحان نکنید. تأیید اینکه مسدودسازی کار میکند، خودِ آزمون است؛ دور زدن آن آزمون نیست. این توضیح درباره اینکه چرا وب سایت ها دامنه های موقت ایمیل را مسدود دلایل پشت این فیلترها را پوشش می‌دهد.
وقتی تستهای ایمیل بدون نظارت اجرا میشوند چه تغییر میکند
وقتی هیچ‌کس ناظر نیست، آزمون به صندوق ورودی‌ای نیاز دارد که بتواند از طریق کد آن را بخواند. یعنی API یک گیرنده SMTP یا API یک صندوق ورودی میزبانیشده. صندوق ورودی وب Tmailor این ابزار نیست، اما API ایمیل موقت Tmailor هست: تستها میتوانند آدرسهای فقط‌دریافت ایجاد کنند، پیامها را فهرست و بخوانند و کد یکبارمصرف یا لینک تأییدی را که API پیدا میکند دریافت کنند. یک سرور MCP به عامل‌های هوش مصنوعی مانند Claude، Cursor یا VS Code Copilot اجازه می‌دهد همین کار را برای جریانهای ثبت‌نامی که مالک آن هستید یا مجاز به آزمایش آنها هستید انجام دهند.
چند عادت باعث میشود تستهای ایمیلی بدون نظارت پایدار بمانند، هر ابزاری که انتخاب کنید:
- به هر اجرای آزمون آدرس و شناسه همبستگی مخصوص خودش را بدهید تا ایمیل دیرهنگام از اجرای قبلی نتواند ادعای اشتباه را تأیید کند.
- از یک انتظار اختصاصی برای رسیدن ایمیل با عقب‌نشینی معقول، جدا از مهلت کلی آزمون استفاده کنید و مدت زمان رسیدن هر پیام را ثبت کنید.
- پیام دقیق را بر اساس گیرنده و موضوع تطبیق دهید، نه با خواندن «آخرین ایمیل».
- کدها و لینک‌های جادویی را در لاگهای CI پنهان کنید، چون لاگها اغلب بیشتر از صندوق ورودی عمر می‌کنند.
همچنین روشن باشید که یک آزمون موفق چه چیزی را ثابت میکند. «برنامه ایمیل را تولید و تحویل داده»، «یک دامنه آزمایشی میزبانیشده آن را از طریق زیرساخت ایمیل عمومی دریافت کرده» و «جیمیل آن را در صندوق ورودی قرار داده، نه در اسپم» سه واقعیت متفاوت هستند. یک گیرنده SMTP اولی را ثابت میکند، API صندوق ورودی میزبانیشده دو مورد اول را ثابت میکند و هیچ‌کدام سومی را ثابت نمی‌کند. برای راه‌اندازی خط لوله در GitHub Actions، GitLab CI و CircleCI، راهنمای تست ایمیل در خطوط لوله CI/CD را ببینید.
دادههای آزمون را ایمن نگه دارید و قوانین را رعایت کنید
از هویت‌های مصنوعی و محتوای غیرحساس در صندوق‌های ورودی آزمایشی موقت استفاده کنید و تستهای ثبتنام را فقط روی سیستم‌هایی اجرا کنید که مالک آن هستید یا مجاز به ارزیابی آنها هستید. حسابهای QA را از تحلیلهای تولید بیرون نگه دارید، محدودیت‌های نرخ را رعایت کنید و دادههای تحت مقررات، اعتبارنامه‌ها، پیوستها و مدارک نگهداری‌شده را به سیستم‌های تأییدشده تحت کنترل شرکت منتقل کنید.
- هیچ داده واقعی در صندوق ورودی موقت نباشد. هرگز سوابق واقعی مشتریان، اعتبارنامه‌ها، کلیدهای API یا دادههای تحت مقررات را به آدرس ایمیل موقت نفرستید. از کاربران مصنوعی با نامهای کاملاً جعلی استفاده کنید.
- فقط چیزی را آزمایش کنید که مجاز به آزمایش آن هستید. تستهای ثبتنام را روی محصول خودتان یا سیستمی اجرا کنید که مجاز به آزمایش آن هستید و محدودیت‌های نرخ و شرایط آن سرویس را رعایت کنید. از ایمیل موقت برای ایجاد انبوه حساب در سایت‌های شخص ثالث استفاده نکنید. تست حجم و بار باید در محیط مرحله‌بندی خودتان و با یک گیرنده SMTP یا API صندوق ورودی میزبانیشده انجام شود.
- ترافیک QA را از آمار تولید بیرون نگه دارید. حسابهای آزمایشی را به‌وضوح برچسب بزنید و آنها را از داشبوردهای تحلیل و رشد حذف کنید. از ارسال حجم زیادی ایمیل آزمایشی از دامنه ارسال تولیدی خود خودداری کنید، چون برگشت‌ها و شکایات میتواند به اعتبار آن آسیب بزند.
- سیاست را مکتوب کنید. مشخص کنید کدام جریان‌ها میتوانند از صندوق ورودی موقت استفاده کنند، کدام‌ها به صندوق پستی شرکت نیاز دارند، دادههای آزمایشی چه مدت نگهداری میشوند و چه کسی دسترسی دارد. بررسی‌های امنیتی و انطباق وقتی مرزها از قبل روی کاغذ باشند سریع‌تر پیش می‌روند.
وقتی تیم امنیت می‌پرسد یک ارائهدهنده چگونه با داده‌ها رفتار میکند، ببینید چه چیزی جمع‌آوری میکند، پیامها را چه مدت نگه میدارد و دسترسی چگونه کار میکند. این مرور کلی ایمیل موقت و حریم خصوصی آنلاین این پرسش‌ها را از دید کاربر پوشش می‌دهد. تصمیم درباره اینکه کدام جریان‌ها میتوانند از صندوق‌های ورودی موقت استفاده کنند همچنان بر عهده تیم‌های حقوقی، حریم خصوصی و امنیتی خودتان است.
محدودیت‌هایی که باید برایشان برنامه ریخت
صندوق ورودی وب Tmailor برای بررسی‌های دستی کوتاه ایمیلهای ورودی غیرحساس مناسب است (اتوماسیون کارِ API ایمیل موقت است). پیش از انتخاب آن، تصمیم بگیرید که آیا گردش کار به اقدامات ارسالی، پیوستها، مدارک طولانی‌مدت یا بازیابی پایدار آدرس نیاز دارد یا نه. هر یک از این الزامات به صندوق پستی تحت کنترل شرکت یا ابزار تست تخصصی نیاز دارد؛ چکلیست زیر توضیح می‌دهد چرا.
- Tmailor فقط دریافت میکند. میتواند ایمیلهای ثبتنام، تأیید و OTP ورودی را بررسی کند، اما جریانهای پاسخ یا هر چیزی که از آن آدرس ارسال میشود را نه.
- Tmailor پیوست دریافت نمی‌کند، بنابراین ایمیلهای فاکتور، قرارداد یا تحویل اسناد به صندوق پستی شرکت یا ابزار تست نیاز دارند.
- پیامها حدود ۲۴ ساعت پس از رسیدن باقی می‌مانند. لینک‌ها، کدها و زمان‌هایی را که برای بررسی طولانی‌تر لازم است صادر کنید.
- توکن دسترسی یک آدرس را دوباره باز میکند، نه پیام‌های منقضی‌شده را، و توکن گمشده قابل بازیابی نیست.
- صندوق ورودی وب را یک انسان میخواند. خواندن صندوق ورودی بدون حضور انسان به یک گیرنده SMTP یا API صندوق ورودی میزبانیشده نیاز دارد، مانند API ایمیل موقت Tmailor.
- برخی سرویس‌ها دامنههای ایمیل موقت را مسدود می‌کنند. اگر جریانی که تست می‌کنید عمداً این کار را انجام می‌دهد، آن را با یک آدرس واقعی یا تحت کنترل شرکت بررسی کنید.
پرسش‌های متداول
آیا میتوانم از یک آدرس ایمیل موقت برای تست تضمین کیفیت استفاده کنم؟
بله، برای تستهای دستی که یک فرد ایمیل را میخواند و هیچ محتوای حساسی در آن نیست. صندوق ورودی موقت برای تستهای دودی، UAT دستی و نمایش جریانهای ثبتنام و OTP خوب کار میکند. اما برای دادههای واقعی مشتری، پیوستها، پاسخها، پیامهایی که باید بیش از حدود ۲۴ ساعت نگه دارید یا تستهایی که بدون حضور فرد اجرا میشوند، انتخاب اشتباهی است.
آیا تستهای خودکار میتوانند صندوق ورودی Tmailor را از طریق API بخوانند؟
بله، با آدرسهایی که از طریق API ایمیل موقت Tmailor ایجاد شدهاند. تستها میتوانند آدرسهای فقط دریافتی بسازند، پیامها را فهرست و بخوانند و کد یکبارمصرف یا لینک تأییدی را که API استخراج میکند (تا حد امکان) با استفاده از SDK رسمی پایتون، Node.js یا PHP دریافت کنند. طرح رایگان برای شروع در دسترس است. فقط برای جریانهایی از آن استفاده کنید که مالک آن هستید یا مجاز به تست آن هستید. وقتی تنظیمات ایمیل خروجی برنامه را در اختیار دارید، گیرنده SMTP مانند Mailpit یا Mailtrap Email Sandbox گزینه دیگری است و از دیگر APIهای صندوق ورودی میزبانیشده میتوان به Mailosaur و MailSlurp اشاره کرد.
تفاوت حساب ایمیل تست و سندباکس SMTP چیست؟
حساب ایمیل تست، یا صندوق پستی تست، آدرسی گیرنده است که برنامه شما میتواند به آن ارسال کند و در آن یک فرد یا یک تست پیام تحویل‌شده را بررسی میکند. در مقابل، سندباکس SMTP جایگزین سرور ایمیل خروجی برنامه میشود و پیام را پیش از تحویل عمومی ضبط میکند. یک صندوق پستی گیرنده بخش بیشتری از مسیر ارسال را آزمایش میکند، اما هیچ‌کدام به‌تنهایی ثابت نمی‌کند که پیام در صندوق ورودی جیمیل یا اوت‌لوک قرار می‌گیرد.
آیا هر تست QA باید از آدرس ایمیل متفاوتی استفاده کند؟
معمولاً بله. یک آدرس برای هر مورد تست، لاگها، اسکرینشاتها و ایمیلها را هماهنگ نگه میدارد و مانع میشود یک تست پیام تست دیگر را بخواند. صندوق ورودی مشترک برای یک بررسی دودی سریع قابل قبول است، اما وقتی چند تست همزمان اجرا شوند، اشکالزدایی آن دشوار میشود.
آیا میتوانم همان آدرس Tmailor را برای تست دیگری دوباره استفاده کنم؟
بله، اگر Access Token آن را ذخیره کرده باشید. توکن همان آدرس را روی هر دستگاهی دوباره باز میکند، که برای تستهای مجدد و سفرهای چندروزه کمک‌کننده است. اما پیام‌های قدیمی‌تر از حدود ۲۴ ساعت را بازنمی‌گرداند و توکن گمشده یک آدرس مهمان قابل بازیابی نیست، پس لینک‌ها و کدهای مورد نیاز را در هر مرحله ثبت کنید.
چه زمانی QA باید به جای ایمیل موقت از صندوق پستی شرکت استفاده کند؟
وقتی ایمیل حاوی دادههای واقعی مشتری یا اطلاعات ورود است، وقتی جریان به پاسخ یا پیوست نیاز دارد، وقتی باید پیام را به عنوان مدرک ممیزی نگه دارید، یا وقتی محصولی عمداً دامنههای ایمیل موقت را مسدود میکند، از صندوق پستی شرکت استفاده کنید. ارائهدهندگان هویت شخص ثالث و مهاجرتهای محیط تولید نیز معمولاً به آدرسهای واقعی و تحت کنترل شرکت نیاز دارند.
آیا آدرسدهی با علامت مثبت میتواند حسابهای تست جداگانه ایجاد کند؟
این کار تنوع آدرس ایجاد میکند، نه صندوق ورودی جداگانه. ایمیلهای ارسالشده به qa+one و qa+two در دامنه شما به همان صندوق qa میرسند، بنابراین تستها تاریخچه پیامها را با هم شریک میشوند. برنامه شما ممکن است این گونهها را حسابهای متفاوت بپذیرد، علامت مثبت را رد کند یا آنها را به یک کاربر یکسانسازی کند. این رفتار را به عنوان یک مورد تست در نظر بگیرید، نه یک فرض.
چرا ایمیل تأیید به صندوق ورودی تست نرسید؟
شایعترین دلایل عبارتاند از خطای ارسال در برنامه، تأخیر در ارائهدهنده ایمیل، محدودیت نرخ برای درخواستهای تکراری، اشتباه تایپی در آدرس، یا فیلتری که دامنههای ایمیل موقت را رد میکند. ابتدا لاگهای ایمیل برنامه خود را بررسی کنید، سپس یک بار با یک آدرس تحت کنترل شرکت دوباره امتحان کنید تا ببینید مشکل از آدرس است یا از جریان.
آیا صندوق ورودی موقت میتواند پیوستها، پاسخها یا قابلیت تحویل ایمیل را آزمایش کند؟
نه با تمایلور. پیوست دریافت نمی کند و نمی تواند ارسال یا پاسخ دهد. دریافت پیام در صندوق ورودی موقت نیز نشان نمی دهد که جیمیل یا اوت لوک آن را در صندوق ورودی یا اسپم قرار می دهند. از صندوق پستی شرکت برای پیوست ها و پاسخ ها استفاده کنید و از سرویس اختصاصی تحویل پذیری یا تست اولیه برای قرار دادن صندوق ورودی استفاده کنید.
آیا ثبتنامهای تست با ایمیل موقت میتواند تحلیلهای ما را منحرف کند؟
اگر ترافیک برچسبگذاری نشده باشد، بله. هر حساب تست را به وضوح علامتگذاری کنید، مثلاً با یک قرارداد نامگذاری یا یک نشانه تست، و آن حسابها را از داشبوردهای محیط تولید و گزارشهای رشد کنار بگذارید. اجرای تستها در یک محیط staging جداگانه از همان ابتدا بیشتر این ترافیک را از اعداد واقعی دور نگه میدارد.
انتخاب صندوق ورودی مناسب برای تست
صندوق ورودی را بر اساس آنچه تست باید اثبات کند انتخاب کنید. وقتی تحویل لازم نیست از یک دامنه نمونه رزروشده استفاده کنید، برای بررسی‌های دستی غیرحساس از صندوق ورودی موقت، برای جریانهای حساس یا نیازمند نگهداری از صندوق پستی شرکت، وقتی تنظیمات خروجی را کنترل می‌کنید از گیرنده SMTP، و برای تستهای سرتاسری بدون حضور انسان از یک API صندوق ورودی میزبانیشده استفاده کنید.
برای موارد دستی، یک صندوق ورودی موقت باز کنید و با جریان ثبت‌نامی که در مرحله بعد منتشر می‌کنید شروع کنید. ایمیل موقت کاربردهای عملی زیادی فراتر از کنترل کیفیت هم دارد.
Marcus Lee writes Tmailor's step-by-step guides, signing up to apps and platforms with temp mail, using the mobile app and Telegram bot, custom domains, reusing addresses, and getting the most out of disposable email day to day.
