Modelos de teste

O AOSP inclui modelos de teste para módulos de teste que não são uma subclasse Python do lado do host do BaseTest do VTS runner.

Os desenvolvedores podem usar esses modelos para minimizar o esforço envolvido na integração desses testes. Esta seção aborda a configuração e o uso dos modelos de teste (localizados no diretório VTS testcases/template ) e fornece exemplos de modelos comumente usados.

modelo BinaryTest

Use o modelo BinaryTest para integrar testes executados no dispositivo de destino no VTS. Os testes do lado do alvo incluem:

• Testes baseados em C++ compilados e enviados para o dispositivo
• Testes Python do lado do destino compilados como binários
• Shell scripts executáveis ​​em dispositivos

Esses testes podem ser integrados ao VTS com ou sem o modelo BinaryTest.

Integre testes do lado do destino com o modelo BinaryTest

O modelo BinaryTest foi projetado para ajudar os desenvolvedores a integrar facilmente os testes do lado do destino. Na maioria dos casos, você pode adicionar algumas linhas simples de configuração em AndroidTest.xml . Configuração de exemplo de VtsDeviceTreeEarlyMountTest :

<configuration description="Config for VTS VtsDeviceTreeEarlyMountTest.">
  ...
<test class="com.android.tradefed.testtype.VtsMultiDeviceTest">
<option name="test-module-name" value="VtsDeviceTreeEarlyMountTest"/>
<option name="binary-test-source" value="_32bit::DATA/nativetest/dt_early_mount_test/dt_early_mount_test" />
<option name="binary-test-source" value="_64bit::DATA/nativetest64/dt_early_mount_test/dt_early_mount_test" />
<option name="test-timeout" value="5m"/>
</test>
</configuration>

Nesta configuração:

• binary-test-source e binary-test-type são específicos do modelo.
• A especificação do caminho de host relativo da fonte binária de teste permite que o modelo lide com a preparação, envio de arquivo, execução de teste, análise de resultados e limpeza.
• O modelo contém métodos relacionados à criação de caso de teste para substituição de subclasses.
• O modelo assume um caso de teste por módulo binário de teste e o nome do arquivo de origem binário é usado como nome do caso de teste por padrão.

Opções de configuração

O modelo BinaryTest suporta as seguintes opções de configuração:

Para opções com strings de tipo de valor, você pode adicionar vários valores repetindo as opções na configuração. Por exemplo, defina binary-test-source duas vezes (conforme mostrado no exemplo VtsDeviceTreeEarlyMountTest ).

tags de teste

Você pode adicionar tags de teste prefixando-as às opções com valores strings e usando :: como delimitador. As tags de teste são especialmente úteis ao incluir fontes binárias com o mesmo nome, mas com diferentes bitness ou diretórios pai. Por exemplo, para evitar o envio de arquivos ou a colisão de nomes de resultados para fontes com o mesmo nome, mas de diretórios de origem diferentes, você pode especificar tags diferentes para essas fontes.

Conforme mostrado no exemplo VtsDeviceTreeEarlyMountTest com as duas origens dt_early_mount_test , as tags de teste são os prefixos _32bit:: e _64bit:: em binary-test-source . Tags que terminam em 32bit ou 64bit marcam automaticamente os testes como disponíveis para um bit ABI; ou seja, testes com a tag _32bit não são executados em ABI de 64 bits. Não especificar uma tag é igual a usar uma tag com uma string vazia.

Opções com as mesmas tags são agrupadas e isoladas de outras tags. Por exemplo, binary-test-args com a tag _32bit é aplicado apenas a binary-test-source com a mesma tag e executado no binary-test-working-directory com a mesma tag. A opção binary-test-working-directory é opcional para testes binários, permitindo que você especifique um único diretório de trabalho para uma tag. Quando a opção binary-test-working-directory não for especificada, os diretórios padrão serão usados ​​para cada tag.

O nome da tag é anexado diretamente ao nome do caso de teste no relatório de resultados. Por exemplo, o caso de teste testcase1 com tag _32bit aparece como testcase1_32bit no relatório de resultados.

Integre testes do lado do destino sem o modelo BinaryTest

No VTS, o formato de teste padrão são os testes Python do lado do host estendidos do BaseTest no VTS runner. Para integrar testes do lado do destino, você deve primeiro enviar os arquivos de teste para o dispositivo, executar os testes usando comandos shell e, em seguida, analisar os resultados usando scripts Python do lado do host.

Binários de teste de push

Recomendamos enviar arquivos usando o preparador de destino VtsFilePusher . Exemplo:

<target_preparer class="com.android.compatibility.common.tradefed.targetprep.VtsFilePusher">
        <option name="push" value="DATA/test->/data/local/tmp/test"/>
    </target_preparer>

O VtsFilePusher faz o seguinte:

1. Verifica a conectividade do dispositivo.
2. Determina o caminho absoluto do arquivo de origem.
3. Envia os arquivos usando o comando adb push .
4. Exclui os arquivos após a conclusão dos testes.

Como alternativa, você pode enviar arquivos manualmente usando um script de teste Python do lado do host que segue um procedimento semelhante.

Executar testes

Depois de enviar os arquivos para o dispositivo, execute o teste usando comandos shell em um script de teste Python do lado do host. Exemplo:

device = self.android_devices[0]
res = device.shell.Execute(["chmod a+x /data/local/tmp/test", "/data/local/tmp/test"])
asserts.AssertFalse(any(res[return_codes]))

Modelo GtestBinaryTest

