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

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

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

Определения

  • Пакет: набор тестовых модулей , настроенных для работы в рамках схожей настройки верхнего уровня и сообщающих о своих результатах за один вызов.
  • Настройка верхнего уровня: настройка, применяемая к устройствам перед запуском любого из тестовых модулей.
  • Основная конфигурация: конфигурация 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 .