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.
Są one używane głównie po to, aby twórcy modułów nie zapominali o sprzątaniu po testach. Jeśli jednak zapomną, SSC zapewni ślad, który pozwoli rozwiązać problem.
Dodatkowo w miarę możliwości przywraca pierwotny stan, np. zamyka klawiaturę ekranową, jeśli został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
uruchamiane przed i po wykonaniu każdego 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. Zalecamy, aby każde wdrożenie skupiało się na jednym sprawdzeniu, co zwiększy możliwość ponownego wykorzystania. Na przykład SystemServerStatusCheck sprawdza, czy podczas wykonywania pakietu 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 określić, 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 dowiesz się, 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 wyniku tego testowe uruchomienie będzie oznaczone jako nieudane, a przyczyną niepowodzenia będzie konkretna kontrola sprawdzania stanu.