Общая структура конфигурации модуля следует шаблону, аналогичному обычной конфигурации 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>
А как насчет информации о сборке или загрузок?
Определение разрешённых тегов может создать неверное впечатление, что модуль не получит никакой информации о сборке. Это не так .
Информация о сборке предоставляется на уровне конфигурации всего пакета и будет общей для всех модулей пакета. Это позволяет использовать единую конфигурацию верхнего уровня для запуска всех модулей, входящих в него.
Например, вместо того, чтобы каждый модуль Compatibility Test Suite (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 . Этот тест не пройдёт в режиме presubmit, если в модуль 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 , тест не будет выполнен в режиме 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>