Visual Testing في GitLab CI: دمج الاختبار البصري في Pipelines الخاصة بك

الاختبار البصري (visual testing) هو طريقة تحقق آلية تقارن لقطات شاشة لواجهة ويب بين نسختين لاكتشاف الانحدارات الرسومية — عنصر منزاح، لون متغير، مكوّن يتجاوز حدود حاويته.

نحن نستخدم GitLab يومياً في Delta-QA. مستودعاتنا، وpipelines الخاصة بنا، وmerge requests الخاصة بنا، وCI/CD الخاص بنا — كل شيء يعمل على GitLab. هذا ليس اختياراً افتراضياً: إنه اختيار مدروس لمنصة توفر pipeline متكاملاً بشكل أصلي، وسجل حاويات، وفلسفة DevOps متسقة من البداية إلى النهاية.

عندما نتحدث عن الاختبار البصري في GitLab CI، فنحن لا نعيد ترديد توثيق قرأناه بالأمس. نحن نشارك ما تعلمناه من خلال الاستخدام الفعلي. يغطي هذا المقال المقاربات المتاحة، وخصوصيات GitLab CI التي تؤثر على الاختبار البصري، وكيفية تحقيق pipeline موثوق للانحدار البصري.

لماذا يناسب GitLab CI الاختبار البصري

يتمتع GitLab CI بخصائص تجعله مناسباً بشكل خاص للاختبار البصري — خصائص لا يمتلكها مستخدمو GitHub Actions أو Jenkins بشكل افتراضي.

القطع الأثرية الأصلية (Artifacts)

يدير GitLab CI بشكل أصلي قطع pipeline الأثرية. عندما ينتج اختبار بصري تقارير HTML أو صور diff أو لقطات شاشة، تُعلنها كقطع أثرية وتكون متاحة مباشرة من واجهة merge request. لا حاجة لخدمة خارجية لتخزين النتائج والاطلاع عليها.

هذه ميزة يُقلّل من شأنها. مع GitHub Actions، تحتاج إلى تكوين رفع قطع أثرية منفصل أو استخدام خدمة طرف ثالث لجعل النتائج متاحة. مع GitLab، الأمر أصلي.

بيئات المراجعة

يقدم GitLab ما يُعرف بـ Review Apps: بيئات مؤقتة تُنشر تلقائياً لكل merge request. تطبيقك يعمل في بيئة مخصصة، متاحة عبر URL مؤقت. هذه البيئة المثالية للاختبار البصري: مستقرة ومعزولة وممثلة للإنتاج.

الـ Runners ذاتية الإدارة

يتيح GitLab استخدام runners مستضافة على بنيتك التحتية الخاصة. بالنسبة للاختبار البصري، هذا أمر بالغ الأهمية: أنت تتحكم في بيئة العرض (نظام التشغيل، الخطوط، GPU)، مما يقلل من الإيجابيات الخاطئة الناتجة عن اختلافات البيئة. نحن نستخدم runners مخصصة بتكوين ثابت لضمان إمكانية إعادة إنتاج اللقطات.

سجل الحاويات المدمج

كل مشروع GitLab لديه سجل حاويات. يمكنك تخزين صورة Docker مُعدّة مسبقاً للاختبار البصري — بالخطوط الصحيحة والمتصفح الصحيح والاعتماديات الصحيحة — واستخدامها كقاعدة لمهام الاختبار الخاصة بك. هذا يزيل مصدراً رئيسياً لعدم الاستقرار.

مقاربات الاختبار البصري في GitLab CI

Playwright في مهمة GitLab CI

Playwright هو أقوى أداة open source للاختبار البصري في CI. طريقته الأصلية toHaveScreenshot() تدير الالتقاط والمقارنة وإعادة المحاولات التلقائية.

التكامل مع GitLab CI. تُنشئ مهمة في ملف .gitlab-ci.yml تستخدم صورة Docker الرسمية لـ Playwright، وتُنفّذ اختباراتك، وتنشر النتائج كقطع أثرية. تقارير HTML الخاصة بـ Playwright يمكن الاطلاع عليها مباشرة في GitLab.

