Configurar suítes

Um conjunto no Tradefed refere-se a uma configuração onde vários testes são executados em um executor de testes comum que orienta a execução geral.

No Tradefed, os pacotes são controlados pela classe ITestSuite , que permite que testes sejam adicionados e removidos independentemente de como são executados.

Definições

  • Suite: Conjunto de módulos de teste configurados para serem executados em uma configuração de nível superior semelhante para relatar seus resultados em uma única invocação.
  • Configuração de nível superior: configuração aplicada aos dispositivos antes de executar qualquer um dos módulos de teste.
  • Configuração principal: A configuração XML Tradefed em nível de suíte que descreve quais módulos devem ser executados e qual configuração de nível superior deve ser usada.
  • Configuração em nível de módulo: configuração aplicada aos dispositivos logo antes de executar o módulo. Elas também são conhecidas como configurações específicas do módulo .
  • Configuração do módulo: refere-se à configuração XML Tradefed AndroidTest.xml que descreve os módulos e qual configuração em nível de módulo deve ser feita.
  • Módulo: Unidade de teste composta por uma etapa de configuração ( module-level setup ), uma etapa de execução de teste e uma etapa de desmontagem.
  • Nova tentativa intramódulo: Nova tentativa automática feita pelo chicote dentro do módulo.
  • Nova tentativa do conjunto: nova execução completa dos testes que falharam anteriormente no conjunto.

Estrutura do ITestSuite

ITestSuite em Tradefed refere-se à classe base comum que conduz a execução de um conjunto. Ele é compartilhado por todos os principais conjuntos de testes, especificamente o Android Compatibility Test Suite (CTS) e o Android Vendor Test Suite (VTS) e garante uma experiência de execução consistente em todos os conjuntos.

Às vezes nos referimos ao ITestSuite como o executor de suíte .

O executor de suíte segue estas etapas ao executar:

  1. Carregue a configuração do módulo e determine qual conjunto deve ser executado.

  2. Execute cada módulo:

    1. Execute a configuração em nível de módulo.
    2. Execute testes de módulo.
    3. Execute a desmontagem em nível de módulo.

  3. Relate os resultados.

Configuração de nível superior

Do ponto de vista do Tradefed, ITestSuite é apenas mais um teste. É complexo, mas ainda é apenas um teste como qualquer outro IRemoteTest . Portanto, ao especificar o executor de suíte em uma configuração Tradefed, o Tradefed segue o padrão usual da configuração: executando build_provider , target_preparer , test (nossa suíte neste caso) e target_cleaner .

Esta sequência na configuração Tradefed contendo o ITestSuite é a configuração de nível superior.

Exemplo:

<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>

Metadados do módulo

Chamamos informações extras de metadados do módulo especificadas no módulo de teste AndroidTest.xml . Esses metadados permitem especificar informações adicionais sobre o módulo, e os módulos podem ser filtrados usando os metadados.

Metadados de exemplo:

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

Exemplo de filtro em metadados:

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

O procedimento acima executaria todos os módulos com uma estrutura como metadados de componentes .

Exemplo completo 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>

Módulo parametrizado

Um tipo especial de metadados é parameter .

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

Esses metadados especificam que o módulo precisa ser executado em um modo diferente, por exemplo, como um app instantâneo, em vez de um modo de app padrão.

Todos os modos ou parâmetros possíveis são descritos por ModuleParameters e possuem um manipulador associado em ModuleParametersHelper que permite alterar a configuração do módulo para execução no modo específico.

Por exemplo, o modo de aplicativo instantâneo força a instalação do APK como modo instantâneo.

Para que a parametrização ocorra, a linha de comando precisa habilitá-la com:

--enable-parameterized-modules

Também é possível executar um único modo com:

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

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

Quando uma versão parametrizada de um módulo é executada, ela relata seus resultados sob um nome de módulo parametrizado, por exemplo CtsGestureTestCases[instant] versus base CtsGestureTestCases .