Sprawdzanie stanu systemu (SSC) jest zdefiniowane w konfiguracji na poziomie pakietu i jest uruchamiane między poszczególnymi modułami. Sprawdzają, czy moduł uległ zmianie, i nie przywracają niektórych stanów, np. zmiany wartości właściwości systemu.
SSC są używane głównie po to, aby twórcy modułów nie zapominali o zwalnianiu miejsca po testach. Jeśli jednak zapomną, SSC zapewniają ślad, który można wykorzystać do rozwiązania problemu.
Dodatkowo w miarę możliwości przywraca pierwotny stan, np. zamyka klawiaturę ekranową, jeśli była otwarta.
Definicja XML narzędzia do sprawdzania stanu systemu
<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" />
SSC są zdefiniowane w tagu system_checker w pliku XML konfiguracji Tradefed.
Implementacja
Każdy SSC musi implementować ISystemStatusCheckerinterfejs, który udostępnia 2 główne metody preExecutionCheck i postExecutionCheck, wykonywane przed i po każdym uruchomieniu modułu.
Sprawdzający może zaimplementować tylko jedną z tych funkcji lub obie, jeśli istnieje potrzeba sprawdzenia stanu przed modułem i porównania go ze stanem po module.
W Tradefed istnieje kilka przykładowych implementacji. Aby zwiększyć możliwość ponownego użycia, zalecamy, aby każde wdrożenie koncentrowało się na jednym sprawdzeniu. Na przykład SystemServerStatusCheck sprawdza, czy podczas wykonywania zestawu testów na urządzeniu ponownie uruchomiono proces system_server. W postExecutionCheck wywołuje funkcję deviceSoftRestarted, która jest zdefiniowana w NativeDevice, aby sprawdzić, czy proces system_server został ponownie uruchomiony.
Każda operacja zwraca wartość StatusCheckerResult, która pozwala platformie testowej zdecydować, czy należy rejestrować dodatkowe informacje, np. raport o błędzie.
Gdzie są one zdefiniowane w CTS?
Sprawdzanie stanu systemu CTS jest zdefiniowane w pliku /test/suite_harness/tools/cts-tradefed/res/config/cts-system-checkers.xml.
Jak znaleźć błędy modułu sprawdzania
Domyślnie błędy narzędzia do sprawdzania systemu są widoczne tylko w dziennikach i raportach o błędach zarejestrowanych w przypadku wywołania o nazwie w formacie bugreport-checker-post-module-<module name>.zip.
Dzięki temu możesz sprawdzić, po którym module wygenerowano raport o błędzie.
Możesz sprawić, że raport narzędzia do sprawdzania systemu będzie traktowany jako niepowodzenie testu, ustawiając opcję --report-system-checkers na true. W rezultacie test zostanie oznaczony jako nieudany, a przyczyną niepowodzenia będzie konkretny test sprawdzania stanu.