ساختار AndroidTest.xml

ساختار کلی پیکربندی ماژول از یک الگوی مشابه با پیکربندی معمولی 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 اطلاعاتی است و بر اجرای آزمون تأثیر می گذارد. مشخص می‌کند که ماژول تست روی کدام حالت اندروید اعمال می‌شود. در این حالت، حالت‌ها به حالت‌های سطح بالای اندروید، مانند 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>