O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.

Esta página foi traduzida pela API Cloud Translation.

CTS do desenvolvedor

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

Cobertura de teste

O CTS-D, assim como o CTS e o 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 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, DEVE, PODE, 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 obsoleta ou alterada, seu teste correspondente deverá ser descontinuado 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 testes devem remover todos os fatores possíveis que possam afetar os resultados dos testes.
Se um dispositivo precisar de uma determinada condição/ambiente/configuração de hardware, essa configuração deverá ser claramente definida na mensagem de commit. Para obter exemplos de instruções de configuração, consulte Configurando o CTS .
O teste não deve ser executado por mais de 6 horas seguidas. Se precisar ser executado por mais tempo, inclua o raciocínio em sua proposta de teste para que possamos revisá-lo.

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

O Wifi está estável (para um teste que depende do Wifi).
O dispositivo permanece estacionário durante o teste (ou não, dependendo do teste).
O dispositivo está 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 o CTS.
A tela fica 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 “pronto para uso”.

Elegibilidade do teste

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

Processo de envio de CTS

Escreva uma proposta de teste: um desenvolvedor de aplicativo 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.
Desenvolva um teste CTS: Após a aprovação de uma proposta, seu proponente cria um teste CTS no AOSP na filial principal (AOSP/principal). A equipe do Android analisa o código.
Publicar teste: envie seu CL em AOSP/main e selecione-o na ramificação androidx-tests-dev mais recente. O teste agora está disponível publicamente.

Diretrizes para redação de testes 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 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 errorprone em build_error.log .
Rebase suas alterações 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 existente. Caso contrário, eles o ajudarão a criar um novo módulo.
Para cada novo módulo de teste criado, crie um arquivo OOWNERS no diretório do novo módulo de teste.
- Seu arquivo OOWNERS 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 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 obter informações sobre como executar o CTS completo, consulte Executar testes CTS .

Aceitação e liberação

Assim que uma solicitação de teste for enviada, uma equipe interna a analisará para garantir que ela teste um requisito de CDD ou um comportamento documentado da API. Se for determinado que o teste verifica um requisito ou comportamento válido, a equipe encaminhará esse 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 Cronograma de lançamento e informações de ramificação para obter detalhes sobre o cronograma de lançamento do CTS.