الاختبار البصري في GitLab CI/CD هو دمج خطوة مؤتمتة لالتقاط ومقارنة لقطات الشاشة ضمن pipeline معرّف في ملف .gitlab-ci.yml، مستفيداً من artifacts لتخزين اللقطات ومن environments لوضع النتائج في سياقها المناسب، بهدف اكتشاف أي تراجع بصري قبل قبول merge request. هذه العملية تضمن أن كل تغيير في واجهة المستخدم يمر عبر فحص بصري منهجي قبل أن يصل إلى الإنتاج.
GitLab CI/CD هو المنافس المباشر لـ GitHub Actions في سوق أنظمة التكامل والتسليم المستمر. إذا اخترت GitLab لمجموعتك التقنية — وملايين الفرق حول العالم فعلت ذلك بالفعل — فلديك نظام CI/CD أصلي قوي، مدمج بعمق مع مدير الكود الخاص بك. وهذا النظام يمتلك ميزات فريدة تجعله مناسباً بشكل خاص للاختبار البصري، أكثر مما قد تظن.
ومع ذلك، كم عدد ملفات .gitlab-ci.yml التي تتضمن فعلاً خطوة تحقق بصري؟ قليلة جداً. الأغلبية الساحقة من الفرق تكتفي بالبناء واختبار الكود وظيفياً والنشر. مظهر التطبيق — أي ما يراه المستخدم فعلاً عندما يفتح الموقع — لا يُتحقق منه إلا يدوياً، إن تم التحقق أصلاً. هذا يعني أن أخطاء CSS وتخطيطات مكسورة وعناصر متداخلة يمكن أن تعبر الـ pipeline دون أن يلتقطها أي اختبار.
موقفنا: GitLab CI مثالي للاختبار البصري، بفضل artifacts وenvironments. هاتان الميزتان، اللتان غالباً ما تكونان مستغلتين بشكل ناقص من قبل معظم الفرق، توفران بنية تحتية مثالية لتخزين لقطات الشاشة ومقارنة النتائج بين الفروع المختلفة ووضع التراجعات البصرية في سياقها. إذا كنت تستخدم GitLab ولا تجري اختبارات بصرية بعد، فأنت تترك إمكانات حقيقية لـ pipeline الخاص بك نائمة دون استثمارها.
ما يقدمه GitLab CI تحديداً للاختبار البصري
يمتلك GitLab CI ميزات لا يقدمها منافسوه — أو لا يقدمونها بنفس الجودة والعمق. للاختبار البصري، ثلاث من هذه الميزات قيّمة بشكل خاص وتمنحه ميزة تنافسية واضحة.
الـ Artifacts: مكتبة لقطات الشاشة الخاصة بك
تسمح artifacts في GitLab CI بحفظ الملفات التي ينتجها أي job وجعلها متاحة للتنزيل والتصفح بعد انتهاء تنفيذ الـ pipeline بالكامل. للاختبار البصري، هذا بالضبط ما تحتاجه: آلية موثوقة لحفظ كل لقطة شاشة ملتقطة خلال عملية الاختبار.
كل تنفيذ للـ pipeline ينتج مجموعة من لقطات الشاشة. هذه اللقطات يجب الاحتفاظ بها لسببين أساسيين. أولاً، لكي يتمكن الفريق من مراجعتها بصرياً عندما يفشل أحد الاختبارات، حتى يفهموا طبيعة التراجع المكتشف. ثانياً، لتكون مراجع أساسية للمقارنات المستقبلية مع عمليات التشغيل اللاحقة.
تقدم artifacts في GitLab إدارة دقيقة لفترة الاحتفاظ بالملفات. يمكنك الاحتفاظ بلقطات الشاشة لآخر سبعة أيام فقط، أو تمديد الفترة إلى ثلاثين يوماً للفرع الرئيسي الذي يحتاج مراجع مستقرة. يمكنك تحميلها مباشرة من واجهة GitLab على الويب، أو تصفحها عبر متصفح artifacts المدمج الذي يعرض الملفات بشكل هرمي واضح.
الـ Environments: وضع لقطاتك في سياقها
تسمح environments في GitLab بربط عملية deploy مع سياق مسمى ومحدد (مثل staging أو production أو review/feature-xyz). للاختبار البصري، هذا يعني أن كل مجموعة لقطات شاشة مرتبطة ببيئة محددة ومعروفة، مما يسهل تتبع مصدرها والتحقق منها.
عند نشر فرع feature إلى بيئة مراجعة، تكون لقطات الشاشة الملتقطة مرتبطة تلقائياً بذلك الـ environment. يمكنك بعد ذلك مقارنة لقطات بيئة المراجعة مع لقطات بيئة الـ staging أو بيئة الإنتاج، للتحقق من أن كل شيء يبدو كما هو متوقع. هذا مستوى من التتبع والسياقية لا تقدمه سوى أنظمة CI/CD قليلة بشكل أصلي.
متصفح artifacts المدمج
يقدم GitLab متصفح ملفات مدمجاً مباشرة في واجهة الويب لاستكشاف وتصفح artifacts. للاختبار البصري، هذا يعني أن فريقك بأكمله يمكنه مراجعة لقطات الشاشة والفروقات البصرية وتقارير المقارنة دون الحاجة لمغادرة GitLab أو فتح أي أداة خارجية. لا حاجة لفتح أداة طرف ثالث. لا رابط خارجي لمتابعته. كل شيء متاح في نفس النظام البيئي الموحد.
مشكلة الـ Pipelines العمياء بصرياً
لنراجع الحقائق بصراحة. pipeline GitLab CI النموذجي ينفذ المراحل التالية بالترتيب: lint، اختبار وحدة، اختبار تكامل، build، deploy. خمس مراحل متتالية. صفر تحقق بصري. هذا هو الوضع السائد في أغلبية المشاريع.
هذا الـ pipeline قادر على إخبارك بوضوح إذا كانت دالة في كودك تعيد نتيجة خاطئة. لكنه غير قادر أبداً على إخبارك إذا كان نصف صفحتك الرئيسية مخفياً خلف مكون موضوع بشكل خاطئ أو إذا كان زر الدعوة للإجراء غير مرئي على الشاشات الصغيرة.
إليك ما يحدث في الحياة الواقعية بشكل متكرر. مطور يعدل ملف CSS مشترك بين عدة صفحات. التغيير يبدو بسيطاً: تعديل هامش صغير على مكون واحد. الـ pipeline يمر بنجاح. الـ merge request يُوافق عليه من قبل مراجع قرأ الـ diff النصي دون أن يتصور العرض الفعلي في المتصفح. يتم الـ merge وتُنشر التغييرات.
بعد ثلاثة أيام، عميل يبلغ أن صفحة التسعير غير قابلة للقراءة على الهاتف المحمول. الهامش المعدّل نشر تأثيراً متتالياً غير متوقع على تخطيط flexbox مستخدم من ست صفحات أخرى. لم يره أحد لأن لا أحد نظر — لا الإنسان ولا الـ pipeline. كانت المشكلة موجودة لكن لا أداة التقطتها.
الاختبار البصري المؤتمت هو الحل النظامي والشامل لهذه المشكلة. ليس مراجعة كود أكثر انتباهاً من المطور. ليس اختباراً يدوياً أكثر دقة من فريق QA. بل اختبار مؤتمت، يعمل داخل الـ pipeline، يقارن الصور قبل وبعد كل تغيير ويشير فوراً إلى أي اختلاف بصري مهما كان صغيراً.
تهيئة الاختبار البصري في .gitlab-ci.yml
تتبع تهيئة pipeline اختبار بصري في GitLab CI منطقاً مرحلياً محدداً جيداً وسهلة المتابعة. إليك البنية المفاهيمية الكاملة لملف .gitlab-ci.yml الخاص بك عند إضافة الاختبار البصري.
بنية الـ Pipeline
يجب أن يتضمن pipeline الخاص بك المراحل التالية، بهذا الترتيب الدقيق، لضمان عمل سليم ومنطقي.
مرحلة build. تجمّع تطبيقك وتجعله جاهزاً للخدمة والتشغيل. هذه المرحلة موجودة بالفعل في أغلبية الـ pipelines.
مرحلة الاختبار البصري. هذه هي المرحلة الجديدة التي تُضاف. تشغل خادماً محلياً، تلتقط لقطات الشاشة لكل صفحة، تقارنها بالمراجع المخزنة مسبقاً، وتنتج تقريراً مفصلاً بالنتائج. يجب أن تُنفذ هذه المرحلة بعد الـ build مباشرة، ويجب تخزين نتائجها كاملة كـ artifacts.
مرحلة deploy. تُنفذ فقط إذا نجحت جميع الاختبارات السابقة — بما فيها الاختبار البصري. هذا يضمن أن ما يصل للمستخدم النهائي مراجع بصرياً.
تبعيات job الاختبار البصري
يحتاج job الاختبار البصري إلى متصفح headless لالتقاط لقطات الشاشة بشكل آلي. في GitLab CI لديك خياران رئيسيان. الخيار الأول هو استخدام صورة Docker تتضمن Chromium بالفعل (مثل صور Playwright الرسمية الجاهزة). الخيار الثاني هو تثبيت Chromium يدوياً في الـ job عبر أوامر before_script.
صورة Docker هي الخيار الأفضل بلا منازع. قابلة للتكرار عبر جميع التشغيلات، سريعة لأنها لا تحتاج لتثبيت في كل مرة، وتضمن إصداراً ثابتاً ومحدداً من المتصفح مما يضمن نتائج متسقة.
تخزين النتائج
يجب أن ينتج job الاختبار البصري عدة أنواع من الملفات وتخزينها كـ artifacts. أولاً: لقطات الشاشة الملتقطة خلال هذا التشغيل الحالي. ثانياً: الفروقات البصرية التي تظهر الاختلافات المكتشفة بين المرجع والحالة الحالية. ثالثاً: تقرير HTML أو JSON يلخص جميع النتائج بشكل منظم.
اضبط سياسة احتفاظ مناسبة لكل نوع من الملفات. لقطات شاشة الفرع الرئيسي يجب أن تُحتفظ بها لفترة أطول لأنها تخدم كمراجع أساسية لجميع المقارنات اللاحقة. لقطات شاشة فروع feature يمكن الاحتفاظ بها لبضعة أيام فقط، طالما أن الـ merge request قيد المعالجة.
شرط الحجب
يجب تهيئة job الاختبار البصري كـ job حاجب إلزامي. إذا اكتُشفت اختلافات بصرية غير معتمدة، يجب أن يفشل الـ pipeline فوراً وبتأكيد. بدون تحذير مرن. بدون خيار "continue on failure". فشل صريح وواضح يمنع الـ merge حتى يتم حل المشكلة البصرية.
الاستفادة من Artifacts للقطات الشاشة
artifacts في GitLab CI هي الركيزة الأساسية لاستراتيجية الاختبار البصري الخاصة بك. إليك كيفية الاستفادة منها لأقصى حد ممكن وبأفضل الممارسات.
هيكلة artifacts بشكل قابل للقراءة
نظّم لقطات شاشتك في شجرة واضحة ومنظمة ضمن artifacts. أنشئ مجلداً منفصلاً لكل صفحة مختبرة، يحتوي على ثلاثة عناصر: لقطة الشاشة المرجعية، ولقطة الشاشة الحالية، وصورة الفرق البصري بينهما. تقرير HTML في الجذر يسمح بالتنقل السلس بين نتائج جميع الصفحات.
هذه البنية المنظمة تسهل المراجعة بشكل كبير. عند فشل اختبار معين، يفتح المراجع متصفح artifacts، ينتقل إلى مجلد الصفحة المتأثرة، ويرى الفرق البصري فوراً دون عناء البحث.
استخدام artifacts كمراجع
يمكن أن تخدم artifacts الفرع الرئيسي كمراجع أساسية لمقارنات فروع feature. يسمح GitLab CI بتحميل artifacts من job محدد على فرع محدد عبر واجهة البرمجة API.
عملياً، يبدأ job الاختبار البصري لفرع feature الخاص بك بتحميل لقطات الشاشة المرجعية من artifacts آخر pipeline ناجح على الفرع الرئيسي. ثم يلتقط لقطات شاشة جديدة لفرع feature بالكامل. يقارن المجموعتين من اللقطات ويُنتج تقريراً بالفروقات. يخزن النتائج كاملة كـ artifacts للـ pipeline الحالي لمراجعتها.
إدارة الاحتفاظ بذكاء
لـ artifacts في GitLab مدة احتفاظ قابلة للتهيئة بمرونة. للاختبار البصري، سياسة من مستويين تعمل بشكل ممتاز. artifacts الفرع الرئيسي تُحتفظ بها لمدة 30 يوماً أو أكثر، لأنها تخدم كمرجع مستقر لجميع الفروع. artifacts فروع feature تُحتفظ بها لمدة 7 أيام فقط، وهو وقت كافٍ لمعالجة merge request واتخاذ القرار.
الـ Environments كسياق للمقارنة
تضيف environments في GitLab بُعداً إضافياً وقوياً لاختبارك البصري. تسمح بربط كل مجموعة لقطات شاشة بسياق deploy محدد ومعروف، مما يضيف طبقة من السياقية والوضوح للنتائج.
Review apps كأرض اختبار
إذا كنت تستخدم review apps في GitLab (وهي deploy مؤقت يتم إنشاؤه تلقائياً لكل فرع feature)، لديك URL فريد ومستقل لكل فرع. يمكن للاختبار البصري التقاط لقطات الشاشة مباشرة من هذا الـ URL الحقيقي، مقدماً عرضاً أكثر دقة وواقعية من خادم محلي في بيئة CI.
الميزة هنا مزدوجة وواضحة. العرض الناتج هو عرض بيئة حقيقية فعلية وليس مجرد خادم تطوير محلي. وURL الـ review app متاح لكل أعضاء الفريق، مما يسهل التحقق اليدوي كمكمل ضروري للاختبار المؤتمت.
المقارنة بين environments
تسمح environments بإجراء مقارنات بصرياً بين سياقات نشر مختلفة. يمكنك مقارنة review app لفرع feature مع بيئة الـ staging للتحقق من الاتساق. أو مقارنة بيئة staging مع بيئة الإنتاج لاكتشاف أي انحرافات بصرية تراكمية.
هذه القدرة على المقارنة بين environments المختلفة هي ميزة رئيسية لـ GitLab CI في مجال الاختبار البصري. تسمح باكتشاف ليس فقط التراجعات البصرية المُدخلة مباشرة بواسطة فرع معين، بل أيضاً الانحرافات البصرية المتراكمة بمرور الوقت بين البيئات المختلفة.
التكامل مع Merge Requests
الاختبار البصري لا يملك أي قيمة حقيقية إلا إذا كانت نتائجه مرئية بوضوح وقابلة للتنفيذ من قبل الفريق. التكامل مع merge requests في GitLab هو الوسيلة المثالية لتحقيق هذا الهدف.
أدوات merge request
يعرض GitLab نتائج pipelines مباشرة على صفحة merge request. حالة job الاختبار البصري تظهر في قائمة checks بشكل واضح. نقرة واحدة تقود مباشرة إلى سجلات الـ job والـ artifacts المرتبطة به.
التعليقات التلقائية
اضبط pipeline الخاص بك لنشر تعليق تلقائي على merge request فور اكتشاف اختلافات بصرية. هذا التعليق يجب أن يتضمن ملخصاً واضحاً (عدد الصفحات المتأثرة، خطورة التغييرات المكتشفة) ورابطاً مباشراً للتقرير الكامل المخزن في artifacts.
اعتماد التغييرات المتوقعة
عندما يكون التغيير البصري مقصوداً ومخططاً له (مثل إعادة تصميم واجهة أو تغيير ألوان)، يجب أن تكون هناك آلية واضحة لاعتماد هذا التغيير وتحديث المراجع accordingly. في GitLab، يمكن القيام بذلك عبر job يدوي يُفعّل بزر في واجهة الـ pipeline. المطور أو مهندس QA يراجع الفروقات البصرية، يؤكد أنها متوقعة ومطلوبة، ثم يُفعّل تحديث المراجع بضغطة زر.
نهج No-Code: تبسيط جذري للتهيئة
كل ما سبق وصفه يعمل بشكل فعلي، لكنه يتطلب استثماراً كبيراً في التهيئة الأولية والصيانة المستمرة. نهج no-code يقلل هذا التعقيد بشكل جذري وملموس.
مع أداة مثل Delta-QA، التكامل في GitLab CI يتلخص في إضافة job واحد يستدعي الأداة بمعلمات مشروعك البسيطة. الأداة تتولى بالكامل إدارة المتصفح headless والالتقاط والمقارنة وإدارة المراجع والتقارير.
لا تحتاج لإدارة صور Docker مع Chromium وتبعياته. لا تحتاج لكتابة سكربتات التقاط من الصفر. لا تحتاج لتنفيذ نظام مقارنة صور معقد. لا تحتاج لبناء تقرير HTML مخصص.
الميزة الرئيسية ليست البساطة الأولية للتهيئة — إنها الصيانة طويلة المدى. pipeline اختبار بصري مصنوع يدوياً يتطلب صيانة مستمرة ومكثفة: تحديثات المتصفحات العادية، ضبط العتبات والحدود، تصحيح سكربتات الالتقاط عند تغير هيكل الواجهة. أداة no-code تستوعب هذا التعقيد كاملاً وتختفي وراء واجهة بسيطة.
ملف .gitlab-ci.yml الخاص بك يبقى نظيفاً ومقروءاً. الـ pipeline يبقى سريعاً وفعالاً. وفريقك يمكنه التركيز على ما يهم حقاً: تحليل النتائج واتخاذ القرارات حول ما إذا كانت التغييرات متوقعة أم لا.
الفخاخ الشائعة والحلول
فخ صور Docker الضخمة
صور Docker التي تحتوي على متصفح headless كامل ثقيلة جداً (غالباً أكثر من جيجابايت واحد). إذا حملتها في كل تشغيل من الصفر، تضيف عدة دقائق إضافية لـ pipeline. استخدم registry Docker خاص مع تخزين مؤقت فعال، أو استخدم صور مثبتة مسبقاً على runners المشتركة لتجنب إعادة التحميل.
فخ دقة الشاشة
runners في GitLab CI ليس لديها شاشة فعلية مادية. المتصفح headless يستخدم framebuffer افتراضي. دقة هذا الـ framebuffer يجب أن تتوافق بدقة مع viewports الاختبار المطلوبة. إذا التقطت لقطات بدقة 1920x1080 لكن الـ framebuffer مضبوط على 1024x768، ستحصل على لقطات شاشة مقصوصة أو مُعاد تحجيمها بشكل غير صحيح.
فخ المحتوى غير المتزامن
التطبيقات الحديثة تحمّل المحتوى بشكل غير متزامن عبر استدعاءات شبكة. API يستجيب في 200 مللي ثانية في بيئة التطوير قد يستغرق 2000 مللي ثانية في CI (بسبب اختلاف الشبكة وتبادل الموارد المشتركة). تأكد من الانتظار حتى تكتمل جميع استدعاءات الشبكة ويتم عرض كل المحتوى بالكامل قبل بدء عملية الالتقاط.
فخ إدارة المراجع في الفروع الطويلة
إذا استمر فرع feature مفتوحاً عدة أسابيع، فقد تكون مراجع الفرع الرئيسي تطورت بشكل ملحوظ في هذه الأثناء. عند إجراء المقارنة، ستكتشف اختلافات تأتي من تطور main وليس من التعديلات في فرعك. الحل الأمثل هو عمل rebase منتظم لفرعك على main، أو تحميل أحدث المراجع في كل تشغيل جديد.
الأسئلة الشائعة
أي صورة Docker يجب استخدامها للاختبار البصري في GitLab CI؟
صور Playwright الرسمية (mcr.microsoft.com/playwright) هي خيار ممتاز ومجرب. تتضمن Chromium وFirefox وWebKit، مع جميع تبعيات النظام اللازمة المثبتة مسبقاً. إذا كنت تستخدم Chromium فقط، تتوفر صور أخف حجماً مبنية على Alpine مع Puppeteer. لأداة no-code مثل Delta-QA، صورة Docker مقدمة ومُحسّنة ومجهزة خصيصاً لهذا الاستخدام.
كم يجب الاحتفاظ بـ artifacts لقطات الشاشة؟
للفرع الرئيسي، احتفظ بالـ artifacts لمدة 30 يوماً على الأقل. تخدم كمراجع أساسية لجميع المقارنات التي تجريها الفروع الأخرى. لفروع feature، 7 أيام كافية عموماً — وهو الوقت الكافي لمعالجة merge request ومناقشتها ودمجها. عدّل هذه المدد حسب إيقاع تطويركم الخاص. فريق بدورات تطوير أطول سيحتاج فترات احتفاظ أطول للمراجع.
هل يعمل الاختبار البصري مع runners GitLab.com المشتركة؟
نعم، runners GitLab.com المشتركة (SaaS) تدعم الاختبار البصري بشكل كامل. تستخدم آلات افتراضية مع Docker مثبت، قادرة على تشغيل متصفح headless بسلاسة. لكن الأداء قد يتفاوت حسب الحمل الحالي على runners المشتركة. إذا كانت الاستقرارية والسرعة عاملين حرجين لمشروعكم، runners مخصصة أو ذاتية الاستضافة توفر تحكماً أفضل وأداءً أكثر اتساقاً.
كيف أتعامل مع اختلافات العرض بين GitLab CI وجهاز التطوير؟
اختلافات العرض بين جهازك المحلي وrunners CI أمر حتمي ولا مفر منه. الخطوط المثبتة وإصدار المتصفح ودقة الـ framebuffer كلها تختلف بين البيئتين. القاعدة الذهبية بسيطة: لا تقارن أبداً لقطة شاشة محلية بلقطة شاشة CI. المراجع يجب أن تُنتج دائماً في نفس البيئة التي تُلتقط فيها لقطات الاختبار. إذا كانت مراجعك مُنتجة في CI، فجميع مقارناتك يجب أن تتم في CI أيضاً.
هل يمكن موازاة التقاط لقطات الشاشة في GitLab CI؟
بالتأكيد، وهذا موصى به بشدة للمشاريع التي تحتوي على عدد كبير من الصفحات للاختبار. يدعم GitLab CI الموازاة عبر الكلمة المفتاحية parallel في تهيئتك. يمكنك توزيع الصفحات على عدة jobs تعمل بالتوازي في نفس الوقت. كل job يلتقط مجموعة فرعية من الصفحات ويخزن لقطات شاشته كـ artifacts مستقلة. job نهائي يجمع ويتابع النتائج. هذا النهج يقسم وقت الالتقاط الإجمالي على عدد الـ jobs المتوازية.
هل يعمل الاختبار البصري في GitLab CI مع monorepos؟
نعم، لكنه يتطلب تهيئة محددة ودقيقة. في monorepo، لديك غالباً عدة تطبيقات frontend مستقلة في نفس المستودع. استخدم rules في GitLab CI لتفعيل الاختبار البصري فقط عندما تُعدّل ملفات التطبيق المعني. كل تطبيق يمكن أن يكون له مجموعة مراجعه الخاصة المستقلة وjob اختبار بصري خاص به. يجب تنظيم artifacts بشكل هرمي حسب التطبيق لتجنب أي تعارضات محتملة.
الخلاصة
يمتلك GitLab CI/CD ميزات أصلية متعددة — artifacts، environments، review apps، متصفح artifacts — تجعله منصة مناسبة بشكل ملحوظ ومتميز للاختبار البصري. هذه ليست مصادفة تقويمية. إنها تقارب معماري حقيقي: الاختبار البصري يحتاج لتخزين ملفات ومقارنة سياقات مختلفة وجعل النتائج متاحة بسهولة. GitLab يفعل كل هذا بشكل أصلي ومدمج.
إذا كنت تستخدم GitLab وpipeline الخاص بك لا يتحقق من مظهر تطبيقك، فأنت لا تستغل أداتك بالكامل. لديك البنية التحتية اللازمة. ينقصك فقط إضافة هذه الخطوة الواحدة.
إضافة الاختبار البصري إلى pipeline GitLab CI ليس مشروع تحول رقمي ضخم. إنه stage في ملف .gitlab-ci.yml، ومجموعة مراجع أولية، وعملية واضحة لاعتماد التغييرات. مع أداة no-code مثل Delta-QA، الأمر أبسط بكثير: تكامل في دقائق معدودة، وكل merge request يُحمى تلقائياً ومنهجياً من التراجعات البصرية غير المرغوبة.
مستخدموك يرون تطبيقك بأعينهم. pipeline الخاص بك يجب أن يراه أيضاً.