Testes da plataforma Android

O Android Open Source Project (AOSP) oferece várias ferramentas e conjuntos de testes para testar várias partes da sua implementação. Antes de usar as páginas desta seção, você precisa estar familiarizado com os seguintes termos:

Dispositivo compatível com Android
Um dispositivo que pode executar qualquer app criado por desenvolvedores de terceiros usando o SDK e o NDK do Android. Dispositivos compatíveis com Android precisam atender aos requisitos do Documento de definição de compatibilidade (CDD) e ser aprovados no Conjunto de teste de compatibilidade (CTS). Dispositivos compatíveis com Android podem participar do nosso ecossistema que inclui potencial licenciamento da Google Play, do pacote de apps e APIs dos Serviços do Google Mobile (GMS) e do uso da marca registrada do Android. Aceitamos todos os usos do código-fonte, mas, para participar do nosso ecossistema, o dispositivo precisa ser compatível com Android.
artifact
Um registro relacionado a builds que permite a solução local de problemas.
Documento de definição de compatibilidade (CDD)
Um documento que enumera os requisitos de software e hardware de um dispositivo compatível com o Android.
Conjunto de teste de compatibilidade (CTS)

Um pacote de testes de nível comercial sem custo financeiro para download como binário ou como fonte no AOSP. O CTS é um pacote de testes de unidade criado para integração no seu fluxo de trabalho diário. O objetivo do CTS é revelar incompatibilidades e garantir que o software permaneça compatível durante todo o processo de desenvolvimento.

Os testes de CTS e de plataforma não são mutuamente exclusivos. Aqui estão algumas diretrizes gerais:

  • Se um teste estiver afirmando a correção das funções ou comportamentos da API do framework e precisar ser aplicado em todos os parceiros OEM, ele deverá estar no CTS.
  • Se um teste for destinado a detectar regressões durante o desenvolvimento da plataforma e puder exigir permissão privilegiada para ser realizado e depender de detalhes de implementação (conforme lançado no AOSP), ele deverá ser um teste de plataforma.
Serviços do Google Mobile (GMS)

Uma coleção de APIs e apps Google que podem ser pré-instalados em dispositivos.

GoogleTest (GTest)

Um framework de teste e simulação C++. Os binários do GTest normalmente acessam camadas de abstração de nível inferior ou executam uma IPC bruta em vários serviços do sistema. A abordagem de teste para o GTest geralmente está fortemente associada ao serviço que está sendo testado. O CTS contém o framework GTest.

teste de instrumentação

Um ambiente de execução de teste especial iniciado pelo comando am instrument, em que o processo do app de destino é reiniciado e inicializado com o contexto básico do app, e uma linha de execução de instrumentação é iniciada dentro da máquina virtual do processo do app. O CTS contém testes de instrumentação.

Logcat

Uma ferramenta de linha de comando que cria um registro de mensagens do sistema, incluindo stack traces de quando o dispositivo gera um erro e mensagens que você escreveu no app com a classe Log.

Geração de registros

Usar um registro para acompanhar eventos do sistema de computador, como erros. A geração de registro no Android é complexa, devido à combinação de padrões usados na ferramenta Logcat.

teste pós-envio

Um teste do Android que é realizado quando um novo patch é confirmado em uma ramificação do kernel comum. Ao inserir aosp_kernel como um nome de ramificação parcial, você vai ver uma lista de ramificações do kernel com resultados disponíveis. Por exemplo, os resultados para android-mainline podem ser encontrados em https://ci.android.com/builds/branches/aosp_kernel-common-android-mainline/grid.

teste de pré-envio

Um teste usado para evitar que falhas sejam introduzidas nos kernels comuns.

Trade Federation

Também chamado de Tradefed, um framework de testes contínuo projetado para executar testes em dispositivos Android. Por exemplo, o Tradefed é usado para executar testes do Conjunto de teste de compatibilidade e do Conjunto de teste de fornecedor.

Conjunto de teste de fornecedor (VTS)

Um conjunto de recursos abrangentes para testes do Android, promovendo um processo de desenvolvimento orientado por teste e automatizando os testes da camada de abstração de hardware (HAL) e do kernel do SO.

Tipos de teste de plataforma

Um teste de plataforma normalmente interage com um ou mais serviços do sistema Android ou camadas HAL, exercita as funcionalidades do assunto em teste e afirma a correção do resultado do teste. Um teste de plataforma pode:

  • (Tipo 1) Exercitar APIs do framework usando o framework do Android. As APIs específicas que estão sendo exercitadas podem incluir:
    • APIs públicas destinadas a apps de terceiros
    • APIs ocultas destinadas a apps privilegiados, ou seja, APIs do sistema ou APIs particulares (@hide ou protected, package private)
  • (Tipo 2) Invocar serviços do sistema Android usando proxies de binder ou IPC brutos diretamente.
  • (Tipo 3) Interagir diretamente com HALs usando APIs de baixo nível ou interfaces IPC.

Os testes de tipo 1 e 2 são normalmente testes de instrumentação, enquanto os testes de tipo 3 são geralmente GTests.

A seguir

Confira uma lista de documentos que você pode ler para mais informações: