Структура 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 носят информационный характер и влияют на выполнение теста. Он указывает, к какому режиму 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" /> Без этого, если тест config включает 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>