CTS do desenvolvedor

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

Cobertura de teste

O CTS-D, como o CTS & CTS Verifier, só pode impor 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 OBRIGATÓRIOS que estão incluídos no Documento de Definição de Compatibilidade do Android (CDD) para um determinado nível de API.

Requisitos não obrigatórios, como FORTEMENTE RECOMENDADO, DEVERIA, MAIO, são opcionais e não podem ser testados usando CTS.

Como todos os requisitos de APIs e CDD estão vinculados a um nível de API específico, todos os testes CTS (CTS, CTS-D e CTS Verifier) ​​estão vinculados ao mesmo nível de API que suas APIs ou requisitos associados. Se uma API específica for preterida ou alterada, seu teste correspondente deverá ser preterido ou atualizado.

Regras de criação de teste CTS

  • Um teste deve produzir o mesmo resultado objetivo de forma consistente.
  • Um teste deve determinar se um dispositivo é aprovado ou reprovado testando-o uma vez fora da caixa.
  • Os criadores de teste devem remover todos os possíveis fatores que podem afetar os resultados do teste.
  • Se um dispositivo precisar de uma determinada condição/ambiente/configuração de hardware, essa configuração deve ser claramente definida na mensagem de confirmação. Para obter instruções de configuração de exemplo, consulte Configurando CTS .
  • O teste não deve ser executado por mais de 6 horas de cada vez. Se ele precisar ser executado por mais tempo, inclua o raciocínio em sua proposta de teste para que possamos analisá-la.

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

  • Wifi é estável (para um teste que depende de Wifi).
  • O dispositivo permanece parado durante o teste (ou não, dependendo do teste).
  • O dispositivo é desconectado de qualquer fonte de alimentação com X por cento do nível da bateria.
  • Nenhum aplicativo, serviço em primeiro plano ou serviço em segundo plano está em execução, exceto CTS.
  • A tela está desligada durante a execução do CTS.
  • O dispositivo NÃO é isLowRamDevice .
  • As restrições de economia de bateria/aplicativos não foram alteradas do estado “out-of-the-box”.

Qualificação do teste

Aceitamos novos testes que impõem um comportamento que não é testado pelos testes CTS, CTS Verifier ou CTS-D existentes. Qualquer teste que verifique um comportamento fora do escopo de nossa cobertura de teste será rejeitado.

Processo de submissão CTS

  1. Escreva uma proposta de teste: um desenvolvedor de aplicativos envia uma proposta de teste usando o Google Issue Tracker , descrevendo o problema que foi identificado e propondo um teste para verificá-lo. A proposta deve incluir o ID do requisito de CDD associado. A equipe do Android analisa a proposta.
  2. Desenvolver um teste CTS: Depois que uma proposta é aprovada, seu apresentador cria um teste CTS no AOSP na filial principal (AOSP/master). A equipe do Android revisa o código.
  3. Teste de publicação: envie seu CL no AOSP/master e, em seguida, selecione-o para a androidx-tests-dev mais recente. O teste já está disponível publicamente.

Diretrizes de redação do teste CTS-D

  • Siga o Guia de estilo de código Java .
  • Siga todas as etapas descritas em Desenvolvimento CTS .
  • Adicione seus testes ao plano de teste apropriado:
    • Use include-filters de inclusão para adicionar seus novos testes ao plano de teste 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 com build_error.log errorprone
  • Rebase suas alterações 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 seu caso de teste pode ser incluído em um módulo CTS existente. Se não puder, eles o ajudarão 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.
    • Seu arquivo OWNERS deve 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 parâmetros a seguir. Consulte os arquivos de amostra ( 1 , 2 ) para obter 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 de teste, classes ou módulos, adicione-os ao plano de teste CTS-D e exclua-os do plano de teste CTS principal da mesma forma que para novos testes.

Execute seu teste CTS-D

Execute o plano de teste CTS-D a partir da 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 obter informações sobre como executar o CTS completo, consulte Executar testes de 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 de API documentado. Se for determinado que o teste está verificando um requisito ou comportamento válido, a equipe encaminhará este caso de teste a um engenheiro do Google para análise adicional. O engenheiro do Google entrará em contato com você para fornecer feedback sobre como o teste pode ser melhorado antes de ser aceito no CTS.

Consulte o cronograma de lançamento e informações da filial para obter detalhes sobre o cronograma de lançamento do CTS.