O modelo GtestBinaryTest hospeda binários de teste GTest, cada um dos quais geralmente contém vários casos de teste. Este modelo estende o modelo BinaryTest substituindo a configuração, a criação de casos de teste e os métodos de análise de resultados, portanto, todas as configurações de BinaryTest são herdadas.

GtestBinaryTest adiciona a opção gtest-batch-mode :

Em geral, definir gtest-batch-mode como true aumenta o desempenho e diminui ligeiramente a confiabilidade. Nos testes de conformidade VTS, muitos módulos usam o modo de lote para melhorar o desempenho. No entanto, para confiabilidade, se o modo não for especificado, o padrão é não em lote.

Modo não em lote

O modo não em lote faz chamadas individuais para o binário GTest para cada caso de teste. Por exemplo, se o binário GTest contiver 10 casos de teste (após a filtragem pela configuração do lado do host), o binário será chamado 10 vezes no shell do dispositivo cada vez com um filtro de teste diferente. Para cada caso de teste, um XML de saída de resultado GTest exclusivo é gerado e analisado pelo modelo.

As vantagens de usar o modo não em lote incluem:

• Isolamento do caso de teste . Uma falha ou travamento em um caso de teste não afeta outros casos de teste.
• Granularidade . Mais fácil de obter perfis/medição de cobertura por caso de teste, systrace, bugreport, logcat, etc. Os resultados e logs do teste são recuperados imediatamente após o término de cada caso de teste.

As desvantagens de usar o modo não em lote incluem:

• Carregamento redundante . Cada vez que o binário GTest é chamado, ele carrega bibliotecas relacionadas e executa configurações iniciais de classe.
• sobrecarga de comunicação . Após a conclusão de um teste, o host e o dispositivo de destino se comunicam para análise de resultados e próximos comandos (otimizações futuras possíveis).

modo de lote

No modo de lote GTest, o binário de teste é chamado apenas uma vez com um valor de filtro de teste longo contendo todos os casos de teste filtrados pela configuração do lado do host (isso evita o problema de carregamento redundante no modo não em lote). Você pode analisar os resultados do teste para GTest usando output.xml ou usando a saída do terminal.

Ao usar output.xml (padrão):

Como no modo não em lote, o resultado do teste é analisado por meio do arquivo xml de saída GTest. No entanto, como o xml de saída é gerado após a conclusão de todos os testes, se um caso de teste travar o binário ou o dispositivo, nenhum arquivo xml de resultado será gerado.

Ao usar a saída do terminal:

Enquanto o GTest está em execução, ele imprime o log do teste e o progresso no terminal em um formato que pode ser analisado pela estrutura para status, resultados e logs do teste.

As vantagens de usar o modo de lote incluem:

• Isolamento do caso de teste . Fornece o mesmo nível de isolamento de caso de teste que o modo não em lote se a estrutura reiniciar o binário/dispositivo após uma falha com um filtro de teste reduzido (excluindo casos de teste concluídos e com falha).
• Granularidade . Fornece a mesma granularidade de caso de teste que o modo não em lote.

As desvantagens de usar o modo de lote incluem:

• Custo de manutenção . Se o formato de log do GTest for alterado, todos os testes serão interrompidos.
• Confusão . Um caso de teste pode imprimir algo semelhante ao formato de progresso GTest, o que pode confundir o formato.

Devido a essas desvantagens, removemos temporariamente a opção de usar a saída da linha de comando. Voltaremos a essa opção no futuro para melhorar a confiabilidade dessa função.

Modelo HostBinaryTest

O modelo HostBinaryTest inclui executáveis ​​do lado do host que não existem em outros diretórios ou em scripts Python. Esses testes incluem:

• Binários de teste compilados executáveis ​​no host
• Scripts executáveis ​​em shell, Python ou outras linguagens

Um exemplo é o teste do lado do host da política VTS Security SELinux :

<configuration description="Config for VTS  Security SELinux policy host-side test cases">
    ...
    <test class="com.android.tradefed.testtype.VtsMultiDeviceTest">
        <option name="test-module-name" value="VtsSecuritySelinuxPolicyHost"/>
        <option name="binary-test-source" value="out/host/linux-x86/bin/VtsSecuritySelinuxPolicyHostTest" />
        <option name="binary-test-type" value="host_binary_test"/>
    </test>
</configuration>

HostBinaryTest não estende o modelo BinaryTest, mas usa configurações de teste semelhantes. No exemplo acima, a opção binary-test-source especifica um caminho relativo do lado do host para o executável de teste, e binary-test-type é host_binary_test . Semelhante ao modelo BinaryTest, o nome do arquivo binário é usado como o nome do caso de teste por padrão.

Estenda modelos existentes

Você pode usar modelos diretamente na configuração de teste para incluir testes não Python ou estendê-los em uma subclasse para lidar com requisitos de teste específicos. Os modelos no repositório VTS têm as seguintes extensões:

Os desenvolvedores são incentivados a estender qualquer modelo existente para quaisquer requisitos de teste específicos. Razões comuns para estender modelos incluem:

• Procedimentos especiais de configuração de teste, como preparar um dispositivo com comandos especiais.
• Gerando diferentes casos de teste e nomes de teste.
• Analisar os resultados lendo a saída do comando ou usando outras condições.

Para facilitar a extensão dos modelos existentes, os modelos contêm métodos especializados para cada funcionalidade. Se você aprimorou designs para modelos existentes, encorajamos você a contribuir com a base de código VTS.