أتمتة الاختبارات باستخدام Playwright

اختبارات شاملة تجرّب تلقائياً مسارات مثل تسجيل الدخول والدفع والطلب في متصفح حقيقي مع كل إصدار.

نبني أتمتة اختبارات شاملة باستخدام Playwright تجرّب المسارات الحرجة في تطبيق الويب لديك داخل متصفح حقيقي مع كل إصدار، تلقائياً.

آخر تحديث:

خبرة فريقنا

هذه ليست مشاريع عملاء لـ Pepechura؛ عمل فريقنا داخل الفرق الخاصة بهذه الشركات.

Subtraid

منصة SaaS لقطاع البناء

عمل فريقنا، من داخل فريق التطوير لدى Subtraid، على أتمتة اختبارات شاملة مدعومة بالذكاء الاصطناعي ومكتوبة باستخدام Playwright وTypeScript. تُكتب الاختبارات بنمط page object وتعمل ضمن مسار CI.

ما فائدة Playwright

Playwright أداة مفتوحة المصدر لأتمتة المتصفح من تطوير Microsoft. يفتح الاختبار متصفحاً حقيقياً، ويسجّل الدخول كما يفعل المستخدم، ويملأ النماذج، وينقر على الأزرار، ثم يتحقق من ظهور النتيجة المتوقعة على الشاشة. يمكن تشغيل الاختبار نفسه على Chromium وFirefox وWebKit، وهو المحرك الذي يقوم عليه Safari. ولأن Playwright ينتظر من تلقاء نفسه حتى يصبح العنصر ظاهراً وقابلاً للنقر، فإنه يزيل منذ البداية أحد الأسباب الرئيسية للاختبارات التي «تنجح أحياناً وتفشل أحياناً».

حيث تؤتي أتمتة الاختبارات ثمارها

  • تصدر نسخاً جديدة كثيراً، وتجربة المسارات نفسها يدوياً في كل مرة تستهلك وقت الفريق
  • لديك مسارات مثل تسجيل الدخول أو الدفع أو الطلبات أو تقديم الطلبات يؤدي تعطلها مباشرة إلى خسارة العملاء
  • يرى المستخدمون الذين يدخلون بأدوار مختلفة، مثل المسؤول أو العميل أو الوكيل، شاشات مختلفة في التطبيق نفسه
  • تريد أن تعرف قبل الإطلاق ما إذا كان تغيير ما قد عطّل شاشة أخرى

حيث لا يكفي Playwright وحده

  • تطبيقات الجوال الأصلية التي تُنزّل من المتاجر: يتحكم Playwright في المتصفح، لا في التطبيق على الهاتف
  • نموذج أولي مبكر جداً تتغير واجهته بالكامل كل أسبوع؛ فتتقادم الاختبارات بسرعة كتابتها
  • اختبارات الحمل والأداء: محاكاة عدد كبير من المستخدمين المتزامنين تحتاج إلى أدوات أخرى
  • الأحكام التي تحتاج إلى عين بشرية، مثل جودة مظهر التصميم أو سهولة فهم المسار

ما الذي يُؤتمت وما الذي يُختبر يدوياً

محاولة أتمتة كل شيء تنتج مجموعة اختبارات تكلف صيانتها أكثر من كتابتها. نخصص الأتمتة للمسارات التي تتكرر مع كل إصدار ويكون تعطلها مكلفاً. أما التجربة الأولى لميزة جديدة، والاختبار الاستكشافي الذي يخرج عن السيناريو، وفحص سهولة الاستخدام، فتبقى عملاً بشرياً. في مشاريعنا يختبر مهندس ضمان جودة أول كل إصدار قبل نشره؛ والأتمتة لا تحل محل هذا الفحص، بل تعفيه من تكرار الخطوات نفسها كل أسبوع.

