Infraestrutura de teste automatizada

O Android 9 inclui uma infraestrutura Vendor Test Suite (VTS) para testes automatizados de VTS, CTS ou outros testes em dispositivos parceiros que executam a imagem de sistema genérica (GSI) AOSP. Anteriormente, executar esses testes era uma operação altamente manual; a nova infraestrutura de teste VTS foi projetada para oferecer suporte a testes automatizados várias vezes ao dia em vários dispositivos.

Arquitetura

A infraestrutura de testes automatizados VTS usa a seguinte arquitetura:

Automated test architecture

Figura 1. Arquitetura de infraestrutura de testes automatizados VTS

Quando um teste é acionado, a infraestrutura de testes automatizados VTS executa as seguintes tarefas:

  1. Busca artefatos de construção e recursos de teste de diferentes locais:
    • Partner Android Build (PAB) . Para a estrutura GSI, VTS e algumas outras compilações.
    • Sistema de arquivos local, Google Cloud Storage ou outro sistema de compilação específico do fornecedor . Para parceiros que não armazenam builds na nuvem do Google.
  2. Os flashes criam artefatos (do dispositivo) e o GSI (do AOSP) no(s) dispositivo(s) conectado(s).
  3. Executa testes VTS usando TradeFed local ou um TradeFed na nuvem.
  4. Relata os resultados dos testes para o painel VTS

O processo é coordenado pelo controlador de host VTS (HC), uma máquina do laboratório que direciona o comportamento de todos os dispositivos conectados em teste. O HC é responsável por buscar as compilações mais recentes, exibi-las em dispositivos e invocar testes (localmente ou por meio do comandante). Ele também se comunica com um agendador de nuvem e direciona o tráfego entre o agendador e a instância do TradeFed (ou algum outro equipamento) em execução no HC. Para obter detalhes sobre o controlador de host, consulte Arquitetura do controlador de host.

Provedores de recursos

O teste automatizado requer recursos como compilações do sistema, arquivos de teste e artefatos VTS. Embora seja possível construí-los a partir do código-fonte, é mais fácil construí-los a partir da ponta da árvore regularmente do que postar os artefatos para download.

Os parceiros podem acessar recursos de automação usando os seguintes locais:

  • Parceiro Android Build . Acesso programático concedido por conta.
  • Sistema de arquivos local (ou similar). Para parceiros que não usam o Partner Android Build.

Para uso posterior na atualização dos dispositivos, os recursos incluem provedores de compilação para ambas as opções, estendendo-se de um único build_provider.py que armazena as compilações em diretórios temporários locais.

Compilação do Android do parceiro

No Android 8.1 e versões anteriores, os parceiros Android precisavam visitar o site do Partner Android Build ( https://partner.android.com/build ), navegar até a conta e buscar as imagens mais recentes do sistema por meio da interface do usuário. Para ajudar os parceiros a evitar esse processo lento e trabalhoso, o Android 9 inclui suporte para download automático desses recursos do PAB quando as credenciais apropriadas são fornecidas.

Estabelecendo acesso

O acesso programático usa OAuth2 nas APIs do Google para acessar as RPCs necessárias. Usando a abordagem padrão para gerar credenciais OAuth2, o parceiro deve configurar um par de ID/segredo do cliente com o Google. Quando o PartnerAndroidBuildClient é apontado para esse segredo pela primeira vez, ele abre uma janela do navegador para o usuário fazer login em sua conta do Google, o que gera as credenciais OAuth2 necessárias para avançar. As credenciais (token de acesso e token de atualização) são armazenadas localmente, o que significa que os parceiros precisam fazer login apenas uma vez.

Solicitação POST para URL

Clicar em um link de recurso no PAB envia uma solicitação POST que inclui os dados necessários para esse recurso, incluindo:

  • id de compilação, destino de compilação
  • nome do recurso
  • ramo
  • nome do candidato de lançamento e se o candidato é ou não uma compilação interna

A solicitação POST é recebida pelo método downloadBuildArtifact do RPC buildsvc , que retorna uma URL que pode ser usada para acessar o recurso.

  • Para recursos de APK do Clockwork Companion, o URL é um URL legível hospedado no PAB (que é protegido por autenticação e acessível com as credenciais OAuth2 apropriadas).
  • Para outros recursos, o URL é um URL longo e não protegido da API interna do Android Build (que expira após cinco minutos).

Obtendo o URL

Para evitar falsificação de solicitação entre sites, o RPC buildsvc requer que um token XSRF seja POSTado com os outros parâmetros. Embora esse token torne o processo mais seguro, ele também torna o acesso programático muito mais difícil, pois o token (que está disponível apenas no JavaScript da página PAB) agora também é necessário para acesso.

Para evitar esse problema, o Android 9 redesenha o esquema de nomenclatura de URL para todos os arquivos (não apenas APKs) para usar nomes de URL previsíveis para acessar listas de artefatos e URLs de artefatos. O PAB agora usa um formato de URL conveniente que permite que os parceiros baixem recursos; Os scripts HC podem baixar esses APKs facilmente, pois o formato do URL é conhecido e o HC pode ignorar os problemas de XSRF/cookie porque não precisa do RPC buildsvc .

Sistema de arquivos local

Dado um diretório com uma lista (ou arquivo zip) de artefatos, o provedor de compilação define as imagens relevantes com base no que está no diretório. Você pode usar a ferramenta gsutil para copiar arquivos do Google Cloud Storage para um diretório local.

Builds piscando

Depois que as imagens de dispositivo mais recentes forem baixadas para o host, essas imagens devem ser exibidas nos dispositivos. Isso é feito usando os comandos padrão adb e fastboot e subprocessos Python, com base nos caminhos de arquivo temporários armazenados pelos provedores de compilação.

Ações suportadas:

  • Piscando apenas o GSI
  • Flashing de imagens individuais do sistema principal (por exemplo, fastboot flash boot boot.img )
  • Piscando todas as imagens do sistema principal. Exemplo:
    • fastboot flashall (usando o utilitário flashall )
    • fastboot flash (um de cada vez)

Executando testes

No Android 9, a infraestrutura de teste automatizado VTS oferece suporte apenas ao equipamento de teste TradeFed, mas pode ser estendida para oferecer suporte a outros equipamentos no futuro.

Depois que os dispositivos estiverem preparados, você poderá invocar testes usando uma das seguintes opções:

  • Ao usar o TradeFed localmente, use o comando test no controlador host, que recebe o nome de um plano de teste VTS (por exemplo vts-selftest ) e executa o teste.
  • Ao usar um cluster TradeFed (opcionalmente conectado ao MTT), use o comando lease no console do controlador de host, que procura execuções de teste não cumpridas.

Se estiver usando o TradeFedCluster, o TradeFed é executado localmente como um gerenciador remoto . Caso contrário, os testes são invocados usando subprocessos do Python.

Resultados de relatórios

Os resultados do teste são relatados automaticamente para alguns projetos do painel VTS pelo VtsMultiDeviceTest .