الاختبار البصري في GitHub Actions هو دمج خطوة مؤتمتة لالتقاط ومقارنة لقطات الشاشة ضمن سير عمل GitHub Actions، تكتشف أي تراجع في العرض بمقارنة لقطات الشاشة الحالية للتطبيق مع مراجع بصرية مُعتمدة، قبل السماح بعملية الدمج أو النشر.
أصبح GitHub Actions منصة CI/CD الأكثر استخدامًا في العالم. وفقًا لتقرير بيئة المطورين من JetBrains لعام 2024، يستخدمه أكثر من 50% من الفرق كنظام أساسي للتكامل المستمر. وهذا منطقي: فهو مدمج أصليًا مع GitHub، ومجاني للمشاريع مفتوحة المصدر، ومرن بما يكفي لتغطية معظم الاحتياجات.
ومع ذلك، فإن الغالبية العظمى من مسارات العمل هذه تكتفي بتشغيل اختبارات الوحدة واختبارات التكامل. الشيفرة تمر، وخط الأنابيب أخضر، ويُدمج طلب السحب. لا أحد يتحقق مما إذا كانت الصفحة الرئيسية قد تحولت إلى فوضى من المكونات غير المتوائمة.
موقفنا واضح: يجب أن يكون الاختبار البصري في GitHub Actions معياريًا مثل اختبارات الوحدة. ليس مكافأة. ليس «من الجيد امتلاكه». خطوة أساسية في مسار العمل، بنفس مستوى فحص الشيفرة أو الاختبارات الوظيفية.
يشرح لك هذا الدليل كيفية تحقيق ذلك، خطوة بخطوة.
لماذا GitHub Actions هو الأرض المثالية للاختبار البصري
يمتلك GitHub Actions خصائص تجعله بيئة طبيعية للاختبار البصري. ليس من قبيل الصدفة أن أكثر أدوات الاختبار البصري شعبية تُعطي الأولوية لتكامل GitHub Actions.
التكامل الأصلي مع طلبات السحب. هذه هي الميزة الحاسمة. يعمل GitHub Actions عند كل طلب سحب، وتظهر نتائجه مباشرة في واجهة طلب السحب. اختبار بصري فاشل يمنع الدمج — تمامًا مثل فشل اختبار وحدة. لا حاجة للتنقل بين أدوات أو علامات تبويب متعددة. النتائج موجودة حيث يتخذ المطورون قراراتهم.
البيئات مؤقتة وقابلة للتكرار. كل تنفيذ لمسار العمل يبدأ على مشغّل جديد. هذا يُزيل مشكلة كلاسيكية في الاختبار البصري: اختلافات العرض الناتجة عن حالة الجهاز. في GitHub Actions، البيئة متطابقة في كل تشغيل. لقطات الشاشة قابلة للمقارنة من تنفيذ لآخر، مما يجعل المقارنات موثوقة وذات معنى.
السوق مليء بالإجراءات الجاهزة للاستخدام. لا تحتاج لبناء كل شيء من الصفر. تتيح لك الإجراءات التي تديرها المجتمع تثبيت التبعيات اللازمة (المتصفحات بدون واجهة، أدوات الالتقاط) في بضعة أسطر في ملف YAML الخاص بك. هذا يُقلّل وقت الإعداد ويُبسّط الصيانة.
تسمح العناصر المرفقة بتخزين النتائج البصرية. يتيح لك GitHub Actions حفظ الملفات (لقطات الشاشة، تقارير الفروقات) كعناصر مرتبطة بكل تشغيل. يمكن لفريقك الاطلاع على اللقطات والفروقات مباشرة من واجهة GitHub، مما يُسهّل عملية المراجعة والتحقيق.
المشكلة التي (ربما) تتجاهلها
إذا كنت تعمل على مشروع واجهة أمامية بحجم كبير — موقع تجارة إلكترونية، تطبيق SaaS، نظام تصميم — فمن المحتمل جدًا أنك مررت بهذا الموقف.
يُعدّل مطور مكونًا مشتركًا. الزر الرئيسي، مثلًا. يُضبط حشوة، أو لونًا، أو نصف قطر الحد. اختبارات الوحدة تمر. اختبارات Cypress أو Playwright تمر. البناء أخضر. يُوافق على طلب السحب ويُدمج.
في اليوم التالي، يلاحظ شخص ما أن صفحة الدفع بها زر صغير جدًا لأن المكون المُعدَّل كان يُستخدم في سياق بأنماط محددة تتفاعل مع الحشوة القديمة. أو أن الزر يتداخل مع عنصر مجاور على الجهاز المحمول. أو أن لون الزر لم يعد يتناسب مع الخلفية بعد تحديث متغير CSS عام.
هذا النوع من التراجعات غير مرئي للاختبارات التقليدية. الاختبار الوظيفي يتحقق من أن الزر قابل للنقر وأن الإجراء المرتبط يعمل. لا يتحقق من أن الزر مرئي ومقروء وموضع بشكل صحيح في سياقه البصري.
الاختبار البصري هو النهج الوحيد الذي يكتشف هذا النوع من المشاكل بشكل موثوق ومؤتمت. فهو يقارن حرفيًا صورة الصفحة قبل وبعد التغيير. إذا تغيّر شيء بصريًا، فأنت تعلم بذلك فورًا.
الخطوات الخمس لسير عمل الاختبار البصري
يتبع سير عمل الاختبار البصري في GitHub Actions نمطًا منطقيًا من خمس خطوات. لكل منها دورها وفروقها الدقيقة.
الخطوة 1: Checkout — استرجاع الشيفرة والمراجع
الخطوة الأولى قياسية: استرجاع الشيفرة المصدرية للمشروع. لكن في سياق الاختبار البصري، لها أهمية خاصة. يجب عليك أيضًا استرجاع المراجع البصرية — لقطات الشاشة الأساسية التي ستُقارن بها اللقطات الجديدة.
توجد استراتيجيتان لتخزين هذه المراجع. إما أن تضعها في المستودع (بسيط لكن يُثقل المستودع مع نمو عدد الصفحات)، أو تخزنها في خدمة خارجية وتحمّلها أثناء مسار العمل (أنظف لكن أكثر تعقيدًا في الإعداد).
الاستراتيجية التي تختارها تعتمد على مشروعك. لمشروع به صفحات قليلة للتحقق، وضع المراجع في المستودع مقبول تمامًا. لمشروع بمئات اللقطات، التخزين الخارجي أفضل.
الأساسي هو أن يجلب الاسترجاع كل ما هو ضروري للمقارنة: الشيفرة الحالية، والمراجع البصرية المقابلة للفرع المستهدف (عادة main).
الخطوة 2: Build — بناء التطبيق
قبل التقاط لقطات الشاشة، يجب أن يكون التطبيق قيد التشغيل. هذه الخطوة مشابهة لما تفعله بالفعل لاختبارات الشاملة: تثبيت التبعيات، بناء المشروع، وتشغيل خادم محلي.
بعض نقاط الانتباه الخاصة بالاختبار البصري.
ثبّت البيئة. الخطوط بشكل خاص مصدر شائع للإيجابيات الكاذبة. على مشغّلات GitHub Actions (Ubuntu افتراضيًا)، الخطوط المثبتة ليست نفسها الموجودة على جهاز التطوير. تأكد من تثبيت الخطوط المستخدمة في تطبيقك، أو استخدم خطوط ويب محمّلة عبر CDN.
عطّل الحركات. حركات CSS تُنتج لقطات شاشة مختلفة حسب اللحظة الدقيقة للالتقاط. أدخل نمطًا يُعطّل جميع الانتقالات والحركات أثناء الاختبارات البصرية. هذه ممارسة قياسية ولا غنى عنها لضمان استقرار اللقطات.
انتظر حتى يكون الخادم جاهزًا. لا تبدأ الالتقاط حتى ينتهي الخادم المحلي من التشغيل. فحص صحة بسيط في مسار العمل كافٍ لتجنب لقطات لصفحات غير مكتملة.
الخطوة 3: Capture — التقاط لقطات الشاشة
هذا هو جوهر العملية. متصفح بدون واجهة (Chromium أو Firefox أو WebKit) ينتقل إلى كل صفحة أو مكون للتحقق ويلتقط لقطة شاشة.
جودة هذه الخطوة تعتمد على عاملين. الأول هو التغطية: أي الصفحات والمكونات تلتقطها؟ الثاني هو الاستقرار: هل اللقطات متطابقة من تشغيل لآخر لنفس الشيفرة؟
بخصوص التغطية، ابدأ بالصفحات الأكثر أهمية. الصفحة الرئيسية، صفحات المنتجات، صفحة الدفع، لوحة التحكم الرئيسية. لا حاجة لالتقاط 500 صفحة من البداية. عشرون صفحة مختارة جيدًا تقدم قيمة كبيرة بالفعل. أضف المزيد تدريجيًا مع نضج عملية الاختبار.
بخصوص الاستقرار، عدة تقنيات ضرورية. أخفِ أو جمّد العناصر الديناميكية: الساعات، العدادات، الإعلانات، الصور الرمزية العشوائية. استخدم بيانات اختبار قابلة للتنبؤ. انتظر حتى يتم تحميل الصفحة بالكامل (بما في ذلك الصور وخطوط الويب) قبل الالتقاط.
مع أداة بدون كود مثل Delta-QA، تُبسَّط هذه الخطوة بشكل كبير. تحدد صفحاتك للالتقاط في واجهة بصرية، دون كتابة سكربتات Playwright أو Puppeteer. الأداة تتولى التثبيت والالتقاط نيابة عنك.
الخطوة 4: Compare — اكتشاف الاختلافات البصرية
تُقارن لقطات الشاشة الجديدة بالمراجع. خوارزمية المقارنة تحلل كل بكسل — أو تستخدم نهجًا إدراكيًا أذكى يتجاهل الاختلافات تحت البكسل غير المهمة.
النتيجة هي قائمة بالاختلافات مُصنّفة حسب الخطورة. زر غيّر لونه أمر مهم. تمويه حواف مختلف قليلًا على نص هو ضوضاء. هذا التصنيف يُساعد الفريق على التركيز على ما يهم حقًا.
عتبة التسامح حاسمة. حساسة جدًا، وتغرق في الإيجابيات الكاذبة. متساهلة جدًا، وتفوتك تراجعات حقيقية. معظم الأدوات تتيح لك تهيئة هذه العتبة لكل صفحة أو منطقة. يجب ضبطها بعناية بناءً على طبيعة كل صفحة.
المقارنة الإدراكية أفضل من المقارنة بكسل ببكسل. تتسامح مع التغيرات الطفيفة في العرض (تمويه الحواف، العرض تحت البكسل) بينما تكتشف التغييرات المهمة بصريًا. إذا لم تقدم أداتك هذا الخيار، فتوقع العديد من الإيجابيات الكاذبة في GitHub Actions، حيث يمكن أن يختلف العرض قليلًا بين إصدارات المشغّلات.
الخطوة 5: Report — إيصال النتائج
الخطوة الأخيرة بنفس أهمية الخطوات السابقة. إذا لم يرَ أحد النتائج، فالاختبار لا قيمة له.
في GitHub Actions، يتم التقرير المثالي مباشرة على طلب السحب. تعليق تلقائي يعرض الاختلافات المكتشفة، مع لقطات الشاشة جنبًا إلى جنب: المرجع، واللقطة الحالية، والفرق المُبرز. هذا يتيح لكل مراجع فهم التغييرات البصرية بسرعة واتخاذ قرار مستنير.
حالة فحص GitHub (الأخضر/الأحمر الشهير على طلب السحب) يجب أن تعكس نتيجة الاختبار البصري. إذا اكتُشفت اختلافات غير مُعتمدة، يفشل الفحص ويمنع الدمج. هذا يضمن عدم وصول أي تراجع بصري إلى الفرع الرئيسي.
هذه النقطة غير قابلة للتفاوض. اختبار بصري نتائجه مدفونة في سجلات مسار العمل لن يُطلَّع عليه أبدًا. يجب أن تكون النتائج مرئية وفورية ومدمجة في مسار العمل الطبيعي للمطور.
النهج بدون كود مقابل النهج البرمجي
فلسفتان تتنافسان على الاختبار البصري في GitHub Actions.
النهج البرمجي
تكتب سكربتات Playwright أو Cypress تنتقل إلى صفحاتك، تلتقط لقطات شاشة، وتقارنها. تحافظ على هذه السكربتات، تدير المحددات، وتُحدّث المراجع يدويًا.
هذا النهج يوفر تحكمًا كاملًا. لكن له ثمن باهظ. السكربتات تتعطل عند تغيير الواجهة. المحددات تصبح قديمة. الصيانة تصبح عملًا بدوام كامل. والأهم من ذلك، فقط المطورون يستطيعون إنشاء الاختبارات وصيانتها، مما يُخلق اختناقًا في الفريق.
النهج بدون كود
تستخدم أداة تدير الالتقاط والمقارنة والتقارير بشكل متكامل. تحدد الصفحات للاختبار في واجهة بصرية. التكامل مع GitHub Actions يتم عبر إجراء جاهز أو webhook.
هذا النهج أكثر سهولة. مهندسو ضمان الجودة والمصممون ومديرو المنتج يمكنهم تهيئة الاختبارات البصرية والتحقق منها دون كتابة شيفرة. الصيانة أقل لأنه لا توجد سكربتات لتحديثها عند تطور الواجهة. هذا يُوسّع قاعدة الأشخاص القادرين على المساهمة في جودة المظهر البصري.
موقفنا هو أن النهج بدون كود أفضل لمعظم الفرق. ليس لأن النهج البرمجي سيئ، بل لأن الاختبار البصري لا ينبغي أن يكون حكرًا على المطورين. التراجع البصري مشكلة تصميم ومنتج، وليس مشكلة شيفرة فقط. الجميع يجب أن يشارك في ضمان جودة المظهر.
يتبنى Delta-QA بالضبط هذا النهج. تربط مستودع GitHub الخاص بك، تحدد صفحاتك للمراقبة، والاختبار البصري يعمل تلقائيًا عند كل طلب سحب. لا سكربتات للكتابة. لا تهيئات YAML معقدة. فقط النتائج، مباشرة على طلب السحب.
الأخطاء التي يجب تجنبها في إعدادك
سنوات من مراقبة مسارات عمل الاختبار البصري في GitHub Actions تكشف عن أخطاء متكررة. إليك الأكثر شيوعًا.
عدم تثبيت إصدارات المتصفحات
يُحدّث مشغّلو GitHub Actions متصفح Chromium بانتظام. تغيير إصدار المتصفح يمكن أن يُغيّر عرض عناصر معينة (تمويه الحواف، عرض الخطوط، التباعد). النتيجة: جميع اختباراتك البصرية تفشل دفعة واحدة، دون أي تغيير في الشيفرة. هذا موقف محبط ويُضعف ثقة الفريق في الاختبار البصري.
الحل هو تثبيت إصدار المتصفح المستخدم للالتقاط، أو استخدام أداة تتولى هذا الجانب نيابة عنك.
تجاهل وقت تحميل خطوط الويب
Google Fonts وخطوط الويب الأخرى تستغرق أحيانًا بضع مئات من الميلي ثانية للتحميل. إذا التقطت لقطة الشاشة مبكرًا جدًا، تحصل على عرض بالخط البديل. يفشل الاختبار للسبب الخطأ، مما يُضيع وقت التحقيق.
انتظر صراحةً اكتمال تحميل الخطوط قبل كل لقطة. هذه نقطة تديرها أدوات بدون كود مثل Delta-QA بشكل أصلي.
اختبار صفحات كثيرة جدًا مبكرًا جدًا
الحماس الأولي يدفع الفرق لالتقاط كل صفحة في الموقع. النتيجة: عشرات الإيجابيات الكاذبة، ووقت خط أنابيب ينفجر، وفريق يُعطّل الاختبار البصري بعد أسبوعين. من الأفضل البدء صغيرًا والتوسع تدريجيًا.
ابدأ بخمس إلى عشر صفحات حرجة. أضف المزيد تدريجيًا بمجرد أن يستقر مسار العمل ويعتاد الفريق على معالجة النتائج.
عدم دمج النتيجة كفحص حاجب
إذا كان الاختبار البصري مجرد خطوة إعلامية في مسار العمل، فسيُتجاهل. اضبطه كفحص مطلوب في قواعد حماية الفروع في GitHub. لا دمج بدون التحقق البصري. هذا يضمن أن كل طلب سحب يجتاز فحصًا بصريًا قبل الوصول إلى الفرع الرئيسي.
عدم التخطيط لآلية اعتماد التغييرات المتوقعة
أي تعديل مقصود على الواجهة سيُفعّل الاختبار البصري. يجب أن تكون هناك عملية واضحة لاعتماد هذه التغييرات وتحديث المراجع. بدون هذه العملية، يصبح الاختبار البصري عائقًا بدلًا من أداة. يجب أن يكون تحديث المراجع سريعًا وبسيطًا لكي لا يُبطئ عملية التطوير.
الأسئلة الشائعة
هل يُبطئ الاختبار البصري في GitHub Actions خط الأنابيب بشكل ملحوظ؟
الوقت الإضافي يعتمد على عدد الصفحات المُلتقطة. لمشروع نموذجي بعشر إلى عشرين صفحة، توقع دقيقتين إلى خمس دقائق إضافية. هذا استثمار متواضع مقارنة بوقت تصحيح تراجع بصري اكتُشف في الإنتاج. أدوات بدون كود مثل Delta-QA تُحسّن هذا الوقت بموازاة عمليات الالتقاط.
هل يمكنني استخدام الاختبار البصري على طلبات سحب من Forks؟
نعم، لكن مع احتياطات. مسارات العمل المُفعَّلة بواسطة Forks لا تصل إلى أسرار المستودع افتراضيًا. إذا كانت أداة الاختبار البصري تتطلب مفتاح API، ستحتاج لتهيئة مسار العمل لاستخدام المُفعِّل pull_request_target، الذي يعمل في سياق المستودع المستهدف. راجع وثائق GitHub لمعرفة التأثيرات الأمنية المرتبطة بهذا الخيار.
هل يجب التقاط نسخي الجهاز المحمول وسطح المكتب بشكل منفصل؟
بالتأكيد. صفحة تُعرض بشكل مثالي على سطح المكتب قد تكون غير مقروءة على الجهاز المحمول. اضبط منافذ عرض مختلفة (مثلًا 1440 بكسل عرضًا لسطح المكتب و375 بكسل للجهاز المحمول) والتقط كل صفحة بالدقتين. هذا يُضاعف عدد اللقطات، لكن التراجعات المتجاوبة من بين الأكثر شيوعًا وتأثيرًا على تجربة المستخدم.
كيف أتعامل مع المحتوى الديناميكي الذي يتغير مع كل تحميل؟
توجد عدة استراتيجيات. يمكنك إخفاء المناطق الديناميكية (الإعلانات، الطوابع الزمنية، العدادات) في تهيئة الاختبار. يمكنك أيضًا استخدام بيانات اختبار ثابتة عبر المحاكيات أو البيانات الاختبارية. تقدم بعض الأدوات مقارنة بالمناطق تتجاهل تلقائيًا المناطق المُعلَّمة كديناميكية. المهم هو تثبيت المحتوى قبل الالتقاط لتجنب الإيجابيات الكاذبة الناتجة عن التباين الطبيعي.
هل يحل الاختبار البصري محل اختبارات Cypress أو Playwright الشاملة؟
لا، وهذا ليس هدفه. الاختبارات الشاملة تتحقق من السلوك الوظيفي: هل يعمل مسار المستخدم من البداية إلى النهاية؟ الاختبار البصري يتحقق من المظهر: هل تبدو الواجهة كما ينبغي؟ هما طبقتان متكاملتان. الاختبارات الشاملة تتحقق من أن الزر يعمل؛ الاختبار البصري يتحقق من أن الزر مرئي ومعروض بشكل صحيح. كلاهما ضروري لتغطية شاملة.
هل تعمل الاختبارات البصرية مع مشغّلي GitHub Actions المستضافين ذاتيًا؟
نعم، وهذا أحيانًا يكون أفضل. المشغّلون المستضافون ذاتيًا يوفرون بيئة أكثر استقرارًا من مشغّلي GitHub، لأنك تتحكم في إصدارات المتصفحات والخطوط المثبتة وتهيئة النظام. هذا يُقلّل الإيجابيات الكاذبة المرتبطة بتغييرات البيئة. ومع ذلك، يجب التأكد من أن التبعيات الرسومية اللازمة (مكتبات X11، الخطوط) مثبتة على المشغّل.
الخلاصة
الاختبار البصري في GitHub Actions ليس ميزة غريبة محجوزة لفرق كبيرة بميزانيات ضمان جودة ضخمة. إنه ممارسة أساسية يجب أن تكون جزءًا من كل مسار عمل، إلى جانب فحص الشيفرة واختبارات الوحدة واختبارات التكامل.
يوفر GitHub Actions كل ما يلزم لدمجه بشكل صحيح: مشغّلون قابلون للتكرار، تكامل أصلي مع طلبات السحب، عناصر لتخزين النتائج، ونظام فحوصات لمنع الدمج في حالة التراجع.
العائق لم يعد تقنيًا. إنه ثقافي. عدد كبير من الفرق لا تزال تعتبر الاختبار البصري رفاهية، بينما تقبل دون تساؤل تسليم تراجعات بصرية إلى الإنتاج.
إذا كنت تستخدم بالفعل GitHub Actions — وإحصائيًا هناك احتمال واحد من اثنين أنك كذلك — ليس لديك عذر لعدم إضافة الاختبار البصري إلى مسار عملك. أدوات بدون كود مثل Delta-QA تجعل التكامل بسيطًا للغاية. بضع دقائق من التهيئة، وكل طلب سحب يُفحص بصريًا تلقائيًا.
حان الوقت لمعاملة مظهر تطبيقك بنفس الجدية التي تعامل بها منطقه.