Mapeamento de teste

Esta é uma breve introdução ao mapeamento de testes e uma explicação de como conseguir começou a configurar testes no Android Open Source Project (AOSP).

Sobre o mapeamento de testes

O mapeamento de testes é uma abordagem baseada em Gerrit que permite aos desenvolvedores criar e regras de teste pós-envio diretamente na árvore de origem do Android e deixe a decisões de ramificações e dispositivos a serem testados na infraestrutura de teste. As definições de mapeamento de teste são arquivos JSON chamados TEST_MAPPING que você pode em qualquer diretório de origem.

O Atest pode usar os arquivos TEST_MAPPING para executar testes de pré-envio no diretórios associados. Com o mapeamento de testes, você pode adicionar o mesmo conjunto de testes ao verificações de pré-envio com uma mudança mínima dentro da árvore de origem do Android.

Confira estes exemplos:

O mapeamento de testes depende do arcabouço de testes da Trade Federation (TF) para execução de testes e relatórios de resultados.

Definir grupos de teste

Teste grupos de teste mapeados com um grupo de teste. O nome de um grupo de teste pode ser qualquer string. Por exemplo, presubmit pode ser o nome de um grupo de testes para executar ao validar alterações. E postsubmit podem ser os testes usados para validar os builds depois que as alterações forem mescladas.

Regras de script de compilação do pacote

Para o arquinho de testes da Trade Federation para executar módulos de teste para um determinado build, esses módulos precisam ter Definição test_suites para Soong ou LOCAL_COMPATIBILITY_SUITE definida para Make a um destes dois pacotes:

  • general-tests serve para testes que não dependem de dispositivos específicos. (como hardwares específicos de fornecedores que a maioria dos dispositivos têm). A maioria dos testes precisa estar no pacote general-tests, mesmo se forem específicos para uma ABI ou recursos de bits ou de hardware como HWASan (há uma um destino test_suites separado para cada ABI) e mesmo que elas tenham que ser executadas em um dispositivo.
  • device-tests serve para testes que dependem de recursos específicos do dispositivo. Normalmente, esses testes são encontrados em vendor/. Específico do dispositivo se refere apenas a recursos que são exclusivos de um dispositivo. Portanto, isso se aplica aos testes JUnit, bem como aos testes GTest (que normalmente devem ser marcados como general-tests, mesmo que sejam específicas da ABI).

Exemplos:

Android.bp: test_suites: ["general-tests"],
Android.mk: LOCAL_COMPATIBILITY_SUITE := general-tests

Configurar testes para serem executados em um pacote de testes

Para que um teste seja executado dentro de um pacote de testes, o teste:

  • Não pode ter nenhum provedor de build.
  • precisa limpar após a conclusão, por exemplo, excluindo qualquer elemento temporário arquivos gerados durante o teste.
  • É preciso alterar as configurações do sistema para o valor padrão ou original.

  • Não pode presumir que um dispositivo está em um determinado estado, por exemplo, pronto para o root. A maioria dos testes não exige privilégio raiz para ser executada. Se um teste exigir raiz, ela deve especificar isso com RootTargetPreparer na AndroidTest.xml, como no exemplo a seguir:

    <target_preparer class="com.android.tradefed.targetprep.RootTargetPreparer"/>

Criar arquivos de mapeamento de teste

Para o diretório que exige cobertura de teste, adicione um arquivo JSON TEST_MAPPING semelhante ao exemplo. Essas regras garantem que os testes sejam executados pré-envio verifica quando algum arquivo é tocado nesse diretório ou em qualquer subdiretórios.

Siga um exemplo

Confira um exemplo de arquivo TEST_MAPPING (está no formato JSON, mas com comentários) compatíveis):

{
  "presubmit": [
    // JUnit test with options and file patterns.
    {
      "name": "CtsWindowManagerDeviceTestCases",
      "options": [
        {
          "include-annotation": "android.platform.test.annotations.RequiresDevice"
        }
      ],
      "file_patterns": ["(/|^)Window[^/]*\\.java", "(/|^)Activity[^/]*\\.java"]
    },
    // Device-side GTest with options.
    {
      "name" : "hello_world_test",
      "options": [
        {
          "native-test-flag": "\"servicename1 servicename2\""
        },
        {
          "native-test-timeout": "6000"
        }
      ]
    }
    // Host-side GTest.
    {
      "name" : "net_test_avrcp",
      "host" : true
    }
  ],
  "postsubmit": [
    {
      "name": "CtsDeqpTestCases",
      "options": [
        {
          // Use regex in include-filter which is supported in AndroidJUnitTest
          "include-filter": "dEQP-EGL.functional.color_clears.*"
        }
      ]
    }
  ],
  "imports": [
    {
      "path": "frameworks/base/services/core/java/com/android/server/am"
    }
  ]
}

Definir atributos

No exemplo, presubmit e postsubmit são os nomes de cada grupo de teste. Consulte Definir grupos de teste para mais informações. sobre grupos de teste.

Você pode definir o nome do módulo de teste ou do teste de integração da Trade Federation name (caminho do recurso para o arquivo XML de teste, por exemplo, uiautomator/uiautomator-demo) no valor do atributo name. O campo name não pode use a classe name ou o método de teste name. Para restringir os testes a serem executados, use opções como include-filter. Consulte (include-filter de exemplo de uso).

