كتابة برنامج لتشغيل اختبارات Tradefed

تنظيم صفحاتك في مجموعات يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.

توضِّح هذه الصفحة كيفية كتابة أداة جديدة لتشغيل الاختبارات في Tradefed.

خلفية

إذا كنت تريد معرفة مكان مشغّلات الاختبار في بنية Tradefed، اطّلِع على بنية مشغّل الاختبار.

هذا ليس شرطًا أساسيًا لكتابة أداة جديدة لتشغيل الاختبارات، إذ يمكن كتابة هذه الأدوات بشكل منفصل.

الحد الأدنى: تنفيذ الواجهة

إنّ الحدّ الأدنى المطلوب للتأهّل ليكون مشغّل اختبار Tradefed هو تنفيذ واجهة IRemoteTest وبشكل أدق، طريقة run(TestInformation testInfo, ITestInvocationListener listener).

وهذه الطريقة هي التي يتم استدعاؤها بواسطة أداة التسطير عند استخدام عدّاء الاختبار، يشبه لغة Java Runnable.

يعتبر كل جزء من هذه الطريقة جزءًا من تنفيذ عدّاء الاختبار.

الإبلاغ عن النتائج من أداة تشغيل الاختبار

تتيح الطريقة run في الواجهة الأساسية الوصول إلى كائن مستمع اكتب ITestInvocationListener. هذا العنصر هو الأساس لإعداد التقارير المنظَّمة النتائج من عداء الاختبار إلى متسجير الاختبار.

من خلال إعداد تقارير عن النتائج المنظَّمة، يتضمّن عدّاء الاختبار السمات التالية:

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

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

يمكن استدعاء الأحداث التالية لدى المستمع لإبلاغ مستمع التقدم الحالي لعمليات التنفيذ:

• testRunStarted: إرسال إشعار ببدء مجموعة من حالات الاختبار التي تكون مرتبطة ببعضها.
  • testStarted: الإشعار ببداية بدء حالة اختبار
  • testFailed/testIgnored: إشعار بتغيير حالة ملف اختبار قيد التنفيذ يتم اعتبار حالة اختبارية بدون أي تغيير في الحالة تمت بنجاح.
  • testEnded: إرسال إشعار بنهاية حالة الاختبار
• testRunFailed: إشعار بأنّ الحالة العامة لتنفيذ مجموعة ملفّات اختبار تشير إلى تعذُّر التنفيذ يمكن أن يكون التشغيل التجريبي ناجحًا أو تعذّر إكماله بغض النظر عن نتائج حالات الاختبار استنادًا إلى ما كان من المفترض أن يحصل عليه التوجيه. على سبيل المثال، يقوم برنامج ثنائي بتشغيل العديد من حالات الاختبار الإبلاغ عن جميع حالات اجتياز الاختبارات ولكن مع رمز خروج بخطأ (لأي الأسباب: الملفات المسرّبة وغيرها).
• testRunEnded: إرسال إشعار بنهاية مجموعة حالات الاختبار.

إن صيانة وضمان الترتيب الصحيح لطلبات معاودة الاتصال هي مسئول مُنفذ الاختبار، على سبيل المثال، ضمان يتم استدعاء الدالة testRunEnded في حال الاستثناء باستخدام عبارة finally.

إنّ طلبات معاودة الاتصال لحالات الاختبار (testStarted وtestEnded وما إلى ذلك) اختيارية. اختبار الإطلاق دون أي حالات اختبار.

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

سجلات التقارير من أداة تشغيل الاختبار

إذا كنت تكتب فئة اختبار Tradefed أو أداة تنفيذ اختبارات، عليك تنفيذ IRemoteTest والحصول على ITestInvocationListener من خلال طريقة run(). هذا المستمع لتسجيل الملفات على النحو التالي:

    listener.testLog(String dataName, LogDataType type_of_data, InputStreamSource data);

الاختبار باستخدام جهاز

يتيح الحد الأدنى من الواجهة أعلاه إجراء اختبارات بسيطة للغاية ومعزولة ولا تتطلب أي موارد معيّنة، على سبيل المثال اختبارات وحدة Java.

سيحتاج كاتبو الاختبار الذين يريدون الانتقال إلى الخطوة التالية من اختبار الجهاز إلى الواجهات التالية:

• يتيح IDeviceTestتلقّي عنصر ITestDevice الذي يمثّل الجهاز الذي يخضع للاختبار، ويقدّم واجهة برمجة التطبيقات للتفاعل معه.
• IBuildRECEIVEr يسمح الاختبار بالحصول على الكائن IBuildInfo الذي تم إنشاؤه في خطوة مقدِّم الخدمة الذي يتضمن جميع المعلومات والعناصر المتعلقة بإعدادات الاختبار.

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

الاختبار باستخدام أجهزة متعددة

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

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

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

اختبارات على علم بعمليات الإعداد

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

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

لتنفيذ عدّاء الاختبار، عليك تنفيذ IConfigurationConfigurationr لاستلام الكائن IConfiguration.

أداة تنفيذ اختبارات مرنة

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

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

يتم وصف دعم التصفية في واجهة ITestFilterRecipientr، ما يسمح بتلقّي مجموعات من فلترَي include وexclude للاختبارات. يجب تشغيله أو عدم تشغيله.

اصطلاحنا هو أنه سيتم إجراء اختبار IFF، حيث يتطابق مع واحد أو أكثر من تضمين الفلاتر AND لا يتطابق مع أيٍّ من فلاتر الاستبعاد. في حال عدم تضمين: تقديم الفلاتر، ويجب إجراء جميع الاختبارات طالما أنها لا تتطابق مع أي من وفلاتر الاستبعاد.