بخصوص البنية الدقيقة لملف YAML، اسأل مساعدك الذكي — فهو جيد جداً في صياغة GitLab CI، وهذا تقريباً الشيء الوحيد الذي لا يهلوس فيه (حتى الآن). بجدية أكثر، التوثيق الرسمي لـ Playwright لبيئات CI هو أفضل مرجع لك.

ما يعمل بشكل جيد. صورة Docker الرسمية لـ Playwright تتضمن جميع المتصفحات واعتماديات النظام المطلوبة. بالاقتران مع سجل حاويات GitLab، يمكنك إنشاء صورة مشتقة بخطوطك وتكويناتك الخاصة. قطع GitLab الأثرية تجعل تقارير الاختبار متاحة دون تكوين إضافي.

القيود في سياق GitLab. يجب إنشاء الـ baselines في بيئة CI، وليس محلياً. هذه قاعدة عالمية في الاختبار البصري، لكن GitLab يسهّل الأمور: يمكنك تشغيل pipeline يدوياً لإعادة إنشاء الـ baselines. إدارة الـ baselines في Git تبقى تحدياً (ملفات ثنائية، تعارضات merge)، لكن GitLab LFS مدمج بشكل أصلي.

Percy مع GitLab CI

يقدم Percy (BrowserStack) تكاملاً رسمياً مع GitLab CI. يلتقط SDK الخاص بـ Percy اللقطات أثناء pipeline الخاص بك ويرسلها إلى سحابة Percy للمقارنة والمراجعة.

ما يعمل. يكتشف Percy تلقائياً الفرع وmerge request في GitLab. تظهر النتائج كحالة خارجية على MR الخاصة بك. اختبار المتصفحات المتعددة يُدار من جانب السحابة.

القيود. التسعير لكل لقطة يبقى موضوعاً مهماً. وأنت تضيف اعتمادية خارجية إلى pipeline الخاص بك — إذا كان Percy غير متاح، تبقى عملية التحقق معلّقة. لفريق اختار GitLab تحديداً للتحكم في بنيته التحتية، هذه الاعتمادية الخارجية قد تتناقض مع الفلسفة.

BackstopJS في GitLab CI

يعمل BackstopJS في GitLab CI عبر صورته Docker الرسمية. تقارير HTML مناسبة تماماً لنظام القطع الأثرية في GitLab.

ما يعمل. تقرير HTML الخاص بـ BackstopJS هو من أكثر التقارير بصرية وقابلية للقراءة في المنظومة. منشوراً كقطعة أثرية في GitLab، يمكن الاطلاع عليه مباشرة في المتصفح من واجهة MR. التكوين عبر سيناريوهات JSON واضح وقابل للتحكم بالإصدارات.

القيود. مرّ المشروع بفترات صيانة متقطعة — تحقق من النشاط الأخير قبل الالتزام به. قد يصبح التكوين مطوّلاً للتطبيقات المعقدة، وعليك إدارة التكرار على صفحاتك أو مكوناتك يدوياً.

Delta-QA: تكامل أصلي مع GitLab CI

بنينا Delta-QA أثناء استخدام GitLab CI يومياً. التكامل ليس فكرة لاحقة — إنه حالة استخدام من الدرجة الأولى.

كيف يعمل. يندمج Delta-QA في pipeline GitLab CI الخاص بك كمهمة مخصصة. يلتقط صفحاتك، ويقارن مع المراجع، ويُبلّغ عن النتائج. الاختلافات المكتشفة مرئية في واجهة مراجعة مخصصة، مع رابط مباشر من merge request الخاصة بك.

ما يختلف. لا سكريبتات اختبار لكتابتها أو صيانتها. لا baselines لتخزينها في مستودعك. لا إيجابيات خاطئة بسبب اختلافات البيئة بين جهازك وrunner CI. الأداة تدير استقرار العرض داخلياً.

