كتابة مقتطف اختبار متداول

توضّح هذه الصفحة كيفية كتابة أداة جديدة لتشغيل الاختبارات في 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 الذي يمثل الجهاز قيد الاختبار ويوفر واجهة برمجة التطبيقات للتفاعل معه.
• يسمح IBuildBuildr للاختبار بإنشاء العنصر IBuildInfo الذي تم إنشاؤه من خلال خطوة موفِّر الإصدار الذي يحتوي على جميع المعلومات والعناصر المتعلقة بإعدادات الاختبار.

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

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

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

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

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

الاختبارات التي تكون على دراية بإعداداتها

ملاحظة: هذه ليست حالة استخدام شائعة جدًا. تم توثيقها للتأكد من اكتمالها، ولكنك لن تحتاج إليها عادةً.

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

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

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

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

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

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

يتم شرح إمكانية الفلترة في واجهة ITestFilterReceiver، التي تسمح بتلقّي مجموعات من فلترَي include وexclude للاختبارات التي يجب إجراؤها أو التي لا يجب إجراؤها.

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

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