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

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

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

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

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

هرم الاختبار

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

الموضوع الذي يتم اختباره	وصف لما يتم اختباره	فئة الاختبار	مثال على نوع الاختبار
منطق مدقّق النموذج	فئة تتحقّق من صحة عنوان البريد الإلكتروني وفقًا لتعبير عادي وتتحقّق من إدخال حقل كلمة المرور لا توجد أي تبعيات.	اختبارات الوحدات	اختبار وحدة آلة Java الافتراضية (JVM) على الجهاز
سلوك واجهة مستخدم نموذج تسجيل الدخول	نموذج يتضمّن زرًا لا يتم تفعيله إلا بعد التحقّق من صحة النموذج	اختبارات المكوّنات	اختبار سلوك واجهة المستخدم الذي يتم إجراؤه على Robolectric
مظهر واجهة مستخدم نموذج تسجيل الدخول	نموذج يتبع مواصفات تجربة المستخدم	اختبارات المكوّنات	اختبار لقطة شاشة المعاينة
الدمج مع "مدير المصادقة"	واجهة المستخدم التي تُرسِل بيانات الاعتماد إلى مدير المصادقة وتتلقّى ردودًا يمكن أن تحتوي على أخطاء مختلفة.	اختبارات الميزات	اختبار آلة Java الافتراضية باستخدام بيانات زائفة
مربّع حوار تسجيل الدخول	شاشة تعرض نموذج تسجيل الدخول عند الضغط على زر تسجيل الدخول	اختبارات التطبيقات	اختبار سلوك واجهة المستخدم الذي يتم تشغيله على Robolectric
رحلة المستخدِم الرئيسية: تسجيل الدخول	عملية تسجيل دخول كاملة باستخدام حساب تجريبي مقابل خادم مرحلي	سحب المرشح	اختبار سلوك واجهة مستخدم ميزة "إنشاء" الشامل الذي يتم تشغيله على الجهاز

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

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

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

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

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

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

الفئة	البيئة (مكان)	المشغّل (الوقت)
وحدة	[Local][4]	كل عملية إرسال
المكوّن	بالتوقيت المحلي	كل التزام
الميزة	الأجهزة المحلية وأجهزة المحاكاة	قبل الدمج، قبل دمج تغيير أو إرساله
التطبيق	الأجهزة المحلية وأدوات المحاكاة والهاتف القابل للطي	بعد الدمج، بعد دمج تغيير أو إرساله
إصدار مُقترَح	8 هواتف مختلفة، جهاز واحد قابل للطي، جهاز لوحي واحد	قبل الإصدار

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

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