Os resultados do teste CTS são colocados no arquivo:
CTS_ROOT/android-cts/results/start_time.zip
Se você mesmo construiu o CTS, CTS_ROOT se parece com out/host/linux-x86/cts , mas difere de acordo com a plataforma. Isso reflete o caminho onde você descompactou o CTS oficial pré-construído baixado deste site.
Dentro do zip, o arquivo test_result.xml contém os resultados reais.
Exibir resultados do Android 10 e posteriores
Um arquivo test_result.html existe dentro do arquivo zip, você pode abri-lo diretamente em qualquer navegador compatível com HTML5
Exibir resultados pré-Android 10
Abra o arquivo test_result.xml em qualquer navegador compatível com HTML5 para visualizar os resultados do teste
Se este arquivo exibir uma página em branco ao usar o navegador Chrome, altere a configuração do navegador para ativar o sinalizador de linha de comando --allow-file-access-from-files .
Leia os resultados do teste
Os detalhes dos resultados do teste dependem de qual versão do CTS você está usando:
- CTS v1 para Android 6.0 e anteriores
- CTS v2 para Android 7.0 e posterior
Informação de dispositivo
No CTS v1 e anteriores, selecione Informações do dispositivo (link acima do Resumo do teste) para visualizar detalhes sobre o dispositivo, firmware (marca, modelo, construção do firmware, plataforma) e hardware do dispositivo (resolução da tela, teclado, tipo de tela). O CTS v2 não exibe 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 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 passaram, falharam, atingiram o tempo limite ou não puderam ser executados.
Resumo de teste de amostra do Android 10 CTS
Figura 1: resumo do teste de amostra do Android 10 CTS
Resumo do teste de amostra CTS v2
Figura 2: Resumo do teste de amostra CTS v2
Resumo do teste de amostra CTS v1
Figura 3: Resumo do teste de amostra CTS v1
Relatório de teste
A próxima seção, o relatório de teste CTS, fornece um resumo dos testes aprovados por pacote.
Isto é seguido por detalhes dos testes reais que foram executados. O relatório lista o pacote de testes, o conjunto de testes, o caso de teste e os testes executados. Ele mostra o resultado da execução do teste – aprovado, reprovado, atingido o tempo limite ou não executado. No caso de uma falha no teste, detalhes 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 – a visualização do arquivo XML com um editor de texto deve fornecer detalhes da falha do teste (procure pela tag [Test] correspondente a o teste com falha e procure nele a tag [StackTrace] ).
Mostrar relatório de teste de amostra do CTS v2
Figura 4: Relatório de teste de amostra CTS v2
Mostrar relatório de teste de amostra CTS v1
Figura 5: Relatório de teste de amostra 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 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 "concluído" para cada módulo no relatório de resultados. Módulos com valor feito = "falso" não foram concluídos.
Falhas nos testes de triagem
Use as sugestões a seguir para fazer a triagem de falhas nos testes.
- Verifique se o seu ambiente CTS está configurado corretamente, se um teste estiver falhando devido a condições prévias 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 problemas ambientais, se um teste parecer excessivamente instável.
- Tente novamente o teste isoladamente se ainda falhar.
- Verifique se há fatores externos que causam falhas nos testes, como:
- Configuração ambiental. Por exemplo, uma configuração incorreta de máquina desktop pode ser a causa de falhas de teste que ocorrem em todos os dispositivos sob teste (DUTs) (incluindo dispositivos de referência).
- Dependências externas. Por exemplo, se um teste falhar em todos os dispositivos em vários sites, começando em um momento específico, um URL incorreto poderá ser o culpado.
- Se o DUT não incluir o patch de segurança, é esperada uma falha no teste de segurança.
- Valide e analise as diferenças entre dispositivos aprovados e reprovados.
- Analise a asserção, o log, o relatório de bug e a origem do CTS . Para um HostTest, a asserção e o log 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 de teste.
Salvar resultados parciais
Tradefed não salva resultados parciais do teste quando a invocação do teste falha.
Quando o Tradefed não gera nenhum resultado de teste, fica implícito que ocorreu um problema sério durante a execução do teste, tornando o resultado do teste não confiável. O resultado parcial é considerado inútil, pois não fornece valor ao investigar problemas no dispositivo.