اختبار أحجام الشاشات والنوافذ المختلفة

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

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

ما يجب اختباره

عند تطوير واجهات مستخدم مصمّمة لأحجام مختلفة للشاشة والنافذة، يجب الانتباه بشكل خاص إلى جانبَين:

  1. كيف تختلف السمات المرئية للمكوّنات والتخطيطات على النوافذ بأحجام مختلفة
  2. كيف يتم الاحتفاظ بالحالة عند إجراء تغييرات في الإعدادات

السمات المرئية

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

الشكل 1. شاشة "من أجلك" في تطبيق Now In Android بأحجام نوافذ مختلفة

قد لا يعرض تطبيقك أيضًا بعض المكوّنات في نظام التصميم على النحو المتوقّع عند توسيع قيود حجمها.

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

استعادة الحالة

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

الشكل 2. جهاز قابل للطي في حالات الطي والفتح بشكل مسطّح والفتح بشكل مسطّح مع تدويره إلى الوضع الأفقي والفتح حتى المنتصف (وضع سطح المنضدة).

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

هناك طرق متعددة لاختبار تغييرات الإعدادات، ولكن في معظم الحالات، هناك طريقتان للاختبار:

  • في Compose، استخدِم StateRestorationTester لمحاكاة تغيير في الإعدادات بطريقة فعّالة بدون إعادة تشغيل النشاط. لمزيد من المعلومات، يُرجى الاطّلاع على الأقسام التالية.
  • في أي اختبار لواجهة المستخدم، مثل Espresso أو Compose، حاكِ تغييرًا في الإعدادات من خلال طلب Activity.recreate().

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

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

لاختبار تغييرات الإعدادات التي تحدث على الأجهزة التي تنتقل من شاشة إلى أخرى أو تدخل وضع النوافذ المتعدّدة، تتوفّر خيارات متعددة:

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

أنواع الاختبارات لأحجام الشاشات والنوافذ المختلفة

يجب استخدام النوع المناسب من الاختبار لكل حالة استخدام للتحقّق من أنّ الاختبار يعمل بشكل صحيح على عوامل الشكل المختلفة:

  • تُشغّل اختبارات سلوك واجهة المستخدم جزءًا من واجهة مستخدم التطبيق، مثل عرض نشاط. تتحقّق الاختبارات من وجود عناصر معيّنة أو من أنّها تتضمّن سمات معيّنة . قد تُجري الاختبارات اختياريًا إجراءات مستخدم محاكاة. بالنسبة إلى طرق العرض، استخدِم Espresso. تتضمّن Jetpack Compose واجهات برمجة تطبيقات خاصة بـ الاختبار APIs. يمكن أن تكون اختبارات سلوك واجهة المستخدم اختبارات خاضعة للأجهزة أو محلية. يتم تشغيل الاختبارات الخاضعة للأجهزة على الأجهزة أو المحاكيات، بينما يتم تشغيل اختبارات واجهة المستخدم المحلية على Robolectric على جهاز JVM.

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

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

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

الخطوات التالية

لمزيد من المعلومات حول كيفية تنفيذ عمليات التحقّق الواردة في هذا المستند، يُرجى الاطّلاع على المكتبات والأدوات.