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

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

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

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

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

هرم الاختبار

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

	النطاق	الوصول إلى الشبكة	التنفيذ	نوع الإصدار	مراحل النشاط
الوحدة	طريقة أو فئة واحدة مع الحد الأدنى من التبعيات	لا	بالتوقيت المحلي	قابل للتصحيح	الدمج المُسبَق
المكوّن	مستوى الوحدة أو المكوّن صفوف متعددة معًا	لا	Local Robolectric Emulator	قابل للتصحيح	الدمج المُسبَق
الميزة	مستوى الميزة التكامل مع المكوّنات التي تملكها فِرق أخرى	محاكاة	Local Robolectric Emulator Devices	قابل للتصحيح	الدمج المُسبَق
التطبيق	مستوى التطبيق التكامل مع الميزات و/أو الخدمات التي تملكها فِرق أخرى	Mocked خادم مرحلة الاختبار خادم الإنتاج	أجهزة المحاكي	قابل للتصحيح	قبل الدمج بعد الدمج
الإصدار المحتمل	مستوى التطبيق التكامل مع الميزات و/أو الخدمات التي تملكها فِرق أخرى	خادم الإنتاج	أجهزة المحاكي	إنشاء إصدار مضغوط	Post-merge Pre-release

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

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

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

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

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

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

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

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

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

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

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

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

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