Les résultats des tests 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. Il reflète le chemin d'accès où vous avez décompressé le CTS officiel prédéfini téléchargé sur 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 avec 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 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 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 agrégé du nombre de tests réussis, échoués, expirés ou qui n'ont pas pu être exécutés.
Résumé des tests d'exemple CTS Android 10
Figure 1:Résumé d'un exemple de test CTS Android 10
Exemple de résumé de test CTS v2
Figure 2:Résumé d'un exemple de test CTS v2
Exemple de résumé de test CTS v1
Figure 3:Résumé d'un exemple de 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 plus de concision. L'affichage du fichier XML dans un éditeur de texte devrait fournir des informations sur l'échec du test (recherchez la balise [Test] correspondant au test ayant échoué, puis recherchez 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
Examiner le fichier 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 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 "done" est "false" ne se sont pas exécutés jusqu'à la fin.
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 l'ordinateur de bureau et la configuration de l'appareil 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, par exemple :
- 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 testés (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 de joindre le logcat de l'appareil.
- Envoyez un correctif d'amélioration des tests pour réduire les échecs.
Enregistrer des résultats partiels
Tradefed n'enregistre pas les résultats de test partiels en cas d'échec de l'appel de test.
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'a aucune utilité pour résoudre le problème de l'appareil.