Sprawdzający stan systemu (SSC) są definiowane na poziomie konfiguracji pakietu i uruchamiane między poszczególnymi modułami. Wykonują one kontrole, aby określić, czy moduł się zmienił i czy nie przywrócił niektórych stanów, np. czy nie zmieniła się wartość właściwości systemowej.
Testy jednostkowe służą głównie do zapewnienia, że autorzy modułów nie zapomną o usunięciu kodu po testach. Jeśli jednak zapomną to zrobić, testy jednostkowe pozostawiają ślad, dzięki któremu można rozwiązać problem.
Drugim zastosowaniem jest przywrócenie pierwotnego stanu, o ile to możliwe, na przykład zamknięcie blokady klawiatury, jeśli była otwarta.
Definicja XML 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ą definiowane w tagu system_checker w pliku XML konfiguracji Tradefed.
Implementacja
Każdy SSC musi implementować interfejs ISystemStatusChecker, który udostępnia 2 główne metody: preExecutionCheck i postExecutionCheck, które są wykonywane przed i po wykonaniu każdego modułu.
Sprawdzacz może zaimplementować tylko jedną z tych metod lub obie, jeśli zachodzi potrzeba sprawdzenia stanu przed modułem i porównania go ze stanem po module.
W pliku Tradefed znajduje się kilka implementacji przykładowych. Zalecamy, aby każda implementacja koncentrowała się na jednym sprawdzeniu, co zwiększy możliwość jej ponownego użycia. Na przykład SystemServerStatusChecksprawdza, czy proces system_server został ponownie uruchomiony na urządzeniu podczas wykonywania zestawu testów. W funkcji postExecutionCheck wywołuje ona funkcję deviceSoftRestarted, która jest zdefiniowana w NativeDevice, aby sprawdzić, czy proces system_server został wznowiony.
Każda operacja zwraca wartość StatusCheckerResult, która pozwala mechanizmowi zdecydować, czy należy zebrać dodatkowe informacje, np. raport o błędzie.
Gdzie są one zdefiniowane w CTS?
Sprawdzający stan systemu CTS są zdefiniowani w pliku /test/suite_harness/tools/cts-tradefed/res/config/cts-system-checkers.xml.
Jak znaleźć błędy sprawdzania
Domyślnie błędy sprawdzania systemu są wyświetlane tylko w dziennikach i jako raporty o błędach zarejestrowane dla wywołania o nazwie w formacie bugreport-checker-post-module-<module name>.zip.
Dzięki temu możesz sprawdzić, z którego modułu wygenerowano raport o błędzie.
Raport sprawdzania systemu można ustawić jako niepowodzenie testu, ustawiając opcję --report-system-checkers na true. W efekcie test jest wyświetlany jako nieudany, a przyczyną niepowodzenia jest sprawdzanie stanu konkretnego testu.