مناسب للأتمتةالأفضل اختباره يدوياً
المسارمسارات تبقى كما هي مع كل إصدار: تسجيل الدخول، إنشاء الحساب، الدفع، الطلب، إرسال النماذجالميزات الجديدة التي لم تستقر بعد
ما يُفحصإنشاء السجل، ورؤية الدور الصحيح للشاشة الصحيحة، وظهور رسالة الخطأوضوح النص وراحة التخطيط
متىمع كل إصدار وكل دمج للكود، تلقائياًعلى الشاشات التي تغيرت، مرة في كل إصدار
الطريقةسيناريو مكتوب مسبقاً بالخطوات نفسها في كل مرةاختبار استكشافي يجرّب الاستخدام غير المتوقع

كيف نتعامل مع الاختبارات غير المستقرة (flaky)

عندما ينجح اختبار أحياناً ويفشل أحياناً، يتوقف الفريق بعد فترة عن النظر في النتائج الحمراء وتفقد الأتمتة قيمتها. لتجنب ذلك نكتب الاختبارات منذ البداية وفق هذه القواعد:

  • بدلاً من الانتظار مدة ثابتة، ننتظر ظهور حالة محددة على الشاشة
  • نحدد العناصر بأسمائها الميسّرة أو بمعرّفات اختبار ثابتة (data-testid) تُضاف إلى الواجهة، لا بأصناف CSS قابلة للتغيير
  • يُعدّ كل اختبار بياناته بنفسه؛ ولا تعتمد نتيجة أي اختبار على بيانات تركها اختبار سابق
  • يُحفظ أثر الاختبار الفاشل (trace) ولقطة الشاشة وسياق الخطأ، فيتضح من التقرير سبب الفشل
  • الاختبار الذي ينجح عند إعادة المحاولة فقط يُبلَّغ عنه بشكل منفصل على أنه «flaky»، ويُعالج سببه الجذري كمهمة مستقلة

طبّق فريقنا هذه القواعد أثناء عمله على أتمتة اختبارات مبنية على Playwright من داخل فريق التطوير لدى Subtraid: اختبارات مكتوبة بلغة TypeScript، وبنية تضع كل شاشة في page object، وإعداد يسجّل الدخول مرة واحدة لكل دور مستخدم ويشارك الجلسة بين الاختبارات، ومسار CI يشغّل مجموعة حرجة قصيرة والمجموعة الكاملة كلاً على حدة. واستُعين في كتابة الاختبارات بوكلاء برمجة بالذكاء الاصطناعي زُوّدوا بقواعد بنية الاختبارات مكتوبة.

ما نستخدمه بجانب Playwright

TypeScript

نكتب الاختبارات باللغة نفسها التي كُتب بها التطبيق؛ فيُكتشف المحدِّد المكتوب خطأً أو المعامل الناقص قبل تشغيل الاختبار.

Page object

حقول كل شاشة وأزرارها في صنف واحد. عندما تتغير الواجهة يُحدَّث هذا الصنف وحده وتبقى السيناريوهات كما هي.

مسار CI

تعمل الاختبارات في مسار CI مثل GitHub Actions أو Bitbucket Pipelines، داخل صورة Docker الرسمية لـ Playwright؛ تعطي المجموعة الحرجة نتيجة سريعة، وتعمل المجموعة الكاملة في خطوات متوازية.

Trace Viewer

يتيح إعادة مشاهدة كل خطوة من الاختبار الفاشل وطلبات الشبكة والشاشة في تلك اللحظة، فيُعثر على السبب دون تخمين.

Faker

لتوليد بيانات اختبار جديدة وواقعية في كل تشغيل، فلا تتصادم الاختبارات في بياناتها.

وكلاء البرمجة بالذكاء الاصطناعي

في الأعمال المتكررة مثل كتابة سيناريوهات جديدة وإضافة معرّفات الاختبار إلى الواجهة، نستعين بوكلاء يعملون وفق قواعد بنية مكتوبة.

