Modelos de teste

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

Figura 1. Arquitetura do modelo de teste.

Os desenvolvedores podem usar esses modelos para minimizar o esforço envolvido para integrar esses testes. Nesta seção, você vai aprender a configurar e usar o modelos (localizados na VTS casos de teste/modelo do Google) e fornece exemplos dos modelos mais usados.

Modelo BinaryTest

Use o Teste binário para integrar testes que são executados no dispositivo de destino no VTS. Os testes do lado do alvo 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 BinaryTest. modelo.

Integrar testes do lado do destino com Modelo BinaryTest

O modelo BinaryTest foi projetado para ajudar os desenvolvedores a integrar facilmente no lado do alvo. Na maioria dos casos, você pode adicionar algumas linhas simples 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 estão específicos do modelo.
• Especificar o caminho do host relativo da fonte binária de teste ativa o modelo para lidar com preparação, envio de arquivos, execução de testes, análise de resultados e limpeza.
• O modelo contém métodos relacionados à criação de casos de teste para subclasses a substituir.
• O modelo pressupõe um caso de teste por módulo binário de teste, e o binário O nome do arquivo de origem é usado como o nome do caso de teste por padrão.

Opções de configuração

O modelo BinaryTest é compatível com as seguintes opções de configuração:

Nome da opção	Tipo de valor	Descrição
Fonte-de-teste-binário	cordas	Caminhos de origem de teste binários relativos ao diretório de casos de teste vts em host. Exemplo: DATA/nativetest/test
Diretório-de-trabalho-de-teste-binário	cordas	Diretórios de trabalho (caminho do lado do dispositivo). Exemplo: /data/local/tmp/testing/
binary-test-envp	cordas	Variáveis de ambiente para binários. Exemplo: PATH=/new:$PATH
binary-test-args	cordas	Argumentos ou flags de teste. Exemplo: --gtest_filter=test1
binary-test-ld-library-path	cordas	LD_LIBRARY_PATH. Exemplo: /data/local/tmp/lib
binary-test-disable-framework	booleano	Execute adb stop para desativar o framework do Android antes do teste. Exemplo: true
binary-test-stop-native-servers	booleano	Interrompa todos os servidores nativos configurados corretamente durante o teste. Exemplo: true
tipo de teste binário	string	Tipo de modelo. Outros tipos de modelo se estendem a partir desse modelo, mas é não precisa especificar essa opção para este modelo porque você já binary-test-source especificado.

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

Tags de teste

É possível adicionar tags de teste usando o prefixo strings nas opções. e usando :: como delimitador. As tags de teste são especialmente útil ao incluir fontes binárias com o mesmo nome, mas com diferentes bitness ou diretórios pai. Por exemplo, para evitar envio de arquivo ou nome de resultado entre origens com o mesmo nome, mas de diretórios de origem diferentes, é possível especificar tags diferentes para essas origens.

Conforme mostrado no exemplo VtsDeviceTreeEarlyMountTest com o duas origens dt_early_mount_test, as tags de teste são as Prefixos _32bit:: e _64bit:: ativados binary-test-source. Tags que terminam com 32bit ou 64bit marca automaticamente os testes como disponíveis para uma quantidade de bits da ABI. Ou seja, os testes com a tag _32bit não são executados em uma 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. Para exemplo, binary-test-args com a tag _32bit é aplicada somente a binary-test-source com a mesma tag e executada em binary-test-working-directory com a mesma tag. A A opção binary-test-working-directory é opcional para testes binários, que permitem especificar um único diretório de trabalho para uma tag. Quando o A opção binary-test-working-directory não é especificada, o 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 Modelo BinaryTest

No VTS, o formato de teste padrão são testes Python no lado do host estendidos BaseTest no executor do VTS. Para integrar testes do lado do alvo, primeiro é preciso enviar por push o arquivos de teste no dispositivo, executar os testes usando comandos shell e, em seguida, analisar o usando scripts Python no 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. Envia 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 teste Python no lado do host que segue um procedimento semelhante.

