Настройка люксов

Под набором тестов в Tradefed понимается настройка, в которой несколько тестов выполняются под управлением общего средства выполнения тестов, которое управляет общим выполнением.

В Tradefed наборы управляются через класс ITestSuite , который позволяет добавлять и удалять тесты независимо от того, как они выполняются.

Определения

• Suite: Набор тестовых модулей , настроенных на работу в рамках схожей настройки верхнего уровня для предоставления отчетов о результатах за один вызов.
• Настройка верхнего уровня: настройка, применяемая к устройствам перед запуском любого из тестовых модулей.
• Основная конфигурация: конфигурация Tradefed XML на уровне пакета, описывающая, какие модули должны работать и какую настройку верхнего уровня следует использовать.
• Настройка на уровне модуля: настройка, применяемая к устройствам непосредственно перед запуском модуля. Такие настройки также называются настройками, специфичными для модуля .
• Конфигурация модуля: относится к конфигурации AndroidTest.xml Tradefed XML, которая описывает модули и то, какую настройку на уровне модуля следует выполнить.
• Модуль: Тестовый блок, состоящий из этапа настройки ( настройка на уровне модуля ), этапа выполнения теста и этапа демонтажа.
• Внутримодульный повтор: автоматический повтор, выполняемый жгутом внутри модуля.
• Повтор набора: полный повтор ранее проваленных тестов набора.

Структура ITestSuite

ITestSuite в Tradefed — это общий базовый класс, управляющий выполнением набора тестов. Он используется всеми основными наборами тестов, в частности, Android Compatibility Test Suite (CTS) и Android Vendor Test Suite (VTS) , и обеспечивает единообразное выполнение всех наборов.

Иногда мы называем ITestSuite исполнителем набора тестов .

При выполнении пакета исполнитель выполняет следующие шаги:

1. Загрузите конфигурацию модуля и определите, какой набор должен работать.

2. Запустите каждый модуль:

   1. Запустите настройку на уровне модуля.
   2. Запустите модульные тесты.
   3. Выполнить демонтаж на уровне модулей.

3. Сообщите результаты.

Настройка верхнего уровня

С точки зрения Tradefed, ITestSuite — это просто ещё один тест. Он сложный, но всё же это всего лишь тест, как и любой другой IRemoteTest . Поэтому при указании исполнителя набора тестов в конфигурации Tradefed, Tradefed следует стандартному шаблону конфигурации: запуск build_provider , target_preparer , test (в данном случае нашего набора тестов) и target_cleaner .

Эта последовательность в конфигурации Tradefed, содержащей ITestSuite , является настройкой верхнего уровня.

Пример:

<configuration description="Common config for Compatibility suites">

    <build_provider class="com.android.compatibility.common.tradefed.build.CompatibilityBuildProvider" />
    <!-- Setup applied before the suite: so everything running in the suite will
    have this setup beforehand -->
    <target_preparer class="com.android.tradefed.targetprep.RunCommandTargetPreparer">
        <option name="run-command" value="settings put global package_verifier_enable 0" />
        <option name="teardown-command" value="settings put global package_verifier_enable 1"/>
    </target_preparer>

    <!-- Our ITestSuite implementation -->
    <test class="com.android.compatibility.common.tradefed.testtype.suite.CompatibilityTestSuite" />

    <result_reporter class="com.android.compatibility.common.tradefed.result.ConsoleReporter" />
</configuration>

Метаданные модуля

Метаданные модуля называются дополнительной информацией, указанной в тестовом модуле AndroidTest.xml . Эти метаданные позволяют указать дополнительную информацию о модуле, и модули можно фильтровать по этим метаданным.

Пример метаданных:

<option name="config-descriptor:metadata" key="component" value="framework" />
<option name="config-descriptor:metadata" key="parameter" value="instant_app" />

Пример фильтра по метаданным:

--module-metadata-include-filter component=framework

Вышеуказанный код будет запускать все модули с фреймворком в качестве метаданных компонента .

Полный пример AndroidTest.xml :

<configuration description="Config for CTS Gesture test cases">
    <option name="test-suite-tag" value="cts" />
    <!-- Metadata -->
    <option name="config-descriptor:metadata" key="component" value="framework" />
    <option name="config-descriptor:metadata" key="parameter" value="instant_app" />
    <!-- End: metadata -->
    <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>

Параметризованный модуль

Особым типом метаданных является parameter .

<option name="config-descriptor:metadata" key="parameter" value="instant_app" />

Эти метаданные указывают, что модуль должен выполняться в другом режиме , например, как мгновенное приложение, а не в стандартном режиме приложения.

Все возможные режимы или параметры описаны в ModuleParameters и имеют связанный обработчик в ModuleParametersHelper , который позволяет изменить настройку модуля для выполнения в определенном режиме.

Например, режим мгновенного приложения принудительно устанавливает APK в мгновенном режиме.

Чтобы произошла параметризация, ее необходимо включить в командной строке с помощью:

--enable-parameterized-modules

Также возможно запустить один заданный режим с помощью:

--enable-parameterized-modules --module-parameter <Mode>

--enable-parameterized-modules --module-parameter INSTANT_APP

При запуске параметризованной версии модуля она сообщает о своих результатах под именем параметризованного модуля, например CtsGestureTestCases[instant] вместо базового CtsGestureTestCases .