Les vérificateurs d'état du système (CSI) 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 changé et s'il n'a pas restauré certains états donnés, par exemple en modifiant la valeur d'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.
Un vérificateur peut n'implémenter qu'un seul des deux ou les deux si vous devez vérifier l'état avant le module et 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, doivent être collectées.
Où sont-ils définis dans CTS ?
Les vérificateurs d'état du système CTS sont définis /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 système ne s'affichent que dans les journaux et sous forme de rapports de bugs capturés pour l'appel avec un nom au 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. Le test s'affiche alors comme ayant échoué, et la raison de l'échec est la vérification spécifique du vérificateur d'état.