Systemstatusprüfer (SSCs) werden in der Konfiguration auf Suite-Ebene definiert und zwischen den einzelnen Modulen ausgeführt. Sie führen Prüfungen durch, um festzustellen, ob sich das Modul geändert hat und bestimmte Zustände nicht wiederhergestellt wurden, beispielsweise die Änderung eines Systemeigenschaftswerts.
SSCs werden hauptsächlich verwendet, um sicherzustellen, dass Modulschreiber nach ihren Tests nicht vergessen, aufzuräumen; Wenn dies jedoch der Fall ist, stellen Sie eine Spur davon bereit, damit das Problem behoben werden kann.
Eine sekundäre Verwendung besteht darin, nach Möglichkeit auch den ursprünglichen Zustand wiederherzustellen, beispielsweise das Entfernen der Tastensperre, wenn diese offen gelassen wurde.
XML-Definition für die Systemstatusprüfung
<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" />
SSCs werden unter dem system_checker Tag im Tradefed-Konfigurations-XML definiert.
Implementierung
Jeder SSC muss die ISystemStatusChecker Schnittstelle implementieren, die die beiden Hauptmethoden preExecutionCheck und postExecutionCheck bereitstellt, die vor und nach jeder Modulausführung ausgeführt werden.
Es ist möglich, dass ein Prüfer nur eines der beiden implementiert oder beide implementiert, wenn der Status vor dem Modul überprüft und mit dem Status nach dem Modul verglichen werden muss.
In Tradefed gibt es mehrere Beispielimplementierungen . Es wird empfohlen, sich bei jeder Implementierung auf eine einzige Prüfung zu konzentrieren, um die Wiederverwendbarkeit zu verbessern. SystemServerStatusCheck prüft beispielsweise, ob der system_server Prozess während der Ausführung der Testsuite auf dem Gerät neu gestartet wurde. Im postExecutionCheck wird deviceSoftRestarted aufgerufen, das in NativeDevice definiert ist, um zu prüfen, ob der system_server Prozess neu gestartet wurde.
Jeder Vorgang gibt StatusCheckerResult zurück, wodurch der Harness entscheiden kann, ob zusätzliche Informationen, wie etwa ein Fehlerbericht, erfasst werden sollen.
Wo sind sie im CTS definiert?
CTS-Systemstatusprüfer sind in /test/suite_harness/tools/cts-tradefed/res/config/cts-system-checkers.xml definiert.
So finden Sie Checker-Fehler
Standardmäßig werden Systemprüffehler nur in den Protokollen und als Fehlerberichte angezeigt, die für den Aufruf erfasst werden, wobei der Name dem Format bugreport-checker-post-module-<module name>.zip folgt.
Dadurch können Sie herausfinden, nach welchem Modul der Fehlerbericht erstellt wurde.
Es ist möglich, dass der Systemprüfer selbst einen Testfehler meldet, indem die Option --report-system-checkers auf true gesetzt wird. Dies führt dazu, dass ein Testlauf als fehlgeschlagen angezeigt wird, wobei der Grund für den Fehler in der jeweiligen Prüfung des Statusprüfers liegt.