الاختبار البصري (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، دقة الشاشة)، مما يقلل بشكل كبير من الإيجابيات الخاطئة الناتجة عن اختلافات البيئة بين مراحل التطوير. نحن في Delta-QA نستخدم 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 في مشاريعنا. التكامل مع 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 الخاصة بك مباشرة. نمط شائع وفعّال:
- build — تجميع التطبيق
- deploy-review — نشر Review App
- test-visual — الاختبار البصري على Review App
- cleanup — حذف البيئة
تتيح توجيهة needs في GitLab CI إنشاء اعتماديات صريحة ومباشرة بين المهام دون المرور بالمراحل المتتالية، مما يمكن أن يسرّع pipeline الخاص بك بشكل ملحوظ.
متغيرات البيئة المحمية
يجب تخزين رموز API الخاصة بالخدمات السحابية (Percy، Chromatic) كمتغيرات CI/CD آمنة في GitLab. انتبه جيداً: المتغيرات المحمية متاحة فقط على الفروع المحمية والمحددة. إذا لم تكن فروع الميزات (feature branches) الخاصة بك محمية، فسيفشل الاختبار البصري مع خدمة سحابية بصمت وبدون أي رسالة خطأ واضحة — وهذا فخ كلاسيكي يقع فيه الكثيرون.
حدود الوقت والذاكرة
الاختبار البصري هو عملية تستهلك موارد حاسوبية كثيرة وكبيرة. عرض الصفحات وتقديمها في متصفح headless يستهلك قدراً كبيراً من الذاكرة، ومقارنة الصور بدقة عالية تستغرق وقتاً ملحوظاً. runners المشتركة في GitLab.com لديها حدود زمنية صارمة (عادة ساعة واحدة كحد أقصى لكل مهمة) وحدود ذاكرة محددة. لمجموعات اختبار بصري كبيرة تشمل عشرات الصفحات أو أكثر، يُوصى بشدة بـ runners ذاتية الإدارة بموارد مخصصة ومرنة.
بناء Pipeline اختبار بصري متين
إليك المقاربة التي نوصي بها، بناءً على تجربتنا الخاصة.
ابدأ صغيراً ومركّزاً
لا تختبر بصرياً جميع صفحاتك ومكوناتك من اليوم الأول. حدد الخمس إلى عشر صفحات الأكثر أهمية والأكثر عرضة للتغيير — تلك التي يراها المستخدمون أولاً عند زيارة التطبيق، تلك التي يكون للانحدار البصري فيها أكبر تأثير سلبي على الأعمال والسمعة. ثم وسّع نطاق الاختبار تدريجياً وبشكل مدروس.
استخدم Review Apps كهدف
بدلاً من تشغيل خادم محلي مؤقت في مهمة CI الخاصة بك، انشر Review App كاملة واختبرها على النشر الفعلي. الميزة الرئيسية: البيئة مستقرة ومتاحة للجميع وممثلة للإنتاج. العيب الوحيد: تضيف مدة النشر الإضافية إلى إجمالي وقت pipeline. المقايضة تستحق ذلك تماماً على المدى الطويل.
استقرّ بيئة العرض الخاصة بك
أنشئ صورة Docker مخصصة ومحسّنة للاختبار البصري، مخزنة في سجل حاويات GitLab الخاص بك. ضمّن جميع الخطوط المستخدمة في تطبيقك، والنسخة الدقيقة من المتصفح بدون أي تفاوت، وجميع اعتماديات النظام الأساسية. أدر إصدارات هذه الصورة بدقة مع كل تحديث. عندما تكون بيئة العرض ثابتة ومجمّدة، تنخفض الإيجابيات الخاطئة بشكل كبير وملحوظ.
ابدأ في وضع غير حاجب
كوّن مهمة الاختبار البصري بـ allow_failure: true خلال الأسابيع الأولى من التبني. هذا يسمح لفريقك بالتعرف على النتائج والتعود عليها تدريجياً دون أن يحجب الاختبار البصري merge requests أو يبطئ عملية الدمج. بمجرد تأسيس الثقة الكافية والسيطرة الفعلية على الإيجابيات الخاطئة، انتقل إلى الوضع الحاجب (blocking mode) لتعزيز الحماية.
أشعر بذكاء
يمكن لـ GitLab CI إرسال إشعارات تلقائية عبر قنوات مختلفة ومتعددة (Slack، البريد الإلكتروني، webhook مخصص). كوّن إشعارات الاختبار البصري بحيث تُنبّه وتنبه فريقك فقط عند الإخفاقات الفعلية — وليس عند النجاحات الروتينية. الهدف الذكي هو جذب الانتباه عند الحاجة الفعلية فقط، لا إغراق فريقك بالرسائل غير الضرورية التي تؤدي في النهاية إلى تجاهل كل شيء.
الأسئلة الشائعة
هل GitLab CI بنفس جودة GitHub Actions للاختبار البصري؟
بالنسبة للاختبار البصري تحديداً، يتمتع GitLab CI بمزايا أصلية واضحة: القطع الأثرية المدمجة مباشرة في واجهة MR، وReview Apps المؤقتة، وسجل الحاويات الجاهز، وrunners ذاتية الإدارة القابلة للتخصيص الكامل. هذه الميزات تسهّل بشكل كبير إعداد بيئة اختبار بصري مستقرة وقابلة للتكرار بثقة. لدى GitHub Actions سوق غني ومتنوع خاص به، لكن بعض هذه الميزات الأساسية تتطلب تكوينات إضافية معقدة.
هل تحتاج إلى runners ذاتية الإدارة للاختبار البصري في GitLab CI؟
ليس إلزامياً بالمعنى التقني، لكنه موصى به بشدة في الممارسة العملية. runners المشتركة في GitLab.com تعمل وتؤدي المهمة، لكن تكوين أجهزتها المتغير وغير المتوقع قد يُدخل اختلافات طفيفة في العرض تتحول إلى إيجابيات خاطئة مزعجة. runner ذاتي الإدارة بتكوين ثابت ومجمد (الخطوط، المتصفح، الدقة، إعدادات GPU) يزيل مصدر الإيجابيات الخاطئة هذا تماماً ويقدم عادةً أداءً أفضل وأسرع.
كيف تدير 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 الخاص بك.