اعتبارًا من عام 2026، ولضمان توافقنا مع نموذج التطوير الثابت الرئيسي وضمان استقرار المنصة في المنظومة المتكاملة، سننشر الرمز المصدري في "مشروع Android مفتوح المصدر" (AOSP) في الربع الثاني والربع الرابع. لإنشاء AOSP والمساهمة فيه، ننصحك باستخدام android-latest-release بدلاً من aosp-main. سيشير فرع البيان android-latest-release دائمًا إلى أحدث إصدار تم إرساله إلى AOSP. لمزيد من المعلومات، يُرجى الاطّلاع على التغييرات في مشروع Android المفتوح المصدر (AOSP).

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

بنية AndroidTest.xml

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

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

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

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

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

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

مثال على إعدادات الوحدة

<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>

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