الاختبار البصري مع Selenium: «مقاربة تستخدم إطار عمل Selenium WebDriver لالتقاط صور واجهات الويب ومقارنتها بلقطات مرجعية بصرية، بهدف اكتشاف الانحدارات البصرية غير المقصودة في مظهر التطبيق.»
Selenium هو إطار عمل الاختبار الآلي الأكثر استخدامًا في العالم. مع أكثر من 22,000 عملية بحث شهرية لعبارة «selenium webdriver» وحدها، من الواضح أن مجتمع ضمان الجودة العالمي لا يزال يدور إلى حد كبير حول هذه الأداة. وهذا له ما يبرره: منذ عام 2004، حدد Selenium معنى «أتمتة المتصفح».
لكن هنا تكمن المشكلة التي لا يريد أحد سماعها حقًا: لم يُصمَّم Selenium للاختبار البصري. إنه يتفوق في الاختبار الوظيفي — التحقق من أن زرًا يعمل، وأن نموذجًا يُرسل البيانات، وأن صفحة تُحمَّل بشكل صحيح. أما عندما يتعلق الأمر بالتحقق من أن تلك الصفحة تبدو كما ينبغي، فإن Selenium ينظر إليك بملل روبوت طُلب منه تحكيم مسابقة جمال.
هذا المقال ليس دليلًا تعليميًا يعدك بأن Selenium يستطيع فعل كل شيء. إنه دليل صادق يستكشف ما هو ممكن، وما هو مؤلم، وما يستحق حلًا أفضل.
المحتويات
- لماذا أصبح الاختبار البصري ضروريًا
- ما يستطيع Selenium فعله (وما لا يستطيع)
- المقاربة 1: لقطات الشاشة والمقارنة الخارجية
- المقاربة 2: الإضافات والمكتبات الخارجية
- المقاربة 3: التكامل مع Applitools
- الحكم النهائي: Selenium مخصص للاختبار الوظيفي
- البديل المخصص للاختبار البصري
- الأسئلة الشائعة
لماذا أصبح الاختبار البصري ضروريًا
لفترة طويلة، كان اختبار البرمجيات يتلخص في سؤال ثنائي: «هل يعمل؟». هل يُرسل الزر النموذج؟ هل تعرض الصفحة البيانات الصحيحة؟ هل تنتهي رحلة المستخدم بعملية دفع ناجحة؟
هذه الأسئلة تبقى جوهرية. لكن في عام 2026، لم تعد كافية.
يُصدر المستخدمون المعاصرون حكمهم على تطبيق ما في أقل من 50 مللي ثانية — وهو الوقت الذي يحتاجه الدماغ البشري لتشكيل انطباع بصري أولي، وفقًا لدراسة أجرتها جامعة كارلتون في كندا. زر يعمل لكنه منزاح بمقدار 20 بكسل، نص يتجاوز حاويته، سمة داكنة تعرض نصًا أسود على خلفية رمادية — كل هذا «يعمل» بالمعنى الوظيفي، لكنه يُدمّر تجربة المستخدم.
الاختبار البصري يسد هذه الفجوة. إنه لا يتحقق مما يفعله التطبيق، بل مما يعرضه. وفي عالم تتغير فيه الواجهات في كل سبرنت، لم يعد اكتشاف الانحدارات البصرية تلقائيًا ترفًا — بل ضرورة حتمية لحماية تجربة المستخدم.
المشكلة؟ أدوات الاختبار الوظيفي مثل Selenium لم تُصمَّم قط لهذا الغرض.
ما يستطيع Selenium فعله (وما لا يستطيع)
Selenium WebDriver أداة استثنائية لما صُمِّم من أجله: قيادة متصفح والتفاعل مع عناصر الويب. يستطيع النقر والكتابة والتنقل والانتظار والتحقق من وجود العناصر أو محتواها في DOM.
ما يستطيع Selenium فعله على الصعيد البصري يتلخص في شيء واحد بالضبط: takeScreenshot(). هذه الطريقة تلتقط الحالة الحالية للمتصفح كصورة PNG. هذا كل شيء. لا مقارنة، لا فروقات، لا عتبات تسامح، لا إخفاء للمناطق الديناميكية.
الأمر أشبه بأن يُعطوك كاميرا ويُقال لك: «ها أنت، أصبحت مصورًا محترفًا». أداة الالتقاط موجودة، لكن كل العمل الإبداعي — والتقني — لا يزال أمامك.
إليك ما لا يستطيع Selenium فعله محليًا:
- مقارنة لقطتَي شاشة
- اكتشاف الفروق البصرية بين نسختين من صفحة
- إدارة اللقطات المرجعية (baselines) للانحدار البصري
- تصفية الضوضاء البصرية (anti-aliasing، الرسوم المتحركة، المحتوى الديناميكي)
- إنشاء تقارير بصرية تفصيلية عن الفروقات
- تحديث اللقطات المرجعية تلقائيًا عندما يكون التغيير مقصودًا
للحصول على كل ذلك، يجب عليك البناء أو التكامل مع أدوات خارجية. لنستعرض الخيارات المتاحة.
المقاربة 1: لقطات الشاشة والمقارنة الخارجية
المقاربة الأكثر بساطة — والأكثر إيلامًا — تتمثل في استخدام takeScreenshot() من Selenium لالتقاط الصور، ثم مقارنتها بمكتبة معالجة صور خارجية.
المبدأ
تأخذ لقطة شاشة لصفحتك باستخدام Selenium. تخزنها كلقطة مرجعية. في المرة التالية التي تشغّل فيها الاختبار، تأخذ لقطة جديدة وتقارنها بكسل بكسل مع المرجع. إذا تجاوزت الفروق عتبة معينة، يفشل الاختبار.
أدوات المقارنة الشائعة
تسمح عدة مكتبات مفتوحة المصدر بمقارنة الصور: pixelmatch (JavaScript)، Pillow أو scikit-image (Python)، ImageMagick (سطر الأوامر). لكل منها نقاط قوتها، لكن لا واحدة منها مصممة خصيصًا لاختبار واجهات الويب.
ما يجب عليك بناؤه بنفسك
في الممارسة العملية، تُجبرك هذه المقاربة على أن تصبح مهندسًا معماريًا لإطار عمل مصغر للاختبار البصري. عليك إدارة تخزين وإصدار اللقطات المرجعية، ومنطق المقارنة بعتبات قابلة للتكوين، وإخفاء المناطق الديناميكية (التواريخ، الإعلانات، المحتوى المخصص)، والتعامل مع الدقات وأحجام العرض المختلفة، وتقارير عملية تُظهر الفروق بوضوح، وسير عمل لتحديث المراجع عند التغييرات المقصودة.
الحدود
هذه المقاربة تمنحك أكبر قدر من التحكم، لكنها أيضًا الأكثر تطلبًا للاستثمار. تقضي وقتًا أطول في صيانة بنيتك التحتية للاختبار البصري أكثر مما تقضيه في كتابة اختبارات فعلية. وكل تحديث للمتصفح، كل تغيير في عرض الخطوط يمكن أن يولّد إيجابيات كاذبة تُغرق الانحدارات الحقيقية في بحر من التنبيهات.
تخيل مساعدًا بدلًا من مساعدتك في إيجاد الأخطاء في مستند، يقضي وقته في وضع خط تحت كل فاصلة سائلًا إياك إن كانت في مكانها الصحيح. دقيق تقنيًا، لا يُطاق عمليًا.
المقاربة 2: الإضافات والمكتبات الخارجية
لتجنب بناء كل شيء من الصفر، أنشأ المجتمع مكتبات تضيف قدرات الاختبار البصري فوق Selenium. من أشهرها:
Ashot (Java)
Ashot مكتبة Java تُوسّع قدرات التقاط الشاشة في Selenium. تسمح بالتقاط الصفحات الكاملة (بما في ذلك المحتوى خارج الشاشة عبر التمرير)، ومقارنة الصور مع إبراز الفروقات، والاقتصاص حسب عنصر محدد.
إنها الخيار الأكثر شعبية في بيئة Java/Selenium، لكنها تبقى أداة منخفضة المستوى. لديك الطوب، لكن البيت عليك بناؤه بنفسك.
needle (Python)
needle إضافة pytest تدمج Selenium مع مقارنة الصور. تقارن لقطات الشاشة لصفحات كاملة أو عناصر محددة، تستخدم Pillow للمقارنة، وتتكامل بسلاسة مع pytest.
شهد المشروع فترات من عدم النشاط، والتوثيق قد يكون ناقصًا. إنه خيار مقبول لاحتياجات متواضعة، لكنه يُظهر حدوده في المشاريع الحقيقية ذات الحجم الكبير.
BackstopJS
BackstopJS ليست بالضبط إضافة Selenium — إنها أداة مستقلة تستخدم Puppeteer أو Playwright في الخلفية. لكنها تستحق الذكر لأن العديد من فرق Selenium تضيفها كمكمّل للاختبار البصري.
تقدم BackstopJS تهيئة تصريحية بصيغة JSON، والتقاطات متعددة عبر أبعاد عرض مختلفة، وتقرير HTML تفاعلي، وسير عمل approve/reject لإدارة التغييرات.
إنها على الأرجح الأداة مفتوحة المصدر الأكثر نضجًا للاختبار البصري. لكنها لا تتكامل مباشرة مع اختبارات Selenium الحالية — إنها أداة منفصلة بخط أنابيب خاص بها.
الحدود المشتركة للإضافات
تتشارك جميع هذه الأدوات في قيود جوهرية. تتطلب مهارات تطوير للإعداد والصيانة المستمرة. تعتمد على مشاريع مفتوحة المصدر لا يُضمن استمراريتها — يُغيّر مشرف واحد وظيفته فيتباطأ نظام بيئي بأكمله. تضيف تعقيدًا إلى مكدّسك التقني دون حل المشاكل البنيوية للمقارنة بكسل بكسل. والأهم من ذلك كله، إنها تبقى أدوات للمطورين، غير متاحة لبقية أعضاء الفريق.
المقاربة 3: التكامل مع Applitools
الطريق الثالث هو التكامل مع خدمة سحابية مخصصة للاختبار البصري. Applitools Eyes هو الأكثر شهرة في هذه الفئة.
المبدأ
يوفر Applitools حزمة تطوير برمجية (SDK) تتكامل مباشرة مع Selenium. يتم تعزيز اختبارات Selenium الحالية باستدعاءات واجهة برمجة تطبيقات Applitools التي ترسل لقطات الشاشة إلى سحابتهم للمقارنة والتحليل.
ما يقدمه Applitools
يستخدم Applitools تقنية مقارنة قائمة على الذكاء الاصطناعي («Visual AI» الخاصة بهم) أذكى بكثير من المقارنة البكسل بكسل التقليدية. تفهم بنية الصفحة، وتتجاهل الفروق غير المهمة، وتكتشف الانحدارات البصرية الحقيقية بمعدل إيجابيات كاذبة منخفض بشكل ملحوظ.
تسمح لوحة المعلومات السحابية لكامل الفريق — وليس للمطورين فقط — برؤية النتائج، والموافقة على التغييرات، ومتابعة حالة الاختبارات البصرية في الوقت الفعلي.
الحدود
الراحة لها ثمنها. Applitools خدمة سحابية مدفوعة تزداد تكلفتها مع حجم اللقطات الملتقطة. صور واجهتك تغادر بنيتك التحتية لتُعالج على خوادمهم — نقطة حساسة بالنسبة لبعض المنظمات ذات متطلبات الأمان الصارمة. وتبقى معتمدًا على خدمة طرف ثالث: إذا تعطل Applitools، تتعطل اختباراتك البصرية معه.
التكامل عبر حزمة التطوير يعني أيضًا أنك لا تزال بحاجة لكتابة وصيانة اختبارات Selenium. لقد بسّطت عملية المقارنة، لكن لم تبسّط إنشاء سيناريوهات الالتقاط. إنه أفضل بالتأكيد من فعل كل شيء بنفسك — كاستخدام نظام الملاحة GPS بدلًا من خريطة ورقية، الطريق نفسه لكنك تضل أقل.
الحكم النهائي: Selenium مخصص للاختبار الوظيفي
بعد استكشاف المقاربات الثلاث، تفرض نفسها خلاصة واضحة: Selenium أداة اختبار وظيفي، ومحاولة تطعيمها بقدرات اختبار بصري أشبه بتركيب حامل دراجات على دراجة نارية — يصمد، لكنها لم تكن الفكرة الأصلية أبدًا.
لكل مقاربة مزاياها، لكن لا واحدة منها تحل المشكلة الجوهرية: الاختبار البصري والاختبار الوظيفي تخصصان مختلفان يستحقان أدوات مختلفة.
الاختبار الوظيفي يتحقق من السلوك. يُجيب عن السؤال: «هل يفعل ما يُفترض به أن يفعله؟». DOM والأحداث والبيانات — هذا هو مجال Selenium، وفيه يتفوق بلا منازع.
الاختبار البصري يتحقق من المظهر. يُجيب عن السؤال: «هل يبدو كما يُفترض به أن يبدو؟». البكسلات والتخطيطات والعرض المرئي — هذا مجال يزوره Selenium كسائح عابر.
واصل استخدام Selenium لاختباراتك الوظيفية. إنها الأداة المناسبة لذلك. لكن للاختبار البصري، فكّر جديًا في أداة صُمِّمت من الأساس لهذه المهمة تحديدًا.
البديل المخصص للاختبار البصري
Delta-QA موجود تحديدًا لأن الاختبار البصري لا ينبغي أن يكون منتجًا فرعيًا مُرتجلًا من اختباراتك الوظيفية. إنها أداة مخصصة، صُمِّمت من السطر الأول للكشف عن الانحدارات البصرية وحماية مظهر واجهاتك.
إليك ما يتغير مع نهج مخصص حقيقي:
بدون كود، حقًا: لا تحتاج إلى Selenium أو WebDriver أو أي مهارة برمجية على الإطلاق. تُشير إلى صفحاتك، وDelta-QA يتولى الباقي. محلل ضمان الجودة، المصمم، مالك المنتج — الجميع يستطيع إطلاق وتفسير الاختبارات البصرية بسهولة.
مقارنة ذكية: Delta-QA لا يكتفي بمقارنة البكسلات. يفهم الفروقات ذات المغزى الحقيقي ويُصفّي الضوضاء التقنية (anti-aliasing، اختلافات العرض، المحتوى الديناميكي). النتيجة: إيجابيات كاذبة أقل، وانحدارات بصرية حقيقية أكثر اكتشافًا.
تنفيذ محلي بالكامل: لقطات الشاشة تبقى على بنيتك التحتية. لا بيانات مُرسلة إلى سحابة طرف ثالث، لا اعتماد على خدمة خارجية، لا فاتورة تتضخم مع حجم الاستخدام.
مجاني وبلا حدود مصطنعة: لا يوجد مستوى «enterprise» لفتح الميزات الأساسية، ولا عدّاد لقطات يُجبرك على تقنين اختباراتك.
مكمّل لـ Selenium: Delta-QA لا يحل محل اختبارات Selenium الوظيفية. إنه يكمّلها بتغطية البُعد البصري الذي لا يستطيع Selenium معالجته محليًا.
الاختبار البصري أهم من أن يُعامل كإضافة مُلحقة في اللحظة الأخيرة. مستخدموك يرون الواجهة قبل أن يتفاعلوا معها. إذا كانت تلك الواجهة مكسورة بصريًا، لن يبقوا وقتًا كافيًا ليكتشفوا أن كل اختباراتك الوظيفية تجتاز بنجاح.
الأسئلة الشائعة
هل يستطيع Selenium إجراء اختبار بصري محليًا؟
لا. يسمح Selenium WebDriver بأخذ لقطات شاشة عبر takeScreenshot()، لكنه لا يقدم أي وظيفة محلية لمقارنة الصور أو إدارة اللقطات المرجعية البصرية أو اكتشاف الانحدارات البصرية بشكل تلقائي. كل شيء يجب بناؤه يدويًا أو تكامله مع أدوات خارجية.
ما هي أفضل مكتبة للاختبار البصري مع Selenium؟
يعتمد ذلك على بيئتك التقنية. في Java، Ashot هو الخيار الأكثر شيوعًا. في Python، تقدم needle تكاملًا سلسًا مع pytest. لحل أكثر شمولًا، غالبًا ما يُفضَّل BackstopJS (الذي يستخدم Puppeteer/Playwright بدلًا من Selenium). لا يوجد حل من هذه الحلول متكاملًا كما يقدم Playwright محليًا.
هل يستحق Applitools تكلفته للاختبار البصري؟
تقنية Visual AI من Applitools مبهرة وتقلل بشكل ملحوظ من الإيجابيات الكاذبة. للشركات الكبيرة ذات الميزانيات المريحة والمتطلبات العالية، إنه خيار قوي وموثوق. للفرق الأصغر أو المهتمة بخصوصية البيانات، قد تكون التكاليف والاعتماد على السحابة عائقًا حقيقيًا. توجد بدائل محلية مجانية مثل Delta-QA.
هل يجب التخلي عن Selenium للاختبار البصري؟
لا. يبقى Selenium ممتازًا للاختبار الوظيفي ويجب أن يستمر في أداء هذا الدور. الفكرة ليست استبدال Selenium، بل تكميله بأداة مخصصة للاختبار البصري. التخصصان متكاملان، وأفضل النتائج تأتي من استخدام الأداة المناسبة لكل حاجة.
هل الاختبار البصري ضروري حقًا إذا كانت لديك اختبارات وظيفية شاملة؟
بالتأكيد. تتحقق الاختبارات الوظيفية من السلوك (هل يعمل الزر؟) لكن ليس من المظهر (هل الزر مرئي، في موضعه الصحيح، باللون الصحيح؟). وفقًا لتقرير Web Almanac من HTTP Archive، تمثل مشاكل التخطيط حصة كبيرة من الأخطاء التي يُبلغ عنها المستخدمون — أخطاء لا تكتشفها الاختبارات الوظيفية أبدًا.
كيف يُقارن Delta-QA بنهج Selenium + Applitools؟
Delta-QA بدون كود (لا حاجة لـ Selenium أو SDK)، محلي بالكامل (لا سحابة طرف ثالث)، ومجاني. نهج Selenium + Applitools يتطلب مهارات تطوير، يُرسل البيانات إلى سحابة Applitools، ويتضمن تكلفة متكررة. صُمِّم Delta-QA للفرق التي تريد اختبارًا بصريًا متاحًا للجميع، بدون أي اعتماد خارجي.
للمزيد من القراءة
- اختبار الانحدار البصري: الدليل الشامل 2026
- إمكانية الوصول WCAG والاختبار البصري: الدليل لاكتشاف التراجعات
مستعد لفصل اختباراتك البصرية عن اختباراتك الوظيفية؟