Configurar suítes

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

No Tradefed, as suítes são conduzidas por meio da classe ITestSuite , que permite que os 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 chamada.
  • 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 de 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. Eles também são conhecidos como configurações específicas do módulo .
  • Configuração do módulo: Refere-se à configuração AndroidTest.xml Tradefed 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 ( configuração em nível de módulo ), uma etapa de execução de teste e uma etapa de desmontagem.
  • Nova tentativa intramódulo: Nova tentativa automática feita pelo arnês dentro do módulo.
  • Repetição da suíte: reexecução completa dos testes anteriores com falha da suíte.

Estrutura ITestSuite

ITestSuite em Tradefed refere-se à classe base comum que conduz a execução de uma suíte. 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 a 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. Executar testes de módulo.
    3. Execute a desmontagem no nível do 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 suite runner em uma configuração Tradefed, o Tradefed segue o padrão usual da configuração: executando build_provider , target_preparer , test (nosso suite neste caso) e target_cleaner .

Essa 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 as 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.

Exemplo de metadados:

<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 acima executaria todos os módulos com uma estrutura como metadados de componentes .

Exemplo AndroidTest.xml completo:

<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 aplicativo instantâneo, em vez de um modo de aplicativo padrão.

Todos os modos ou parâmetros possíveis são descritos por ModuleParameters e têm um manipulador associado em ModuleParametersHelper que permite alterar a configuração do módulo para executar 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 ocorra a parametrização, a linha de comando precisa habilitá-la com:

--enable-parameterized-modules

Também é possível executar um único modo dado 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 .