بنية 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>