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 com tecnologia de desenvolvedor

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

Cobertura de teste

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

Todas as APIs públicas descritas no SDK do desenvolvedor (developer.android.com) para acessar um nível específico da API.
Todos os requisitos OBRIGATÓRIOS incluídos na Compatibilidade do Android Documento de definição (CDD, na sigla em inglês) de um determinado nível da API.

Os requisitos que não são OBRIGATÓRIOS, como FORTEMENTE RECOMENDADO, DEVE e MAIO, são opcionais. e não pode ser testado usando o CTS.

Como todas as APIs e os requisitos do CDD estão vinculados a um nível específico de API, todos os CTS testes (CTS, CTS-D e Verificador do CTS) estão vinculados ao mesmo nível de API APIs ou requisitos associados. Se uma API específica for descontinuada ou alterada, o teste correspondente precisa 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 foi aprovado ou reprovado uma vez pronto para uso.
Os criadores de testes precisam remover todos os fatores que possam afetar os resultados do teste.
Caso um dispositivo precise de uma determinada condição, ambiente ou configuração de hardware, essa configuração precisa estar claramente definido na mensagem de confirmação. Por exemplo, instruções de configuração, consulte Como configurar o CTS.
O teste não pode ser executado por mais de seis horas por vez. Se ele precisar ser executado mais tempo, inclua o raciocínio em sua proposta de teste para que possamos analisá-la.

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

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 energia com X% do nível de bateria.
Nenhum app ou serviço em primeiro plano ou serviço em segundo plano está em execução, exceto para o CTS.
A tela fica desligada ao executar o CTS.
O dispositivo NÃO é isLowRamDevice.
As restrições de Economia de bateria / apps não foram alteradas do um estado "pronto para uso".

Qualificação para teste

Aceitamos novos testes que impõem um comportamento que não é testado por CTS que já existe. CTS Verifier, ou testes CTS-D. Qualquer teste que verifique um comportamento fora do escopo da nossa cobertura de teste vão ser rejeitadas.

Processo de envio do CTS

Criar uma proposta de teste:um desenvolvedor de apps envia uma proposta de teste usando Issue Tracker do Google, descrevendo o problema identificado e propondo um teste para verificar para isso. A proposta precisa incluir o ID de requisito do CDD associado. A equipe do Android analisa a proposta.
Desenvolver um teste CTS: depois que uma proposta é aprovada, o requerente cria um CTS testar no AOSP na ramificação principal (AOSP/main). A equipe do Android revisa o código.
Teste de publicação:envie seu CL em AOSP/main, depois selecione-o a dedo no ramificação androidx-tests-dev mais recente. Agora o teste está disponível publicamente.

Diretrizes para a elaboração de 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 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.
Realize o rebase das suas mudanças em head. Isso inclui as APIs cts-developer.xml e cts-developer-exclude.xml planos de teste.
Trabalhe com seu contato de engenharia do Google para determinar se seu caso de teste podem ser incluídas em um módulo CTS existente. Se não puder, eles ajudarão você criar um novo módulo.
Para cada novo módulo de teste criado, crie um arquivo OWNERS no novo módulo de teste. diretório.
- Seu arquivo OWNERS deve conter as seguintes informações, obtidas de o 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 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 o elemento <uses-sdk> Documentação.
Ao verificar novos métodos, classes ou módulos de teste, adicione-os ao CTS-D plano de teste e excluí-los do plano de teste do CTS da mesma maneira que para novos testes.

Executar o teste CTS-D

Executar 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 informações sobre como executar o CTS completo, consulte Executar testes de CTS.

Aceitação e liberação

Quando uma solicitação de teste é enviada, uma equipe interna a analisa para garantir ele testa um requisito do CDD ou um comportamento de API documentado. Se o teste for determinada a verificar um requisito ou comportamento válido, a equipe encaminhará este caso de teste a um engenheiro do Google para análise posterior. A página de engenharia vai entrar em contato com você para dar feedback sobre como o teste pode ser melhorado antes de ser aceita no CTS.

Consulte Informações sobre a programação de lançamentos e ramificações para detalhes sobre o cronograma de lançamento do CTS.