استراتيجيات الاختبار

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

تحقّق الفِرق مستويات أعلى من الإنتاجية عند استخدام نهج منظَّم للاختبارات مع تحسينات في البنية الأساسية. ويتيح لك ذلك الحصول على ملاحظات في الوقت المناسب حول طريقة عمل الرمز البرمجي. تتضمّن استراتيجية الاختبار الجيدة ما يلي:

• رصد المشاكل في أقرب وقت ممكن
• يتم تنفيذها بسرعة.
• تقديم مؤشرات واضحة عند الحاجة إلى إصلاح شيء ما

ستساعدك هذه الصفحة في تحديد أنواع الاختبارات التي يجب تنفيذها ومكان إجرائها وعدد مرّات إجرائها.

android skills add testing-setup

هرم الاختبار

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

تشير *الدقة إلى مدى تشابه بيئة وقت التشغيل التجريبية مع بيئة التشغيل الفعلي.

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

تقليل تكلفة الخطأ

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

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

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

من المهم مراعاة الآثار المترتبة على ذلك في ما يتعلق بتكلفة تحديد الأخطاء وإصلاحها، وأهمية توجيه جهود الاختبار نحو إجراء اختبارات أصغر حجمًا وأكثر تكرارًا:

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

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

استراتيجية اختبار قابلة للتوسّع

تم تقسيم هرم الاختبار تقليديًا إلى 3 فئات:

• اختبارات الوحدات
• اختبارات الدمج
• اختبارات شاملة

ومع ذلك، لا تتوفّر تعريفات دقيقة لهذه المفاهيم، لذا قد تحتاج الفِرق إلى تحديد فئاتها بشكل مختلف، مثلاً باستخدام 5 طبقات:

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

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

تحديد فئة الاختبار

كقاعدة عامة، عليك مراعاة أدنى مستوى في الهرم يمكنه تقديم المستوى المناسب من الملاحظات إلى الفريق.

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

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

يُرجى العِلم أنّ فئة الاختبار لا تحدّد نوع الاختبار، وليس من الضروري اختبار جميع الميزات في كل فئة.

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

البنية الأساسية للاختبار

يجب أن تستند استراتيجية الاختبار إلى بنية أساسية وأدوات تساعد المطوّرين على إجراء اختباراتهم باستمرار وفرض قواعد تضمن اجتياز جميع الاختبارات.

يمكنك تصنيف الاختبارات حسب النطاق لتحديد وقت ومكان إجراء الاختبارات. على سبيل المثال، باتّباع النموذج ذي الطبقات الخمس:

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

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