CTS com tecnologia de desenvolvedor

Esta página descreve as diretrizes de uso do CTS desenvolvido por desenvolvedores (CTS-D).

Cobertura do teste

O CTS-D, assim como o CTS e o Verificador do CTS, só pode aplicar o seguinte:

  • Todas as APIs públicas descritas no SDK do desenvolvedor (developer.android.com) para um determinado nível da API.
  • Todos os requisitos OBRIGATÓRIOS incluídos no Documento de definição de compatibilidade do Android (CDD) para um determinado nível da API.

Os requisitos não obrigatórios, como FORTEMENTE RECOMENDADO, DEVE, PODE, são opcionais e não podem ser testados usando o CTS.

Como todos os requisitos de APIs e CDD estão vinculados a um nível da API específico, todos os testes do CTS (CTS, CTS-D e Verificador do CTS) estão vinculados ao mesmo nível da API que as APIs ou requisitos associados. Se uma API específica for descontinuada ou alterada, o teste correspondente precisará ser descontinuado ou atualizado.

Regras de criação de testes do CTS

  • Um teste precisa produzir o mesmo resultado objetivo de forma consistente.
  • Um teste precisa determinar se um dispositivo é aprovado ou reprovado testando-o uma vez.
  • Os criadores de testes precisam remover todos os fatores possíveis que possam afetar os resultados do teste.
  • Se um dispositivo precisar de uma determinada condição/ambiente/configuração de hardware, essa configuração precisará ser definida claramente na mensagem de commit. Para conferir instruções de configuração de exemplo, consulte Configurar o CTS.
  • O teste não pode ser executado por mais de seis horas de cada vez. Se precisar ser executado por mais tempo, inclua o raciocínio na proposta de teste para que possamos analisá-lo.

Confira a seguir um exemplo de conjunto de condições de teste para testar uma restrição de app:

  • O Wi-Fi está estável (para um teste que depende do Wi-Fi).
  • O dispositivo permanece parado durante o teste (ou não, dependendo do teste).
  • O dispositivo está desconectado de qualquer fonte de energia com X por cento de nível de bateria.
  • Nenhum app, serviço em primeiro plano ou serviço em segundo plano está em execução, exceto o CTS.
  • A tela está desligada durante a execução do CTS.
  • O dispositivo NÃO é isLowRamDevice.
  • O modo de economia de bateria e as restrições de apps não foram alterados em relação ao estado original.

Qualificação para o teste

Aceitamos novos testes que aplicam um comportamento que não é testado pelos testes atuais do CTS, do Verificador do CTS ou do CTS-D. Qualquer teste que verifique um comportamento fora do escopo de nossa cobertura de testes será rejeitado.

Processo de envio do CTS

  1. Escreva uma proposta de teste: um desenvolvedor de apps envia uma proposta de teste usando o Google Issue Tracker, descrevendo o problema identificado e propondo um teste para verificá-lo. A proposta precisa incluir o ID do requisito do CDD associado. A equipe do Android analisa a proposta.
  2. Desenvolva um teste do CTS:depois que uma proposta é aprovada, o autor cria um teste do CTS no AOSP na ramificação de lançamento mais recente do Android (android17-release). A equipe do Android analisa o código e, se aceito, seleciona a mudança e a mescla na ramificação de desenvolvimento interna. Para mais detalhes, consulte Onde devo propor mudanças no AOSP?.

Diretrizes para escrever testes do CTS-D

  • Siga o Guia de estilo de código Java.
  • Siga todas as etapas descritas em Desenvolvimento do CTS.
  • Adicione seus testes ao plano de teste apropriado:
    • Use include-filters para adicionar seus novos testes ao plano de teste do CTS-D: platform/cts/tools/cts-tradefed/res/config/cts-developer.xml.
    • Use exclude-filters para excluir seus novos testes do plano de teste principal do CTS: platform/cts/tools/cts-tradefed/res/config/cts-developer-exclude.xml.
  • Gerencie todos os avisos e sugestões de errorprone em build_error.log.
  • Rebase suas mudanças para head. Isso inclui os planos de teste cts-developer.xml e cts-developer-exclude.xml.
  • Trabalhe com seu contato de engenharia do Google para determinar se o caso de teste pode ser incluído em um módulo do CTS atual. Se não for possível, eles vão ajudar você a criar um novo módulo.
  • Para cada novo módulo de teste criado, crie um arquivo OWNERS no novo diretório do módulo de teste.
    • O arquivo OWNERS precisa conter as seguintes informações, obtidas do proprietário do teste do Google com quem você está trabalhando:
    • # Bug component: xxx
    • LDAP do proprietário do teste do Google
  • Em AndroidTest.xml, especifique os seguintes parâmetros. Consulte os arquivos de exemplo (1, 2) para conferir exemplos:
    • Instant_app ou not_instant_app
    • secondary_user ou not_secondary_user
    • all_foldable_states ou no_foldable_states
  • Para especificar o minSDK correto, consulte a documentação de <uses-sdk>.
  • Ao fazer check-in de novos métodos, classes ou módulos de teste, adicione-os ao plano de teste do CTS-D e exclua-os do plano de teste principal do CTS da mesma forma que para novos testes.

Executar o teste do CTS-D

Execute o plano de teste do CTS-D na linha de comando usando run cts --plan cts-developer.

Para executar um caso de teste específico, use run cts --include-filter "test_module_name test_name".

Para informações sobre como executar o CTS completo, consulte Executar testes do CTS.

Aceitação e lançamento

Depois que uma solicitação de teste é enviada, uma equipe interna a analisa para garantir que ela teste um requisito do CDD ou um comportamento documentado da API. Se o teste for determinado como uma verificação de um requisito ou comportamento válido, a equipe encaminhará esse caso de teste a um engenheiro do Google para análise mais detalhada. O engenheiro do Google vai entrar em contato com você para dar feedback sobre como o teste pode ser melhorado antes de ser aceito no CTS.

Consulte Programação de lançamentos e informações sobre ramificações para detalhes sobre a programação de lançamentos do CTS.