Les résultats des tests CTS sont placés dans le fichier :
CTS_ROOT/android-cts/results/start_time.zip
Si vous avez construit le CTS vous-même, CTS_ROOT ressemble à out/host/linux-x86/cts mais diffère selon la plateforme. Cela reflète le chemin par lequel vous avez décompressé le CTS officiel prédéfini téléchargé à partir de ce site.
À l'intérieur du zip, le fichier test_result.xml contient les résultats réels.
Afficher les résultats d'Android 10 et versions ultérieures
Un fichier test_result.html existe dans l'archive zip, vous pouvez l'ouvrir directement dans n'importe quel navigateur Web compatible HTML5
Afficher les résultats pré-Android 10
Ouvrez le fichier test_result.xml dans n'importe quel navigateur Web compatible HTML5 pour afficher les résultats du test
Si ce fichier affiche une page vierge lors de l'utilisation du navigateur Chrome, modifiez la configuration de votre navigateur pour activer l'indicateur de ligne de commande --allow-file-access-from-files .
Lire les résultats des tests
Les détails des résultats des tests dépendent de la version de CTS que vous utilisez :
- CTS v1 pour Android 6.0 et versions antérieures
- CTS v2 pour Android 7.0 et versions ultérieures
Informations sur l'appareil
Dans CTS v1 et versions antérieures, sélectionnez Informations sur l'appareil (lien au-dessus du résumé du test) pour afficher les détails sur l'appareil, le micrologiciel (marque, modèle, version du micrologiciel, plate-forme) et le matériel de l'appareil (résolution d'écran, clavier, type d'écran). CTS v2 n'affiche pas les informations sur le périphérique.
Résumé du test
La section Résumé des tests fournit des détails sur le plan de test exécuté, tels que le nom du plan CTS et les heures de début et de fin d'exécution. Il présente également un résumé global du nombre de tests qui ont réussi, échoué, expiré ou n'ont pas pu être exécutés.
Exemple de résumé de test Android 10 CTS
Figure 1 : exemple de résumé de test Android 10 CTS
Exemple de résumé de test CTS v2
Figure 2 : exemple de résumé de test CTS v2
Exemple de résumé de test CTS v1
Figure 3 : exemple de résumé de test CTS v1
Rapport d'essai
La section suivante, le rapport de test CTS, fournit un résumé des tests réussis par package.
Ceci est suivi de détails sur les tests réels qui ont été exécutés. Le rapport répertorie le package de tests, la suite de tests, le scénario de test et les tests exécutés. Il affiche le résultat de l'exécution du test : réussite, échec, expiration du délai ou non exécuté. En cas d'échec du test, des détails sont fournis pour aider à diagnostiquer la cause.
De plus, la trace de la pile de l'échec est disponible dans le fichier XML mais n'est pas incluse dans le rapport par souci de concision : l'affichage du fichier XML avec un éditeur de texte devrait fournir des détails sur l'échec du test (recherchez la balise [Test] correspondant à le test échoué et recherchez à l'intérieur la balise [StackTrace] ).
Afficher un exemple de rapport de test CTS v2
Figure 4 : exemple de rapport de test CTS v2
Afficher un exemple de rapport de test CTS v1
Figure 5 : exemple de rapport de test CTS v1
Consultez test_result.xml pour les modules de test incomplets
Pour déterminer le nombre de modules incomplets dans une session de test donnée, exécutez la commande « list results ». Le nombre de modules terminés et le nombre total de modules sont répertoriés pour chaque session précédente. Pour déterminer quels modules sont complets ou incomplets, ouvrez le fichier test_result.xml et lisez la valeur de l'attribut « done » pour chaque module dans le rapport de résultats. Les modules avec la valeur done = "false" ne sont pas terminés.
Échecs des tests de triage
Utilisez les suggestions suivantes pour trier les échecs de test.
- Vérifiez que votre environnement CTS est correctement configuré si un test échoue en raison de conditions préalables incorrectes. Cela inclut l'environnement physique, la configuration de l'ordinateur de bureau et la configuration des appareils Android.
- Vérifiez la stabilité de l'appareil, la configuration du test ou les problèmes d'environnement, si un test semble excessivement irrégulier.
- Réessayez le test de manière isolée s'il échoue toujours.
- Recherchez les facteurs externes provoquant des échecs de test, tels que :
- Configuration environnementale. Par exemple, une configuration d'ordinateur de bureau mal configurée peut être à l'origine d'échecs de test survenant sur tous les périphériques sous test (DUT) (y compris les périphériques de référence).
- Dépendances externes. Par exemple, si un test échoue sur tous les appareils de plusieurs sites à partir d’un moment précis, une mauvaise URL peut être en cause.
- Si le DUT n’inclut pas le correctif de sécurité, son test de sécurité échouera probablement.
- Validez et analysez les différences entre les appareils qui réussissent et ceux qui échouent.
- Analysez l'assertion, le journal, le rapport de bug et la source CTS . Pour un HostTest, l'assertion et le journal peuvent être très génériques, il est donc utile de vérifier et d'attacher également le logcat du périphérique.
- Soumettez un correctif d’amélioration des tests pour aider à réduire les échecs des tests.
Enregistrer les résultats partiels
Tradefed n'enregistre pas les résultats partiels des tests lorsque l'appel du test échoue.
Lorsque Tradefed ne génère aucun résultat de test, cela implique qu'un problème grave s'est produit pendant le test, rendant ainsi le résultat du test peu fiable. Le résultat partiel est jugé inutile car il n’apporte aucune valeur lors de l’enquête sur un problème de périphérique.