ساختار 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 ، کامپوننت کلی اندروید را که ماژول قصد تست آن را دارد، توصیف می‌کند. این متادیتا هیچ تأثیر مستقیمی بر اجرای تست ندارد؛ در درجه اول برای اهداف سازمانی استفاده می‌شود.

فهرست به‌روز اجزای مجاز برای CTS در CtsConfigLoadingTest موجود است. اگر یک جزء ناموجود به یک ماژول CTS اضافه شود، این تست در مرحله‌ی پیش‌ارسال با شکست مواجه می‌شود.

شما می‌توانید با استفاده از module-metadata-include-filter و module-metadata-exclude-filter یک مجموعه را بر اساس اجزا فیلتر کنید.

مثال:

  --module-metadata-include-filter component framework

این مثال فقط ماژول تست حاشیه‌نویسی شده با کامپوننت framework اجرا می‌کند.

پارامتر

parameter فراداده، اطلاعاتی است و بر اجرای تست تأثیر می‌گذارد. این پارامتر مشخص می‌کند که ماژول تست به کدام حالت اندروید اعمال می‌شود. در این حالت، حالت‌ها به حالت‌های سطح بالای اندروید، مانند instant apps ، secondary users یا different abis ، محدود می‌شوند.

در طول اجرای مجموعه، اگر حالت مورد نظر برای تست اعمال شود، چندین نسخه از ماژول تست بر اساس آن حالت ایجاد می‌شود. هر نسخه تست‌های مشابهی را اما تحت حالت‌های مختلف اجرا می‌کند.

  • instant_app : نوعی از تست‌ها را ایجاد می‌کند که APKها را به عنوان برنامه‌های فوری نصب می‌کنند.
  • multi_abi : برای هر ABI پشتیبانی شده توسط دستگاه، یک نوع تست ایجاد می‌کند.
  • secondary_user : نوعی از تست‌ها را ایجاد می‌کند که APKها را نصب می‌کند و تست‌ها را به عنوان یک کاربر ثانویه اجرا می‌کند.

جمع‌آوری و پردازش متریک برای ماژول‌های تست عملکرد

برای ماژول‌های تست عملکرد، metrics_collector و metric_post_processor در سطح ماژول مجاز هستند زیرا برای تست‌های عملکرد ضروری هستند. collectors و post-processors متریک در سطح ماژول می‌توانند مختص ماژول باشند. توصیه نمی‌شود post-processors را هم در سطح بالا و هم در سطح ماژول مشخص کنید.

پیکربندی ماژول تست عملکرد باید شامل فراداده test-type با مقدار performance باشد، مانند: xml <option name="config-descriptor:metadata" key="test-type" value="performance" /> بدون این، اگر پیکربندی تست شامل metric_collector دیگری غیر از FilePullerLogCollector یا هر metric_post_processor دیگری باشد، تست در presubmit با شکست مواجه می‌شود.

پیکربندی ماژول تست عملکرد نمونه:

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