Sprawdzający stan systemu (SSC) są definiowane na poziomie konfiguracji pakietu i uruchamiane między poszczególnymi modułami. Sprawdzają, czy moduł się zmienił i nie przywrócił niektórych stanów, np. zmiany wartości 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 przywracanie 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żda inteligentna kampania produktowa musi implementować interfejs ISystemStatusChecker, który udostępnia 2 główne metody preExecutionCheck i postExecutionCheck, które działają przed i po każdym wykonaniu modułu.
Moduł sprawdzający może wdrożyć tylko jedną z tych 2 lub oba te elementy, jeśli konieczne jest sprawdzenie stanu przed modułem i porównanie 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ł ponownie uruchomiony.
Każda operacja zwraca wartość StatusCheckerResult, która pozwala mechanizmowi określić, 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ą 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 dowiesz się, po którym module został wygenerowany raport o błędzie.
Możesz ustawić opcję --report-system-checkers na true, aby system sprawdzania raportował niepowodzenie testu. W efekcie test jest wyświetlany jako nieudany, a przyczyną niepowodzenia jest sprawdzanie stanu konkretnego sprawdzania.