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 assemelha-se 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
Existe um arquivo test_result.html 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 habilitar 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 anterior
- 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 do teste de amostra do Android 10 CTS
Figura 1: Resumo do teste de amostra do Android 10 CTS
Resumo do teste de amostra do CTS v2
Figura 2: Resumo do teste de amostra do CTS v2
Resumo do teste de amostra 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 CTS, fornece um resumo dos testes aprovados por pacote.
Isso é 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, esgotado ou não executado. No caso de uma falha de teste, são fornecidos detalhes 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 do CTS v2
Mostrar relatório de teste de amostra CTS v1
Figura 5: relatório de teste de amostra 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 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 done = "false" não foram executados até a conclusão.
Falhas no teste de triagem
Use as sugestões a seguir para triagem de falhas de teste.
- Verifique se o 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 da máquina desktop e a configuração do dispositivo Android.
- Verifique a estabilidade do dispositivo, configuração de teste ou problemas de ambiente, se um teste estiver aparecendo excessivamente irregular.
- Repita o teste isoladamente se ainda falhar.
- Verifique se há fatores externos que causam falhas no teste, como:
- Configuração do ambiente. Por exemplo, uma configuração incorreta da 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 ponto específico no tempo, um URL inválido pode ser o culpado.
- Se o DUT não incluir o patch de segurança, sua 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 do 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 as falhas de teste.
Salvar resultados parciais
Tradefed não salva resultados de teste parciais quando a invocação do 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.