الاختبار البصري لتطبيقات Electron: الويب في غلاف سطح مكتب، والأخطاء كهدية

النقاط الرئيسية

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

يُعرَّف Electron في وثائقه الرسمية بأنه "إطار عمل لبناء تطبيقات سطح مكتب أصلية بتقنيات الويب (HTML، CSS، JavaScript)، يجمع بين Chromium للعرض وNode.js للوصول إلى وظائف النظام، في بيئة تشغيل واحدة متعددة المنصات" (Electron Documentation، electronjs.org).

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

إذا كنت تطور تطبيق Electron — ومن المرجح أنك تستخدم عدة تطبيقات (VS Code، Slack، Discord، Figma، Notion، Obsidian) — فإن هذا المقال سيوضح لك لماذا يستحق الاختبار البصري لتطبيق سطح المكتب الخاص بك اهتمامًا خاصًا، ولماذا معاملته "كالويب" ليست كافية لكنها تبقى نقطة البداية الصحيحة.

Electron يرث جميع المشاكل البصرية للويب

CSS لا يزال CSS

تطبيق Electron الخاص بك يستخدم نفس محرك العرض مثل Chrome (Chromium، عبر مشروع Electron الذي يُضمّن نسخة محددة من Chromium). هذا يعني أن جميع المشاكل البصرية للويب تنطبق: انحدارات CSS بعد تحديث المكتبات، تجاوز النص، مشاكل z-index، الصور غير المحجمة بشكل صحيح، الرسوم المتحركة المتقطعة، الخطوط التي لا تُحمَّل.

إذا كنت قد أجريت بالفعل اختبارًا بصريًا للويب، فأنت تعرف هذه المشاكل. وهي موجودة بالضبط في Electron بنفس القدر.

