اختبارات الصور المرجعية للواجهات: متى تكشف خللًا ومتى تصنع إنذارًا كاذبًا؟

لماذا قد يفشل اختبار صورة والواجهة سليمة؟

تلتقط أداة الاختبار صورة لصفحة ثم تقارنها بصورة مرجعية محفوظة. تبدو الفكرة بسيطة: أي اختلاف بكسلات يعني تغييرًا. لكن الخطوط قد تُرسم بشكل مختلف بين نظامين، وقد يتحرك مؤشر تحميل أو إعلان أو وقت معروض دون وجود خلل. وفي الاتجاه الآخر، قد تمر صورة مشابهة رغم اختفاء زر مهم إذا كان الاختبار يقص جزءًا غير مناسب من الشاشة. لهذا يجب أن يُصمم الاختبار البصري بوصفه وسيلة لرصد التغييرات، لا حكمًا مطلقًا على جودة الواجهة. الحكم النهائي يحتاج فهمًا للسبب والأثر.

حدد السؤال الذي تريد من الصورة الإجابة عنه

هل تختبر محاذاة الهيدر، أم اتساق بطاقة منتج، أم عدم تداخل زر مع نافذة، أم شكل صفحة كاملة؟ كل سؤال يحتاج مساحة تصوير وبيئة وعتبة اختلاف مختلفة. التقاط الصفحة كلها لكل تعديل صغير يخلق ضوضاء كبيرة ويجعل المراجعة بطيئة. ابدأ بمكون ثابت ومهم، مثل نموذج تسجيل أو بطاقة سعر، ثم أضف لقطات للصفحات الحرجة. اكتب سبب وجود كل صورة مرجعية ومعيار قبولها، كي لا تصبح مجموعة صور قديمة لا يعرف أحد لماذا يجب أن تبقى مطابقة.

ثبت المتصفح والمنصة وحجم العرض

قد تختلف الصورة بين Chromium و Firefox أو بين Windows و Linux بسبب محرك الخطوط ومقاييس العرض. توثيق Playwright يوصي بمراعاة اختلاف الصور بين البيئات، حتى لو كان HTML نفسه. شغّل المقارنة في بيئة متسقة قدر الإمكان، مع إصدار متصفح معروف، وحجم نافذة ثابت، ومقياس جهاز محدد، وخطوط مثبتة. لا تعتبر اختلافًا بين جهاز مطور وخادم CI خطأ في CSS تلقائيًا. إذا كان دعم المنصات المتعددة هدفًا حقيقيًا، احتفظ بمراجع منفصلة أو استخدم فحوصًا دلالية مكملة بدل إجبار الجميع على صورة واحدة.

تأكد من اكتمال الحالة قبل التصوير

قد تُلتقط الصورة أثناء ظهور skeleton أو قبل تحميل خط الواجهة أو بعد بدء حركة انتقال. انتظار زمن ثابت طويل ليس حلًا موثوقًا؛ انتظر علامة جاهزية واضحة في التطبيق، وتحقق من تحميل الخطوط والصور الضرورية. إذا كانت هناك حركة CSS، يمكن تعطيل الرسوم المتحركة ضمن إعداد الاختبار عندما لا تكون الحركة نفسها موضوع الفحص. أما إذا كنت تختبر تأثير الانتقال، فالتقط نقاطًا زمنية محددة ومعروفة. لا تخفِ مؤشر تحميل لا ينتهي بمجرد تأخير الصورة؛ ذلك عطل وظيفي يجب أن يظهر في اختبار منفصل.

ميز المحتوى الديناميكي عن خلل التصميم

التاريخ والساعة واسم المستخدم وعدد الإشعارات والأسعار المتغيرة يمكن أن تغير الصورة دون تغيير التصميم. استخدم بيانات اختبار ثابتة أو اعزل المناطق الديناميكية المعروفة بعناية، مع تسجيل سبب العزل. لا تُخفِ أجزاء كبيرة من الشاشة لمجرد تقليل الإخفاقات؛ فقد تخفي بذلك خطأ حقيقيًا في محاذاة مكون مهم. الأفضل حقن بيانات تجريبية معروفة في بيئة اختبار، أو اختبار المكون وحده مع حالة محددة. إذا كانت البيانات تأتي من طرف ثالث، حدد ما تختبره أنت وما لا تتحكم فيه.

فهم عتبة الاختلاف قبل زيادتها

