Infraestrutura de testes automatizada

O Android 9 inclui uma infraestrutura do 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 teste do VTS foi projetada para oferecer suporte a testes automatizados várias vezes por dia em vários dispositivos.

Arquitetura

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

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

1. Busca artefatos de build e testa recursos de diferentes locais:
   • Versão do parceiro para Android (PAB, na sigla em inglês). Para o framework GSI, 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. Atualiza os artefatos de build (do dispositivo) e a GSI (do AOSP) nos dispositivos conectados.
3. Executa testes VTS usando o TradeFed local ou um TradeFed na nuvem.
4. Informa os resultados do teste no painel do VTS

O processo é coordenado pelo controlador de host do VTS (HC), 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, fazer a instalação deles em dispositivos e invocar testes (localmente ou pelo comando). 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 outro harness) em execução no HC. Para ver 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 VTS. Embora seja possível criar esses artefatos a partir da fonte, é mais fácil criá-los regularmente na ponta da árvore e postar os artefatos para download.

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

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

Para uso na atualização 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 do parceiro

Nas versões do Android 8.1 e anteriores, os parceiros do Android precisavam acessar o site do parceiro do Android Build (https://partner.android.com/build), navegar até a conta deles e buscar as imagens do 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 é direcionado para esse segredo pela primeira vez, uma janela do navegador é aberta para que o usuário faça login na Conta do Google, o que gera as credenciais OAuth2 necessárias para prosseguir. As credenciais (token de acesso e 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 na PAB envia uma solicitação POST que inclui os dados necessários para esse recurso, incluindo:

• ID do build, destino do build
• nome do recurso
• branch
• nome da versão candidata e se o candidato é 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 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 adequadas).
• Para outros recursos, o URL é longo e não protegido da API Android Build interna (que expira após cinco minutos).

Conseguir o URL

Para evitar a falsificação de solicitações 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 o acesso programático, já que o token (disponível apenas no JavaScript da página PAB) agora também é necessário para o acesso.

Para evitar esse problema, o Android 9 redesenhou 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 façam o download de recursos. Os scripts de HC podem fazer o download desses APKs com facilidade, já que o formato de URL é conhecido, e o HC pode contornar 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 build define as imagens relevantes com base no que está no 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 são transferidas por download para o host, essas imagens precisam ser instaladas nos dispositivos. Isso é feito usando os comandos adb e fastboot padrão e os subprocessos do Python, com base nos caminhos de arquivo temporários armazenados pelos provedores de build.

Ações compatíveis:

• Como atualizar apenas a GSI
• Atualizar imagens individuais do sistema principal (por exemplo, fastboot flash boot boot.img)
• Flashing 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 TradeFed, mas pode ser estendida para oferecer suporte a outros recursos 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 do host, que recebe o nome de um plano de teste do VTS (por exemplo, vts-selftest) e executa o teste.
• Ao usar um cluster do TradeFed (conectado opcionalmente ao MTT), use o comando lease no console do host controller, que procura execuções de teste não concluídas.

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

Relatar resultados

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