Les résultats du test CTS sont placés dans le fichier:
CTS_ROOT/android-cts/results/start_time.zip
Si vous avez créé vous-même la CTS, CTS_ROOT se présente comme suit :
out/host/linux-x86/cts, mais diffère selon la plate-forme. Cela reflète le chemin
où
vous avez décompressé le fichier CTS officiel
téléchargé depuis ce site.
Il contient les résultats réels dans le fichier test_result.xml.
Afficher les résultats associés à Android 10 ou version ultérieure
L'archive zip contient un fichier test_result.html ; vous pouvez l'ouvrir directement dans n'importe quel navigateur Web compatible avec HTML5.
Afficher les résultats antérieurs à Android 10
Pour afficher le test, ouvrez le fichier test_result.xml dans un navigateur Web compatible HTML5. résultats
Si ce fichier affiche une page vierge
lorsque vous utilisez le navigateur Chrome,
modifier 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 CTS v1 et versions antérieures, sélectionnez "Informations provenant des appareils" (lien au-dessus du résumé du test) pour afficher les détails de l'appareil, le micrologiciel (marque, modèle, build du micrologiciel, plate-forme) ; et le matériel de l'appareil (résolution d'écran, clavier, type d'écran). CTS v2 ne permet pas afficher les informations provenant des appareils.
Résumé de test
La section Résumé du test fournit les détails du plan de test exécuté, tels que le CTS le nom du plan et les heures de début et de fin d'exécution. Il présente également une vue agrégée le nombre de tests qui ont réussi, échoué, qui ont expiré ou qui n'ont pas pu l'être ; exécuté.
Résumé de l'exemple de test 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é du test pour CTS v2
Exemple de résumé du 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 d'un package.
Cette page est suivie des détails des tests qui ont été exécutés. Le rapport liste le package de tests, la suite de tests, le scénario de test et les tests exécutés. Émissions le résultat de l'exécution du test (réussi, échec, expiré ou non exécuté). Dans d'un échec de test sont fournis pour vous aider à en déterminer la cause.
De plus, la trace de la pile de l'échec est disponible dans le fichier XML, mais pas inclus dans le rapport pour des raisons de concision (affichage du fichier XML avec un éditeur de texte). doit fournir des détails sur l'échec du test (recherchez la balise [Test]). correspondant au test ayant échoué et recherchez le tag [StackTrace].
Afficher l'exemple de rapport de test CTS v2
Figure 4:Exemple de rapport de test CTS v2
Afficher l'exemple de rapport de test CTS v1
Figure 5:Exemple de rapport de test CTS v1
Rechercher des modules de test incomplets dans le fichier test_result.xml
Pour déterminer le nombre de modules incomplets dans une session de test donnée, exécutez la commande suivante : kubectl "list results". Le nombre de modules terminés et le nombre total de modules sont listées pour chaque session précédente. Pour déterminer quels modules sont terminés incomplet, ouvrez le fichier test_result.xml et lisez la valeur de « done » pour chaque module dans le rapport de résultats. Modules avec une valeur terminée = "faux" qui n'ont pas été exécutées jusqu'à la fin.
Tri des échecs des tests
Utilisez les suggestions suivantes pour trier les échecs de test.
- Validez votre Environnement CTS est configuré correctement, si un test échoue en raison de conditions préalables incorrectes. Cela inclut l'environnement physique, la configuration de la machine de bureau et Configuration des appareils Android.
- Vérifier la stabilité de l'appareil, tester la configuration ou les problèmes liés à l'environnement si un test semble trop irrégulier.
- Effectuez à nouveau le test de façon isolée si l'échec persiste.
- Recherchez les facteurs externes à l'origine des échecs des tests, tels que:
<ph type="x-smartling-placeholder">
- </ph>
- Configuration de l'environnement. Par exemple, un ordinateur de bureau mal configuré configuration peut être à l'origine d'échecs des tests sur tous les appareils Test (DUT) (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 précis, une URL incorrecte peut être en cause.
- Si l'appareil testé n'inclut pas le niveau de sécurité l'échec du test de sécurité est attendu.
- Valider et analyser les différences entre les appareils ayant réussi et ceux défaillants
- Analysez l'assertion, le journal, le rapport de bug Source CTS : Pour un HostTest, une assertion et un journal peuvent être très génériques, il est donc utile de également vérifier et rattacher le fichier logcat de l’appareil.
- Envoyez un correctif d'amélioration des tests pour réduire le nombre d'échecs.
Enregistrer les 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 implique qu'un problème grave s'est produite pendant l'exécution du test, ce qui rend le résultat du test non fiable. Le résultat partiel est jugé inutile, car il n'apporte aucune valeur lorsque enquêter sur un problème d'appareil.