يمكن مقارنة الصور بكسلًا ببكسل أو باستخدام مقياس أكثر تسامحًا. رفع نسبة السماح حتى تختفي الأخطاء قد يجعل الاختبار يمر رغم انزياح مهم في الواجهة. لا توجد عتبة واحدة مناسبة لكل الصفحات؛ فاختلاف طفيف في تنعيم الخط قد يكون غير مؤثر، بينما اختفاء أيقونة تحذير صغيرة قد يكون حرجًا. حدد العتبة بناءً على طبيعة المكون ومساحة الصورة، ثم راجع أمثلة فشل ونجاح حقيقية. احتفظ بصورة فرق توضح مكان الاختلاف، ولا تعتمد على رقم النسبة وحده لاتخاذ قرار.

الخطوط العربية مصدر شائع للإنذارات الكاذبة

اختلاف نسخة خط عربي أو وزن محمّل من الشبكة قد يغير التفاف الأسطر وارتفاع البطاقة بالكامل. قد ينتقل عنوان إلى سطر جديد فيظهر مئات الآلاف من البكسلات المختلفة دون أن يكون هناك خطأ وظيفي. ثبت ملفات الخطوط وإعدادات العرض في بيئة الاختبار، وانتظر اكتمال تحميلها. اختبر في المقابل حالات عربية طويلة عمدًا حتى تكشف قص النصوص وتداخل الأزرار. لا تعالج كل اختلاف خط بزيادة العتبة؛ قد يكون تغيير التفاف النص مشكلة حقيقية عند حجم شاشة صغير أو تكبير النص.

RTL يحتاج سيناريوهات بصرية مستقلة

واجهة تعمل جيدًا بالإنجليزية قد تعرض أيقونة البحث في مكان خاطئ أو تقص حقلًا عربيًا عند التحويل إلى RTL. أنشئ صورًا مرجعية منفصلة لحالات اللغة والاتجاه المهمة، ولا تفترض أن قلب الصفحة أفقيًا ينتج واجهة صحيحة. افحص موضع القوائم المنسدلة واتجاه الأيقونات وأرقام الهواتف والنص المختلط. استخدم أحجام عرض متنوعة لأن خطأ RTL قد يظهر فقط عند ضيق المساحة. اربط الصورة باختبار دلالي يثبت أن الزر ما زال قابلًا للوصول، فالمظهر وحده لا يكشف كل أخطاء التفاعل.

اختبر التغيرات التي لا تراها صورة ثابتة

قد تكون الصورة مطابقة بينما الزر لا يستجيب للنقر أو حقل الإدخال فقد التسمية القابلة للوصول. لذلك يجب أن تكمل الصور المرجعية اختبارات الوظائف وإمكانية الوصول، لا أن تحل محلها. اختبر أيضًا حالات hover و focus والخطأ والتحميل والنجاح، إذا كانت مهمة للمكون. صورة الحالة الافتراضية لا تكشف نافذة تأكيد تظهر خارج الشاشة أو قائمة لا تفتح بلوحة المفاتيح. حدد مجموعة حالات ذات معنى تجاري بدل تصوير كل حالة ممكنة بلا أولوية. الاختبار البصري قوي في رصد الانزياحات والتداخل، لكنه محدود في إثبات السلوك.

متى تفضل اختبار مكون على صورة صفحة كاملة؟

إذا كان التغيير في زر أو بطاقة أو نموذج، فصورة المكون تقلل تأثير المحتوى المحيط وتحسن تفسير الفشل. أما اختبار الصفحة كاملة فيناسب كشف تغيرات التخطيط العام أو تداخل الهيدر والفوتر والسايدبار. يمكن الجمع بينهما: صور صغيرة سريعة لكل مكون حساس، وعدد محدود من صور الصفحات الرئيسية في أحجام عرض ممثلة. لا تجعل كل صفحة تحتوي مئات الصور المرجعية المتشابهة؛ تكاليف الصيانة قد تتجاوز الفائدة. ضع أسماء واضحة للصور تشير إلى المكون واللغة وحجم العرض والحالة المختبرة.

مثال: إعلان متحرك يفسد نتيجة سليمة

لنفترض أن صفحة مقال تعرض إعلانًا يتغير في كل تحميل. المقارنة الكاملة تفشل لأن صورة الإعلان مختلفة، بينما النص والعناوين والهوامش ثابتة. الحل ليس قبول كل فرق، بل استخدام مساحة إعلانية ثابتة ببيانات اختبار أو عزل محتوى الإعلان فقط مع الاستمرار في فحص أبعاده وعدم تغطيته للنص. إذا تحرك الإعلان وغطى زر القراءة، يجب أن يفشل اختبار التخطيط. بذلك تميز بين تغير المحتوى المسموح به وتغير هندسة الصفحة المؤثر. اكتب هذا التمييز في عقد الاختبار حتى لا يصبح العزل ثغرة في جودة المراجعة.