ميزة GitLab. يستفيد Delta-QA من خصوصيات GitLab CI: Review Apps كهدف للالتقاط، والقطع الأثرية للتقارير المفصلة، وwebhooks GitLab لتشغيل الاختبارات في اللحظة المناسبة من pipeline.

خصوصيات GitLab CI التي يجب معرفتها للاختبار البصري

الكاش مقابل القطع الأثرية

هذا تمييز يخلط كثيرون بينهما. الكاش في GitLab CI مشترك بين pipelines المشروع نفسه — يُستخدم لتسريع المهام (اعتماديات npm، متصفحات Playwright). القطع الأثرية هي مخرجات مهمة محددة — تقارير الاختبار، لقطات الشاشة، الفروقات.

للاختبار البصري، استخدم الكاش للمتصفحات والاعتماديات، والقطع الأثرية لنتائج الاختبار. لا تقم أبداً بتخزين الـ baselines في الكاش — يجب أن تعيش في المستودع لتكون مُصدّرة مع الكود.

المراحل والاعتماديات بين المهام

ينظم GitLab CI المهام في مراحل (stages) متتالية. يجب أن يكون الاختبار البصري في مرحلة تُنفّذ بعد نشر Review App الخاصة بك. نمط شائع:

1. build — تجميع التطبيق
2. deploy-review — نشر Review App
3. test-visual — الاختبار البصري على Review App
4. cleanup — حذف البيئة

تتيح توجيهة needs في GitLab CI إنشاء اعتماديات صريحة بين المهام دون المرور بالمراحل المتتالية، مما يمكن أن يسرّع pipeline الخاص بك.

متغيرات البيئة المحمية

يجب تخزين رموز API للخدمات السحابية (Percy، Chromatic) كمتغيرات CI/CD في GitLab. انتبه: المتغيرات المحمية متاحة فقط على الفروع المحمية. إذا لم تكن فروع الميزات الخاصة بك محمية، فسيفشل الاختبار البصري مع خدمة سحابية بصمت — فخ كلاسيكي.

حدود الوقت والذاكرة

الاختبار البصري يستهلك موارد كثيرة. عرض الصفحات في متصفح headless يستهلك الذاكرة، ومقارنة الصور تستغرق وقتاً. runners المشتركة في GitLab.com لديها حدود زمنية (عادة ساعة واحدة لكل مهمة) وحدود ذاكرة. لمجموعات اختبار بصري كبيرة، يُوصى بـ runners ذاتية الإدارة بموارد مخصصة.

بناء Pipeline اختبار بصري متين

إليك المقاربة التي نوصي بها، بناءً على تجربتنا الخاصة.

ابدأ صغيراً ومركّزاً

لا تختبر بصرياً جميع صفحاتك من اليوم الأول. حدد الخمس إلى عشر صفحات الأكثر أهمية — تلك التي يراها المستخدمون أولاً، تلك التي يكون للانحدار البصري فيها أكبر تأثير على الأعمال. ثم وسّع تدريجياً.

استخدم Review Apps كهدف

بدلاً من تشغيل خادم محلي في مهمة CI الخاصة بك، انشر Review App واختبرها. الميزة: البيئة مستقرة ومتاحة وممثلة. العيب: تضيف مدة النشر إلى pipeline. المقايضة تستحق.

استقرّ بيئة العرض الخاصة بك

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

ابدأ في وضع غير حاجب

كوّن مهمة الاختبار البصري بـ allow_failure: true خلال الأسابيع الأولى. هذا يسمح لفريقك بالتعرف على النتائج دون أن يحجب الاختبار البصري merge requests. بمجرد تأسيس الثقة والسيطرة على الإيجابيات الخاطئة، انتقل إلى الوضع الحاجب.

أشعر بذكاء

يمكن لـ GitLab CI إرسال إشعارات عبر قنوات مختلفة (Slack، البريد الإلكتروني، webhook). كوّن إشعارات الاختبار البصري بحيث تُنبّه فقط عند الإخفاقات — وليس عند النجاحات. الهدف هو جذب الانتباه عند الحاجة، لا إغراق فريقك بالرسائل.

الأسئلة الشائعة

