نسخهٔ نامطمئن یک آزمون ایمیل کوتاه است: یک آدرس ایجاد کنید، به مدت پنج ثانیه صبر کنید، اولین پیام را بخوانید و امیدوار باشید که به این اجرا تعلق داشته باشد.
نسخهٔ قابل اعتماد همچنان ساده است، اما تحویل را به‌صورت ناهمزمان در نظر می‌گیرد. یک آدرس منحصربه‌فرد ایجاد می‌کند، زمان شروع را ثبت می‌کند، تا مهلت تعیین‌شده نظرسنجی می‌کند، پیام موردنظر را تطبیق می‌دهد، عمل محصول را اعتبارسنجی می‌کند و هنگام بروز خطا، زمینهٔ کافی را گزارش می‌دهد.
کلید API را از URL دور نگه دارید
کلید GPTMail را در هدر X-API-Key بفرستید. آن را در پارامترهای پرس‌و‌جو ?api_key= قرار ندهید. URLها به‌طور معمول در تاریخچه مرورگر، لاگ‌های دسترسی، سیستم‌های مانیتورینگ و داده‌های ارجاع ذخیره می‌شوند.
X-API-Key: YOUR_API_KEYکلید را در مدیر اسرار CI خود ذخیره کنید و در لاگ‌ها مخفی کنید. یک کلید عمومی روزانه برای کاوش راحت است؛ مجموعه‌های خودکار کنترل‌شده باید از کلیدی استفاده کنند که سهمیه و استفادهٔ آن را بتوانید ردیابی کنید.
نقطه‌های انتهایی و نمونه‌های پاسخ فعلی در صفحهٔ مستندات API GPTMail نگهداری می‌شوند.
یک آدرس برای هر اجرا
برای هر آزمون مستقل یک آدرس جدید تولید کنید. صحت را از صندوق‌پستی که توسط کل مجموعهٔ آزمون به اشتراک گذاشته شده است استخراج نکنید.
آدرس، شناسهٔ سناریو، محیط و زمان شروع آزمون را ثبت کنید. این مقادیر به شما امکان می‌دهند پیام‌های منقضی‌شده را رد کنید و برخوردها را بدون ثبت اسرار پیام تشخیص دهید.
نظرسنجی تا مهلت، نه خواب ثابت
زمان تحویل ایمیل متغیر است. خواب ثابت پنج ثانیه هم وقتی تحویل سریع است هدررفت است و هم وقتی تحویل کند است ناپایدار.
از یک حلقهٔ محدود استفاده کنید:
deadline = now + 90 seconds
delay = 2 seconds
while now < deadline:
messages = list inbox
candidate = newest message matching sender, subject, and start time
if candidate exists:
read candidate and continue the product test
wait delay with a small random jitter
delay = min(delay * 1.5, 10 seconds)مهلت بخشی از قرارداد آزمون است. جریان بازنشانی رمز عبور ممکن است به محدودیتی متفاوت نسبت به پیش‌نمایش خبرنامهٔ انبوه نیاز داشته باشد. محدودیت را به‌صورت صریح نگه دارید تا وابستگی کند به‌صورت خاموش کل کار CI را طولانی نکند.
به‌دقت مطابقت دهید
«اولین پیام در صندوق‌پست» یک انتخاب‌کنندهٔ مفید نیست. چندین سیگنال را مطابقت دهید:
- گیرنده برابر با آدرسی باشد که برای این اجرا ایجاد شده است؛
- زمان ایجاد پس از زمان تحریک باشد؛
- فرستنده متعلق به سرویس مورد انتظار باشد؛
- موضوع یا نوع پیام با جریان مطابقت داشته باشد؛
- شناسهٔ پیام قبلاً مصرف نشده باشد.
وقتی فرستنده می‌تواند چندین کد صادر کند، جدیدترین پیام مطابقت‌دار را انتخاب کنید. شناسهٔ آن را در خروجی آزمون حفظ کنید تا تلاش‌های مجدد به‌صورت تصادفی از آن استفاده نکنند.
پس از تطبیق فهرست، فقط بخوانید
فهرست‌کردن صندوق‌پست باید گام کشف ارزان باشد. فقط برای نامزد انتخاب‌شده پیام کامل را دریافت کنید. این کار بار غیرضروری را کاهش می‌دهد و از تجزیه‌وتحلیل ایمیل‌های تبلیغاتی نامرتبط جلوگیری می‌کند.
نتیجهٔ تجاری را اعتبارسنجی کنید، نه فقط وجود یک رشتهٔ شش‌رقمی. کد را ارسال کنید یا لینک مورد انتظار را باز کنید، سپس تأیید کنید که حساب به وضعیت صحیح می‌رسد.
محدودیت‌های نرخ را به‌عنوان سیگنال مدیریت کنید
اگر API پاسخی مربوط به سهمیه یا محدودیت نرخ برگرداند، تلاش جاری را متوقف کنید و اطلاعات بازنشانی را نمایش دهید. تلاش‌های مکرر تهاجمی سیگنال واضح ظرفیت را به نویز تبدیل می‌کند و می‌تواند آزمون‌های نامرتبط را به تأخیر بیندازد.
همزمانی را در رانر آزمون محدود کنید، به‌ویژه وقتی یک مجموعه تعداد زیادی آدرس را همزمان ایجاد می‌کند. یک استخر کارگر کوچک برای اشکال‌زدایی راحت‌تر از صدها حلقهٔ نظرسنجی همزمان است.
پاک‌سازی بدون پنهان کردن شکست‌ها
پاک‌سازی باید پس از ضبط شواهد اجرا شود. در صورت موفقیت، پیام‌ها را حذف کنید یا بگذارید نگهداری کوتاه‌مدت آن‌ها را مدیریت کند. در صورت شکست، آدرس و شناسهٔ پیام را در artefacts محافظت‌شدهٔ CI به‌مدت کافی برای بررسی نگه دارید، سپس آن‌ها را حذف کنید.
هرگز کدهای تأیید، لینک‌های خصوصی یا بدنهٔ کامل HTML را در لاگ‌های عمومی ساخت چاپ نکنید.
تلاش‌های مجدد را ایندموت کنید
آزمون را به‌عنوان یک اجرا جدید با آدرس جدید دوباره انجام دهید. فرض نکنید که تکرار همان درخواست نسبت به همان حساب و صندوق‌پست از وضعیت پاک شروع می‌شود. فرستنده ممکن است کدهای قدیمی را نامعتبر کند، درخواست‌های مکرر را محدود کند یا دعوت‌نامه‌های تکراری را رد کند.
اگر یک درخواست شبکه زمان‌سنجی شد، «پاسخی دریافت نشد» را از «عملیات انجام نشد» متمایز کنید. قبل از انجام یک تلاش مجدد مخرب، وضعیت قابل مشاهده را بررسی کنید.
نقطهٔ شکست را گزارش کنید
یک شکست مفید در اتوماسیون یکی از این مراحل را شناسایی می‌کند:
- تولید آدرس ناموفق بود؛
- عمل محصول قبل از صف‌گذاری ایمیل ناموفق بود؛
- پیام مطابقت‌دار قبل از مهلت نرسید؛
- پیام رسید اما محتوا مطابقت نداشت؛
- عمل تأیید ناموفق بود؛
- پاک‌سازی ناموفق بود.
این طبقه‌بندی یک «آزمون ایمیل ناموفق» متناوب را به کاری تبدیل می‌کند که تیم می‌تواند بر عهده بگیرد.
برای ماتریس بزرگتر آزمون‌ها، مقالهٔ یک برنامهٔ واقعی آزمون ایمیل را بخوانید. برای تشخیص تحویل، از ایمیل تأیید دریافت نمی‌شود: یافتن گام خراب استفاده کنید.