يتبع الهيكل العام لتكوين الوحدة نمطًا مشابهًا لتكوين Tradefed XML العادي ولكن مع بعض القيود بسبب حقيقة أنها تعمل كجزء من مجموعة.
قائمة العلامات المسموح بها
يمكن أن يحتوي تكوين وحدة AndroidTest.xml أو تكوين الوحدة على نطاق أوسع على علامات XML التالية فقط: target_preparer و multi_target_preparer و test و metrics_collector .
على الرغم من أن هذه القائمة تبدو مقيدة، إلا أنها تسمح لك بتحديد احتياجات إعداد وحدة الاختبار بدقة والاختبار المطلوب تشغيله.
ملاحظة: راجع تكوين Tradefed 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>