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.