Executar testes

Depois de enviar os arquivos para o dispositivo, execute o teste usando comandos do shell em um script de teste do Python no 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

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

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

Nome da opção	Tipo de valor	Descrição
tipo de teste binário	string	Tipo de modelo. Usa o valor gtest.
modo gtest-batch	booleano	Executar binários do Gtest em modo de lote. Exemplo: true

Em geral, definir gtest-batch-mode como true aumenta o desempenho e diminui um pouco a confiabilidade. Conformidade com a VTS vários módulos usam o modo em lote para melhorar o desempenho. Para confiabilidade No entanto, se o modo não for especificado, o padrão será não lote.

Modo sem lote

O modo sem lote faz chamadas individuais ao binário GTest para cada caso de teste. Para exemplo, se o binário do GTest tiver 10 casos de teste (após a filtragem por host) configuração secundária), o binário é chamado 10 vezes no shell do dispositivo cada vez com um filtro de teste diferente. Para cada caso de teste, uma saída de resultado do GTest exclusiva O XML é gerado e analisado pelo modelo.

Figura 2. Modo sem lote.

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

• Isolamento do caso de teste. Falha ou travamento em um caso de teste não afeta outros casos de teste.
• Granularidade. Mais fácil para conseguir perfil/cobertura por caso de teste medição, Systrace, relatório de bugs, logcat etc. Os registros e resultados de teste 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 do GTest é chamado, ele carrega bibliotecas relacionadas e executa as configurações iniciais da 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 (futuros possíveis otimizações).

Modo de lote

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

Ao usar output.xml (padrão):

Figura 3. modo de lote, output.xml.

Assim como no modo sem lote, o resultado do teste é analisado usando o XML de saída do GTest. . No entanto, como o XML de saída é gerado depois que todos os testes são concluído, se um caso de teste falhou o binário ou o dispositivo, nenhum arquivo XML de resultado foi gerada.

Ao usar a saída do terminal:

Figura 4. Modo de lote, saída do terminal.

Enquanto o GTest está em execução, ele imprime o registro de teste e avança para o terminal. em um formato que possa ser analisado pelo framework quanto ao status, resultados e ou de sistemas operacionais de contêineres.

As vantagens de usar o modo em lote incluem:

• Isolamento do caso de teste. Oferece o mesmo nível de teste isolamento de casos como modo sem lote se o framework reiniciar o binário/dispositivo após uma falha com um filtro de teste reduzido, excluindo testes concluídos e com falha casos de uso diferentes.
• Granularidade. Fornece a mesma granularidade de caso de teste que em um modo que não seja em lote.

As desvantagens de usar o modo de lote incluem:

• Custo de manutenção. Se o formato de geração de registros do GTest mudar, todos os testes apresentarão falhas.
• Confusão. Um caso de teste pode gerar algo semelhante a GTest o formato de progresso, o que pode confundir o formato.

Devido a essas desvantagens, removemos temporariamente a opção de usar saída da linha de comando. Vamos rever 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 VTS Teste do host da política de SELinux de segurança:

<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 similares configurações de teste. No exemplo acima, o binary-test-source especifica um caminho relativo do lado do host para o executável de teste, e O valor da coluna binary-test-type é host_binary_test. Semelhante a BinaryTest, o nome do arquivo binário é usado como o nome do caso de teste padrão.

Estender modelos

É possível usar modelos diretamente na configuração de teste para incluir testes que não sejam Python ou estendê-los em uma subclasse para lidar com requisitos de teste específicos. Modelos em o repositório VTS tem as seguintes extensões:

Figura 5. Estender modelos existentes na VTS repositório

.

Os desenvolvedores são encorajados a estender qualquer modelo existente para quaisquer e requisitos de teste. Estes são alguns motivos comuns para ampliar modelos:

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

Para facilitar a extensão dos modelos existentes, eles contêm métodos especializada para cada funcionalidade. Se você melhorou os designs , recomendamos que você contribua para a base de código VTS.