بنية AndroidTest.xml

تتّبع البنية العامة لإعدادات الوحدة النمط نفسه الذي تتّبعه إعدادات XML العادية في Tradefed، ولكن مع بعض القيود بسبب تشغيلها كجزء من مجموعة.

قائمة بالعلامات المسموح بها

AndroidTest.xml أو إعدادات الوحدة بشكل عام يمكن أن تحتوي فقط على علامات XML التالية: target_preparer وmulti_target_preparer وtest و metrics_collector.

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

ملاحظة: اطّلِع على إعداد ملف XML في Tradefed إذا كنت بحاجة إلى تذكير بالعلامات المختلفة.

ستؤدي عناصر مثل build_provider أو result_reporter إلى طرح ConfigurationException في حال محاولة تشغيلها من داخل ملف تكوين الوحدة. ويهدف ذلك إلى تجنُّب توقّع أنّه يمكن لهذه العناصر تنفيذ بعض المهام من داخل وحدة.

مثال على ضبط الوحدة

<configuration description="Config for CTS Gesture test cases">
    <option name="test-suite-tag" value="cts" />
    <target_preparer class="com.android.tradefed.targetprep.suite.SuiteApkInstaller">
        <option name="cleanup-apks" value="true" />
        <option name="test-file-name" value="CtsGestureTestCases.apk" />
    </target_preparer>
    <test class="com.android.tradefed.testtype.AndroidJUnitTest" >
        <option name="package" value="android.gesture.cts" />
        <option name="runtime-hint" value="10m50s" />
    </test>
</configuration>

يصف هذا الإعداد اختبارًا يتطلّب تثبيت CtsGestureTestCases.apk ، وسيتم تشغيل أداة قياس أداء على حزمة android.gesture.cts.

علامتا الإدراج <include> و<template-include>

ننصح بعدم استخدام <include> و<template-include> في إعدادات الوحدات. ليس مضمونًا أن تعمل على النحو المتوقع.

حالة خاصة لعلامة metrics_collector

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

مثال على الضبط:

<configuration description="Config for CTS UI Rendering test cases">
    <target_preparer class="com.android.tradefed.targetprep.suite.SuiteApkInstaller">
        <option name="cleanup-apks" value="true" />
        <option name="test-file-name" value="CtsUiRenderingTestCases.apk" />
    </target_preparer>
    <test class="com.android.tradefed.testtype.AndroidJUnitTest" >
        <option name="package" value="android.uirendering.cts" />
        <option name="runtime-hint" value="11m55s" />
        <option name="runner" value="android.uirendering.cts.runner.UiRenderingRunner" />
        <option name="isolated-storage" value="false" />
    </test>

    <!-- Collect the files in the dump directory for debugging -->
    <metrics_collector class="com.android.tradefed.device.metric.FilePullerLogCollector">
        <option name="directory-keys" value="/sdcard/UiRenderingCaptures" />
        <option name="collect-on-run-ended-only" value="true" />
    </metrics_collector>
</configuration>

ماذا عن معلومات الإصدار أو عمليات التنزيل؟

قد يعطي تعريف العلامات المسموح بها انطباعًا غير صحيح بأنّ الوحدة لن تحصل على أي معلومات إصدار. هذا غير صحيح.

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

على سبيل المثال، بدلاً من إرسال كل وحدة من وحدات مجموعة أدوات اختبار التوافق (CTS) للاستعلام عن معلومات الجهاز وأنواعه وما إلى ذلك بشكل فردي، تُجري عملية الإعداد على مستوى مجموعة أدوات CTS (cts.xml) هذه العملية مرة واحدة وستتلقّى كل وحدة تلك المعلومات في حال طلبها.

لكي تتلقّى العناصر في إحدى الوحدات معلومات الإصدار، يجب أن يتم تنفيذ الإجراء نفسه المُستخدَم في إعداد Tradefed العادي: تنفيذ واجهة IBuildReceiver لتلقّي IBuildInfo. اطّلِع على الاختبار باستخدام الجهاز للحصول على مزيد من التفاصيل.

