Infraestrutura de testes automatizada

O Android 9 inclui uma infraestrutura do Vendor Test Suite (VTS) para testes automatizados de VTS, CTS ou outros testes em dispositivos parceiros que executam a imagem genérica do sistema (GSI, na sigla em inglês) do AOSP. Antes, a execução desses testes era uma operação altamente manual. A nova infraestrutura de testes do VTS foi projetada para oferecer suporte a testes automatizados várias vezes por dia em vários dispositivos.

Arquitetura

A infraestrutura de testes automatizada do VTS usa a seguinte arquitetura:

Quando um teste é acionado, a infraestrutura de testes automatizada do VTS realiza as seguintes tarefas:

1. Busca artefatos de build e recursos de teste de diferentes locais:
   • Build do Android para parceiros (PAB). Para a GSI, a estrutura do VTS e alguns outros builds.
   • Sistema de arquivos local, Google Cloud Storage ou outro sistema de build específico do fornecedor. Para parceiros que não armazenam builds na nuvem do Google.
2. Faz o flash dos artefatos de build (do dispositivo) e da GSI (do AOSP) nos dispositivos conectados.
3. Executa testes do VTS usando o TradeFed local ou na nuvem.
4. Informa os resultados do teste ao painel do VTS.

O processo é coordenado pelo controlador host do VTS (HC, na sigla em inglês), uma máquina no laboratório que direciona o comportamento de todos os dispositivos conectados em teste. O HC é responsável por buscar os builds mais recentes, gravar em dispositivos e invocar testes (localmente ou pelo comandante). Ele também se comunica com um programador de nuvem e direciona o tráfego entre o programador e a instância do TradeFed (ou algum outro arnês) em execução no HC. Para mais detalhes sobre o controlador de host, consulte Arquitetura do controlador de host.

Provedores de recursos

Os testes automatizados exigem recursos como builds do sistema, arquivos de teste e artefatos do VTS. Embora seja possível criar esses itens da origem, é mais fácil criar regularmente a partir da ponta da árvore e postar os artefatos para download.

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

• Build do Android para parceiros. O acesso programático é concedido por conta.
• Sistema de arquivos local (ou similar). Para parceiros que não usam a versão do Android para parceiros.

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

Build do Android para parceiros

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

Estabelecer acesso

O acesso programático usa o OAuth2 nas APIs do Google para acessar as RPCs necessárias. Usando a abordagem padrão para gerar credenciais do OAuth2, o parceiro precisa configurar um par de ID/chave secreta do cliente com o Google. Quando o PartnerAndroidBuildClient é apontado para esse segredo pela primeira vez, ele abre uma janela do navegador para que o usuário faça login na Conta do Google, o que gera as credenciais do OAuth2 necessárias para continuar. 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

Ao clicar em um link de recurso no PAB, uma solicitação POST é enviada com os dados necessários para esse recurso, incluindo:

• ID do build, destino do build
• nome do recurso
• ramificação
• nome da versão candidata e se ela é um build interno

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

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

Acessar o URL

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

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

Sistema de arquivos local

Dado um diretório com uma lista (ou arquivo ZIP) de artefatos, o provedor de build define as imagens relevantes com base no conteúdo do diretório. É possível usar a ferramenta gsutil para copiar arquivos do Google Cloud Storage para um diretório local.

Versões do Flash

Depois que as imagens mais recentes do dispositivo forem baixadas para o host, elas precisarão ser transferidas para os dispositivos. Isso é feito usando os comandos padrão adb e fastboot e subprocessos do Python, com base nos caminhos de arquivos temporários armazenados pelos provedores de build.

Ações aceitas:

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

Executar testes

No Android 9, a infraestrutura de testes automatizados do VTS oferece suporte apenas ao arcabouço de testes do TradeFed, mas pode ser estendida para oferecer suporte a outros arcabouços no futuro.

Depois que os dispositivos estiverem preparados, invoque os testes usando uma das seguintes opções:

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

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

Resultados do relatório

Os resultados dos testes são informados automaticamente a alguns projetos do painel do VTS por VtsMultiDeviceTest.