اكتب عداء اختبار 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 للاختبارات التي ينبغي أو لا ينبغي تشغيلها.

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