حقول البيانات الوصفية

يتضمّن عدد كبير من وحدات الاختبار بعض مواصفات metadata، لكلّ منها هدف فريد.

مثال:

  <option name="config-descriptor:metadata" key="component" value="framework" />
  <option name="config-descriptor:metadata" key="parameter" value="instant_app" />
  <option name="config-descriptor:metadata" key="parameter" value="multi_abi" />
  <option name="config-descriptor:metadata" key="parameter" value="secondary_user" />

المكوّن

تصف بيانات التعريف component مكوّن Android العام الذي تريد الوحدة اختباره. ولا يؤثر ذلك في تنفيذ الاختبار، بل يتم استخدامه بشكل أساسي لأغراض تنظيمية.

تتوفّر القائمة المحدّثة للمكونات المسموح بها لمجموعة أدوات اختبار التوافق (CTS) في CtsConfigLoadingTest. يتعذّر هذا الاختبار في مرحلة ما قبل الإرسال إذا تمت إضافة مكوّن غير متوفّر إلى ملف برمجي لوحدة اختبار CTS.

يمكنك فلترة عملية تنفيذ مجموعة استنادًا إلى المكوّنات باستخدام module-metadata-include-filter وmodule-metadata-exclude-filter.

مثال:

  --module-metadata-include-filter component framework

لا يشغِّل هذا المثال سوى وحدة الاختبار التي تمت إضافة تعليقات توضيحية لها باستخدام المكوّن framework.

المَعلمة

بيانات التعريف parameter هي معلوماتية وتؤثّر في تنفيذ الاختبار. تحدّد هذه السياسة وضع Android الذي تنطبق عليه وحدة الاختبار. في هذه الحالة، تقتصر الأوضاع على أوضاع Android العالية المستوى، مثل instant apps أو secondary users أو different abis.

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

• instant_app: أنشئ نسخة من الاختبارات التي تثبِّت حِزم APK كتطبيقات فورية.
• multi_abi: يمكنك إنشاء صيغ مختلفة من الاختبارات لكل واجهة تطبيق ثنائية (ABI) متوافقة مع الجهاز.
• secondary_user: أنشئ نسخة من الاختبارات التي تُثبِّت حِزم APK و تُجري الاختبارات بصفتك مستخدمًا ثانويًا.

جمع المقاييس والمعالجة اللاحقة لوحدات اختبار الأداء

بالنسبة إلى وحدات اختبار الأداء، يُسمح باستخدام metrics_collector و metric_post_processor على مستوى الوحدة لأنّهما عنصران أساسيان لاختبارات الأداء. يمكن أن تكون أدوات جمع المقاييس ومعالجاتها على مستوى الوحدة خاصة بالوحدة. لا يُنصح بتحديد معالِجات ما بعد المعالجة على مستوى كلّ من المستوى الأعلى والوحدة.

يجب أن تتضمّن إعدادات وحدة اختبار الأداء البيانات الوصفية test-type بالقيمة performance، مثل: xml <option name="config-descriptor:metadata" key="test-type" value="performance" /> في حال عدم توفّر هذه البيانات، إذا كانت إعدادات الاختبار تتضمّن metric_collector غير FilePullerLogCollector أو أي metric_post_processor، يفشل الاختبار في مرحلة ما قبل الإرسال.

مثال على إعداد وحدة اختبار الأداء:

<configuration description="Runs sample performance test.">
    <!-- Declare as a performance test module -->
    <option name="config-descriptor:metadata" key="test-type" value="performance" />
    <option name="test-tag" value="hello-world-performance-test" />
    <test class="com.android.tradefed.testtype.HostTest" >
        <option name="class" value="android.test.example.helloworldperformance.HelloWorldPerformanceTest" />
    </test>
    <!-- Add module-level post processor MetricFilePostProcessor -->
    <metric_post_processor class="com.android.tradefed.postprocessor.MetricFilePostProcessor">
        <option name="aggregate-similar-tests" value="true" />
        <option name="enable-per-test-log" value="false" />
    </metric_post_processor>
</configuration>