مثال آخر: زر مختفٍ لا يغير الصورة كثيرًا

قد يختفي زر حذف صغير من جدول طويل، فتظل نسبة البكسلات المتغيرة أقل من العتبة العامة. لو اكتفيت بنسبة الاختلاف، قد يمر الاختبار. أضف تحققًا دلاليًا من وجود الزر وعدد الأزرار المهمة، أو التقط صورة مركزة للصف الذي يحتويه. إذا كان الزر لا ينبغي أن يظهر لحساب محدود الصلاحيات، فاستخدم بيانات اختبار مختلفة لهذا الدور بدل تعديل المرجع عشوائيًا. هذه الحالة تشرح لماذا يجب ألا تساوي بين صغر المساحة وصغر الأثر؛ بعض التفاصيل الصغيرة تتحكم في وظائف حرجة.

إدارة تحديث الصور المرجعية دون اعتماد أعمى

عندما يتغير التصميم عن قصد، يجب تحديث المرجع بعد مراجعة الفرق ومقارنته بمتطلبات التغيير. لا تستخدم أمر تحديث كل الصور تلقائيًا لمجرد أن الاختبارات فشلت؛ قد تحفظ أخطاء جديدة باعتبارها الحقيقة. احتفظ بالنسخة السابقة في نظام التحكم بالإصدارات، واربط التحديث بطلب تغيير أو وصف مختصر. إذا تغيرت البيئة مثل إصدار المتصفح أو الخط، سجل ذلك في طلب المراجعة. يمكن أن يراجع المصمم أو المطور الصور المختلفة على دفعات، لكن يجب أن تبقى هناك إمكانية لرفض فرق غير متوقع حتى مع نجاح اختبارات الوظائف.

اجعل تقرير الفشل قابلًا للفهم

أفضل تقرير يعرض الصورة المرجعية والصورة الحالية وصورة الفرق، مع معلومات المتصفح والمنصة واللغة وحجم العرض ومقياس الشاشة. أضف اسم المكون وحالته ووقت التصوير، واذكر إن كانت هناك مناطق مستثناة. إذا كان الاختلاف محصورًا في ساعة ديناميكية، ينبغي أن يراه المراجع فورًا. إذا كان هناك انزياح عام بسبب خط غير محمل، ينبغي أن يربط التقرير ذلك بحالة الخطوط. تجنب إرسال صور تحتوي بيانات عملاء حقيقية إلى خدمات خارجية؛ استخدم حسابات اختبار وبيانات اصطناعية قبل حفظ اللقطات.

مصفوفة اختيار بين الأدوات البصرية والدلالية

استخدم مقارنة الصور لرصد المحاذاة والتداخل والتباعد والتغيرات غير المقصودة في التصميم. استخدم اختبارات DOM للتحقق من النصوص والسمات والأزرار، واختبارات الشبكة للتحقق من البيانات، واختبارات إمكانية الوصول لمسار التركيز والأسماء الدلالية. قد تحتاج صفحة الدفع إلى الأنواع الأربعة، بينما تكفي بطاقة تعريف بسيطة صورة ومراجعة محتوى. لا تضع مقياس نجاح واحدًا لكل فريق؛ اجعل لكل اختبار سؤالًا واضحًا وتكلفة صيانة مقبولة. النجاح الحقيقي هو تقليل أخطاء تصل إلى المستخدم دون خلق ضوضاء تعطل التطوير.

الخلاصة والمراجع

اختبار الصورة المرجعية يصبح مفيدًا عندما تثبت البيئة والحالة، وتحدد منطقة المقارنة، وتراجع الفرق في سياقه. يصبح مضللًا عندما تُرفع العتبة بلا تفسير أو تُحدّث الصور تلقائيًا بعد كل فشل. راجع توثيق Playwright عن المقارنات البصرية: https://playwright.dev/docs/test-snapshots ، وعن لقطات الشاشة: https://playwright.dev/docs/screenshots . وللمقارنة داخل إيجي تاج، اقرأ «خطة اختبار تغييرات CSS قبل النشر على الهواتف والشاشات الكبيرة». الصور تكشف جانبًا مهمًا من الجودة، لكنها لا تثبت صحة التفاعل أو البيانات أو إمكانية الوصول وحدها.