Os resultados do teste CTS são colocados no arquivo:
CTS_ROOT/android-cts/results/start_time.zip
Se você mesmo criou o CTS, o CTS_ROOT se parece com
out/host/linux-x86/cts, mas é diferente de acordo com a plataforma. Isso reflete o caminho em que
você descompactou o CTS oficial pré-criado
feito o download neste site.
Dentro do zip, o arquivo test_result.xml contém os resultados reais.
Mostrar resultados no Android 10 e versões mais recentes
Existe um arquivo test_result.html no arquivo zip que pode ser aberto diretamente em qualquer navegador da Web compatível com HTML5
Mostrar resultados de versões anteriores do Android 10
Abra o arquivo test_result.xml em qualquer navegador da Web compatível com HTML5 para ver os resultados do teste
Se esse arquivo mostrar uma página em branco ao usar o navegador Chrome,
mude a configuração do navegador
para ativar a flag de linha de comando --allow-file-access-from-files.
Ler os resultados do teste
Os detalhes dos resultados do teste dependem da versão do CTS que você está usando:
- CTS v1 para Android 6.0 e versões anteriores
- CTS v2 para Android 7.0 e versões mais recentes
Informações do dispositivo
No CTS v1 e versões anteriores, selecione "Informações do dispositivo" (link acima de "Resumo do teste") para conferir detalhes sobre o dispositivo, o firmware (marca, modelo, versão do firmware, plataforma) e o hardware do dispositivo (resolução da tela, teclado, tipo de tela). A CTS v2 não mostra informações do dispositivo.
Resumo do teste
A seção Resumo do teste fornece detalhes do plano de teste executado, como o nome do plano do CTS e os horários de início e término da execução. Ele também apresenta um resumo agregado do número de testes que foram aprovados, reprovados, expirados ou não puderam ser executados.
Resumo do teste de amostra do CTS do Android 10
Figura 1:resumo do teste de amostra do CTS do Android 10
Resumo do teste de amostra do CTS v2
Figura 2: resumo do teste de amostra do CTS v2
Resumo do teste de amostra do CTS v1
Figura 3:resumo do teste de amostra do CTS v1
Relatório de teste
A próxima seção, o relatório de teste do CTS, fornece um resumo dos testes aprovados por pacote.
Em seguida, são mostrados os detalhes dos testes que foram executados. O relatório lista o pacote de teste, o conjunto de testes, o caso de teste e os testes executados. Ele mostra o resultado da execução do teste: aprovado, reprovado, com tempo limite ou não executado. No caso de uma falha no teste, são fornecidos detalhes para ajudar a diagnosticar a causa.
Além disso, o stack trace da falha está disponível no arquivo XML, mas não é incluído no relatório para garantir brevidade. A visualização do arquivo XML com um editor de texto deve fornecer detalhes da falha do teste (procure a tag [Test] correspondente ao teste com falha e procure a tag [StackTrace] dentro dele).
Mostrar exemplo de relatório de teste do CTS v2
Figura 4. Relatório de teste de exemplo do CTS v2
Mostrar relatório de teste de amostra do CTS v1
Figura 5:relatório de teste de exemplo da CTS v1
Revise o arquivo test_result.xml para conferir se há módulos de teste incompletos.
Para determinar o número de módulos incompletos em uma determinada sessão de teste, execute o comando "list results". A contagem de módulos concluídos e o total de módulos são listados para cada sessão anterior. Para determinar quais módulos estão completos ou incompletos, abra o arquivo test_result.xml e leia o valor do atributo "done" para cada módulo no relatório de resultados. Módulos com o valor concluído = "false" não foram executados até a conclusão.
Triagem de falhas de teste
Use as sugestões a seguir para fazer a triagem das falhas no teste.
- Verifique se o ambiente CTS está configurado corretamente se um teste falhar devido a pré-condições incorretas. Isso inclui o ambiente físico, a configuração da máquina desktop e a configuração do dispositivo Android.
- Verifique a estabilidade do dispositivo, a configuração do teste ou os problemas do ambiente, se um teste estiver apresentando falhas excessivas.
- Tente novamente o teste de forma isolada se ainda houver falhas.
- Verifique se há fatores externos causando falhas no teste, como:
- Configuração do ambiente. Por exemplo, uma configuração de máquina de computador incorreta pode ser a causa de falhas de teste que ocorrem em todos os dispositivos em teste (DUTs, na sigla em inglês), incluindo dispositivos de referência.
- Dependências externas. Por exemplo, se um teste falhar em todos os dispositivos em vários sites a partir de um ponto específico, um URL incorreto pode ser o problema.
- Se o DUT não incluir o patch de segurança, é esperado que o teste de segurança falhe.
- Valide e analise as diferenças entre os dispositivos que passaram e os que falharam.
- Analise a declaração, o registro, o relatório de bugs e a fonte do CTS. Para um HostTest, a declaração e o registro podem ser muito genéricos, por isso é útil também verificar e anexar o logcat do dispositivo.
- Envie um patch de melhoria de teste para ajudar a reduzir falhas.
Salvar resultados parciais
O Tradefed não salva resultados de teste parciais quando a invocação do teste falha.
Quando o Tradefed não gera resultados de teste, isso implica que um problema grave ocorreu durante a execução do teste, tornando o resultado do teste não confiável. O resultado parcial é considerado irrelevante porque não agrega valor ao investigar o problema do dispositivo.