Общая структура конфигурации модуля аналогична стандартной XML-конфигурации Tradefed, но с некоторыми ограничениями, обусловленными тем, что модули работают в составе комплексного пакета.
Список разрешенных тегов
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.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 , тест завершится с ошибкой на этапе 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>