Kontrolery stanu systemu (SSC) są definiowane na poziomie konfiguracji pakietu i działają pomiędzy każdym modułem. Sprawdzają, czy moduł się zmienił i nie przywrócił niektórych zadanych stanów, na przykład zmieniając wartość właściwości systemu.
SSC są używane głównie w celu zapewnienia, że twórcy modułów nie zapomną posprzątać po testach; jeśli jednak tak się stanie, podaj jego ślad, aby można było go rozwiązać.
Drugim zastosowaniem jest również przywrócenie pierwotnego stanu, jeśli to możliwe, na przykład zwolnienie blokady klawiatury, jeśli pozostał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ą zdefiniowane w tagu system_checker w pliku XML konfiguracji Tradefed.
Realizacja
Każdy SSC musi implementować interfejs ISystemStatusChecker , który udostępnia dwie główne metody preExecutionCheck i postExecutionCheck , które są uruchamiane przed i po wykonaniu każdego modułu.
Możliwe jest, że moduł sprawdzający zaimplementuje tylko jeden z nich lub zaimplementuje oba, jeśli istnieje potrzeba sprawdzenia stanu przed modułem i porównania go ze stanem za modułem.
W Tradefed istnieje kilka przykładowych implementacji . Zaleca się, aby każda implementacja skupiała się na pojedynczym sprawdzeniu w celu poprawy możliwości ponownego użycia. Na przykład SystemServerStatusCheck sprawdza, czy proces system_server został ponownie uruchomiony na urządzeniu podczas wykonywania zestawu testów. W postExecutionCheck wywołuje deviceSoftRestarted , które jest zdefiniowane w NativeDevice w celu sprawdzenia, czy proces system_server został zrestartowany.
Każda operacja zwraca StatusCheckerResult , co pozwala wiązce zdecydować, czy należy przechwycić dodatkowe informacje, takie jak raport o błędzie.
Gdzie są one zdefiniowane w CTS?
Kontrolery stanu systemu CTS są zdefiniowane w pliku /test/suite_harness/tools/cts-tradefed/res/config/cts-system-checkers.xml .
Jak znaleźć błędy sprawdzania
Domyślnie awarie modułu sprawdzania systemu są widoczne tylko w dziennikach i raportach o błędach przechwyconych dla wywołania z nazwą zgodną z formatem bugreport-checker-post-module-<module name>.zip .
Dzięki temu dowiesz się, po jakim module wygenerowano raport o błędzie.
Możliwe jest, że moduł sprawdzania systemu sam zgłosi błąd testu, ustawiając opcję --report-system-checkers na true . Powoduje to, że uruchomienie testowe kończy się niepowodzeniem, a przyczyną niepowodzenia jest konkretna kontrola modułu sprawdzania stanu.