اعتبارًا من 27 آذار (مارس) 2025، ننصحك باستخدام android-latest-release بدلاً من aosp-main لإنشاء AOSP والمساهمة فيه. لمزيد من المعلومات، يُرجى الاطّلاع على التغييرات في AOSP.

تمت ترجمة هذه الصفحة بواسطة Cloud Translation API‏.

بنية AndroidTest.xml

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

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

يمكن أن يحتوي 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.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>

بنية AndroidTest.xml تنظيم صفحاتك في مجموعات يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.