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 por 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.
Exibindo resultados do Android 10 e posteriores
Existe um arquivo test_result.html dentro do arquivo zip, você pode abri-lo diretamente em qualquer navegador compatível com HTML5
Exibindo 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 .
Lendo 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 anterior, selecione Informações do dispositivo (link acima do Resumo do teste) para visualizar detalhes sobre o dispositivo, firmware (marca, modelo, compilação de firmware, plataforma) e hardware do dispositivo (resolução de 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 do 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 teste, suíte de teste, caso de teste e os testes executados. Ele mostra o resultado da execução do teste — aprovado, reprovado, expirado ou não executado. No caso de uma falha de teste, os 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 está incluído no relatório para garantir a brevidade - visualizar o arquivo XML com um editor de texto deve fornecer detalhes da falha do teste (procure a tag [Test] correspondente a o teste com falha e procure nele a tag [StackTrace] ).
Mostrar relatório de teste de amostra 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
Revisando 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 versus 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 valor done = "false" não foram executados até a conclusão.
Triagem de falhas de teste
Use as sugestões a seguir para fazer a triagem de falhas de teste.
- Verifique se seu ambiente CTS está configurado corretamente, se um teste estiver falhando devido a pré-condições incorretas. Isso inclui o ambiente físico, a configuração do computador desktop e a configuração do dispositivo Android.
- Verifique a estabilidade do dispositivo, a configuração do teste ou os problemas de ambiente, se um teste parecer excessivamente irregular.
- Repita o teste isoladamente se ainda estiver falhando.
- Verifique se há fatores externos que causam falhas no teste, como:
- Configuração ambiental. Por exemplo, uma configuração de máquina desktop mal configurada 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 ponto específico no tempo, um URL incorreto pode estar com defeito.
- 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 asserção, o log, o relatório de erros e a origem do CTS . Para um HostTest, a asserção e o log podem ser muito genéricos, portanto, é útil verificar e anexar o logcat do dispositivo.
- Envie um patch de melhoria de teste para ajudar a reduzir as falhas de teste.
Salvando resultados parciais
Tradefed não salva resultados de teste parciais quando a chamada de teste falha.
Quando o Tradefed não está gerando nenhum resultado de teste, está 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 o problema do dispositivo.