هل GitLab CI بنفس جودة GitHub Actions للاختبار البصري؟

بالنسبة للاختبار البصري تحديداً، يتمتع GitLab CI بمزايا أصلية: القطع الأثرية المدمجة، وReview Apps، وسجل الحاويات، وrunners ذاتية الإدارة. هذه الميزات تسهّل إعداد بيئة اختبار بصري مستقرة وقابلة للتكرار. لدى GitHub Actions سوق غني خاص به، لكن بعض هذه الميزات تتطلب تكوينات إضافية.

هل تحتاج إلى runners ذاتية الإدارة للاختبار البصري في GitLab CI؟

ليس إلزامياً، لكنه موصى به بشدة. runners المشتركة في GitLab.com تعمل، لكن تكوين أجهزتها المتغير قد يُدخل اختلافات في العرض. runner ذاتي الإدارة بتكوين ثابت (الخطوط، المتصفح، الدقة) يزيل مصدر الإيجابيات الخاطئة هذا ويقدم عادةً أداءً أفضل.

كيف تدير baselines الاختبار البصري في مستودع GitLab؟

إذا كنت تستخدم Playwright أو BackstopJS، فإن الـ baselines (ملفات PNG) تعيش في مستودعك. فعّل GitLab LFS لمنع الملفات الثنائية من تضخيم تاريخ Git. لتعارضات merge على الـ baselines، الاستراتيجية الأبسط هي قبول الـ baselines الجديدة من الفرع المصدر وإعادة الإنشاء إذا لزم الأمر. مع Delta-QA، تُدار الـ baselines بواسطة الأداة ولا تلوّث مستودعك.

هل يمكن استخدام Review Apps في GitLab كبيئة اختبار بصري؟

نعم، وهذه هي المقاربة التي نوصي بها. توفر Review App بيئة مستقرة ومعزولة لكل merge request. مهمة الاختبار البصري تنتظر نشر Review App، وتلتقط لقطات الشاشة على URL المؤقت، وتقارن مع المراجع. هذا أكثر موثوقية من خادم يُشغّل بسرعة في مهمة CI.

هل يعمل الاختبار البصري في GitLab CI مع المستودعات الأحادية (monorepos)؟

نعم. يدعم GitLab CI قواعد شرطية تسمح بتشغيل الاختبار البصري فقط إذا تم تعديل ملفات الواجهة الأمامية. بالاقتران مع توجيهة only:changes، تتجنب تشغيل اختبارات بصرية غير ضرورية عندما يتغير الخلفية فقط. هذا ضروري للحفاظ على pipeline سريع في مستودع أحادي.

ما هي أفضل صورة Docker للاختبار البصري في GitLab CI؟

صورة Playwright الرسمية (mcr.microsoft.com/playwright) هي نقطة انطلاق ممتازة. تتضمن المتصفحات واعتماديات النظام. لبيئة أكثر استقراراً، أنشئ صورة مشتقة تضيف خطوط تطبيقك وتثبّت الإصدارات الدقيقة. خزّنها في سجل حاويات مشروع GitLab الخاص بك للوصول السريع.

الخلاصة

GitLab CI هو منصة مناسبة بشكل طبيعي للاختبار البصري. ميزاته الأصلية — القطع الأثرية، وReview Apps، وسجل الحاويات، وrunners ذاتية الإدارة — تحل مشاكل تتطلب منصات CI الأخرى التعامل معها يدوياً.

لكن المنصة لا تفعل كل شيء. يبقى الاختبار البصري في CI تحدياً هندسياً: استقرار العرض، وإدارة الـ baselines، ومعالجة الإيجابيات الخاطئة، وبناء سير عمل مراجعة يعمل للفريق بأكمله.

إذا كنت على GitLab وتريد إضافة الاختبار البصري إلى pipeline الخاص بك دون تعقيد سكريبتات الاختبار وإدارة الـ baselines اليدوية، فإن Delta-QA مصمم للتكامل بشكل أصلي في سير عمل GitLab CI الخاص بك.

جرّب Delta-QA مجاناً ←