Les résultats du test CTS sont placés dans le fichier:
CTS_ROOT/android-cts/results/start_time.zip
Si vous avez créé le CTS vous-même, CTS_ROOT ressemble à out/host/linux-x86/cts, mais diffère selon la plate-forme. Cela reflète le chemin d'accès où vous avez décompressé le fichier CTS officiel prédéfini téléchargé à partir de ce site.
Dans le fichier 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 avec HTML5.
Afficher les résultats antérieurs à Android 10
Ouvrez le fichier test_result.xml dans un navigateur Web compatible HTML5 pour afficher les résultats du test.
Si ce fichier affiche une page vide lorsque vous utilisez le navigateur Chrome, modifiez la configuration de votre navigateur pour activer l'option de ligne de commande --allow-file-access-from-files.
Lire les résultats du test
Les détails des résultats du test 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 la version 1 de CTS et les versions antérieures, sélectionnez "Device Information" (Informations sur l'appareil) (lien au-dessus de "Test Summary" (Récapitulatif des tests)) pour afficher des informations sur l'appareil, le micrologiciel (marque, modèle, version du micrologiciel, plate-forme) et le matériel de l'appareil (résolution de l'écran, clavier, type d'écran). La version 2 de CTS n'affiche pas les informations sur l'appareil.
Résumé de test
La section Récapitulatif des tests fournit des informations sur le plan de test exécuté, telles que le nom du plan CTS, ainsi que les heures de début et de fin de l'exécution. Il présente également un récapitulatif global du nombre de tests qui ont réussi, échoué, qui ont expiré ou n'ont pas pu être exécutés.
Résumé des tests d'exemple CTS Android 10
Figure 1:Exemple de résumé de test pour Android 10 CTS
Exemple de résumé de test CTS v2
Figure 2:Exemple de résumé de test pour CTS v2
Exemple de résumé de test CTS v1
Figure 3:Exemple de résumé du test CTS v1
Rapport de test
La section suivante, le rapport de test CTS, fournit un résumé des tests réussis par package.
Viennent ensuite les détails des tests réels exécutés. Le rapport liste le package de test, la suite de tests, le scénario de test et les tests exécutés. Il indique le résultat de l'exécution du test : succès, échec, expiration du délai ou non exécuté. En cas d'échec d'un test, des informations sont fournies pour vous aider à en 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 pour des raisons de concision. Si vous consultez le fichier XML avec un éditeur de texte, vous devez obtenir des détails sur l'échec du test (recherchez la balise [Test] correspondant au test ayant échoué et recherchez la balise [StackTrace]).
Afficher l'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
Vérifier les modules de test incomplets dans test_result.xml
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 indiqués pour chaque session précédente. Pour déterminer les modules terminés et inachevés, ouvrez le fichier test_result.xml et lisez la valeur de l'attribut "done" pour chaque module dans le rapport sur les résultats. Les modules dont la valeur est définie sur "false" ne sont pas exécutés intégralement.
Trier les échecs des tests
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 la machine de bureau et celle des appareils Android.
- Vérifiez la stabilité de l'appareil, la configuration du test ou les problèmes d'environnement si un test semble trop instable.
- Réessayez le test de manière isolée si le problème persiste.
- Recherchez les facteurs externes à l'origine des échecs des tests, tels que :
- Configuration de l'environnement. Par exemple, une configuration de machine de bureau mal configurée peut être à l'origine d'échecs de test sur tous les appareils sous test (y compris les appareils de référence).
- Dépendances externes Par exemple, si un test échoue sur tous les appareils de plusieurs sites à partir d'un moment donné, une mauvaise URL peut être en cause.
- Si le DUT n'inclut pas le correctif de sécurité, l'échec du test de sécurité est attendu.
- 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'associer également le logcat de l'appareil.
- Envoyez un correctif d'amélioration des tests pour réduire le nombre d'échecs.
Enregistrer des 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 signifie qu'un problème grave s'est produit lors de l'exécution du test, ce qui rend le résultat du test peu fiable. Le résultat partiel est considéré comme inutile, car il n'apporte aucune valeur lors de l'examen du problème de l'appareil.