اكتب عداء اختبار 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);

الاختبار بجهاز

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

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

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

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

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

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

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

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

الاختبارات تدرك أجهزتهم

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

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

من أجل تحقيق ذلك ، يمكن للمشغل التجريبي الوصول إلى كائن التكوين IConfiguration الذي يمثل جزءًا منه ويتم تنفيذه فيه. راجع وصف كائن التكوين لمزيد من التفاصيل.

لتنفيذ عداء الاختبار ، ستحتاج إلى تنفيذ IConfigurationReceiver لتلقي كائن IConfiguration .

عداء اختبار مرن

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

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

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

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

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