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 CTS Verifier, só pode aplicar o seguinte:

  • Todas as APIs públicas descritas no SDK para desenvolvedores (developer.android.com) para um determinado nível de API.
  • Todos os requisitos obrigatórios incluídos no Documento de definição de compatibilidade do Android (CDD) para um determinado nível de 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 todas as APIs e os 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) são vinculados ao mesmo nível de API que as APIs ou os 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.
  • Se um dispositivo precisar de uma determinada condição/ambiente/configuração de hardware, essa configuração precisa ser claramente definida na mensagem de confirmação. Para ver instruções de configuração de exemplo, consulte Como configurar o CTS.
  • O teste não pode ser executado por mais de 6 horas de cada vez. Se precisar ser executado por mais tempo, inclua o raciocínio na proposta de teste para que possamos analisá-la.

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 alimentação com X% 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 fica desligada durante a execução do CTS.
  • O dispositivo NÃO é isLowRamDevice.
  • A economia de bateria / restrições de app não foram alteradas do estado "padrão".

Testar a qualificação

Aceitamos novos testes que apliquem um comportamento que não é testado por testes de CTS, CTS Verifier ou CTS-D. Qualquer teste que verifique um comportamento fora do escopo da nossa cobertura de teste 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 que foi identificado e propondo um teste para verificação. A proposta precisa 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, o remetente cria um teste CTS no AOSP no branch principal (AOSP/main). A equipe do Android analisa o código.
  3. Publicar teste:envie seu CL em AOSP/main e selecione-o a dedo para a ramificação mais recente do androidx-tests-dev. Agora o teste está disponível publicamente.

Diretrizes para a elaboração de 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 apropriado:
    • Use include-filters para adicionar 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.
  • Processe todos os avisos e sugestões de errorprone em build_error.log.
  • Rebaseie as 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 o caso de teste pode ser incluído em um módulo CTS existente. Se não puder, eles ajudarão 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
    • Proprietário de teste do Google ldap
  • 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 verificar 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 de CTS.

Aceitação e liberação

Depois que uma solicitação de teste é enviada, uma equipe interna a analisa para garantir que ela testa um requisito de CDD ou um comportamento documentado da API. Se o teste for determinado como uma verificação de requisito ou comportamento válido, a equipe vai encaminhar o caso de teste a um engenheiro do Google para uma 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çamento e informações de ramificação para mais detalhes sobre a programação de lançamentos do CTS.