الاختبار البصري الآلي ممارسة تحقق تعتمد على التقاط لقطات شاشة لواجهة ويب في مراحل مختلفة من التطوير ومقارنتها تلقائيًّا لاكتشاف أي انحدارات رسومية غير مقصودة.
أصبح GitHub Actions المعيار الفعلي لـ CI/CD في منظومة GitHub. مسارات عمله بصيغة YAML قوية، وسوق الإجراءات غني، والتكامل مع pull requests سلس. للأتمتة التقليدية — البناء، الاختبارات الوحدوية، التدقيق اللغوي، النشر — هو خيار ممتاز.
لكن عندما يتعلق الأمر بالاختبار البصري، تتعقد الأمور. ليس لأن GitHub Actions محدود — فهو مُنفِّذ CI مثل أي آخر — بل لأن الاختبار البصري في بيئة CI يطرح تحديات تستهين بها معظم الفرق. يُفصِّل هذا المقال المقاربات المتاحة، والمزالق الحقيقية، وكيفية الحصول على مسار اختبار بصري موثوق في GitHub Actions.
لماذا الاختبار البصري في CI أعقد مما يبدو
تنفيذ الاختبارات الوحدوية في CI أمر يمكن التنبؤ به. الكود حتمي النتائج. النتيجة ثنائية: إما أن ينجح أو يفشل. أما الاختبار البصري فيعمل في مجال تكون فيه الحتمية وهمًا.
مشكلة العرض غير الحتمي
لقطة شاشة ملتقطة على جهاز التطوير الخاص بك ولقطة شاشة ملتقطة على مُنفِّذ GitHub Actions لن تكونا متطابقتين، حتى مع استخدام نفس المتصفح ونفس الدقة. الأسباب عديدة:
الخطوط. مُنفِّذات Ubuntu في GitHub Actions لا تحتوي على نفس الخطوط الموجودة في macOS المحلي لديك. خط بديل مختلف يمكن أن يُزيح النص بضعة بكسلات — وهذا يكفي لإفشال مقارنة بكسل ببكسل.
مكافحة التعرج (Anti-aliasing). يختلف عرض المنحنيات والحدود بحسب وحدة معالجة الرسومات (GPU) أو غيابها والإعدادات الرسومية. مُنفِّذات CI تعمل عادةً بدون تسريع رسومي، مما يُغيّر التنعيم.
الرسوم المتحركة والانتقالات. يمكن التقاط مكوِّن يحتوي على رسوم CSS متحركة في حالة وسيطة إذا لم يكن التوقيت مُتحكمًا فيه بدقة. على جهازك السريع، الرسوم المتحركة تكون قد انتهت. على مُنفِّذ CI مشغول، لا تزال جارية.
منفذ العرض والتحجيم. مُنفِّذات GitHub Actions تستخدم دقة افتراضية قد تختلف عن إعداداتك المحلية. DPI مختلف يُغيّر العرض.
هذه الاختلافات دقيقة — غالبًا بضع بكسلات فقط — لكنها كافية لتوليد فيضان من الإيجابيات الكاذبة التي تجعل مسار عملك غير صالح للاستخدام.
المقاربات المتاحة
المقاربة 1: Playwright + toHaveScreenshot() في مسار عمل GitHub Actions
يُعد Playwright حاليًّا الأداة مفتوحة المصدر الأفضل تجهيزًا للاختبار البصري في CI. طريقة toHaveScreenshot() الخاصة به تتولى الالتقاط والمقارنة وتخزين خطوط الأساس.
المبدأ. تكتب اختبارات Playwright تنتقل إلى صفحاتك، وتنتظر استقرار المحتوى، وتلتقط لقطة شاشة تُقارن بخط أساس مخزّن في مستودعك. مسار عمل GitHub Actions يُثبِّت Playwright ومتصفحاته، ويُنفِّذ الاختبارات، ويُبلِّغ عن النتائج.
بالنسبة لتهيئة مسار عمل YAML، يمكن لمساعدك الذكي المفضل أن يُنشئ لك قالبًا جاهزًا للاستخدام — فهو حرفيًّا يعيش من أجل ذلك، هذا كل ما لديه. على محمل الجد، التوثيق الرسمي لـ Playwright الخاص بـ GitHub Actions ممتاز ويتم تحديثه باستمرار.
المزايا. كل شيء مفتوح المصدر ومجاني. خطوط الأساس في مستودعك. لا حاجة لخدمة خارجية. يُدير Playwright بصورة أصلية انتظار الاستقرار البصري مع إعادة المحاولة التلقائية.
القيود العملية. يجب إنشاء الجيل الأول من خطوط الأساس في بيئة CI، وليس محليًّا. هذه هي القاعدة الذهبية التي يكتشفها الكثيرون بعد ساعات من تصحيح الإيجابيات الكاذبة. خطوط الأساس المُنشأة على جهاز Mac الخاص بك لن تتطابق مع العرض على مُنفِّذ Ubuntu.
التحدي الآخر هو صيانة خطوط الأساس. كل تغيير بصري مقصود — إعادة تصميم، تغيير لون، خط جديد — يتطلب تحديث خطوط الأساس. مع --update-snapshots، الأمر بسيط لاختبار واحد. مع 200 صفحة، يصبح عملية بحد ذاتها.
المقاربة 2: الخدمات السحابية (Percy، Chromatic، Applitools)
تقدم خدمات الاختبار البصري السحابية إجراءات رسمية لـ GitHub Actions. المبدأ: يلتقط مسار عمل CI اللقطات ويرسلها إلى الخدمة السحابية، التي تتولى المقارنة والعرض متعدد المتصفحات ولوحة المراجعة.
المبدأ. تضيف الإجراء الرسمي للخدمة إلى مسار عملك، وتُهيئ رمز API، وكل دفعة push تُطلق التقاطًا بصريًّا. تظهر النتيجة كفحص على pull request الخاص بك.
المزايا. تُفوِّض مشكلة العرض غير الحتمي إلى طرف خارجي — الخدمة السحابية تعرض الصفحات في بيئة مُتحكم فيها ومستقرة. لوحة المراجعة احترافية. الاختبار عبر المتصفحات يعمل بدون تهيئة.
القيود. التكلفة. تفرض جميع هذه الخدمات رسومًا بحسب حجم اللقطات، والأسعار ترتفع بسرعة مع نمو تطبيقك. الاعتماد على خدمة خارجية يعني أيضًا أن أي انقطاع من جانبهم يمنع merge requests الخاصة بك — إذا كنت قد جعلت الفحص إلزاميًّا. ولقطات شاشتك تمر عبر بنية تحتية لطرف ثالث، مما قد يثير مخاوف تتعلق بالامتثال.
المقاربة 3: BackstopJS في GitHub Actions
BackstopJS أداة مفتوحة المصدر لاختبار الانحدار البصري يمكن تهيئتها عبر سيناريوهات JSON. تعمل في GitHub Actions عبر حاوية Docker أو تثبيت مباشر.
المبدأ. تُحدد سيناريوهاتك (عناوين URL، منافذ العرض، المحددات للالتقاط)، يلتقط BackstopJS لقطات الشاشة ويُقارنها بخطوط الأساس. يُنشأ تقرير HTML كأثر من آثار مسار العمل.
المزايا. مفتوح المصدر، مجاني، وتقرير HTML أكثر قابلية للقراءة من مقارنة صور خام.
القيود. التهيئة عبر سيناريوهات JSON تصبح مطوَّلة للتطبيقات المعقدة. شهد المشروع فترات صيانة متفاوتة. وكما هو الحال مع Playwright، تبقى مشكلة خطوط الأساس المُنشأة في بيئات مختلفة قائمة.
المقاربة 4: Delta-QA — اختبار بصري يُبسِّط CI
يقدم Delta-QA مقاربة مختلفة للاختبار البصري في GitHub Actions. بدلًا من مطالبتك بكتابة نصوص اختبار وإدارة خطوط الأساس في Git وتصحيح الإيجابيات الكاذبة المتعلقة بالبيئة، يتولى Delta-QA الالتقاط والمقارنة بشكل مستقل.
ما الذي يتغيَّر عمليًّا. يُطلق مسار عمل GitHub Actions الخاص بك Delta-QA، الذي يتولى التقاط صفحاتك في بيئة عرض مستقرة ومُتحكم فيها. تُدار خطوط الأساس بواسطة الأداة، وليس بمستودع Git الخاص بك. تختفي الإيجابيات الكاذبة المتعلقة باختلافات البيئة لأن العرض يتم دائمًا في نفس السياق.
واجهة المراجعة. عند اكتشاف اختلاف، يظهر في واجهة مخصصة — وليس في مجلد ملفات PNG أو في سجل CI من 500 سطر. يمكن لفريق QA والمصممين مراجعة التغييرات البصرية دون الحاجة إلى الوصول إلى GitHub.
لا نصوص صيانة. الاختبار البصري غير مقترن بحزمة اختباراتك. ليس لديك اختبارات Playwright أو سيناريوهات JSON لتحديثها عند تطور تطبيقك.
المزالق الشائعة للاختبار البصري في CI
بغض النظر عن المقاربة المختارة، هذه المزالق تتربص بأي فريق يخوض غمار الاختبار البصري في CI.
المزلق 1: إنشاء خطوط الأساس محليًّا
هذا هو الخطأ الأكثر شيوعًا. تُنشئ صورك المرجعية على جهازك، وتعمل لها commit، وفي CI، تفشل جميع الاختبارات. الحل: أنشئ خطوط الأساس دائمًا في بيئة CI، أو استخدم أداة تُدير هذا الاستقرار نيابة عنك.
المزلق 2: اختبار عدد كبير من الصفحات في وقت مبكر جدًّا
الحماس الأولي يدفع الفرق إلى التقاط كل صفحة في التطبيق. النتيجة: مسار عمل بطيء، مئات الاختلافات للمراجعة مع كل تغيير CSS شامل، وفريق ينتهي به الأمر إلى تجاهل النتائج. ابدأ بالصفحات الحرجة — الرئيسية، الدفع، لوحة التحكم — ووسِّع تدريجيًّا.
المزلق 3: جعل الفحص حاجبًا فورًا
إذا كان الاختبار البصري يمنع دمج pull requests الخاص بك من اليوم الأول، سيكره مطوروك الأمر بسرعة. ابدأ في الوضع الإعلامي: الفحص يُبلِّغ عن الاختلافات بدون منع الدمج. عندما تترسخ الثقة في الأداة وتكون الإيجابيات الكاذبة تحت السيطرة، انتقل إلى الوضع الحاجب.
المزلق 4: تجاهل المحتوى الديناميكي
التواريخ، بيانات المستخدمين، المحتوى المُحمَّل عبر API — أي شيء يتغير بين تنفيذين يجب أن يُحاكى أو يُخفَّى. وإلا، يُنتج كل تنفيذ اختلافات ليست انحدارات. يمكن للذكاء الاصطناعي التوليدي كتابة المحاكيات بدلًا منك، لكنه يخاطر بتوليد بيانات أكثر إبداعًا حتى من مستخدميك الحقيقيين.
المزلق 5: عدم وجود مسار مراجعة واضح
اختبار بصري فاشل ليس مثل اختبار وحدوي فاشل. الاختلاف قد يكون مقصودًا (إعادة تصميم) أو عرضيًّا (انحدار). بدون مسار عمل واضح لفرز التغييرات والموافقة عليها أو رفضها، يتحول الاختبار البصري إلى مجرد ضوضاء.
تحسين وقت التنفيذ
الاختبار البصري أبطأ بطبيعته من الاختبارات الوحدوية — تحتاج إلى فتح متصفح، وتحميل صفحات، وانتظار الاستقرار، والتقاط لقطات شاشة. في GitHub Actions، كل دقيقة تُحسب (حرفيًّا، إذا كنت تدفع مقابل المُنفِّذات).
وزِّع بالتوازي. GitHub Actions يدعم مصفوفات الاستراتيجية strategy matrices. وزِّع اختباراتك البصرية على عدة مهام متوازية لتقسيم الوقت الإجمالي.
استهدف التغييرات. لا حاجة لاختبار التطبيق بالكامل بصريًّا إذا كان commit يُمس مكونًا محددًا فقط. بعض الأدوات تتيح لك استهداف الاختبارات بناءً على الملفات المعدَّلة.
خزِّن المتصفحات مؤقتًا. تثبيت Chromium عبر Playwright يستغرق وقتًا. استخدم التخزين المؤقت في GitHub Actions لتجنُّب تنزيله في كل تنفيذ.
استخدم مُنفِّذات أقوى. المُنفِّذات القياسية في GitHub Actions مناسبة للاختبارات الوحدوية لكنها متواضعة لعرض الصفحات المعقدة. المُنفِّذات الكبيرة Large runners أو المُنفِّذات المستضافة ذاتيًّا self-hosted runners تُقلل بشكل ملحوظ من وقت الالتقاط.
الأسئلة الشائعة
هل يُبطئ الاختبار البصري في GitHub Actions مسار العمل بشكل كبير؟
يعتمد ذلك على عدد الصفحات المُختبَرة والمقاربة المختارة. اختبار بصري لـ 10 صفحات مع Playwright يضيف عادةً من 2 إلى 5 دقائق. مع 100 صفحة، توقَّع من 15 إلى 30 دقيقة بدون توازي. الخدمات السحابية تُفوِّض العرض خارجيًّا، مما يُقلل الحمل على المُنفِّذات لكن يضيف تأخرًا شبكيًّا. Delta-QA يُحسِّن هذه العملية لتقليل التأثير على مسار عملك.
هل المُنفِّذات المستضافة ذاتيًّا self-hosted ضرورية للاختبار البصري؟
لا، لكنها تُساعد. المُنفِّذات المستضافة من GitHub تعمل للاختبار البصري، لكن تهيئة عتادها المتغيرة قد تُدخل تباينات في العرض. المُنفِّذات المستضافة ذاتيًّا توفر بيئة أكثر استقرارًا وعادةً أسرع. إنه استثمار مُبرَّر إذا كان الاختبار البصري محوريًّا في مسار عملك.
كيف تُدار خطوط الأساس عندما يعمل عدة مطورين بالتوازي؟
هذه من أكثر المشاكل التي يُستهان بها. مع خطوط أساس مخزنة في Git، تكون تعارضات الدمج في الملفات الثنائية (PNG) متكررة ومؤلمة الحل. الخدمات السحابية تُدير خطوط الأساس لكل فرع تلقائيًّا. Delta-QA يتجنب هذه المشكلة بإدارة خطوط الأساس بشكل مستقل عن مستودع Git الخاص بك.
هل يمكن استخدام الاختبار البصري في GitHub Actions مع تطبيقات تتطلب مصادقة؟
نعم، لكنه يتطلب تهيئة محددة. تحتاج إلى أتمتة تسجيل الدخول قبل التقاط لقطات الشاشة — إما عبر ملفات تعريف ارتباط مُهيأة مسبقًا أو نص مصادقة. يجب تخزين أسرار GitHub (الرموز، كلمات المرور) في GitHub Secrets، وليس أبدًا كنص صريح في مسار العمل. جميع أدوات الاختبار البصري تدعم هذا السيناريو بدرجات متفاوتة من السهولة.
هل يحل الاختبار البصري في CI محل المراجعة البصرية البشرية؟
لا. الاختبار البصري الآلي يكتشف التغييرات — لا يحكم على ما إذا كانت جيدة أو سيئة. يُنبهك بأن عنصرًا قد تغيّر. بعد ذلك يقرر الإنسان (مطور، مصمم، QA) ما إذا كان التغيير مقصودًا أو انحدارًا. أفضل مسارات العمل تجمع بين الاكتشاف الآلي وعملية مراجعة بشرية مُنظمة.
ما الفرق بين اختبار بصري واختبار لقطة شاشة تقليدي؟
اختبار لقطة الشاشة التقليدي يلتقط صورة ويخزنها — إنها لقطة وليس تحققًا. الاختبار البصري يذهب أبعد من ذلك: يقارن تلقائيًّا لقطة الشاشة الحالية بصورة مرجعية معتمدة، ويُحدد مناطق الاختلاف، ويُبلِّغ عن التباينات. المقارنة هي التي توفر القيمة، وليس الالتقاط.
الخاتمة
GitHub Actions منصة CI/CD ممتازة. الاختبار البصري قابل للتنفيذ فيها تمامًا. لكن لا تستهن بالتعقيد الخاص بالاختبار البصري في بيئة CI: العرض غير الحتمي، إدارة خطوط الأساس، الإيجابيات الكاذبة، ومسار عمل المراجعة هي تحديات تعالجها كل مقاربة بطريقة مختلفة.
إذا كنت تريد التحكم في كل جانب من العملية وكان فريقك يملك المهارات اللازمة لصيانة البنية التحتية، فإن Playwright في GitHub Actions خيار متين. إذا كنت تُفضِّل تفويض التعقيد خارجيًّا، فالخدمات السحابية تعمل لكن بتكاليف متصاعدة.
وإذا كنت تبحث عن مقاربة تُبسِّط الاختبار البصري في CI بشكل جذري دون التضحية بالتحكم أو انفجار الميزانية، فقد صُمم Delta-QA تحديدًا لهذا السيناريو.
جرِّب Delta-QA مجانًا →