Modelos de teste

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

Os desenvolvedores podem usar esses modelos para minimizar o esforço envolvido na integração de tais testes. Esta seção abrange 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 de teste binário

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
• Scripts de shell executáveis ​​em dispositivos

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

Integrando 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 . 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.
• Especificar o caminho de host relativo da fonte 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 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 nas opções com valores de strings e usando :: como delimitador. As tags de teste são especialmente úteis ao incluir fontes binárias com o mesmo nome, mas com bitness ou diretórios pai diferentes. Por exemplo, para evitar push de arquivo ou colisão de nome de resultado para origens com o mesmo nome, mas de diretórios de origem diferentes, você pode especificar tags diferentes para essas origens.

Conforme mostrado no exemplo VtsDeviceTreeEarlyMountTest com as duas fontes dt_early_mount_test , as tags de teste são os _32bit:: e _64bit:: em binary-test-source . Tags que terminam com 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 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 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 é 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, caso de teste testcase1 com tag _32bit aparece como testcase1_32bit no relatório de resultados.

Integrando 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 os testes do lado do destino, você deve primeiro enviar os arquivos de teste para o dispositivo, executar os testes usando comandos do shell e analisar os resultados usando scripts Python do lado do host.

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

Executando testes

Depois de enviar 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]))

GtestBinaryTest template

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 os métodos de configuração, criação de caso de teste e análise de resultados, para que todas as configurações do BinaryTest sejam herdadas.

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

Em geral, definir gtest-batch-mode como true aumenta o desempenho enquanto 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 será 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 filtrar por configuração do lado do host), o binário será chamado 10 vezes no shell do dispositivo a 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 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, relatório de erros, logcat, etc. Os resultados de teste e os logs são recuperados imediatamente após a conclusão 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 sem 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 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 para o 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 de casos 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 travados).
• 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 registro 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. Revisitaremos 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.

Estendendo 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.
• Analisando os resultados lendo a saída do comando ou usando outras condições.

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