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 genérica do sistema (GSI) AOSP. Anteriormente, a execução desses testes era uma operação altamente manual; a nova infraestrutura de teste VTS foi projetada para suportar testes automatizados várias vezes ao dia em vários dispositivos.
Arquitetura
A infraestrutura de testes automatizados VTS utiliza a seguinte arquitetura:
Quando um teste é acionado, a infraestrutura de testes automatizados VTS executa as seguintes tarefas:
- Busca artefatos de construção e testa recursos de diferentes locais:
- Parceiro Android Build (PAB) . Para o GSI, estrutura 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.
- Os flashes criam artefatos (do dispositivo) e o GSI (do AOSP) no(s) dispositivo(s) conectado(s).
- Executa testes VTS usando TradeFed local ou TradeFed na nuvem.
- Relata os resultados dos testes ao painel VTS
O processo é coordenado pelo controlador host 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 as versões mais recentes, atualizá-las nos 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 TradeFed (ou algum outro equipamento) em execução no HC. Para obter detalhes sobre o controlador host, consulte Arquitetura do controlador host .
Provedores de recursos
Os testes automatizados requerem recursos como construções de sistema, arquivos de teste e artefatos VTS. Embora seja possível construí-los a partir do código-fonte, é mais fácil construí-los regularmente a partir da ponta da árvore e depois 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 build para ambas as opções, estendendo-se de um único build_provider.py que armazena os builds em diretórios temporários locais.
Versão Android do parceiro
No Android 8.1 e versões anteriores, os parceiros Android eram obrigados a 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.
Estabeleça acesso
O acesso programático usa OAuth2 nas APIs do Google para acessar os RPCs necessários. Usando a abordagem padrão para gerar credenciais OAuth2, o parceiro deve configurar um par de ID/segredo do cliente com o Google. Quando 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 devem precisar 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
- filial
- liberar o nome do candidato 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 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).
Obtenha 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 este token torne o processo mais seguro, também torna o acesso programático muito mais difícil, uma vez que o token (que está disponível apenas no JavaScript da página PAB) agora também é necessário para o 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 aos parceiros baixar recursos; Os scripts HC podem baixar esses APKs facilmente, uma vez que o formato da 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.
Compilações em Flash
Depois que as imagens mais recentes do dispositivo forem baixadas para o host, essas imagens deverão ser flasheadas nos dispositivos. Isso é feito usando os comandos padrão adb e fastboot e subprocessos Python, com base nos caminhos de arquivos temporários armazenados pelos provedores de compilação.
Ações apoiadas:
- Piscando apenas o GSI
- Atualizando 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árioflashallintegrado) -
fastboot flash(um de cada vez)
-
Execute testes
No Android 9, a infraestrutura de testes automatizados 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
testno controlador host, que leva o nome de um plano de teste VTS (por exemplovts-selftest) e executa o teste. - Ao usar um cluster TradeFed (opcionalmente conectado ao MTT), use o comando
leaseno console do controlador host, que procura execuções de teste não realizadas.
Se estiver usando o TradeFedCluster, o TradeFed é executado localmente como um gerenciador remoto . Caso contrário, os testes serão invocados usando subprocessos Python.
Relatar resultados
Os resultados dos testes são relatados automaticamente para alguns projetos de painel VTS por VtsMultiDeviceTest .