Les vérificateurs d'état du système (SSC) sont définis au niveau de la configuration qui s'exécutent entre chaque module. Ils effectuent des vérifications pour déterminer si le module a été modifié et n'a pas restauré certains états donnés (par exemple, en modifiant une propriété système) .
Les CSI servent principalement à s'assurer que les rédacteurs de modules n'oublient pas de nettoyer après leurs tests ; mais si c'est le cas, fournissez-en une trace afin qu'il puisse être traité.
Une utilisation secondaire consiste également à restaurer l'état d'origine lorsque cela est possible, par exemple désactiver le verrouillage du clavier s'il était resté ouvert.
Définition XML du vérificateur d'état du système
<system_checker class="com.android.tradefed.suite.checker.KeyguardStatusChecker" />
<system_checker class="com.android.tradefed.suite.checker.LeakedThreadStatusChecker" />
<system_checker class="com.android.tradefed.suite.checker.SystemServerStatusChecker" />
Les CSI sont définies sous la balise system_checker dans la configuration Tradefed
XML.
Implémentation
Chaque CSI doit implémenter la ISystemStatusChecker
de commande,
qui fournit les deux méthodes principales preExecutionCheck et postExecutionCheck
qui s'exécutent avant et après l'exécution de chaque module.
Il est possible qu'un vérificateur n'implémente qu'un seul des deux à la fois s'il est nécessaire de vérifier l'état avant le module et de le comparer l'état après le module.
Plusieurs exemples
implémentations
qui existent dans Tradefed. Chaque implémentation est recommandée pour se concentrer sur une seule vérification
pour améliorer la réutilisabilité. Par exemple :
SystemServerStatusCheck
vérifie si le processus system_server a redémarré sur l'appareil pendant le
de la suite de tests. Dans postExecutionCheck, il appelle deviceSoftRestarted,
qui est défini dans
NativeDevice
pour vérifier si le processus system_server a redémarré.
Chaque opération renvoie
StatusCheckerResult,
ce qui permet au harnais de décider
si des informations supplémentaires, comme un rapport de bug,
doit être capturé.
Où sont-ils définis dans CTS ?
Les vérificateurs d'état du système CTS sont définis dans /test/suite_harness/tools/cts-tradefed/res/config/cts-system-checkers.xml.
Identifier les échecs du vérificateur
Par défaut, les échecs du vérificateur du système ne s'affichent que dans les journaux et les rapports de bug
capturé pour l'appel, dont le nom suit le format
bugreport-checker-post-module-<module name>.zip
Cela vous permet de savoir dans quel module le rapport de bug a été généré.
Il est possible de faire du rapport du vérificateur
du système comme un échec de test lui-même en
en définissant l'option --report-system-checkers sur true. Cela se traduit par
l'exécution du test s'affiche comme ayant échoué, le motif de l'échec étant le vérificateur d'état
un contrôle particulier.