Modelos de teste

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

Os desenvolvedores podem usar esses modelos para minimizar o esforço envolvido na integração de tais 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 comumente usados.

Modelo de teste binário

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

• Testes baseados em C++ compilados e enviados para o dispositivo
• Testes 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.

Integre testes do lado do destino com o modelo BinaryTest

O modelo BinaryTest foi projetado para ajudar os desenvolvedores a integrar facilmente testes do lado do destino. Na maioria dos casos, você pode adicionar algumas linhas simples de configuração em AndroidTest.xml . Exemplo de configuração 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 relativo do host da origem binária de teste permite que o modelo lide com a preparação, envio de arquivos, execução de teste, análise de resultados e limpeza.
• O modelo contém métodos relacionados à criação de casos 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 oferece suporte às seguintes opções de configuração:

Para opções com tipo de valor strings , 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 em opções com valores strings e usando :: como delimitador. Tags de teste são especialmente úteis ao incluir fontes binárias com o mesmo nome, mas com bits ou diretórios pai diferentes. Por exemplo, para evitar envio de arquivos ou 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 fontes 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 bitness ABI; ou seja, testes com a tag _32bit não são executados na 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 em binary-test-working-directory com a mesma tag. A opção binary-test-working-directory é opcional para testes binários, permitindo especificar um único diretório de trabalho para uma tag. Quando a opção binary-test-working-directory não é especificada, 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 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 testes Python do lado do host estendidos do BaseTest no executor VTS. 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 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.

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

Execute 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, de forma que todas as configurações de BinaryTest sejam 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 em lote para melhorar o desempenho. No entanto, para maior confiabilidade, se o modo não for especificado, o padrão será não-lote.

Modo sem lote

O modo não em lote faz chamadas individuais ao 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 sem lote incluem:

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

As desvantagens de usar o modo sem 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 (possíveis otimizações futuras).

Modo em lote

No modo em 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):

Assim como no modo não em lote, o resultado do teste é analisado por meio do arquivo xml de saída do 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 de teste e o progresso no terminal em um formato que pode ser analisado pela estrutura para status de teste, resultados e logs.

As vantagens de usar o modo em lote incluem:

• Isolamento de casos de teste . Fornece o mesmo nível de isolamento de caso de teste que o modo sem 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 sem lote.

As desvantagens de usar o modo em 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 do 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. Revisitaremos esta opção no futuro para melhorar a confiabilidade desta 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 nome do caso de teste por padrão.

Estenda os 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 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ê melhorou os designs dos modelos existentes, encorajamos você a contribuir com a base de código VTS.