عندما نتعمق في عالم تطوير تطبيقات أندرويد الحديثة، ندرك أن أنشئ واجهة رائعة هذا لا يكفي؛ المهم حقًا هو ألا يتعطل عند أول نقرة للمستخدم. القفزة إلى يؤلف Jetpack لقد غير ذلك قواعد اللعبة، مما سمح لنا ببناء طرق العرض بشكل تصريحي، ولكنه طرح أيضًا تحديات جديدة في ضمان أن كل شيء يبدو ويعمل كما ينبغي.
أحيانًا نواجه مواقف يائسة، مثل الرغبة في تحقق من صورة ليس لها وسم لا نملك ملفات اختبار أو أوصاف محتوى، وبسبب قيود قانونية أو تقنية، لا يمكننا الوصول إلى الشفرة البرمجية. في هذه الحالات، يصبح اختبار واجهة المستخدم أشبه بلعبة ألغاز، ولكن توجد طرق للتحقق من تجربة المستخدم دون تعطيل سير عملية التطوير.
أساسيات التصميم والبنية في برنامج Compose
لإجراء اختبار فعال، عليك أولاً فهم كيفية تجميع المكونات. في شركة Compose، يقوم التنظيم على ثلاثة أركان أساسية: العمود والصف والمربعبينما تقوم الأعمدة بتكديس العناصر عموديًا وتقوم الصفوف بذلك أفقيًا، فإن مكون الصندوق هو الأداة الرئيسية لـ عناصر التراكبيتيح لك ذلك وضع أيقونات أو شارات فوق الصور باستخدام معلمة المحاذاة.
أحد المجالات الحرجة التي يرتكب فيها العديد من المطورين أخطاءً هو استخدام الصفات التعريفيةلا تقتصر وظيفة هذه العناصر على تحديد المظهر فحسب، بل إن ترتيب استخدامها يُغير النتيجة النهائية. إتقان إعادة استخدام المكونات وإنشاء المُعدِّلات لإنشاء عناصر تقبل مُعدِّلًا اختياريًا في مُنشئها، وفقًا لإرشادات Android الرسمية.
استراتيجيات الاختبار: من اختبار الوحدات إلى التنقل
تتمثل إحدى أكبر مزايا برنامج Compose في قدرته على الأداء اختبارات وحدة واجهة المستخدمعلى عكس نظام العرض القديم، أصبح بإمكاننا الآن اختبار المكونات المعزولة دون تحميل نموذج العرض بالكامل أو تكوين مُحقِّنات التبعية المعقدة. وهذا يسمح لنا بإنشاء أنواع قابلة للتركيب التي لا تعتمد على منطق الأعمال، مما يجعل صيانة الاختبارات أمرًا سهلاً للغاية.
لكن لا يمكننا إغفال التدفقات الكاملة. لاختبار التنقل، نحتاج إلى أدوات محددة مثل... اختبار وحدة تحكم مضيف الملاحة وقاعدة التركيب. الهدف هنا هو محاكاة التفاعلات في العالم الحقيقي باستخدام التطبيق العملي لخاصية الإنشاء والتنقل وتأكد من أن الانتقالات بين الشاشات تتم بشكل صحيح. ومن الحيل المهمة استخدام waitForIdle() لمنع فشل الاختبار بسبب عدم تحديث واجهة المستخدم بنفس سرعة كود الاختبار.
فن اختبار واجهة المستخدم (واجهة المستخدم مقابل واجهة المستخدم الرسومية)
من الشائع الخلط بين واجهة المستخدم (UI) وواجهة المستخدم الرسومية (GUI)، ولكن ثمة فروق دقيقة بينهما. واجهة المستخدم (UI) هي المفهوم العام لـ التفاعل بين الإنسان والحاسوبواجهة المستخدم الرسومية هي الفئة الفرعية المرئية التي تستخدم الأيقونات والقوائم. ولضمان موثوقية التطبيق، يجب تطبيق أنواع مختلفة من التحقق من الصحة:
- الاختبارات الوظيفية: يركزون على التأكد من أن كل زر وواجهة برمجة تطبيقات (API) يقوم بما يفترض أن يقوم به، وعادةً ما يتم ذلك من خلال اختبار الصندوق الأسود.
- اختبارات الانحدار: من الضروري بعد أي تغيير في الكود التأكد من أننا لم نقم شيء كان يعمل بالفعل أصبح معطلاً.
- اختبارات الأداء: يقومون بتحليل الاستقرار وسرعة الاستجابة لتجنب الاختناقات.
- اختبار القبول الموحد (UAT): الحاجز الأخير حيث يتحقق المستخدم النهائي من أن التدفق العام متسق.
التنفيذ الآلي مقابل التنفيذ اليدوي
للنقاش القديم بين الاختبار الآلي والاختبار اليدوي تفاصيله الدقيقة. يوفر الاختبار اليدوي الذكاء البشري والتفكير النقديتكشف هذه الأدوات عن مشاكل في سهولة الاستخدام لا يمكن للبرامج النصية رصدها، مثل بطء استجابة الخادم رغم عدم ظهور أي خطأ. مع ذلك، فهي عرضة للخطأ البشري وتستغرق وقتًا طويلاً للغاية.
من ناحية أخرى، تتيح الأتمتة باستخدام أدوات متخصصة تنفيذ آلاف الحالات في ثوانٍ. وهناك خيارات وسيطة مثل... سجل والتشغيلوالتي تسجل الفعل البشري وتكرره. والمثالي هو التوازن: أتمتة المهام المتكررة و اترك الفحص البصري وتجربة المستخدم للعين البشرية.
حالات الاختبار والتخطيط التفصيلي
لتجنب الفوضى في عملية الاختبار، تُعد خطة الاختبار ضرورية. يجب أن تحدد هذه الوثيقة كل شيء بدءًا من المهنيون المعنيون وصولاً إلى بيئات الأجهزة المستهدفة وأنظمة التشغيل. يمكننا البدء بـ اختبارات الدخان للكشف عن الأخطاء الصارخة ثم الانتقال إلى اختبارات سلامة أكثر شمولاً.
عند تصميم السيناريوهات، يجب أن نطرح على أنفسنا أسئلة حاسمة: ماذا يحدث إذا ترك المستخدم الحقول فارغة؟ كيف يتفاعل التطبيق مع ذلك؟ بيانات اعتماد غير صحيحةيجب أن يتضمن نص الاختبار الجيد معرفًا فريدًا، والإجراء خطوة بخطوة، والنتيجة المتوقعة، مع تعيين رمز خطأ محدد في حالة الفشل. تسريع إصلاح الأخطاء.
قائمة التحقق من التحقق المرئي
ولضمان عدم ترك أي شيء للصدفة، يُنصح باتباع قائمة تدقيق صارمة. أولاً، تحقق من صحة التوافق عبر الأنظمة الأساسية وبدقة شاشة مختلفة، مع الحرص على الاختبار في الوضعين الرأسي والأفقي. من الضروري التحقق من أن أنواع البيانات صحيح وأن الحقول لها حدود ثابتة لعدد الأحرف.
لا يوجد podemos olvidar la إمكانية الوصولالتحقق من أن ينبغي أن تكون أنماط الطباعة والنصوص في Compose مناسبة للجميع. وأخيرًا، مراجعة للوحة الألوان، والتهجئة، و... سرعة الملاحة سيضمن هذا أن يكون التطبيق ليس قويًا فحسب، بل يوفر أيضًا تجربة مميزة للمستخدم النهائي.
