Os resultados do teste do CTS são colocados no arquivo:
CTS_ROOT/android-cts/results/start_time.zip
Se você criou o CTS, CTS_ROOT é semelhante a
out/host/linux-x86/cts, mas difere por plataforma. Isso reflete o caminho em que você
descompactou o CTS oficial pré-criado
baixado deste site.
Dentro do ZIP, o arquivo test_result.xml contém os resultados reais.
Mostrar resultados do Android 10 e versões mais recentes
Um arquivo test_result.html existe no arquivo ZIP. Você pode abri-lo diretamente em qualquer navegador da Web compatível com HTML5.
Mostrar resultados anteriores ao Android 10
Abra o arquivo test_result.xml em qualquer navegador da Web compatível com HTML5 para conferir 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 em versões anteriores, selecione "Informações do dispositivo" (link acima de "Resumo do teste") para conferir detalhes sobre o dispositivo, o firmware (marca, modelo, build do firmware, plataforma) e o hardware do dispositivo (resolução da tela, teclado, tipo de tela). O 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, expiraram 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 do teste
A próxima seção, o relatório de teste do CTS, fornece um resumo dos testes aprovados por pacote.
Em seguida, há detalhes dos testes reais 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, falha, tempo limite excedido ou não executado. Em caso de falha, os detalhes do teste são fornecidos para ajudar a diagnosticar a causa.
Além disso, o rastreamento de pilha da falha está disponível no arquivo XML, mas não é incluído no relatório para garantir a brevidade. Para ver os detalhes da falha do teste, abra o arquivo XML com um editor de texto. Procure a tag [Test] correspondente ao teste com falha e, dentro dela, a tag [StackTrace].
Mostrar relatório de teste de amostra do CTS v2
Figura 4:exemplo de relatório de teste do CTS v2
Mostrar relatório de teste de amostra do CTS v1
Figura 5:exemplo de relatório de teste do CTS v1
Revise test_result.xml para 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 "Total de módulos" é listada para cada sessão anterior. Para determinar quais módulos estão completos e quais não, abra o arquivo test_result.xml e leia o valor do atributo "done" de cada módulo no relatório de resultados. Os módulos com o valor "done" = "false" não foram concluídos.
Classificar falhas de teste
Use as sugestões a seguir para triar falhas de teste.
- Verifique se o ambiente do 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 de trabalho e a configuração do dispositivo Android.
- Verifique a estabilidade do dispositivo, a configuração do teste ou problemas no ambiente se um teste estiver aparecendo com muita instabilidade.
- Tente de novo de forma isolada se ainda estiver falhando.
- Verifique se há fatores externos que causam falhas nos testes, como:
- Configuração do ambiente. Por exemplo, uma configuração incorreta de um computador desktop pode ser a causa de falhas de teste em todos os dispositivos em teste (DUTs), 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 no tempo, um URL ruim pode ser o problema.
- Se o DUT não incluir o patch de segurança, a falha no teste de segurança é esperada.
- Valide e analise as diferenças entre dispositivos aprovados e reprovados.
- Analise a declaração, o registro, o bugreport e a fonte do CTS. Para um HostTest, a declaração e o registro podem ser muito genéricos. Por isso, é útil 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 parciais quando a invocação de teste falha.
Quando o Tradefed não gera resultados de teste, isso significa que ocorreu um problema grave durante a execução, o que torna o resultado não confiável. O resultado parcial é considerado inútil porque não oferece valor ao investigar um problema no dispositivo.