Общая структура конфигурации модуля соответствует шаблону, аналогичному обычной конфигурации 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>