Modelos de teste

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

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 testcases/template do VTS) e fornece exemplos de modelos usados com frequência.

Modelo BinaryTest

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

• Testes baseados em C++ compilados e enviados ao dispositivo
• Testes do Python do lado do destino compilados como binários
• Scripts de shell executáveis em dispositivos

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

Integrar testes do lado do destino com o modelo BinaryTest

O modelo BinaryTest foi criado para ajudar os desenvolvedores a integrar facilmente testes do lado do destino. Na maioria dos casos, é possível adicionar algumas linhas simples de configuração em AndroidTest.xml. Exemplo de configuração do 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.
• Especificar o caminho do host relativo da fonte binária de teste permite que o modelo processe a preparação, o envio de arquivos, a execução de teste, a análise de resultados e a limpeza.
• O modelo contém métodos relacionados à criação de casos de teste para que as subclasses sejam substituídas.
• 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 oferece suporte às seguintes opções de configuração:

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

Testar tags

Para adicionar tags de teste, adicione um prefixo a opções com valores strings e use :: como delimitador. As tags de teste são especialmente úteis ao incluir origens binárias com o mesmo nome, mas com diferentes bitness ou diretórios pai. Por exemplo, para evitar colisões de nome de envio de arquivos ou resultados em fontes com o mesmo nome, mas de diretórios de origem diferentes, especifique tags diferentes para essas fontes.

Como mostrado no exemplo de VtsDeviceTreeEarlyMountTest com as duas origens dt_early_mount_test, as tags de teste são os prefixos _32bit:: e _64bit:: em binary-test-source. As tags que terminam com 32bit ou 64bit marcam automaticamente os testes como disponíveis para um bitness ABI, ou seja, os 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.

As opções com as mesmas tags são agrupadas e isoladas das outras. Por exemplo, binary-test-args com a tag _32bit é aplicada apenas a binary-test-source com a mesma tag e executada em 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 é especificada, os diretórios padrão sã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 a tag _32bit aparece como testcase1_32bit no relatório de resultados.

Integrar testes do lado do destino sem o modelo BinaryTest

No VTS, o formato de teste padrão são testes Python do host estendidos de BaseTest no VTS runner. Para integrar testes do lado de destino, primeiro envie os arquivos de teste para o dispositivo, execute os testes usando comandos de shell e analise os resultados usando scripts Python do lado do host.

Enviar binários de teste

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. Encaminha os arquivos usando o comando adb push.
4. Exclui os arquivos após a conclusão dos testes.

Como alternativa, é possível enviar arquivos manualmente usando um script de teste Python do lado do host que segue um procedimento semelhante.

Executar testes

Depois de enviar arquivos para o dispositivo, execute o teste usando comandos do 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 do GTest, cada um deles geralmente contendo vários casos de teste. Esse modelo estende o modelo BinaryTest substituindo os métodos de configuração, criação de casos de teste e análise de resultados. Assim, todas as configurações do BinaryTest são herdadas.

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

Em geral, definir gtest-batch-mode como true aumenta a performance e diminui um pouco a confiabilidade. Nos testes de compliance do 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 será não-lote.

Modo não em lote

O modo não em lote faz chamadas individuais para o binário do GTest para cada caso de teste. Por exemplo, se o binário GTest contiver 10 casos de teste (após a filtragem por configuração 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 do GTest exclusivo é gerado e analisado pelo modelo.

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

• Isolamento de casos de teste. Uma falha ou congelamento em um caso de teste não afeta outros casos de teste.
• Granularidade. É mais fácil fazer medições de perfil/cobertura por caso de teste, systrace, bugreport, logcat etc. Os resultados e registros de 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 do GTest é chamado, ele carrega as bibliotecas relacionadas e executa as configurações iniciais da classe.
• Sobrecarga de comunicação. Depois que um teste é concluído, o host e o dispositivo de destino se comunicam para a análise de resultados e os próximos comandos (otimizações futuras possíveis).

Modo de lote

No modo de lote do GTest, o binário de teste é chamado apenas uma vez com um valor de filtro de teste longo que contém todos os casos de teste filtrados pela configuração do host. Isso evita o problema de carregamento redundante no modo não em lote. É possível analisar os resultados de teste do GTest usando output.xml ou a saída do terminal.

Ao usar output.xml (padrão):

Como no modo não em lote, o resultado do teste é analisado pelo arquivo XML de saída do GTest. No entanto, como o XML de saída é gerado depois que todos os testes são concluídos, se um caso de teste falhar, o arquivo XML de resultado do dispositivo ou binário não será gerado.

Ao usar a saída do terminal:

Enquanto o GTest está em execução, ele imprime o registro de teste e o progresso para o terminal em um formato que pode ser analisado pelo framework para status, resultados e registros de teste.

As vantagens do uso do modo de lote incluem:

• Isolamento de casos de teste. Oferece o mesmo nível de isolamento de caso de teste que o modo não em lote, se o framework 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. Oferece 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 registro do GTest mudar, todos os testes serão interrompidos.
• Confusão. Um caso de teste pode imprimir algo semelhante ao formato de progresso do GTest, o que pode confundir o formato.

Por causa dessas desvantagens, removemos temporariamente a opção de usar a saída da linha de comando. Vamos analisar 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 de segurança SELinux do VTS:

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

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

Estender modelos

É possível usar modelos diretamente na configuração de teste para incluir testes que não são do Python ou estendi-los em uma subclasse para processar requisitos de teste específicos. Os modelos no repositório VTS têm as seguintes extensões:

Recomendamos que os desenvolvedores estendam qualquer modelo existente para requisitos específicos de teste. Confira alguns motivos comuns para estender modelos:

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

Para facilitar a extensão de modelos existentes, eles contêm métodos especializados para cada funcionalidade. Se você tiver designs aprimorados para modelos existentes, recomendamos que contribua com a base de código do VTS.