CTS com tecnologia de desenvolvedor

Esta página descreve as diretrizes de uso do CTS com tecnologia de desenvolvedor (CTS-D).

Cobertura de 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 de API.
  • Todos os requisitos MUST incluídos no Documento de definição de compatibilidade (CDD) do Android para um determinado nível de API.

Requisitos que não são MUST, como STRONGLY RECOMMENDED, SHOULD e MAY, são opcionais e não podem ser testados usando o CTS.

Como todas as APIs e requisitos do CDD estão vinculados a um nível de API específico, todos os testes do CTS (CTS, CTS-D e CTS Verifier) estão vinculados ao mesmo nível de API das 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 fora da caixa.
  • Os criadores de testes precisam remover todos os fatores possíveis que possam afetar os resultados.
  • Se um dispositivo precisar de uma determinada condição/ambiente/configuração de hardware, essa configuração precisa ser claramente definida na mensagem de commit. Para 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 ele precisar ser executado por mais tempo, inclua o motivo na proposta para que possamos analisar.

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 dele).
  • O dispositivo permanece parado durante o teste (ou não, dependendo do teste).
  • O dispositivo está desconectado de qualquer fonte de alimentação com X por cento de bateria.
  • Nenhum app, serviço em primeiro plano ou serviço em segundo plano está em execução, exceto o CTS.
  • A tela fica desligada durante a execução do CTS.
  • O dispositivo NÃO é isLowRamDevice.
  • A Economia de bateria / restrições de apps não foram alteradas em relação ao estado "pronto para uso".

Qualificação para o teste

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

Processo de envio do CTS

  1. Escrever 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 verificar se ele existe. A proposta precisa incluir o ID do requisito de CDD associado. A equipe do Android analisa a proposta.
  2. Desenvolver um teste do CTS:depois que uma proposta é aprovada, o autor cria um teste do CTS no AOSP no branch de lançamento mais recente do Android (android16-release). A equipe do Android analisa o código e se aceito, faz o cherrypick da mudança e a mescla no branch de desenvolvimento interno. Para mais detalhes, consulte Onde devo propor mudanças no AOSP?.

Diretrizes para escrever testes 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 adequado:
    • 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.
  • Lide com todos os avisos e sugestões de errorprone em build_error.log.
  • Faça o rebase das suas mudanças em 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 seu caso de teste pode ser incluído em um módulo 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 diretório do novo 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 amostra (1, 2) para ver 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 <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 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 liberação

Depois que uma solicitação de teste é enviada, uma equipe interna a analisa para garantir que ela teste um requisito de CDD ou um comportamento documentado da API. Se o teste for considerado uma verificação de um requisito ou comportamento válido, a equipe vai encaminhar o 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 melhorar o teste antes que ele seja 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.