این صفحه قصد و رویکرد پیاده سازی چارچوب اتوماسیون e2e را در پروژه در حال انجام شما پوشش می دهد
بیایید Cypress vs Playwrit را به پایان برسانیم، زمانی که الزامات شما مشخص شود، نتیجه آشکار خواهد بود
انگیزه من برای اجرای تست E2E
به عنوان یک توسعه دهنده وب، هدف من ارائه تغییرات در تولید در سریع ترین زمان ممکن برای ارزیابی تأثیر آنها بر کاربران نهایی است. با این حال، اطمینان از کیفیت بسیار مهم است – من نمی‌خواهم به‌روزرسانی‌های باگ را منتشر کنم. در حالی که من تست‌های واحد را می‌نویسم، اثربخشی آنها اغلب به ضرب‌الاجل‌های مشخص ویژگی‌ها بستگی دارد، و آنها به آزمایش واحدهای جداگانه محدود می‌شوند.
در حال حاضر، ما به تیم QA برای انجام دستی آزمایش دود و دود در محیط‌های پایین‌تر مانند UAT متکی هستیم. با این حال، زمانی که ضرب‌الاجل دقیقی برای ویژگی‌های با اولویت بالا وجود دارد، اغلب باید منتظر بمانم تا منابع QA در دسترس قرار گیرند. این امر بازخورد را به تاخیر می اندازد و کارایی فرآیند را کاهش می دهد.
برای رسیدگی به این موضوع، وضعیت را با اعضای ارشد تیم مورد بحث قرار دادم و شروع به کار بر روی اثبات مفهوم (POC) برای پیاده‌سازی موارد تست خودکار E2E کردم.
ملاحظات کلیدی:
- پیامدهای بودجه و هزینه چارچوب اتوماسیون و اجراکننده های CI/CD.
- حفظ سرعت و کارایی خط لوله CI/CD.
- مهمتر از همه، اطمینان از اینکه تیم QA از نوشتن و نگهداری موارد آزمایشی در آینده پشتیبانی می کند.
هدف این رویکرد کاهش وابستگی به آزمایش دستی، سرعت بخشیدن به حلقه های بازخورد و بهبود بهره وری کلی است.
شکستن رویکرد من
تحقیق در مورد چارچوب های محبوب و هزینه های آنها
من بر شناسایی چارچوب هایی تمرکز کردم که معیارهای زیر را دارند:
- پشتیبانی قوی از جامعه: برای اطمینان از در دسترس بودن منابع، کمک عیب‌یابی و به‌روزرسانی‌های مداوم. پشتیبانی از مرورگر داخلی: باید شامل مرورگرهای اصلی خارج از جعبه باشد.
- قابلیت اطمینان: پوسته پوسته شدن حداقل برای قابل اعتمادتر کردن خط لوله CI/CD. پشتیبانی از اجرای موازی: برای سرعت بخشیدن به آزمایش و فعال کردن انتشار سریعتر.
- ویژگی های اشکال زدایی: فیلم ها، اسکرین شات ها و گزارش های تحلیلی را برای اشکال زدایی سریع موارد تست E2E ناموفق یا پوسته پوسته ارائه می دهد. ادغام شخص ثالث: به راحتی قابل گسترش برای ارائه دهندگان شخص ثالث برای آزمایش جامع بر روی دستگاه های مختلف، سیستم عامل ها و قابلیت های گزارش.
اجرای اثبات مفهوم (POC)
بر اساس تحقیقات انجام شده، من دو چارچوب را در فهرست نهایی قرار دادم: Cypress و Playwright. سایر چارچوب‌ها به دلیل محدودیت‌هایشان کوتاهی کردند:
عروسک گردان: فاقد پشتیبانی گسترده داخلی از مرورگر است، کمتر قابل اعتماد است و در مقایسه با Cypress و Playwright از پشتیبانی جامعه ضعیف تری برخوردار است. همچنین فاقد پشتیبانی بومی برای اجرای موازی است.
سلنیوم: اگرچه قوی است، اما منحنی یادگیری تندتری دارد و به تلاش قابل توجهی برای راه اندازی اولیه و اجرای موازی نیاز دارد، که باعث می شود در مقایسه با گزینه های جایگزین، کارایی کمتری داشته باشد.
نتایج POC
نتایج تحلیلی POC نقاط قوت و ضعف چارچوب های فهرست کوتاه را برجسته می کند و تصمیم گیری برای مناسب ترین راه حل تست E2E را راهنمایی می کند.
خلاصه
بر اساس تجزیه و تحلیل بالا، نتایج منفی به طور قابل توجهی (که با رنگ های قرمز مشخص می شود) با سرو در مقایسه با نمایشنامه نویس وجود دارد. در نتیجه، من Playwright را به عنوان چارچوب تست E2E خود انتخاب کردم، که برای برآورده کردن نیازهای خاص ما طراحی شده است.
یکی از ویژگی های برجسته Playwright ابزار تولید کد E2E است که یک تغییر دهنده بازی است. این امر باعث می‌شود که تیم QA ما به‌طور باور نکردنی آزمایش‌های E2E را تولید کرده و با حداقل تغییرات در خط لوله تولید ادغام کند. این منحنی یادگیری را برای تیم QA کاهش می دهد و همکاری بهتری را بین QA و توسعه دهندگان تقویت می کند – یک موقعیت برد-برد واقعی.
در حالی که تیم QA ما همچنان به ایفای نقش حیاتی خود ادامه می دهد، استفاده از Playwright به طور قابل توجهی قابلیت اطمینان تست های ما و سرعت عرضه در خط لوله تولید را بهبود بخشیده است.
