O Google está comprometido em promover a equidade racial para as comunidades negras. Veja como.
Esta página foi traduzida pela API Cloud Translation.
Switch to English

Configuração de teste complexa

Alguns módulos de teste podem exigir etapas personalizadas de configuração e desmontagem que não podem ser executadas no próprio caso de teste. Exemplos típicos podem incluir:

  • instale outros aplicativos (além do apk de teste)
  • envie alguns arquivos para o dispositivo
  • executar comandos (por exemplo, adb shell pm ...)

No passado, as equipes de componentes geralmente recorriam à gravação de um teste no lado do host para executar essas tarefas, o que requer entendimento do equipamento da Federação do Comércio e normalmente aumenta a complexidade de um módulo de teste.

Tomando emprestado do CTS, introduzimos o conceito de configuração do módulo de teste para suportar essas tarefas. A lista de tarefas comuns acima pode ser alcançada com apenas algumas linhas de configuração. Para flexibilidade máxima, você pode implementar seu próprio preparador de destino, conforme definido por ITargetPreparer ou ITargetCleaner , e configurá-los para usar em sua própria configuração do módulo de teste.

Uma configuração do módulo de teste para um módulo de teste é um arquivo XML necessário adicionado à pasta de origem do módulo de nível superior, denominada 'AndroidTest.xml'. O XML segue o formato de um arquivo de configuração usado pelo equipamento de automação de teste da Federação de Comércio. Atualmente, as principais tags tratadas através das configurações do módulo de teste são as tags "target_preparer" e "test".

Preparadores de alvos

Uma tag "target_preparer", como o nome sugere, define um preparador de destino (consulte ITargetPreparer ) que oferece um método de configuração, que é chamado antes que o módulo de teste seja executado para teste; e se a classe mencionada na tag "target_preparer" também implementar ITargetCleaner , seu método de desmontagem será chamado após o término do módulo de teste.

Para usar a configuração interna do módulo comum, adicione um novo arquivo 'AndroidTest.xml' na pasta de nível superior do seu módulo de teste e preencha-o com o seguinte conteúdo:

 <?xml version="1.0" encoding="utf-8"?>
<!-- [insert standard AOSP copyright here] -->
<configuration description="Test module config for Foo">
<!-- insert options here -->
</configuration>
 

Como exemplo, podemos adicionar as seguintes tags de opção (no comentário "inserir" acima):

     <target_preparer class="com.android.tradefed.targetprep.RunCommandTargetPreparer">
        <option name="run-command" value="settings put secure accessibility_enabled 1" />
        <option name="teardown-command" value="settings put secure accessibility_enabled 0" />
    </target_preparer>
 

As opções configuram o equipamento de teste para:

  1. antes que o módulo de teste seja chamado, execute o comando shell "settings put secure accessibility_enabled 1" no dispositivo
  2. após a conclusão do módulo de teste, execute o comando shell "settings put secure accessibility_enabled 0"

Neste exemplo em particular, a acessibilidade é ativada / desativada antes / após a execução do módulo de teste, respectivamente. Com um exemplo simples demonstrado, é necessário cobrir mais detalhes sobre como a tag "option" é usada. Como mostrado acima, a tag pode ter dois atributos: nome, valor. O atributo name indica o nome da opção e é dividido em duas partes separadas por dois pontos: nome abreviado do preparador e o nome da opção real oferecido pelo preparador.

O objetivo exato do campo de valor depende de como o preparador definiu a opção: pode ser uma sequência de caracteres, um número, um booleano ou até um caminho de arquivo etc. No exemplo acima, o nome “comando de execução: comando de execução” significa que estamos definindo um valor para a opção "comando de execução" definida por um preparador de destino com o nome abreviado "comando de execução"; e o nome “run-command: teardown-command” significa que estamos definindo um valor para a opção “teardown-command” também definida pelo mesmo preparador de destino com o nome abreviado “run-command”. Aqui está um resumo dos três preparadores de destino comuns:

  • nome da classe: PushFilePreparer

    • nome abreviado : push-file
    • função : envia arquivos arbitrários da pasta de casos de teste para o destino no dispositivo
    • notas :
      • esse preparador pode enviar de pasta para pasta ou arquivo para arquivo; ou seja, não é possível enviar por push um arquivo para uma pasta no dispositivo: você também deve especificar o nome do arquivo de destino nessa pasta
    • opções :
      • push: uma especificação de envio, formatada como ' /path/to/srcfile.txt->/path/to/destfile.txt ' ou ' /path/to/srcfile.txt->/path/to/destdir/ '. Pode ser repetido Esse caminho pode ser relativo ao diretório do módulo de teste ou ao próprio diretório de saída.
      • ** pós-envio: ** Um comando para executar no dispositivo (com ` adb shell <your command> `) após todas as tentativas terem sido tentadas. Caso de uso típico seria usar chmod para permissões
  • nome da classe: InstallApkSetup

    • nome curto: install-apk
    • função: envia arquivos apk arbitrários para o destino no dispositivo
    • opções:
      • test-file-name: o nome do apk a ser instalado no dispositivo.
      • install-arg: argumentos adicionais a serem passados ​​para o comando pm install, incluindo o traço principal, por exemplo, “-d”. Pode ser repetido
  • nome da classe: RunCommandTargetPreparer

    • nome curto: comando de execução
    • função: executa comandos arbitrários do shell antes ou depois da execução do módulo de teste
    • opções:
      • comando de execução: comando do shell adb a ser executado. Pode ser repetido
      • teardown-command: comando adb shell para executar durante a fase de desmontagem. Pode ser repetido

Classe de teste

Uma classe de teste é a classe da Federação do Comércio a ser usada para executar o teste.

 <test class="com.android.tradefed.testtype.AndroidJUnitTest">
  <option name="package" value="android.test.example.helloworld"/>
  <option name="runner" value="android.support.test.runner.AndroidJUnitRunner"/>
</test>
 

Aqui estão três classes de teste comuns:

  • nome da classe: GTest

    • nome curto: gtest
    • função: Um teste que executa um pacote de teste nativo em determinado dispositivo.
    • opções:
      • caminho do dispositivo de teste nativo : o caminho no dispositivo em que os testes nativos estão localizados.
  • nome da classe: InstrumentationTest

    • nome curto: instrumentação
    • função: Um teste que executa um pacote de testes de instrumentação em um determinado dispositivo
    • opções:
      • pacote: o nome do pacote de manifesto do aplicativo de teste Android a ser executado.
      • classe: o nome da classe de teste a ser executada.
      • método: o nome do método de teste a ser executado.
  • nome da classe: AndroidJUnitTest

    • função: Um teste que executa um pacote de teste de instrumentação em determinado dispositivo usando o android.support.test.runner.AndroidJUnitRunner Essa é a principal maneira de executar um teste de instrumentação.