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

توضح هذه الصفحة كيفية كتابة عداء اختبار جديد في Tradefed.

خلفية

إذا كنت مهتمًا بمعرفة مكان عدّاءي الاختبار في بنية Tradefed، راجع بنية أداة تشغيل الاختبار.

وهذا ليس شرطًا أساسيًا لكتابة اختبار جديد؛ عدّاء الاختبارات مكتوبة بمعزل عن بعضها.

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

الحد الأدنى للتأهل لتكون عداءًا لاختبار Tradefed هو تنفيذ واجهة IRemoteTest وبشكل أكثر تحديدًا طريقة run(TestInformation testInfo, ITestInvocationListener listener).

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

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

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

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

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

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

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

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

• testRunStarted: إبلاغ بداية مجموعة من حالات الاختبار مرتبطين معًا.
  • testStarted: الإشعار ببداية بدء حالة اختبار
  • تعذُّر الاختبار/تم تجاهله: إرسال إشعار بتغيير حالة حالة الاختبار قيد التقدم. يتم اعتبار حالة اختبارية بدون أي تغيير في الحالة تمت بنجاح.
  • testEnded: إرسال إشعار بنهاية حالة الاختبار
• testRunFound: إرسال إشعار بأنّ الحالة العامة لمجموعة حالات الاختبار فشل التنفيذ. يمكن أن يشير الجري الاختباري إلى اجتياز أو تعذُّر. بشكل مستقل عن نتائج حالات الاختبار اعتمادًا على التنفيذ المتوقع. على سبيل المثال، يقوم برنامج ثنائي بتشغيل العديد من حالات الاختبار الإبلاغ عن جميع حالات اجتياز الاختبارات ولكن مع رمز خروج بخطأ (لأي الأسباب: الملفات المسرّبة وغيرها).
• 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 تحتوي على القائمة الكاملة للأشكال التمثيلية للأجهزة ومعلومات الإصدار المرتبطة بها.

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

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

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

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

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

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

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

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

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

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