A configuração host de um teste indica se ele é sem dispositivo. em execução no host ou não. O valor padrão é false, o que significa que o teste requer um dispositivo para funcionar. Os tipos de teste com suporte são HostGTest para Binários do GTest e HostTest para JUnit provas.

O atributo file_patterns permite definir uma lista de strings de expressões regulares para corresponder ao caminho relativo de qualquer arquivo de código-fonte (relativo ao que contém o arquivo TEST_MAPPING). No exemplo, O teste CtsWindowManagerDeviceTestCases é executado no pré-envio somente quando um arquivo Java começa com Window ou Activity, que existe no mesmo diretório do TEST_MAPPING ou qualquer um dos subdiretórios será alterado. As barras invertidas `` precisam ter escape, porque estão em um arquivo JSON.

O atributo imports permite incluir testes em outros arquivos TEST_MAPPING. sem copiar o conteúdo. Os arquivos TEST_MAPPING na pasta pai do caminho importado também são incluídos. O mapeamento de teste permite importações aninhadas; isso significa que dois arquivos TEST_MAPPING podem importar um ao outro, e o mapeamento de teste pode mesclar os testes incluídos.

O atributo options contém opções adicionais de linha de comando do Tradefed.

Para conferir uma lista completa das opções disponíveis em um determinado teste, execute:

tradefed.sh run commandAndExit [test_module] --help

Consulte Processamento de opções no Tradefed para mais detalhes sobre como as opções funcionam.

Executar testes com o Atest

Para executar as regras de teste de pré-envio localmente:

  1. Acesse o diretório que contém o arquivo TEST_MAPPING.

  2. Execute o comando:

    atest

Todos os testes de pré-envio configurados nos arquivos TEST_MAPPING do e os diretórios pai são executados. O Atest localiza e executa dois testes para o pré-envio (A e B).

Essa é a maneira mais simples de executar testes de pré-envio no TEST_MAPPING arquivos no diretório de trabalho atual (CWD) e nos diretórios pai. Atesto localiza e usa o arquivo TEST_MAPPING no CWD e todos os diretórios.

Código-fonte da estrutura

Este exemplo mostra como configurar arquivos TEST_MAPPING no árvore de origem:

src
├── project_1
│   └── TEST_MAPPING
├── project_2
│   └── TEST_MAPPING
└── TEST_MAPPING

Conteúdo de src/TEST_MAPPING:

{
  "presubmit": [
    {
      "name": "A"
    }
  ]
}

Conteúdo de src/project_1/TEST_MAPPING:

{
  "presubmit": [
    {
      "name": "B"
    }
  ],
  "postsubmit": [
    {
      "name": "C"
    }
  ],
  "other_group": [
    {
      "name": "X"
    }
  ]}

Conteúdo de src/project_2/TEST_MAPPING:

{
  "presubmit": [
    {
      "name": "D"
    }
  ],
  "import": [
    {
      "path": "src/project_1"
    }
  ]}

Especificar diretórios de destino

É possível especificar um diretório de destino para executar testes em arquivos TEST_MAPPING nesse diretório. O comando a seguir executa dois testes (A, B):

atest --test-mapping src/project_1

Executar regras de teste pós-envio

Você também pode usar esse comando para executar as regras de teste pós-envio definidas no TEST_MAPPING em src_path (o padrão é CWD) e os diretórios pais:

atest [--test-mapping] [src_path]:postsubmit

Executar apenas testes que não exigem dispositivo

Use a opção --host para que o Atest execute apenas os testes configurados. que não precisam de dispositivos. Sem essa opção, o Atest executa os dois testes, aqueles que exigem dispositivo e aqueles que são executados no host e não precisam de dispositivo. A os testes são executados em dois conjuntos separados:

atest [--test-mapping] --host

Identificar grupos de teste

Você pode especificar grupos de teste no comando "Atest". O comando a seguir executa todos os testes de postsubmit relacionados a arquivos no diretório src/project_1, que contém apenas um teste (C).

Ou você pode usar :all para executar todos os testes, independente do grupo. O seguinte executa quatro testes (A, B, C, X):

atest --test-mapping src/project_1:all

Incluir subdiretórios

Por padrão, executar testes no TEST_MAPPING com o Atest executa apenas o pré-envio. de testes configurados no arquivo TEST_MAPPING no CWD (ou diretório fornecido) e os diretórios pai. Se você quiser executar testes em todos TEST_MAPPING nos subdiretórios, use a opção --include-subdir para forçar o Atest a incluir esses testes também.

atest --include-subdir

Sem a opção --include-subdir, o Atest executa apenas o teste A. Com o --include-subdir, o Atest executa dois testes (A, B).

Compatível com comentário no nível da linha

Você pode adicionar um comentário no formato // no nível da linha para detalhar o TEST_MAPPING. com uma descrição da configuração a seguir. ATest e Trade Federation pré-processar TEST_MAPPING para um formato JSON válido sem comentários. Para manter o arquivo JSON limpo, apenas o comentário do formato // no nível da linha é suportado.

Exemplo:

{
  // For presubmit test group.
  "presubmit": [
    {
      // Run test on module A.
      "name": "A"
    }
  ]
}