Systemstatusprüfungen (System Status Checkers, 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 stellen einige bestimmte Status nicht wieder her, z. B. wenn sich der Wert einer Systemeigenschaft geändert hat.
SSCs werden hauptsächlich verwendet, um sicherzustellen, dass Modulautoren nicht vergessen, nach ihren Tests aufzuräumen. Wenn sie es doch tun, sollte ein Trace bereitgestellt werden, damit das Problem behoben werden kann.
Eine sekundäre Verwendung besteht darin, den ursprünglichen Zustand nach Möglichkeit wiederherzustellen, z. B. die Keyguard zu schließen, wenn sie geöffnet war.
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 im Tradefed-Konfigurations-XML unter dem Tag system_checker definiert.
Implementierung
Jeder SSC muss die ISystemStatusChecker-Schnittstelle implementieren, die die beiden Hauptmethoden preExecutionCheck und postExecutionCheck bereitstellt, die vor und nach der Ausführung jedes Moduls ausgeführt werden.
Ein Checker kann nur eine der beiden oder beide implementieren, wenn der Status vor dem Modul geprüft und mit dem Status nach dem Modul verglichen werden muss.
In Tradefed sind mehrere Beispielimplementierungen vorhanden. Jede Implementierung sollte sich auf einen einzelnen Check konzentrieren, um die Wiederverwendbarkeit zu verbessern. Beispiel:
SystemServerStatusCheck
prüft, ob der system_server-Prozess auf dem Gerät während der Ausführung der Testsuite 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. So kann das Harness entscheiden, ob zusätzliche Informationen wie ein Fehlerbericht erfasst werden sollen.
Wo sind sie im CTS definiert?
CTS-Systemstatusprüfungen sind in /test/suite_harness/tools/cts-tradefed/res/config/cts-system-checkers.xml definiert.
Fehler bei der Prüfung finden
Standardmäßig werden Fehler des Systemprüfers nur in den Logs und als Fehlerberichte angezeigt, die für den Aufruf mit dem Namen im Format bugreport-checker-post-module-<module name>.zip erfasst wurden.
So können Sie herausfinden, nach welchem Modul der Fehlerbericht generiert wurde.
Sie können den Systemprüfbericht selbst als Testfehler festlegen, indem Sie die Option --report-system-checkers auf true setzen. Dies führt dazu, dass ein Testlauf als fehlgeschlagen angezeigt wird. Der Grund für den Fehler ist die jeweilige Prüfung des Status-Checkers.