Общая структура конфигурации модуля похожа на структуру обычного XML-файла конфигурации Tradefed, но с некоторыми ограничениями, связанными с тем, что модули выполняются как часть набора.
Список разрешенных тегов
Конфигурация модуля AndroidTest.xml или более широкая конфигурация может содержать только следующие XML-теги: target_preparer, multi_target_preparer, test и metrics_collector.
Хотя этот список выглядит ограничивающим, он позволяет точно определить потребности в настройке тестового модуля и запустить тест.
ПРИМЕЧАНИЕ. Если вам нужно вспомнить, какие теги используются, ознакомьтесь с XML-конфигурацией Tradefed.
Объекты, такие как 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. Этот тест не проходит предварительную отправку, если в модуль CTS добавлен несуществующий компонент.
Вы можете отфильтровать запуск набора на основе компонентов, используя module-metadata-include-filter и module-metadata-exclude-filter.
Пример:
--module-metadata-include-filter component framework
В этом примере выполняется только тестовый модуль, аннотированный компонентом framework.
Параметр
Метаданные parameter носят информационный характер и влияют на выполнение теста. Он указывает, к какому режиму Android применяется тестовый модуль.
В этом случае modes ограничиваются режимами 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, тест не пройдет предварительную проверку.
Пример конфигурации модуля тестирования производительности:
<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>