بيئة قابلة للاستنساخ: تكوين برمجي متطابق في كل تنفيذ — نفس نظام التشغيل، نفس المكتبات، نفس الخطوط، نفس محرك العرض — يضمن ألا تختلف نتائج الاختبار باختلاف الجهاز الذي يُنفَّذ عليه. — مبدأ أساسي في هندسة الاختبار الآلي.
أعددت اختبارك البصري. تُقارن لقطات الشاشة. اختباراتك تمر بنجاح محليًا. وحين تُنفَّذ على CI، تحصل على 47 اختلافًا مُبلَّغًا عنه — لا واحد منها يتوافق مع خلل حقيقي.
هذا السيناريو تعيشه الغالبية العظمى من الفرق التي تُجري اختبارًا بصريًا. ومعظم هذه الفرق تستخلص الاستنتاج الخاطئ: "الاختبار البصري ضوضاء كثيرة، إنه لا يعمل."
الاختبار البصري يعمل بشكل ممتاز. ما لا يعمل هو بيئتك.
لقطات شاشة مُلتقَطة على macOS مع خطوط Apple لن تكون أبدًا متطابقة بكسل بكسل مع لقطات مُلتقَطة على Ubuntu مع خطوط FreeType. ومتصفح يعمل بدقة 1920×1080 مع تحجيم 100% لا يُنتج نفس العرض مثل متصفح بدقة 1920×1080 مع تحجيم 125%. تنعيم الحواف، وتلميح الخطوط، وتنعيم البكسل الفرعي — كل شيء يختلف.
Docker يحل هذه المشكلة. وإذا كنت تُجري اختبارًا بصريًا بدون Docker، فأنت تُضيع وقتك.
لماذا تختلف لقطات الشاشة من جهاز لآخر
عرض الخطوط: المتهم الأول
يُعدُّ عرض الخطوط بحسب المصدر الأول والرئيسي للاختلافات بين لقطات الشاشة. يستخدم كل نظام تشغيل محرك عرض طبوعي خاصًا به. يستخدم macOS محرك Core Text الذي يُعطي الأولوية للدقة في تصميم الخط الأصلي. ويستخدم Windows محرك DirectWrite الذي يُعطي الأولوية لمحاذاة شبكة البكسل للحصول على وضوح أعلى على الشاشات. أما Linux فيستخدم FreeType، والذي يختلف سلوكه بشكل ملحوظ حسب تكوين fontconfig المُثبَّت على النظام.
النتيجة: نفس النص، بنفس الخط، بنفس الحجم، على نفس الصفحة، لا يُنتج نفس البكسلات باختلاف نظام التشغيل. قد تكون الاختلافات غير مرئية بالعين المجردة — إزاحة بكسل واحدة، أو تنعيم مختلف قليلاً. لكن أداة المقارنة بكسل بكسل تكتشفها فورًا وتُسجِّلها كانحدارات تتطلب تحقيقًا.
وهذا ليس كل شيء. الخطوط المتاحة تختلف من نظام لآخر. إذا كان CSS الخاص بك يُحدِّد خطًا غير مُثبَّت على خادم CI، يستخدم المتصفح خطًا بديلاً تلقائيًا. هذا الاستبدال قد يُغيِّر التباعد بين الحروف، وارتفاع السطر، وعرض الأحرف الفردية — وبالتالي التخطيط بالكامل بشكل جذري.
محرك عرض المتصفح
حتى عند استخدام نفس المتصفح (Chrome مثلًا)، فإن الإصدار الدقيق لمحرك العرض يؤثر على النتيجة بشكل ملموس. لا يُنتج Chrome 120 نفس العرض بالضبط مثل Chrome 122 لبعض خصائص CSS.
الدقة والتحجيم
يؤثر DPI شاشتك بشكل مباشر على جودة ودقة العرض المُلتقَط. تُنتج شاشة Retina (2x) لقطات شاشة بدقة مختلفة تمامًا عن شاشة قياسية (1x). خوادم CI لا تمتلك شاشات فعلية عمومًا. إنها تستخدم مخزنًا مؤقتًا إطاريًا افتراضيًا (Xvfb على Linux) قد يختلف تكوين DPI الخاص به بشكل كبير عن محطة عمل التطوير الخاصة بك.
Docker: البيئة المتطابقة، في كل مرة
يحل Docker هذه المشاكل بتغليف بيئة الاختبار بالكامل في حاوية. نفس نظام التشغيل، نفس الخطوط، نفس المتصفح، نفس الإصدار، نفس تكوين العرض — سواء أُطلِقت الحاوية على محطة عمل macOS، أو عامل تشغيل GitHub Actions على Linux، أو مثيل EC2.
ما يجب أن تحتويه الحاوية
يجب أن تتضمن حاوية Docker للاختبار البصري: جميع الخطوط التي يستخدمها تطبيقك (مُثبَّتة محليًا، وليس مُحمَّلة على الهواء)، ومتصفحًا بإصدار ثابت، وتكوين عرض صريح (fontconfig، وDPI المخزن المؤقت الإطاري الافتراضي، وإعدادات تنعيم الحواف)، والتبعيات النظامية التي يتطلبها المتصفح بدون واجهة.
صورة الأساس: لا تُعد اختراع العجلة من جديد
تتضمن الصور الرسمية لـ Playwright متصفحات وتبعيات بإصدارات مُغلَقة ومختبرة جيدًا. ابدأ من صورة تُثبت أنها تعمل. أضف خطوطك وتكوينك الخاص فوقها. لا تبدأ من الصفر إلا إذا كان لديك سبب مقنع ومحدد يتطلب بناءً مخصصًا بالكامل.
ملف Dockerfile كوثيقة حية ومُوثَّقة
ملف Dockerfile الخاص بك هو وصف شامل وقابل للتنفيذ لبيئة اختبارك بأكملها. عندما ينضم عضو جديد إلى الفريق، لا يحتاج إلى تخمين أي الخطوط يجب تثبيتها أو أي إصدار Chrome يجب استخدامه. يُطلق الحاوية ويحصل فورًا على نفس البيئة المتطابقة التي يمتلكها جميع أعضاء الفريق.
إعداد Docker للاختبار البصري: الخطوات الرئيسية
الخطوة 1: تثبيت الإصدارات بدقة
أدرِج كل ما يشارك في عرض صفحاتك — المتصفح، والخطوط، والمكتبات، ونظام التشغيل. ثبِّت كل عنصر على إصدار دقيق ومحدد. لا "latest"، ولا نطاقات دلالية. في الاختبار البصري، "أي إصدار يعمل" مرادف لـ "إيجابيات كاذبة لا حصر لها."
الخطوة 2: بناء الصورة
ابدأ من صورة أساسية تتضمن المتصفح بإصدار ثابت. أضف الخطوط وتكوين fontconfig والأدوات اللازمة. رتِّب التعليمات من الأقل تغيُّرًا (نظام التشغيل، المتصفح، الخطوط) إلى الأكثر تغيُّرًا (كود التطبيق، ملفات الاختبار) لتحسين ذاكرة التخزين المؤقت للبناء.
الخطوة 3: التحقق من قابلية الاستنساخ
ابنِ الصورة. شغِّل الاختبارات البصرية ووثِّق النتائج. ابنِ الصورة مرة أخرى من نفس الملفات. أعد تشغيل الاختبارات. يجب أن تكون النتائج متطابقة تمامًا. تحقق على جهازين مختلفين للتأكد من أن الحاوية تُنتج نفس النتائج بغض النظر عن بيئة الاستضافة.
الخطوة 4: التكامل مع خط أنابيب CI/CD
ادفع صورتك إلى سجل (registry) وأشر إليها في تكوين CI الخاص بك. عند تحديث الصورة، أعد توليد خطوط الأساس.
الخطوة 5: إدارة التحديثات
حدِّد إيقاع تحديث شهري. حدِّث إصدار المتصفح في ملف Dockerfile، وأعد البناء، وأعد تشغيل الاختبارات، وفحص الاختلافات، وحدِّث خطوط الأساس للتغييرات المتوقعة.
فوائد تتجاوز قابلية الاستنساخ
التوازي
تبدأ حاويات Docker في ثوانٍ معدودة. أطلِق 10 أو 20 أو 50 حاوية بالتوازي لاختبار عدد مماثل من الصفحات في الوقت نفسه. اختبارات كانت تستغرق 30 دقيقة تسلسليًا يمكن أن تُنجَز في 3 دقائق بالتوازي.
عزل الاختبارات
تبدأ كل حاوية من حالة نظيفة تمامًا. لا ذاكرة مخبئية متبقية للمتصفح، ولا ملفات تعريف ارتباط (cookies) باقية من اختبار سابق. يبدأ كل اختبار في بيئة نظيفة كما لو كان أول تشغيل، مما يُلغي فئة كاملة من الإيجابيات الكاذبة المرتبطة بتلوث الحالة بين الاختبارات.
موقع Delta-QA في هذا النهج
يُبسِّط Delta-QA معادلة Docker بشكل كبير. تحليله الهيكلي أقل حساسية بطبيعته لتباينات العرض بين البيئات المختلفة. حين تُسجِّل أداة المقارنة بكسل بكسل كل اختلاف فرعي ناتج عن تباين عرض الخطوط، يحلل Delta-QA خصائص CSS المحسوبة — الهوامش، والحشوات، والأبعاد، والتموضع — وهي قيم متطابقة بغض النظر عن بيئة العرض.
هذا لا يعني أن Docker غير ضروري مع Delta-QA. تظل البيئة القابلة للاستنساخ أفضل ممارسة. لكن التسامح مع تباينات البيئة أعلى بما لا يُقارن مقارنة بأدوات المقارنة البكسلية التقليدية. بالنسبة للفرق التي لا تستطيع أو لا ترغب في الاستثمار في بناء صورة Docker مخصصة، فهذه ميزة حاسمة. يُقدِّم Delta-QA نتائج موثوقة حتى في البيئات غير المثالية.
أخطاء شائعة يجب تجنبها
استخدام "latest" كعلامة للصورة
هذا هو السبب الأول للاختبارات غير المستقرة في سياقات Docker. ثبِّت إصدارًا دقيقًا وحدِّثه بطريقة مُتحكَّم بها.
نسيان الخطوط
إذا كان تطبيقك يستخدم Inter وRoboto وخطًا مخصصًا، ثبِّتها جميعًا محليًا في الحاوية عبر ملف Dockerfile. لا تعتمد على التحميل التلقائي من Google Fonts.
تجاهل حجم الـ viewport
شاشة افتراضية بدقة 1920×1080 لا تعني بالضرورة أن الـ viewport بحجم 1920×1080 بكسل. عيِّن الـ viewport بشكل صريح في أداة الاختبار البصري.
عدم تعيين إصدار للصورة
ادفع الصور إلى سجل، ووسِّمها بتجزئة (hash) أو تاريخ، وأشر إلى العلامة الدقيقة في خط أنابيب CI.
الأسئلة الشائعة
هل Docker إلزامي للاختبار البصري؟
لا، لكن بدون Docker (أو آلية مكافئة لضمان بيئة قابلة للاستنساخ)، ستقضي وقتًا كبيرًا في إدارة الإيجابيات الكاذبة الناتجة عن اختلافات العرض بين الأجهزة المختلفة.
أي صورة Docker أساسية تنصحون بها؟
الصور الرسمية لـ Playwright (mcr.microsoft.com/playwright) نقطة انطلاق ممتازة.
هل Docker يُبطئ الاختبارات البصرية؟
يضيف بدء الحاوية بضع ثوانٍ فقط. في المقابل، يُتيح Docker توازيًا هائلًا يُقلل من الوقت الإجمالي بشكل ملحوظ، مما يؤدي عادةً إلى توازن إيجابي صافٍ في وقت التنفيذ.
كيف أتعامل مع Google Fonts في حاوية Docker؟
حمِّل ملفات الخطوط وثبِّتها محليًا في الحاوية عبر ملف Dockerfile. لا تعتمد على التحميل التلقائي من خوادم Google في وقت التشغيل.
هل يمكن استخدام Docker Desktop للاختبار البصري المحلي؟
نعم، وهو مُوصَى به أثناء التطوير. تُشغِّل نفس الحاوية المُستخدَمة في CI على محطة عمل التطوير الخاصة بك.
هل يتطلب Delta-QA Docker ليعمل؟
لا. يعمل Delta-QA بدون Docker بفضل نهج التحليل الهيكلي، الذي أقل حساسية بطبيعته لتباينات العرض. يظل Docker أفضل ممارسة لأقصى قابلية للاستنساخ، لكنه ليس شرطًا مسبقًا لنتائج موثوقة مع Delta-QA.
للمزيد من القراءة
- الاختبار البصري والمتصفحات Headless: ما يفعله Chromium بدون واجهة رسومية (وما لا يفعله) بلقطات الشاشة
- الاختبار البصري لـ Remix: لماذا يجعل إطار العمل Full-Stack الاختبار البصري أكثر أهمية
- الاختبار البصري لـ Ruby on Rails: لماذا لا تكفي View Specs وكيف يسدّ الاختبار البصري الفجوة
- الاختبار البصري في الرعاية الصحية: HIPAA و HDS ولماذا لقطات الشاشة الخاصة بك تمثل خطراً
لقطة شاشة تتغير من جهاز لآخر ليست اختبارًا. إنها ضوضاء. Docker يُحوِّل التقاطاتك إلى أدلة موثوقة وقابلة للاستنساخ.