ساختار AndroidTest.xml

ساختار کلی پیکربندی واحد از الگوی مشابهی با پیکربندی معمولی Tradefed XML پیروی می‌کند، اما به‌دلیل اینکه به‌عنوان بخشی از مجموعه اجرا می‌شوند، محدودیت‌هایی دارد.

فهرست برچسب‌های مجاز

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