بنية AndroidTest.xml

تتبع البنية العامة لتهيئة الوحدة نمطًا مشابهًا. إلى تهيئة XML العادية، ولكن مع بعض القيود بسبب حقيقة إدارتها كجزء من مجموعة.

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

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

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

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

ستؤدي عناصر مثل 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>