لكن هنا الفخ: العديد من الفرق التي تطور تطبيقات Electron لا تأتي من الويب. تأتي من تطوير سطح المكتب الأصلي (C++، C#، Java Swing) حيث مشاكل عرض CSS غير موجودة. يكتشفون هذه المشاكل لأول مرة، بدون الخبرة أو الأدوات للتعامل معها.

تحديثات Chromium: الخطر الصامت

كل تحديث رئيسي لـ Electron يتضمن نسخة جديدة من Chromium. وكل نسخة جديدة من Chromium يمكن أن تغير العرض بشكل طفيف. تعديل في antialiasing تحت البكسل، تغيير في حسابات التقريب، تطور في معالجة الخطوط — هذه التغييرات نادرًا ما تُوثَّق كتغييرات كاسرة، لكنها يمكن أن تسبب انحدارات بصرية قابلة للقياس.

ينشر فريق Electron نسخة رئيسية جديدة تقريبًا كل ثمانية أسابيع. وفقًا لمدونة Electron الرسمية، تتضمن كل نسخة رئيسية نسخة من Chromium ونسخة من Node.js ونسخة من V8. هذا كثير من أسطح التغيير المحتملة.

إذا لم تجرِ اختبارات بصرية قبل وبعد كل تحديث Electron، فأنت تقبل خطرًا صامتًا للانحدار عبر واجهتك بالكامل.

خصوصيات سطح المكتب التي تغير كل شيء

النافذة القابلة لتغيير الحجم: التصميم المتجاوب تحت الستيرويد

على الويب، يعني "التصميم المتجاوب" تكييف التخطيط مع عدد محدود من نقاط التوقف المُعرَّفة مسبقًا (جوال، جهاز لوحي، سطح مكتب). منافذ العرض الممكنة متعددة لكنها محدودة بأحجام الشاشات الموجودة.

على سطح المكتب، يمكن لنافذة تطبيق Electron أن تأخذ حرفيًا أي حجم، من 400×300 بكسل إلى 3840×2160، مرورًا بكل بُعد وسيط. المستخدمون يغيرون الحجم بحرية، وهم يفعلون ذلك فعلًا.

هذا يخلق طيفًا مستمرًا من التخطيطات الممكنة، وليس مجموعة منفصلة من نقاط التوقف. يجب أن يكون تطبيقك صحيحًا بصريًا عند أي حجم — والأحجام الوسيطة (تلك الموجودة بين نقاط التوقف) هي غالبًا حيث تظهر المشاكل.

تشمل سيناريوهات أخطاء تغيير الحجم النموذجية ما يلي:

شريط جانبي يتداخل مع المحتوى الرئيسي عندما تكون النافذة ضيقة جدًا لعرض كليهما لكنها واسعة جدًا لتفعيل وضع "المطوي".

جدول يتجاوز حاويته ويُنشئ تمريرًا أفقيًا غير متوقع عند عروض معينة.

أزرار إجراءات في ترويسة تتداخل عندما يكون المساحة الأفقية غير كافية لكن نقطة توقف الجوال لم تُبلغ بعد.

لوحة عائمة (مفتش، طرفية، لوحة الأوامر) تخرج من المنطقة المرئية عندما تكون النافذة صغيرة جدًا.

القوائم الأصلية: الواجهة التي لا تتحكم فيها

تطبيقات Electron يمكنها استخدام القوائم الأصلية لنظام التشغيل (شريط القوائم على macOS، قائمة النافذة على Windows وLinux). هذه القوائم يعرضها نظام التشغيل، وليس كود CSS الخاص بك. مظهرها يختلف حسب نظام التشغيل وإصداره وسمة النظام لدى المستخدم.

بصريًا، منطقة الانتقال بين القائمة الأصلية ومحتوى الويب الخاص بك هي مصدر متكرر للمشاكل. على macOS، شريط العنوان والقوائم يُداران من قبل النظام. على Windows، تستخدم العديد من تطبيقات Electron شريط عنوان مخصص (نافذة بدون إطار مع أزرار تحكم مُعاد إنشاؤها بـ CSS) لمظهر أكثر حداثة.

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

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

الشاشات المتعددة وDPI المتغير

بيئة سطح المكتب الحديثة غالبًا ما تعني حاسوبًا محمولًا بشاشة Retina (2x DPI) متصلًا بشاشة خارجية بدقة 1080p (1x DPI). ينقل المستخدمون تطبيقك من شاشة إلى أخرى. وعندما ينتقل التطبيق من شاشة 2x إلى شاشة 1x، يجب أن يُعاد عرض كل شيء بشكل صحيح.

المشاكل البصرية المرتبطة بـ DPI خبيثة بشكل خاص:

صور bitmap (PNG، JPG) مصممة لـ DPI واحد تظهر ضبابية على الشاشات عالية الدقة أو مُبكسلة على الشاشات منخفضة الدقة. يجب توفير الأيقونات والرسوم التوضيحية بدقات متعددة أو بصيغة متجهية (SVG).

حدود 1 بكسل لا تُعرض بنفس الطريقة في 1x و2x. على شاشة 2x، حدود CSS بقيمة 1 بكسل تساوي 0.5 بكسل فيزيائي، مما يمكن أن يجعلها غير مرئية أو غير متسقة حسب محرك العرض.

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

النصوص تخضع لـ antialiasing مختلف. قابلية قراءة خط رفيع يمكن أن تكون ممتازة عند 2x وضعيفة عند 1x. الاختيار الطباعي الذي يعمل على شاشة التطوير الخاصة بك (على الأرجح MacBook Retina) يمكن أن يكون كارثيًا على الشاشة الخارجية لمستخدمك.

شريط المهام والـ Dock وsystem tray

يتفاعل تطبيقك مع بيئة سطح المكتب من خلال أيقونة شريط المهام (Windows/Linux) والـ dock (macOS) وsystem tray. هذه الأيقونات الصغيرة (16×16 إلى 48×48 بكسل) يجب أن تكون لا تشوبها شائبة. شارات الإشعارات، تراكبات الحالة، القوائم السياقية — هذه عناصر بصرية يراها مستخدموك باستمرار، حتى عندما لا يكون تطبيقك في المقدمة.

ثلاثة أنظمة تشغيل: ثلاثة عروض، ثلاث مجموعات مشاكل

macOS: المرجع المتطلب

macOS غالبًا ما يكون منصة التطوير الأساسية. تشمل الخصوصيات البصرية أزرار إشارة المرور (الأحمر والأصفر والأخضر) على اليسار، عرض الخطوط بـ Core Text (أكثر "سمكًا" بصريًا عند نفس الوزن مقارنة بـ Windows)، والتعامل الأصلي مع الوضع المظلم الذي يجب أن يتناغم مع سمة تطبيقك.

Windows: تنوع التكوينات

Windows يوفر أعلى تنوع في التكوينات. الدقات تتراوح من 1366×768 (لا تزال تمثل 20% من الشاشات وفقًا لـ StatCounter في 2025) إلى 3840×2160. عوامل التحجيم (100% إلى 200%) تضيف تعقيدًا غير موجود على macOS.

عرض الخطوط بـ DirectWrite ينتج نتائج مختلفة بشكل ملحوظ عن Core Text: خطوط أنحف وأكثر حدة، وأحيانًا أقل قابلية للقراءة عند الأحجام الصغيرة. وضع "التباين العالي" لإمكانية الوصول يمكن أن يغير مظهر تطبيقك بشكل جذري إذا كانت أنماط CSS الخاصة بك لا تدعمه.

Linux: الحالة الخاصة

تشتت بيئات سطح المكتب (GNOME، KDE، XFCE) يصعّب التوحيد. لكن وفقًا لـ Stack Overflow Developer Survey 2024، حوالي 27% من المطورين يستخدمون Linux. إذا كان تطبيقك يستهدف المطورين، فإن Linux يستحق التغطية. الحد الأدنى القابل للتطبيق: Ubuntu مع GNOME.

استراتيجية الاختبار البصري لـ Electron

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

الخطوة الأولى هي تحديد التوليفات التي ستختبرها بشكل صريح. كحد أدنى، يجب أن تتضمن مصفوفتك ما يلي:

أنظمة التشغيل المستهدفة. macOS (الإصدار الأحدث والسابق)، Windows 10، Windows 11. Ubuntu LTS إذا كان جمهورك يبرر ذلك.

دقات الشاشة ذات الأولوية. لكل نظام تشغيل، الدقتان أو الثلاث الأكثر استخدامًا من قبل مستخدميك. على macOS: 1440×900 و2560×1600 (Retina). على Windows: 1920×1080 و1366×768. عدّل بناءً على بيانات التحليلات الفعلية لديك.

عوامل DPI. 1x و2x كحد أدنى. على Windows، أضف 1.5x (150%) وهو إعداد شائع جدًا.

أحجام النوافذ. ملء الشاشة، نصف الشاشة (شاشة مقسمة)، وحجم "الحد الأدنى الوظيفي" المُصغَّر. هذه الأحجام الثلاثة تغطي سيناريوهات الاستخدام الفعلية.

أتمتة الالتقاط على عدة أنظمة تشغيل

التحدي التقني الرئيسي للاختبار البصري لـ Electron هو التقاط لقطات شاشة عبر عدة أنظمة تشغيل. لديك عدة خيارات.

نهج CI متعدد المنصات. GitHub Actions وGitLab CI وAzure Pipelines تدعم مهام على macOS وWindows وLinux. قم بإعداد وظيفة اختبار بصري لكل نظام تشغيل تُطلق تطبيقك وتتنقل إلى الشاشات المراد اختبارها والتقط لقطات شاشة.

نهج Playwright. يدعم Playwright أتمتة Electron بشكل أصلي منذ الإصدار 1.20: إطلاق التطبيق، التفاعلات، التقاط لقطات الشاشة، كل ذلك عبر المنصات.

نهج Delta-QA. للفرق التي لا ترغب في صيانة سكريبتات، يقدم Delta-QA نهجًا بدون كود للالتقاط والمقارنة البصرية لشاشات تطبيقك.

المناطق ذات الأولوية للمراقبة

في تطبيق Electron، بعض المناطق أكثر عُرضة للانحدارات البصرية من غيرها. ركّز اختباراتك البصرية على هذه المناطق:

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

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

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

النوافذ المنبثقة والحواريات. صناديق الحوار الخاصة بالنظام (فتح ملف، حفظ، طباعة) أصلية ولا تتطلب اختبارًا بصريًا من جانبك. لكن النوافذ المنبثقة المخصصة لتطبيقك يجب اختبارها، خاصة توسيطها والتراكب وسلوكها عندما تكون النافذة صغيرة.

حالات التحميل والانتقالات. بدء تشغيل تطبيق Electron قد يستغرق بضع ثوانٍ. ما يراه المستخدم خلال هذا الوقت (شاشة الترحيب، شاشة التحميل، نافذة فارغة) هو جزء من التجربة ويستحق الاختبار البصري.

الأخطاء الأكثر شيوعًا

الاختبار على نظام تشغيل واحد فقط

هذا هو الخطأ الأكثر شيوعًا والأكثر تكلفة. إذا كانت فرقتك تطور على macOS وتختبر على macOS، فإن الأخطاء البصرية الخاصة بـ Windows وLinux تصل إلى الإنتاج دون تصفية. وWindows يمثل عادةً غالبية قاعدة مستخدمي Electron الخاصين بك (وفقًا لبيانات Electron Fiddle والعديد من تطبيقات Electron الشائعة، يمثل Windows غالبًا 60 إلى 70% من التثبيتات).

تجاهل عوامل DPI

الاختبار فقط عند 1x عندما نسبة كبيرة من مستخدميك عند 2x (أو العكس) هو وصفة للمفاجآت. مشاكل DPI دقيقة — نصوص ضبابية قليلًا، حدود اختفت، أيقونات مُبكسلة — لكنها تعطي انطباعًا بعدم الإتقان يُقوّض الثقة.

معاملة Electron كمتصفح ويب

تطبيق Electron ليس تبويب متصفح. إنه تطبيق سطح مكتب قام المستخدم بتثبيته، له مكانه الخاص في شريط المهام، ويُحكم عليه بمعايير التطبيقات الأصلية. المستخدمون يتسامحون مع موقع ويب تخطيطه معطوب قليلًا. لا يتسامحون مع تطبيق سطح مكتب مثبت يعاني من مشاكل بصرية واضحة.

إهمال أحجام النوافذ الوسيطة

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

الأسئلة الشائعة

Electron يستخدم Chromium، إذاً اختبارات الويب التقليدية كافية، أليس كذلك؟

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

كيف تتعامل مع اختلافات عرض الخطوط بين macOS وWindows؟

عرض الخطوط يختلف هيكليًا بين Core Text (macOS) وDirectWrite (Windows). الطريقة الموثوقة الوحيدة للتعامل مع هذه الاختلافات هي الحفاظ على baselines بصرية منفصلة لكل نظام تشغيل. لا تقارن لقطة شاشة macOS بلقطة Windows — ستكون مختلفة دائمًا، وهذه الاختلافات طبيعية. قارن macOS مع macOS، Windows مع Windows.

هل يجب اختبار كل تحديث لنسخة Electron؟

نعم، وهذا غير قابل للتفاوض. كل تحديث رئيسي لـ Electron يتضمن نسخة Chromium جديدة يمكن أن تغير العرض. الممارسة المثلى هي تشغيل مجموعة اختباراتك البصرية الكاملة قبل وبعد التحديث، ومقارنة النتائج، والتحقق من الاختلافات. بعض الاختلافات ستكون تحسينات في محرك العرض (يمكنك قبولها بتحديث baselines)، وأخرى ستكون انحدارات (يجب إصلاحها أو الإبلاغ عنها).

كيف تختبر وضع التباين العالي في Windows؟

وضع التباين العالي في Windows هو إعداد إمكانية الوصول يستبدل ألوان تطبيقك بمخطط ألوان عالي التباين. يمكنك تفعيله برمجيًا في بيئة اختبار CI (عبر إعدادات النظام أو أدوات الأتمتة). التقط لقطات شاشة في هذا الوضع واحتفظ بـ baseline مخصص. هذا مهم بشكل خاص إذا كان تطبيقك يستهدف بيئات مهنية حيث سياسات إمكانية الوصول صارمة.

تطبيق Electron الخاص بي يستهدف macOS فقط. هل الاختبار متعدد الأنظمة ضروري؟

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

ما التردد المثالي للاختبار البصري لتطبيق Electron؟

مع كل commit يمس الواجهة، ومع كل تحديث لنسخة Electron أو تبعيات واجهة المستخدم. عمليًا، ادمج الاختبار البصري في خط أنابيب CI/CD بحيث يعمل تلقائيًا عند كل pull request. تكلفة إيجابي خاطئ عرضي أقل بكثير من تكلفة انحدار بصري يُشحَن إلى آلاف مستخدمي سطح المكتب.

للمزيد من القراءة

Electron يمنحك قوة إنشاء تطبيقات سطح مكتب بتقنيات الويب. إنها قوة خارقة. لكن هذه القوة تأتي مع مسؤولية: أخطاء الويب البصرية تتبعك إلى سطح المكتب، وتنضم إليها مجموعة من المشاكل الخاصة بالبيئة الأصلية.

الخبر الجيد هو أنه إذا كنت تعرف بالفعل كيف تختبر الويب بصريًا، فلديك 80% من المهارات المطلوبة. الـ 20% المتبقية — مصفوفة الأنظمة المتعددة، عوامل DPI، النوافذ القابلة لتغيير الحجم، القوائم الأصلية — هي امتداد طبيعي لنهجك الحالي.

Electron يرث كل مشاكل الويب. اختبره كالويب، ثم اذهب أبعد.

جرّب Delta-QA مجانًا ←