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.
SSC stosuje się głównie po to, aby osoby zapisujące moduły nie zapomniały wyczyścić po zakończeniu testów; ale jeśli tak jest, udostępnij ślad po tym, aby można było rozwiązać ten 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ż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ść ponownego użycia. Przykład:
SystemServerStatusCheck
sprawdza, czy proces system_server został ponownie uruchomiony na urządzeniu podczas
i wykonania 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?
Moduły do sprawdzania stanu systemu CTS definiuje się tutaj: /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 jako raporty o błędach
przechwyconych dla wywołania z nazwą w formacie
bugreport-checker-post-module-<module name>.zip
Dzięki temu możesz sprawdzić, z jakiego modułu wygenerowano 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.