كيف يسير مشروع أتمتة الاختبارات

  1. 01

    مكالمة تعريفية مجانية

    30 دقيقة

    نتحدث عن تطبيقك، وعدد مرات إصدارك للنسخ، والمسارات التي تختبرها يدوياً اليوم.

  2. 02

    المسارات الحرجة وعرض السعر

    نرتّب المسارات الأكثر ضرراً عند تعطلها، ونكتب الأدوار والبيئة (الاختبار أو ما قبل الإنتاج) التي ستعمل عليها.

  3. 03

    إصدارات أسبوعية

    كل أسبوع تُضاف اختبارات جديدة إلى مسار CI. ترى التقرير أنت أيضاً، ونختار معاً مسارات الأسبوع التالي.

  4. 04

    المراجعة والتسليم

    يختبر مهندس ضمان جودة أول الإصدار قبل نشره. ونوثّق طريقة تشغيل الاختبارات وقراءة التقرير وقواعد إضافة اختبارات جديدة.

  5. 05

    الثلاثون يوماً بعد الإطلاق

    30 يوماً

    نصلح مجاناً الأخطاء التي تظهر في هذه الفترة. وبعدها يمكن أن يكون تحديث الاختبارات مع تغير الواجهة جزءاً من الصيانة الشهرية.

ننشر المدد ونطاقات الميزانية في صفحتي تطوير تطبيقات الويب والأسعار، وكل ما في هذه الصفحة يتبع الأرقام نفسها.

أسئلة شائعة عن أتمتة الاختبارات باستخدام Playwright

هل يمكن إضافة اختبارات Playwright إلى تطبيق قائم؟

نعم. لا يهتم Playwright بالتقنية التي بُني بها التطبيق؛ فهو يعمل مع أي تطبيق ويب يُفتح في المتصفح. وإذا لم تكن في الواجهة معرّفات اختبار ثابتة نضيفها مع الاختبارات، وهذا يتطلب الوصول إلى الكود المصدري.

لماذا Playwright وليس Selenium أو Cypress؟

الانتظار التلقائي للعناصر، وتشغيل عدة محركات متصفح عبر واجهة واحدة، وتشغيل الاختبارات بالتوازي، وتسجيل أثر الاختبارات الفاشلة، كلها مدمجة فيه. ومع ذلك، إذا كان لدى فريقك مجموعة اختبارات مستقرة على Cypress أو Selenium، فلا ننصح بإعادة كتابتها لمجرد تغيير الأداة.

هل يمكنكم اختبار تطبيقات الجوال أيضاً؟

Playwright مخصص للويب: يمكنه محاكاة أحجام شاشات متصفحات الجوال وسلوك اللمس، لكنه لا يستطيع التحكم في تطبيق أصلي يُنزّل من المتاجر. إذا كان لديك تطبيق جوال، نناقش الطريقة المناسبة له بشكل منفصل في المكالمة التعريفية.

مع وجود الأتمتة، هل ما زلت أحتاج إلى ضمان الجودة؟

نعم. تتحقق الأتمتة من أن المسارات المعروفة لم تتعطل؛ أما معرفة ما إذا كانت الميزة الجديدة مصممة بشكل صحيح، أو ما يحدث عند استخدام غير متوقع، فهو عمل بشري. في مشاريعنا يختبر مهندس ضمان جودة أول كل إصدار قبل نشره.

ماذا يبقى لديّ في نهاية المشروع؟

ترخيص استخدام دائم للبرنامج ووثائقه. وإذا أردت نقل الكود المصدري إليك فذلك ممكن مقابل رسوم إضافية تُذكر بشكل منفصل في العرض.

خدمات ذات صلة

تطوير تطبيقات الويبتطوير برمجيات مخصصةتطوير MVP
تواصل معنا

لنتحدث عن أتمتة الاختبارات

أخبرنا بالمسارات التي تختبرها يدوياً اليوم؛ وفي مكالمة تعريفية مجانية مدتها 30 دقيقة نحدد معاً أيها يستحق الأتمتة.