تست خودکار وب پوش نوتیفیکیشن
وب پوش نوتیفیکیشن ممکن است در محیط توسعه بی‌نقص به‌نظر برسد، اما پس از انتشار با خطاهایی روبه‌رو شود که فقط در یک مرورگر، یک وضعیت خاص مجوز یا یک نسخه تازه از سرویس‌ورکر رخ می‌دهند. برای کم‌کردن این ریسک، صرفاً یک بار بازکردن سایت و دیدن اعلان کافی نیست؛ باید اجزای سامانه را جداگانه و سپس در یک مسیر واقعی و کنترل‌شده آزمود. در این راهنما، منظور از تست خودکار وب پوش نوتیفیکیشن مجموعه‌ای از آزمون‌هاست که رفتار کد سایت، سرویس‌ورکر و تعامل مرورگر را بررسی می‌کند، بی‌آن‌که پیام آزمایشی اشتباهاً به اشتراک کاربران واقعی فرستاده شود. این مقاله درباره ساخت یک چارچوب آزمون‌پذیر است، نه راهنمای عمومی پیاده‌سازی وب پوش یا عیب‌یابی اعلان دریافت‌نشده.
- چرا تست وب پوش باید چندلایه باشد؟
- معماری قابل‌آزمون برای جریان وب پوش
- چهار لایه اصلی تست
- محیط تست را چگونه از کاربران واقعی جدا کنیم؟
- تست سرویس‌ورکر
- تست مجوز اعلان
- تست اشتراک و کلیدها
- تست API، صف و ارسال سمت سرور
- تست مرورگر واقعی و خودکارسازی رابط
- تست دریافت، نمایش و کلیک روی اعلان
- سناریوهای خطا و بازیابی
- امنیت و حریم خصوصی در تست وب پوش
- اجرای تست‌ها در CI و انتشار
- معیارهای کیفیت تست
- چک‌لیست پیش از انتشار
- چه زمانی استفاده از سرویس آماده منطقی‌تر است؟
- پرسش‌های پرتکرار
چرا تست وب پوش باید چندلایه باشد؟
وب پوش یک تابع منفرد نیست که با یک ورودی، همیشه خروجی یکسانی بسازد. در مسیر آن، کد صفحه، مجوزی که کاربر به مرورگر داده، ثبت سرویس‌ورکر، Push API، اشتراک مرورگر، سرویس ارسال پیام و کد نمایش اعلان با هم کار می‌کنند. اگر یکی از این حلقه‌ها خراب باشد، خروجی برای کاربر ممکن است فقط «اعلانی نرسید» به‌نظر برسد؛ درحالی‌که علت می‌تواند ثبت‌نشدن سرویس‌ورکر، اشتراک منقضی، پاسخ نامعتبر از سرور، خطای رمزنگاری یا نادیده‌گرفتن رویداد push باشد.
آزمون دستی برای بررسی اولیه مهم است، اما تکرارپذیر نیست. ممکن است یک نفر مجوز را قبلاً پذیرفته باشد و نفر دیگر آن را رد کرده باشد؛ ممکن است مرورگر در دستگاه آزمایش هنوز سرویس‌ورکر نسخه قدیمی را نگه داشته باشد؛ یا توسعه‌دهنده روی دامنه امن کار کند ولی محیط پیش‌نمایش روی پیکربندی دیگری باشد. تست خودکار، وضعیت‌ها و پیش‌شرط‌ها را صریح می‌کند و به تیم اجازه می‌دهد پس از هر تغییر مهم، دوباره همان مسیرها را بررسی کند.
هدف تست خودکار این نیست که همه رفتارهای شبکه عمومی را شبیه‌سازی کند یا تضمین کند هر اعلان در هر دستگاه و هر زمانی نمایش داده می‌شود. مسیر تحویل پوش به سرویس‌های مرورگر و سیستم‌عامل وابسته است و شرایط دستگاه کاربر کاملاً در اختیار سایت نیست. هدف واقع‌بینانه‌تر، اثبات این موارد است: کد سایت درخواست درست می‌سازد، سرور داده را با اعتبارسنجی مناسب نگه می‌دارد، سرویس‌ورکر پیام را طبق قرارداد پردازش می‌کند، مسیر کلیک مقصد معتبری دارد و خطاها بدون افشای داده یا ایجاد ارسال تکراری مدیریت می‌شوند.
این نگاه لایه‌ای از یک اشتباه رایج جلوگیری می‌کند: برابر دانستن «تست ارسال موفق سمت سرور» با «تست تجربه کاربر». پاسخ موفق یک API تنها می‌تواند نشان دهد درخواست به یک مرحله از زنجیره رسیده است؛ لزوماً ثابت نمی‌کند مرورگر پیام را دریافت کرده، اعلان را نشان داده یا کاربر روی آن کلیک کرده است. هر ادعا باید با نوع آزمونی که واقعاً آن را پوشش می‌دهد هماهنگ باشد.
معماری قابل‌آزمون برای جریان وب پوش
پیش از نوشتن آزمون، جریان را به اجزای روشن تقسیم کنید. در یک نمونه متداول، صفحه پس از اقدام آگاهانه کاربر وضعیت مرورگر را بررسی می‌کند؛ سرویس‌ورکر ثبت یا بازیابی می‌شود؛ در صورت امکان اشتراک ایجاد می‌شود؛ اشتراک به سرور فرستاده و به حساب یا شناسه ناشناس سایت مرتبط می‌شود؛ سامانه سمت سرور پیام مناسب را صف‌بندی می‌کند؛ سرویس‌ورکر رویداد push را پردازش می‌کند؛ و در صورت تعامل، مقصدی را باز می‌کند. هر مرحله باید ورودی و خروجی قابل‌تعریف داشته باشد.
کد رابط کاربری را طوری بنویسید که منطق تصمیم‌گیری از APIهای مرورگر جدا باشد. برای مثال، تابعی که می‌گوید آیا مرورگر قابلیت اشتراک دارد یا نه، با تابعی که متن راهنما را نمایش می‌دهد یکی نباشد. در تست واحد می‌توان وضعیت‌های granted، denied و default را به ورودی تابع داد و بررسی کرد رابط چه تصمیمی می‌گیرد، بی‌آن‌که مجوز واقعی مرورگر تغییر کند.
در سمت سرور هم کارهایی مانند اعتبارسنجی payload، ذخیره‌سازی اشتراک، انتخاب مخاطب، ساخت کار ارسال و ثبت نتیجه را به بخش‌هایی با مسئولیت روشن تقسیم کنید. اگر یک endpoint هم‌زمان داده را می‌پذیرد، متن اعلان را می‌سازد، مخاطب را انتخاب می‌کند و ارسال را انجام می‌دهد، نوشتن تست دقیق و فهمیدن علت شکست سخت می‌شود. جداسازی مسئولیت‌ها به معنی پیچیده‌کردن معماری نیست؛ یعنی هر بخش قرارداد کوچکی داشته باشد و بتوان رفتار آن را مستقل سنجید.
برای آزمون‌پذیری، وابستگی به مرورگر یا شبکه را پشت رابط‌های قابل‌جایگزینی قرار دهید. در تست واحد می‌توانید پیاده‌سازی جعلی برای خواندن وضعیت مجوز، ذخیره اشتراک یا زمان‌بندی کارها فراهم کنید. در تست یکپارچه، وابستگی‌های جعلی را با اجزای واقعی پروژه جایگزین می‌کنید. در تست انتهابهانتها، چند مسیر واقعی مرورگر را می‌سنجید. این لایه‌ها قرار نیست همگی یک چیز را دوباره بررسی کنند؛ هر کدام باید نوع خاصی از ریسک را هدف بگیرد.
برای هر مرحله رویدادهای قابل‌ردیابی تعریف کنید. نمونه‌هایی مانند registration_started، registration_ready، permission_state_read، subscription_created، subscription_saved، send_job_accepted و notification_click، اگر با شناسه‌های امن و حداقلی ثبت شوند، کمک می‌کنند بفهمید آزمون از کدام نقطه عبور کرده است. در محیط تولید نیز چنین رویدادهایی باید با دقت طراحی شوند تا endpoint کامل یا کلید اشتراک در لاگ عمومی ثبت نشود.
چهار لایه اصلی تست
برای پوشش متعادل، تست‌ها را در چهار سطح ببینید. سطح نخست تست واحد است؛ این آزمون‌ها سریع‌اند و قواعد تبدیل داده، اعتبارسنجی، انتخاب متن جایگزین و تصمیم‌های رابط را بررسی می‌کنند. سطح دوم تست یکپارچه است؛ در این سطح، اتصال اجزای سرور به پایگاه داده آزمایشی، صف و قرارداد API بررسی می‌شود. سطح سوم تست مرورگر است؛ رفتار صفحه و سرویس‌ورکر در مرورگر واقعی یا محیط شبیه‌سازی‌شده سنجیده می‌شود. سطح چهارم آزمون محدود انتهابه‌انتهاست که یک مسیر کامل را از ثبت سایت تا رسیدن به نقطه قابل مشاهده بررسی می‌کند.
| لایه | نمونه پرسش | مزیت | محدودیت |
|---|---|---|---|
| واحد | آیا داده ناقص رد می‌شود؟ | سریع و دقیق | رفتار مرورگر را نمی‌سنجد |
| یکپارچه | آیا اشتراک در پایگاه داده درست ذخیره می‌شود؟ | قرارداد اجزا را بررسی می‌کند | ممکن است سرویس پوش واقعی را دربرنگیرد |
| مرورگر | آیا رابط در وضعیت مجوز ردشده پیام مناسب نشان می‌دهد؟ | رفتار واقعی صفحه را می‌سنجد | کندتر و وابسته به محیط است |
| انتهابهانتها | آیا پیام آزمایشی تا مرحله نمایش و کلیک پیش می‌رود؟ | مسیر کامل را می‌آزماید | هزینه نگهداری و احتمال ناپایداری بیشتر است |
ترکیب خوب معمولاً تعداد زیادی تست سریع و تعدادی کمتر تست مرورگر و انتهابهانتها دارد. اگر برای هر تغییر کوچک فقط به آزمون کامل شبکه‌ای تکیه کنید، بازخورد کند می‌شود و تیم ممکن است آزمون‌ها را نادیده بگیرد. اگر هم فقط تست واحد داشته باشید، خطاهای ناشی از تفاوت واقعی مرورگر و سرویس‌ورکر را دیر می‌بینید. نسبت دقیق به اندازه محصول، پشتیبانی مرورگرها و هزینه خطا وابسته است.
هر آزمون را به یک ادعای مشخص وصل کنید. «وب پوش کار می‌کند» ادعای مبهمی است؛ «وقتی کاربر مجوز را رد کرده، صفحه دوباره بدون توضیح پنجره درخواست مجوز را باز نمی‌کند» یک رفتار قابل‌سنجش است. ادعای کوچک، نام آزمون روشن و پیام شکست مفید، سرعت عیب‌یابی را بالا می‌برد. تستی که شکست آن فقط می‌گوید انتظار برآورده نشد، اما نمی‌گوید کدام قرارداد نقض شده، ارزش نگهداری کمتری دارد.
محیط تست را چگونه از کاربران واقعی جدا کنیم؟
مرز محیط‌ها باید از ابتدا روشن باشد: توسعه محلی، آزمایش خودکار، پیش‌نمایش، staging و تولید نباید بی‌تمایز از یک پایگاه داده یا یک گروه مخاطب استفاده کنند. برای هر محیط، کلیدها و اعتبارنامه‌های مستقل در نظر بگیرید و ارسال آزمون را به گیرنده‌های مجاز محدود کنید. کلید خصوصی VAPID و رمزهای دسترسی را در کد مرورگر یا مخزن عمومی قرار ندهید. داده‌های نمونه نیز باید ساختگی باشند و از اطلاعات شخصی مشتریان کپی نشوند.
یک شیوه امن این است که در staging، ارسال عمومی به‌طور پیش‌فرض بسته باشد و فقط حساب‌های آزمایشی مشخص بتوانند پیام دریافت کنند. اگر تیم امکان اعمال محدودیت در سطح برنامه دارد، هر درخواست ارسال آزمایشی باید شناسه محیط و برچسب test داشته باشد و سرور این برچسب را از منبع مورد اعتماد تعیین کند، نه این‌که صرفاً هر کاربر بتواند با افزودن یک فیلد دلخواه، محدودیت را دور بزند.
برای دامنه آزمایشی نیز سیاست جداگانه تعریف کنید. ثبت اشتراک روی دامنه یکسان با تولید می‌تواند باعث سردرگمی شود، چون سرویس‌ورکر و داده‌های سایت به مبدأ و دامنه مرتبط‌اند. از دامنه آزمایشی اختصاصی استفاده کنید و هرگز فرض نکنید که پاک‌کردن کوکی به‌تنهایی همه وضعیت‌های مرورگر، از جمله ثبت سرویس‌ورکر و اشتراک‌های موجود، را پاک می‌کند.
محیط امن باید امکان پایان‌دادن به آزمون را نیز داشته باشد. برای داده‌های تست، تاریخ انقضا یا فرایند پاک‌سازی تعریف کنید. اشتراک‌های قدیمی آزمایش را از پایگاه داده حذف یا غیرفعال کنید؛ در غیر این صورت، اجرای تکراری سناریوها ممکن است به چند ارسال برای یک دستگاه منجر شود و نتیجه آزمون را مبهم کند. پاک‌سازی نباید به حذف کور داده‌های تولیدی وابسته باشد؛ انتخاب داده باید با شناسه محیط و حساب آزمایشی محدود شود.
حالت‌های محیط را در رابط کاربری نیز قابل‌تشخیص کنید. نشان واضح staging و ممنوع‌بودن استفاده از داده واقعی، خطای انسانی را کم می‌کند. اگر داشبورد یا سامانه داخلی کمپین دارید، برچسب محیط را کنار نام مخاطب و دکمه ارسال نمایش دهید. یک آزمون خودکار هم اضافه کنید که با پیکربندی staging، درخواست به مقصد تولید ساخته نشود. این آزمون از اشتباه پیکربندی‌شده‌ای پیشگیری می‌کند که می‌تواند هزینه عملیاتی و اعتباری داشته باشد.
تست سرویس‌ورکر
سرویس‌ورکر در پس‌زمینه و جدا از چرخه عمر معمول صفحه اجرا می‌شود؛ بنابراین تست آن با تست یک تابع ساده در صفحه تفاوت دارد. اولین مجموعه آزمون باید ثبت فایل در مسیر مورد انتظار، قابل‌دسترسی‌بودن فایل، کنترل مسیر scope و رفتار به‌روزرسانی را بررسی کند. اگر فایل سرویس‌ورکر در مسیر اشتباه یا با scope محدود ثبت شود، صفحه‌ای که انتظار کنترل‌شدن دارد ممکن است تحت کنترل آن نباشد. تست باید به‌جای اتکا به حدس، وضعیت registration و controller را در شرایط مشخص بررسی کند.
آزمون‌های چرخه عمر باید سناریوهای نصب، فعال‌شدن و جایگزینی نسخه را در نظر بگیرند. کدی که هنگام فعال‌سازی کش قدیمی را پاک می‌کند، نباید به‌اشتباه داده یا منابع نسخه جاری را حذف کند. اگر نسخه تازه منتظر بسته‌شدن زبانه‌ها می‌ماند، رفتار محصول را در همان وضعیت آزمون کنید و درباره فعال‌سازی فوری تصمیم آگاهانه بگیرید. در محیط تست، اجرای چندباره ثبت و به‌روزرسانی به شما نشان می‌دهد آیا کد با چند رخداد پشت‌سرهم به وضعیت ناسازگار می‌رسد یا نه.
منطق رویداد push را تا جای ممکن به تابعی مستقل بسپارید: داده ورودی را بخواند، اعتبارسنجی کند، متن و گزینه‌های نمایش را بسازد و نتیجه را به تابع نمایش اعلان بدهد. با این جداسازی می‌توانید ورودی معتبر، JSON خراب، فیلدهای غایب و نوع داده نامنتظره را بدون ارسال واقعی پیام آزمایش کنید. اگر payload متنی یا رمزگشایی‌شده از هر منبعی می‌آید، آن را داده نامطمئن فرض کنید؛ مسیر ناوبری، عنوان و تصویر نباید بدون اعتبارسنجی پذیرفته شوند.
در آزمون رویداد notificationclick، بررسی کنید کلیک به مقصد مجاز می‌رود، صفحه تکراری بی‌دلیل باز نمی‌شود و در صورت وجود زبانه مناسب همان زبانه به‌روزرسانی یا focus می‌شود. رفتار مورد انتظار را پیشاپیش تعیین کنید؛ گاهی ساخت زبانه تازه بهتر است و گاهی بازگرداندن زبانه موجود. آزمون باید هر دو وضعیت را پوشش دهد. همچنین مقصد لینک را بررسی کنید تا URL خارجی غیرمنتظره یا مسیر دارای داده حساس از پیام ورودی پذیرفته نشود.
برای آزمون سرویس‌ورکر، از ابزارهای توسعه مرورگر و آزمون‌های خودکار سازگار با آن استفاده کنید، اما فرض نکنید همه محیط‌های شبیه‌سازی اجرای کامل Service Worker و Push API را فراهم می‌کنند. بعضی آزمون‌ها بهتر است منطق خالص را با ورودی ساختگی بسنجند و آزمون محدود دیگری ثبت واقعی را در مرورگر هدف بررسی کند. مستندات ابزار مورد استفاده را برای سطح پشتیبانی هر API بخوانید و محدودیت آزمون را در گزارش فنی ثبت کنید.
اگر سایت تک‌صفحه‌ای است، تغییر مسیر داخلی باید با کنترل مقصد سرویس‌ورکر سازگار باشد. کلیک روی اعلان نباید به مسیری ختم شود که در برنامه وجود ندارد یا ابتدا کاربر را به صفحه اصلی می‌برد و سپس مقصد را گم می‌کند. برای بررسی این وضعیت می‌توانید چند مسیر داخلی نماینده، از جمله صفحه‌ای که نیازمند ورود است، را در تست‌ها بگنجانید. برای جزئیات نصب در یک پروژه React، راهنمای نصب وب پوش در React و مدیریت چرخه صفحه می‌تواند زمینه فنی مکملی فراهم کند.
تست مجوز اعلان
مجوز اعلان یک وضعیت بیرونی است و همیشه نمی‌توان آن را مانند یک متغیر عادی از برنامه کنترل کرد. در آزمون واحد، وضعیت‌ها را به‌صورت ورودی تزریق کنید و رفتار برنامه را برای granted، denied و default بسنجید. برای نمونه، در وضعیت denied نباید دکمه‌ای وعده فعال‌سازی فوری بدهد اگر مرورگر دیگر پنجره درخواست عادی را نشان نمی‌دهد؛ باید راهنمایی متناسب با تنظیمات مرورگر ارائه شود. در وضعیت default نیز باید درخواست مجوز به زمینه مناسب و پس از توضیح ارزش آن محدود بماند.
رفتار مجوز را در مرورگر واقعی با پروفایل پاک یا context تازه آزمایش کنید. اگر یک تست قبلی مجوز را پذیرفته باشد، تست بعدی ممکن است بدون نمایش پنجره به همان وضعیت قبلی ادامه دهد. این وابستگی پنهان یکی از علت‌های آزمون‌های ناپایدار است. هر تست باید بداند از چه وضعیت اولیه‌ای شروع می‌شود و در پایان، وضعیت را طبق امکانات ابزار پاک‌سازی کند یا یک context مستقل بسازد.
از آزمون‌هایی که برای هر بازدید، بی‌درنگ پنجره درخواست مجوز را باز می‌کنند پرهیز کنید. حتی اگر هدف فقط تست باشد، این رفتار می‌تواند عادت نامطلوب را وارد محصول کند. اجازه را در پاسخ به کنش روشن کاربر و پس از توضیح کوتاه درخواست کنید و در آزمون هم همان مسیر واقعی رابط را اجرا کنید. بررسی کنید که بدون کنش کاربر، برنامه پیام مزاحم یا درخواست خودکار ایجاد نکند.
حالت‌های غیرقابل‌پشتیبانی را هم تست کنید. صفحه‌ای که روی اتصال ناامن یا مرورگری فاقد API لازم باز شده است، نباید با خطای خام جاوااسکریپت از کار بیفتد. برنامه باید پیام جایگزین نشان دهد و باقی قابلیت‌های سایت را سالم نگه دارد. قابلیت‌ها را با تشخیص API بررسی کنید، نه با فهرست ثابت نام مرورگرها؛ رفتار مرورگرها و نسخه‌ها تغییر می‌کند و تشخیص مبتنی بر نام می‌تواند هم کاربران پشتیبانی‌شده را کنار بگذارد و هم کاربران ناسازگار را اشتباهاً وارد مسیر کند.
یک ماتریس ساده بسازید: مجوز پذیرفته، مجوز رد، مجوز هنوز درخواست نشده و API در دسترس نیست. برای هر حالت، رفتار دکمه، متن راهنما، درخواست شبکه و ثبت رخداد مورد انتظار را مشخص کنید. این ماتریس کمک می‌کند آزمون رابط فقط وجود یک عنوان را بررسی نکند؛ بلکه اطمینان دهد برنامه در هر وضعیت، اقدام درست را ارائه می‌دهد و داده غیرضروری ارسال نمی‌کند.
تست اشتراک و کلیدها
اشتراک وب پوش را شناسه‌ای قابل‌حدس یا نام کاربری تلقی نکنید. شیء اشتراک اطلاعاتی برای ارتباط با سرویس پوش و کلیدهای عمومی لازم دارد؛ بعضی بخش‌های آن برای ارسال و رمزنگاری استفاده می‌شوند و endpoint می‌تواند داده حساس عملیاتی باشد. آزمون سمت مرورگر می‌تواند بررسی کند اشتراک تازه ایجادشده ساختار مورد انتظار دارد و نتیجه تبدیل آن به JSON مطابق قرارداد API است. اما نباید مقدارهای واقعی اشتراک یا کلیدها را در گزارش‌های عمومی CI چاپ کند.
در سمت سرور، اعتبارسنجی شکل داده، طول و نوع فیلدها، پروتکل URL و محدودیت اندازه درخواست را آزمایش کنید. داده‌ای ناقص، JSON خراب یا endpoint با پروتکل نامعتبر باید با پاسخ روشن رد شود، نه این‌که تا مرحله ارسال جلو برود. ورودی را صرفاً چون از مرورگر خودتان آمده معتبر فرض نکنید؛ endpoint ثبت اشتراک نیز مانند هر endpoint عمومی دیگری به کنترل دسترسی، محدودیت نرخ و محافظت مناسب نیاز دارد.
سناریوی اشتراک تکراری را مشخص کنید. ممکن است کاربر چند بار دکمه را بزند، صفحه دوباره بارگذاری شود یا درخواست ثبت به‌دلیل قطع ارتباط پاسخ نگیرد و مرورگر یا برنامه آن را تکرار کند. سرور باید بتواند این تکرارها را بدون ساختن بی‌رویه رکورد یا ارسال چندباره پیام مدیریت کند. آزمون باید نشان دهد ثبت تکراری یا به همان رکورد همگرا می‌شود یا طبق سیاست محصول به‌شکل امن جایگزین می‌شود.
تغییر و حذف اشتراک نیز به اندازه ایجاد آن مهم است. اگر مرورگر اشتراک را منقضی یا لغو کند، سامانه باید بتواند داده قدیمی را به‌روز یا غیرفعال کند. آزمون قطع اشتراک باید بررسی کند که بعد از لغو، کاربر بی‌دلیل پیام نمی‌گیرد و رکورد مربوط از مخاطب فعال جدا می‌شود. به‌دلیل تفاوت چرخه عمر اشتراک‌ها، فرض نکنید یک اشتراک برای همیشه ثابت می‌ماند؛ مسیرهای همگام‌سازی و پاک‌سازی را مشخص و قابل‌تکرار کنید.
کلید عمومی برنامه که به subscribe داده می‌شود باید با کلیدی که سرور برای ارسال استفاده می‌کند هماهنگ باشد. تست پیکربندی می‌تواند اطمینان دهد محیط‌های مختلف جفت کلید درست را مصرف می‌کنند، بدون این‌که کلید خصوصی در خروجی آزمون ظاهر شود. آزمون منفی برای جفت‌کلید نامعتبر یا گم‌شده نیز لازم است: برنامه یا سرور باید با خطای قابل‌تشخیص متوقف شود، نه این‌که اشتراک ظاهراً موفق ایجاد کند و شکست را تا زمان ارسال واقعی پنهان نگه دارد.
اگر ذخیره اشتراک به حساب کاربری پیوند می‌خورد، سناریوی ورود و خروج را نیز جداگانه بسنجید. دستگاه مشترک یا چند کاربر روی یک مرورگر می‌تواند باعث شود اعلان به هویت نادرست نسبت داده شود. از ذخیره بی‌ضابطه داده حساب در payload جلوگیری کنید و قواعد انتقال یا جداکردن اشتراک هنگام خروج را روشن کنید. مقاله مدیریت اشتراک‌های وب پوش نوتیفیکیشن درباره چرخه اشتراک زمینه تکمیلی دارد؛ در این مقاله تمرکز بر این است که رفتارهای آن چرخه چگونه به سناریوی تست تبدیل شوند.
تست API، صف و ارسال سمت سرور
آزمون API باید قرارداد قابل‌مشاهده آن را بررسی کند: کدام فیلدها پذیرفته می‌شوند، خطای اعتبارسنجی چه پاسخی دارد، کاربر چه مجوزی برای ثبت یا حذف اشتراک لازم دارد و پاسخ موفق چه معنایی دارد. پاسخ موفق را دقیق تعریف کنید. اگر فقط درخواست به صف افزوده شده است، پاسخ نباید به مشتری القا کند که اعلان حتماً روی دستگاه نمایش داده شده است. این تمایز در نام‌گذاری فیلدها، گزارش‌ها و داشبورد اهمیت دارد.
برای تست یکپارچه، پایگاه داده آزمایشی و صف ساختگی یا محلی به کار ببرید و سرویس ارسال بیرونی را با یک آداپتور قابل‌جایگزینی مدیریت کنید. آزمون واحد می‌تواند بسنجد که برای مخاطب درست و متن مشخص، کار درست ساخته می‌شود. آزمون یکپارچه بررسی می‌کند کار در صف ثبت، پس از خطای موقت دوباره زمان‌بندی و پس از موفقیت از صف خارج می‌شود. این کار را می‌توان بدون فرستادن پیام واقعی انجام داد.
تکرار کار باید با سیاست صریح اداره شود. اگر کارگر پس از ارسال پیام متوقف شود اما پیش از ثبت نتیجه از صف خارج نشود، اجرای دوباره ممکن است ارسال تکراری ایجاد کند. برای کارهای مهم از شناسه یکتا، قفل یا الگوی idempotency مناسب استفاده کنید و آن را با آزمونی که همان کار را چند بار اجرا می‌کند بررسی کنید. تضمین «دقیقاً یک بار» در سامانه‌های توزیع‌شده ساده نیست؛ بهتر است رفتار واقعی سیستم و روش کاهش اثر تکرار را شفاف مستند کنید.
پاسخ‌های خطای سرویس بیرونی را بر اساس معنا دسته‌بندی کنید، نه این‌که همه را یکسان دوباره امتحان کنید. خطای موقت شبکه ممکن است ارزش تلاش دوباره داشته باشد؛ اشتراک نامعتبر یا پاسخ دائمی معمولاً باید موجب غیرفعال‌سازی یا بررسی شود. آزمون‌ها باید نشان دهند خطای دائمی در حلقه تکرار بی‌پایان نمی‌افتد و خطای موقت نیز بدون سقف و فاصله مناسب بار اضافی نمی‌سازد. زمان‌بندی مجدد باید سقف تلاش، فاصله افزایشی و ثبت علت داشته باشد.
همچنین جداگانه بیازمایید که پاسخ سرویس ارسال، وضعیت داخلی کار را درست به‌روزرسانی می‌کند. «درخواست ارسال شد»، «سرویس آن را پذیرفت»، «مرورگر آن را دریافت کرد» و «کاربر روی اعلان کلیک کرد» چهار رخداد متفاوت‌اند. نام‌گذاری دقیق جلوی گزارش‌های گمراه‌کننده را می‌گیرد. اگر سامانه فقط پذیرش سرویس را می‌داند، نباید آن را به‌عنوان مشاهده قطعی اعلان روی صفحه نمایش دهد.
تست مرورگر واقعی و خودکارسازی رابط
خودکارسازی مرورگر برای بررسی ترکیب صفحه، سرویس‌ورکر و منطق رابط ارزشمند است، اما قابلیت ابزارها یکسان نیست. پیش از طراحی تست، بررسی کنید ابزار مورد استفاده اجازه تنظیم permission، دسترسی به context جداگانه و بررسی ثبت سرویس‌ورکر را می‌دهد یا نه. همچنین APIهای Push و Notifications ممکن است در محیط‌های headless، مرورگرهای مختلف یا نسخه‌های مختلف ابزار، محدودیت داشته باشند. محدودیت را با یک تست کوچک اثبات کنید و سپس بر اساس واقعیت ابزار تصمیم بگیرید.
تست‌ها را بر پایه رفتار کاربر بنویسید، نه جزئیات ناپایدار رابط. برای مثال، دکمه باید شناسه دسترس‌پذیر و نام قابل‌فهم داشته باشد تا تست بتواند آن را پیدا کند؛ اتکا به ترتیب عناصر یا کلاس‌های موقت، آزمون را با کوچک‌ترین تغییر طراحی می‌شکند. پس از کلیک، پیام وضعیت مناسب، درخواست ثبت مورد انتظار و مسیر خطا را بررسی کنید. این روش علاوه بر کیفیت تست، به دسترس‌پذیری محصول نیز کمک می‌کند.
در مرورگر خودکار، context مستقل برای هر سناریو بسازید تا مجوزها، storage و ثبت سرویس‌ورکر از آزمون قبلی نمانند. پیش از آزمون، سرویس‌ورکر را ثبت کنید یا صریحاً بررسی کنید که صفحه خودش آن را ثبت می‌کند؛ هر دو شیوه ممکن است مفید باشد، اما نباید در یک تست مبهم با هم مخلوط شوند. پس از پایان، صفحه‌ها و context را ببندید و پاک‌سازی کنترل‌شده انجام دهید.
آزمون یکپارچه مرورگر می‌تواند نصب سرویس‌ورکر و نمایش اعلان محلی را بسنجد، ولی لازم نیست به شبکه عمومی پوش وابسته باشد. در سناریوهای حساس، یک لایه آداپتور ایجاد کنید که رویداد یا پاسخ آزمایشی را به مسیر پردازش بدهد. تست جداگانه و محدود در محیط دستی یا staging می‌تواند ارسال واقعی را به دستگاه‌های ثبت‌شده تیم بررسی کند. این جداسازی باعث می‌شود هر commit به سرویس بیرونی و وضعیت متغیر شبکه وابسته نباشد.
ترکیب مرورگرها را بر اساس کاربران واقعی و ریسک انتخاب کنید. نیازی نیست هر commit همه مرورگرها، نسخه‌ها و سیستم‌عامل‌ها را با آزمون کامل پوشش دهد. می‌توانید تست سریع را روی یک مرورگر اصلی اجرا کنید و برنامه زمان‌بندی‌شده‌ای برای مرورگرهای دیگر داشته باشید. این برنامه باید مرورگرهای هدف تجاری، نسخه‌های پشتیبانی‌شده و تغییرات مهم را در نظر بگیرد. برای موضوعات وابسته به iOS، نصب وب‌اپ و محدودیت‌های خاص آن را جداگانه بررسی کنید؛ نتیجه یک مرورگر دسکتاپ را نمی‌توان بی‌واسطه به همه دستگاه‌ها تعمیم داد.
تست دریافت، نمایش و کلیک روی اعلان
در تست مسیر پیام، payloadهای نماینده داشته باشید: پیام ساده، داده ناقص، داده با فیلد اختیاری، متن بلند، کاراکترهای فارسی، نیم‌فاصله، نشانه‌گذاری و emoji. هدف این نیست که همه محدودیت‌های هر سیستم‌عامل را حدس بزنید؛ هدف این است که متن در مسیر کد شما خراب نشود، داده نامعتبر منجر به خطای کنترل‌نشده نشود و fallback قابل‌فهمی وجود داشته باشد. حجم payload را نیز محدود کنید و سناریوی بیش‌ازحد بزرگ را به‌عنوان ورودی نامعتبر بسنجید.
نمایش اعلان به محیط کاربر وابسته است و ظاهر نهایی ممکن است بین مرورگر و سیستم‌عامل تفاوت داشته باشد. تست خودکار بهتر است گزینه‌های مورد انتظار را در محل فراخوانی showNotification بررسی کند، مانند عنوان، متن، مقصد و تنظیمات رفتاری. برای بررسی پیکسل‌به‌پیکسل اعلان سیستم، به‌دلیل تفاوت رابط سیستم‌عامل، معمولاً آزمون پایدار و مقرون‌به‌صرفه‌ای وجود ندارد. ادعای آزمون را با لایه واقعی‌ای که مشاهده کرده‌اید محدود کنید.
اگر پیام داده‌ای برای کلیک حمل می‌کند، آن را به مقصد مجاز و ساختار مشخص محدود کنید. تست باید مقصد داخلی معتبر، مقصد نامعتبر و داده خالی را شامل شود. بررسی کنید اطلاعات محرمانه مانند شناسه نشست یا داده شخصی در query string قرار نگیرد. همچنین اگر کاربر از اعلان به صفحه‌ای می‌رود که نیازمند ورود است، صفحه باید تجربه منطقی داشته باشد و مقصد پس از ورود به‌شکل امن بازیابی شود.
برای جلوگیری از تکرار یا رقابت بین اعلان‌ها، سیاست نمایش خود را روشن کنید. اگر دو پیام درباره یک رخداد می‌توانند به‌روزرسانی یک اعلان قبلی را انجام دهند، رفتار جایگزینی را تست کنید؛ اگر باید هر دو جدا بمانند، شناسه‌ها باید مناسب باشند. دقت کنید تست این سیاست در سطح کد سرویس‌ورکر انجام شود و با این ادعا اشتباه نشود که همه مرورگرها اعلان‌ها را دقیقاً یکسان نشان می‌دهند.
در آزمون واقعی staging، دستگاه دریافت‌کننده را از فهرست آزمایشی مشخص کنید، زمان اجرا و شناسه پیام را ثبت کنید و پس از آزمون، داده را پاک‌سازی کنید. تعداد کم آزمون‌های انتهابهانتها کافی است؛ اجرای انبوه آن‌ها معمولاً چیزی بیش از بار روی سرویس و سردرگمی تیم ایجاد نمی‌کند. اگر پیام واقعی به هر دلیل به هدف آزمایشی نرسید، باید بتوانید تشخیص دهید کدام مرحله گزارش شده و کدام مرحله صرفاً استنباط شده است.
سناریوهای خطا و بازیابی
یک چارچوب آزمون قابل‌اعتماد فقط مسیر موفق را بررسی نمی‌کند. قطع اینترنت هنگام ثبت، timeout API، پاسخ نامعتبر سرور، شکست ذخیره‌سازی و لغو اشتراک نمونه‌هایی‌اند که باید رفتار برنامه در برابرشان روشن باشد. پیام خطا باید برای کاربر مفید باشد و جزئیات حساس فنی را افشا نکند. در لاگ داخلی نیز علت کافی برای عیب‌یابی ثبت شود، بدون آن‌که کلید خصوصی، payload حساس یا endpoint کامل در گزارش قابل‌دسترسی عمومی قرار گیرد.
برای هر شکست موقت، تعیین کنید آیا تلاش دوباره مجاز است و چه کسی آن را آغاز می‌کند. تکرار خودکار در صفحه همراه با تکرار در سرور ممکن است تعداد درخواست‌ها را چند برابر کند. آزمونی بسازید که چند بار پاسخ timeout بدهد و بررسی کند تعداد تلاش‌ها از سقف تعیین‌شده فراتر نمی‌رود. همچنین آزمون موفقیت پس از شکست موقت را داشته باشید تا مطمئن شوید فرایند بازیابی واقعاً کار می‌کند.
برای اشتراک نامعتبر، رفتار سیستم باید پایان‌پذیر باشد. اگر ارسال به یک اشتراک بارها با پاسخ دائمی ناموفق برگردد، آن اشتراک نباید برای همیشه در صف فعال باقی بماند. آزمون نشان دهد نتیجه به رکورد مربوط وصل می‌شود و اشتراک طبق سیاست محصول غیرفعال یا علامت‌گذاری می‌شود. متن پاسخ سرویس را خام به کاربر ندهید؛ آن را به دسته خطای قابل‌استفاده تبدیل کنید.
تست هم‌زمانی نیز اهمیت دارد. کاربری ممکن است چند بار دکمه فعال‌سازی را فشار دهد یا دو درخواست ثبت نزدیک به هم برسند. آزمون موازی بررسی کند سیستم رکوردهای بی‌دلیل تکراری نسازد و پاسخ‌های ناسازگار ندهد. در صف ارسال، دو کارگر ممکن است کار مشابه را هم‌زمان بردارند؛ قفل، یکتایی یا سازوکار کنترل هم‌زمانی باید با سناریوی واقعی آزموده شود، نه فقط از روی کد حدس زده شود.
رفتار پس از به‌روزرسانی نسخه را هم در برنامه تست قرار دهید. صفحه بازمانده با سرویس‌ورکر قدیمی ممکن است مدتی هم‌زمان با نسخه جدید سایت کار کند. بررسی کنید قرارداد پیام میان نسخه‌ها تا حد لازم سازگار باشد و تغییر ساختار payload باعث ازکارافتادن یک نسخه قدیمی فعال نشود. اگر سازگاری کامل ممکن نیست، برنامه انتشار تدریجی، fallback یا انقضای نسخه را مشخص کنید.
امنیت و حریم خصوصی در تست وب پوش
تست امنیتی را بخشی از کیفیت فنی بدانید، نه مرحله‌ای که فقط پیش از انتشار انجام می‌شود. endpoint ثبت اشتراک باید در برابر ورودی نامعتبر، سوءاستفاده و ارسال انبوه محافظت شود. آزمون محدودیت نرخ، کنترل دسترسی و بررسی داده‌های اجباری را بنویسید. داده‌ای که مرورگر می‌فرستد را معتبر فرض نکنید و لاگ‌ها را از اطلاعات محرمانه پاک نگه دارید.
اطلاعات موردنیاز برای ارسال را از محتوای اعلان جدا کنید. payload نباید جزئیات خصوصی غیرضروری را در اعلان قابل‌مشاهده روی صفحه قفل دستگاه قرار دهد. تست محتوا می‌تواند بررسی کند الگوی پیام برای وضعیت‌های حساس از متن عمومی‌تر استفاده می‌کند. همچنین بررسی کنید داده‌های شخصی در گزارش آزمون، فایل تصویری صفحه یا پیام خطای CI چاپ نشوند.
از secretهای آزمایشی جدا از تولید استفاده کنید و دسترسی به آن‌ها را محدود کنید. secret را در خط فرمانی که در گزارش عمومی ثبت می‌شود، URL یا فایل snapshot قرار ندهید. اگر ناچارید از credential در آزمون استفاده کنید، آن را از مخزن امن CI بخوانید، دسترسی را به job مشخص محدود کنید و دوره‌ای برای چرخش آن داشته باشید. تست پیکربندی باید شکست ایمن را نیز بررسی کند: وقتی secret وجود ندارد، ارسال تولیدی انجام نشود.
دامنه و مقصد لینک را محدود کنید. اگر سرویس‌ورکر بر پایه مقصدی می‌سازد که از پیام می‌آید، آزمون مقصد خارجی نامجاز را رد کند. اگر مقصدها در سرور تولید می‌شوند، همان سرور باید allowlist یا قواعد اعتبارسنجی روشن داشته باشد. اعتبارسنجی سمت مرورگر به‌تنهایی کنترل امنیتی کافی نیست، چون درخواست را می‌توان خارج از رابط سایت ساخت.
سناریوهای دستگاه مشترک را نیز به امنیت آزمون اضافه کنید. اگر اشتراک با حساب پیوند دارد، پس از خروج باید سیاست تعلق اعلان به حساب قبلی روشن باشد. آزمون ورود کاربر دوم، خروج کاربر اول و ارسال پیام آزمایشی را بررسی کند تا اعلان خصوصی به مخاطب نادرست نرسد. در عین حال، داده آزمایشی را به‌گونه‌ای انتخاب کنید که حتی اگر تصادفاً نمایش داده شد، هیچ اطلاعات شخصی واقعی افشا نشود.
اجرای تست‌ها در CI و انتشار
خط لوله CI را مرحله‌ای طراحی کنید. ابتدا lint و بررسی نوع داده، سپس تست واحد، بعد تست یکپارچه و در نهایت مجموعه کوچک مرورگر اجرا شود. آزمون‌هایی که به مرورگر خاص یا سرویس بیرونی وابسته‌اند می‌توانند در job مجزا و زمان‌بندی‌شده اجرا شوند. این چیدمان کمک می‌کند بازخورد سریع برای تغییرهای روزمره حفظ شود، درحالی‌که آزمون گسترده‌تر نیز به‌طور منظم انجام می‌شود.
تست‌ها را مستقل و تکرارپذیر نگه دارید. هر تست باید داده خودش را بسازد، از داده تست دیگری وابسته نباشد و در پایان پاک‌سازی کند. از ساعت ثابت یا شناسه تصادفی کنترل‌نشده پرهیز کنید؛ اگر زمان در منطق تأثیر دارد، ساعت را در تست کنترل کنید. شناسه‌های تصادفی باید در خروجی آزمون قابل‌ردیابی باشند، ولی نباید داده محرمانه باشند.
در CI عمومی از ارسال واقعی به سرویس پوش پرهیز کنید، مگر آن‌که job مجزا، اعتبارنامه محدود و مقصد آزمایشی محصور داشته باشید. اغلب نیاز نیست هر تغییر کد، پیامی به شبکه بیرونی بفرستد. برای کنترل خطای پیکربندی، تستی داشته باشید که با متغیرهای staging، endpointهای تولیدی یا شناسه مخاطب واقعی انتخاب نشوند. از سوی دیگر، آزمون واقعی staging را حذف نکنید؛ آن را با زمان‌بندی، گیرنده مشخص و اطلاع‌رسانی تیمی اجرا کنید.
برای آزمون‌های ناپایدار، صرفاً تعداد تکرار را افزایش ندهید. هر flaky test باید علت قابل‌پیگیری داشته باشد: وابستگی به تأخیر ثابت، وضعیت باقی‌مانده مرورگر، رقابت درخواست‌ها، شبکه یا محدودیت ابزار. انتظار زمانی بر مبنای رخداد یا وضعیت واقعی معمولاً از خواب ثابت قابل‌اعتمادتر است. اگر تستی موقتاً غیرفعال می‌شود، مالک و تاریخ بازبینی تعیین کنید تا استثنا به وضعیت دائمی تبدیل نشود.
گزارش CI باید شکست را قابل‌فهم کند. نام سناریو، مرورگر و نسخه، وضعیت اولیه مجوز، شناسه اجرای آزمایشی و مرحله‌ای که شکست خورده است را ثبت کنید؛ اما کلیدها و endpointهای حساس را پنهان کنید. ذخیره تصویر صفحه یا trace ممکن است برای عیب‌یابی مفید باشد، ولی باید سیاست نگهداری داشته باشد و از ثبت اطلاعات واقعی حساب جلوگیری شود.
پس از انتشار نیز تست تمام نمی‌شود. تغییر مرورگر، نسخه سرویس‌ورکر یا تنظیمات دامنه می‌تواند رفتار را عوض کند. آزمون سلامت دوره‌ای روی محیط آزمایشی و پایش خطاهای واقعی، تصویر کامل‌تری می‌دهد. آزمون مصنوعی را از پایش تولید جدا نگه دارید؛ ارسال آزمایشی در تولید تنها زمانی قابل‌قبول است که گیرنده و برچسب آن کاملاً محدود باشد و کاربران واقعی را هدف نگیرد.
معیارهای کیفیت تست
پوشش خط کد به‌تنهایی معیار کافی نیست. ممکن است درصد پوشش بالا باشد اما سناریوی مجوز ردشده، درخواست تکراری یا اشتراک منقضی اصلاً بررسی نشده باشد. به‌جای دنبال‌کردن یک عدد، فهرست ریسک و مسیرهای مهم را بسازید و مطمئن شوید برای هر ریسک آزمون متناسبی وجود دارد. پوشش کد می‌تواند علامت کمبود آزمون باشد، ولی جای ارزیابی رفتار را نمی‌گیرد.
مدت اجرای مجموعه تست را اندازه بگیرید. اگر تست انتهابهانتها بسیار کند است، مسیر بحرانی را به تعداد کمی آزمون محدود و بقیه قواعد را در سطح سریع‌تر پوشش دهید. زمان اجرا باید در کنار نرخ ناپایداری و میزان عیب‌هایی که پیش از انتشار کشف می‌شوند بررسی شود. هدف، بیشینه‌کردن شمار تست نیست؛ هدف گرفتن بازخورد قابل‌اعتماد با هزینه نگهداری معقول است.
کیفیت شکست را هم بسنجید: آیا توسعه‌دهنده از گزارش می‌فهمد کدام قرارداد نقض شده؟ آزمون‌هایی با نام‌های کلی و پیام‌های مبهم هزینه تشخیص را بالا می‌برند. نام آزمون بهتر است رفتار مورد انتظار را بیان کند؛ مانند «وقتی مجوز رد شده است، برنامه درخواست خودکار تازه نمی‌فرستد». این نام‌ها در گزارش CI هم بدون بازکردن کد معنا دارند.
با مشاهده رخدادهای پشتیبانی و خطاهای محیط واقعی، ماتریس تست را به‌روز کنید. اگر گزارش‌های تکراری نشان می‌دهند کاربران در یک نسخه مرورگر خاص با مسیر نصب مشکل دارند، آن سناریو را به آزمون مناسب اضافه کنید. اما هر گزارش را بی‌درنگ به یک تست شکننده وابسته به همان دستگاه تبدیل نکنید؛ ابتدا علت را پیدا کنید و سپس در لایه‌ای بیازمایید که همان علت را به‌طور پایدار بازتولید می‌کند.
چک‌لیست پیش از انتشار
- مسیر موفق و حالت‌های مجوز پذیرفته، ردشده و درخواست‌نشده آزموده شده‌اند.
- ثبت سرویس‌ورکر، scope و به‌روزرسانی نسخه در دامنه آزمایشی بررسی شده است.
- داده ناقص، اشتراک تکراری، لغو اشتراک و پاسخ نامعتبر سرور آزمون دارند.
- تست واحد و یکپارچه بدون ارسال پیام واقعی اجرا می‌شود.
- ارسال واقعی آزمایشی فقط به گیرنده‌های مجاز و با کلید محیط جدا انجام می‌شود.
- پاسخ پذیرفته‌شدن درخواست با دریافت قطعی یا مشاهده اعلان اشتباه گرفته نمی‌شود.
- کلیک روی اعلان به مقصد معتبر می‌رود و داده حساس در URL قرار نمی‌گیرد.
- تکرار کار، timeout و پاسخ دائمی با سیاست مشخص مدیریت می‌شوند.
- لاگ‌ها و traceها شامل کلید خصوصی، اطلاعات شخصی یا endpoint افشانشده نیستند.
- آزمون‌ها در CI مستقل، تکرارپذیر و دارای گزارش قابل‌تشخیص شکست هستند.
- مسیر ورود و خروج حساب در دستگاه مشترک و جداسازی staging از تولید بررسی شده است.
این چک‌لیست جایگزین شناخت نیاز محصول نیست. برای یک سایت محتوایی، اولویت شاید رضایت کاربر، لینک صحیح و جلوگیری از ارسال تکراری باشد؛ برای یک سامانه تراکنشی، صحت ارتباط اعلان با رخداد و محرمانگی پیام اهمیت بیشتری پیدا می‌کند. آزمون‌ها باید با نوع پیام و پیامد خطای آن متناسب باشند.
چه زمانی استفاده از سرویس آماده منطقی‌تر است؟
ساخت تست‌های خوب ارزشمند است، اما هزینه ساخت و نگهداری کل زیرساخت وب پوش را حذف نمی‌کند. تیم باید سرویس‌ورکر، ثبت اشتراک، ذخیره و پاک‌سازی endpoint، مدیریت خطاهای سرویس ارسال، امنیت کلیدها، سازگاری مرورگرها، صف و گزارش‌گیری را نیز اداره کند. اگر این کارها مستقیماً مزیت اصلی محصول شما نیستند، ممکن است صرف زمان زیاد برای بازسازی زیرساخت، توسعه قابلیت‌های اصلی را عقب بیندازد.
سرویس مدیریت‌شده می‌تواند بخشی از این پیچیدگی را کم کند و ابزارهای آماده‌تری برای ثبت اشتراک، ارسال و مدیریت کمپین فراهم آورد؛ بااین‌حال، انتخاب آن هم باید بر اساس نیاز فنی و سیاست داده باشد. پیش از تصمیم، دامنه‌های پشتیبانی‌شده، امکانات API، روش مهاجرت، گزارش‌ها، دسترسی تیمی، محل پردازش داده و پاسخ‌گویی پشتیبانی را بررسی کنید. هیچ سرویس بیرونی نیاز به آزمون رابط سایت، مقصد لینک، محتوای اعلان و تجربه کاربر را از بین نمی‌برد.
اگر می‌خواهید بخش بزرگی از پیاده‌سازی و نگهداری روزمره را ساده‌تر کنید، می‌توانید سرویس وب پوش پوشفا را بررسی کنید و آن را با معماری و نیازهای سایت خود بسنجید. بهتر است پیش از انتقال، روی دامنه آزمایشی یک مسیر محدود را اجرا کنید، سازگاری را بسنجید و سیاست دسترسی و داده را مرور کنید. در چنین حالتی هم تست خودکار همچنان ضروری است؛ با این تفاوت که آزمون‌ها بیشتر بر اتصال سایت شما به سرویس، انتخاب درست مخاطب و مقصد، کیفیت پیام و کنترل محیط تمرکز می‌کنند، نه بر بازسازی تمام اجزای زیرساخت ارسال.
برای تیمی که خود زیرساخت می‌سازد، این آزمون‌ها ابزار کاهش ریسک‌اند. برای تیمی که از سرویس آماده استفاده می‌کند، همین اصول کمک می‌کنند مطمئن شود رابط سایت، فرایند رضایت، رویدادهای کسب‌وکار و مقصد اعلان درست کار می‌کنند. در هر دو حالت، به‌جای انتظار برای گزارش کاربر، یک مسیر تکرارپذیر از تست واحد تا آزمون محدود مرورگر طراحی کنید.
پرسش‌های پرتکرار
آیا می‌توان تست خودکار را بدون ارسال واقعی وب پوش اجرا کرد؟
بله. منطق ساخت payload، اعتبارسنجی اشتراک، رفتار رابط، پردازش رویداد سرویس‌ورکر و ساخت کار صف را می‌توان با داده ساختگی یا آداپتور آزمایشی بررسی کرد. ارسال واقعی بیرونی فقط برای تعداد محدودی آزمون انتهابهانتها و به گیرنده کنترل‌شده لازم است. این دو نوع آزمون را از هم جدا کنید تا هر تغییر کوچک به شبکه بیرونی وابسته نشود.
آیا تست API موفق ثابت می‌کند اعلان به کاربر رسیده است؟
خیر. پاسخ موفق API معمولاً فقط همان مرحله‌ای را ثابت می‌کند که سامانه گزارش کرده است؛ ممکن است درخواست پذیرفته یا در صف گذاشته شده باشد. دریافت در مرورگر، نمایش اعلان و کلیک کاربر رخدادهای جداگانه‌اند و باید برای هرکدام ابزار مشاهده و تعریف دقیق داشته باشید.
چرا تست مجوز مرورگر گاهی ناپایدار می‌شود؟
اغلب به‌دلیل باقی‌ماندن وضعیت قبلی مجوز، storage یا سرویس‌ورکر، تفاوت مرورگرها، اجرای headless یا وابستگی به مکث زمانی ثابت. context مستقل، وضعیت آغازین صریح، انتظار مبتنی بر رخداد و آزمون‌های جدا برای منطق برنامه و رفتار مرورگر این ناپایداری را کم می‌کنند.
آیا همه مرورگرها باید در هر اجرای CI آزموده شوند؟
نه لزوماً. یک مجموعه سریع می‌تواند روی مرورگر اصلی اجرا شود و آزمون‌های گسترده‌تر برای مرورگرهای مهم در job زمان‌بندی‌شده یا پیش از انتشار اجرا شوند. انتخاب باید بر پایه کاربران واقعی، ریسک محصول و امکانات ابزار خودکارسازی باشد و محدودیت هر آزمون نیز مستند شود.
آیا تست خودکار نمایش اعلان روی سیستم‌عامل ممکن است؟
تا حدی می‌توان فراخوانی نمایش و گزینه‌های اعلان را بررسی کرد، اما ظاهر و رفتار نهایی به مرورگر و سیستم‌عامل وابسته است. آزمون رابط خود سیستم‌عامل معمولاً شکننده‌تر است. بهتر است ادعا را دقیق محدود کنید: کد شما داده درست را به مرحله نمایش رسانده است، نه این‌که در همه دستگاه‌ها اعلان با ظاهر یکسان دیده می‌شود.
برای آغاز، کدام تست‌ها اولویت دارند؟
ابتدا تست واحد برای اعتبارسنجی داده و وضعیت‌های مجوز بنویسید؛ سپس ثبت اشتراک، خطاهای API و جلوگیری از کار تکراری را در تست یکپارچه پوشش دهید. بعد یک مسیر مرورگر محدود برای ثبت سرویس‌ورکر و کلیک اعلان اضافه کنید. ارسال بیرونی آزمایشی را به مرحله‌ای جدا، محدود و قابل‌ردیابی موکول کنید.
نتیجه عملی این است که وب پوش را به‌جای یک قابلیت «روشن یا خاموش»، زنجیره‌ای از قراردادهای قابل‌آزمون ببینید. با جداسازی محیط‌ها، آزمون مستقل سرویس‌ورکر و مدیریت درست خطاها، بسیاری از ایرادها پیش از رسیدن به کاربر پیدا می‌شوند. اگر نمی‌خواهید همه پیچیدگی زیرساخت ارسال را خودتان پیاده‌سازی و نگهداری کنید، استفاده از پوشفا می‌تواند بخش عملیاتی کار را ساده‌تر کند؛ اما طراحی تست برای رفتار سایت و تجربه واقعی مخاطب همچنان مسئولیت مهم تیم شماست.