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 automatizada do VTS realiza as seguintes tarefas:

1. Busca artefatos de build e recursos de teste de diferentes locais:
   • Versão do parceiro para Android (PAB, na sigla em inglês). Para a GSI, o VTS e alguns outros builds.
   • Sistema de arquivos local, Google Cloud Storage ou outros recursos específicos do fornecedor sistema de build. Para parceiros que não armazenam builds no nuvem.
2. Flashes de artefatos de build (do dispositivo) e da 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 que direciona o comportamento de todos os dispositivos conectados que estão sendo testados. 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 mais detalhes sobre o controlador do host, consulte Arquitetura do controlador do 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 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 semelhante). Para parceiros que não usam o build do Android para parceiros.

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

Partner Android Build

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 o padrão abordagem para gerar credenciais do OAuth2, o parceiro precisa configurar uma ID do cliente/secreto par com o Google. Quando o PartnerAndroidBuildClient aponta para esse secret na primeira ele abre uma janela do navegador para o usuário fazer login na conta do Google , que gera as credenciais OAuth2 necessárias para avançar. O as credenciais (token de acesso e de atualização) são armazenadas localmente, ou seja, os parceiros devem precisar fazer login apenas uma vez.

solicitação POST para o URL

Clicar em um link de recurso no PAB envia uma solicitação POST que inclui o 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 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 é um URL longo e não protegido da rede API Android Build (que expira após cinco minutos).

Acessar 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. Esse token deixa processo mais seguro, também torna o acesso programático muito mais difícil, uma vez que (disponível apenas no JavaScript da página PAB) também está disponível. necessários para o acesso.

Para evitar esse problema, o Android 9 reformula o URL de todos os arquivos (não apenas APKs) para usar nomes de URL previsíveis para acessar listas e URLs de artefatos. O PAB agora usa um URL conveniente que permite que os parceiros façam o download de recursos; É possível fazer o download de scripts da Central de Ajuda esses APKs facilmente, já que o formato do URL é conhecido, e a Central de Ajuda pode ignorar a 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 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 para o host, elas precisam ser atualizadas nos dispositivos. Isso é feito com o uso Os comandos adb e fastboot e os subprocessos do Python, com base nos caminhos de arquivos temporários armazenados pelos provedores de build.

Ações compatíveis:

• Atualizar apenas a GSI
• Atualizar imagens individuais do sistema principal (por exemplo, fastboot flash boot boot.img)
• Atualizar 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, os testes automatizados do VTS A infraestrutura só oferece suporte ao arcabouço de testes da TradeFed, mas pode ser estendida para apoiar outros arreios no futuro.

Depois que os dispositivos estiverem preparados, você poderá invocar testes usando um dos 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 (opcionalmente conectado ao MTT), use o lease no console do controlador do host, que procura não cumpridas.

Ao usar o TradeFedCluster, o TradeFed executa localmente como gerente remoto. Caso contrário, os testes serão invocados usando subprocessos do Python.

Denunciar resultados

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