كتابة برنامج لتشغيل اختبارات 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 العنصر الذي يشكّل جزءًا منه والذي يتم تنفيذه فيه. اطّلِع على وصف عنصر الضبط لمزيد من التفاصيل.

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

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

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

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

يتم وصف ميزة الفلترة في واجهة ITestFilterReceiver التي تتيح تلقّي مجموعات من فلاتر include وexclude للاختبارات التي يجب إجراؤها أو عدم إجرائها.

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