Moduły do sprawdzania stanu systemu są zdefiniowane na poziomie pakietu. między poszczególnymi modułami. który sprawdza, czy moduł nie uległ zmianie. i nie przywróciły niektórych stanów, na przykład zmiany właściwości systemu. .
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.
Użycie drugorzędne polega na przywracaniu pierwotnego stanu, gdy jest to możliwe, na przykład przez zamknięcie blokady, jeśli była otwarta.
Definicja kodu 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" />
Konta SSC są zdefiniowane w tagu system_checker
w konfiguracji Tradefed
Plik XML:
Implementacja
Każda inteligentna kampania produktowa musi zaimplementować ISystemStatusChecker
,
który udostępnia 2 główne metody preExecutionCheck
i postExecutionCheck
uruchamianych przed i po każdym wykonaniu modułu.
Moduł sprawdzania może zaimplementować tylko jedną z tych metod lub zarówno te, w których trzeba sprawdzić stan przed modułem i porównać go z stan po module.
Kilka przykładów
implementacji
są dostępne w ramach Tradefed. Zalecamy, aby każda implementacja koncentrowała się na pojedynczym sprawdzeniu
aby zwiększyć możliwość
ponownego wykorzystania. Przykład:
SystemServerStatusCheck
sprawdza, czy proces system_server
został ponownie uruchomiony na urządzeniu podczas
i wykonania zestawu testów. W aplikacji postExecutionCheck
nazywa się deviceSoftRestarted
,
, która jest definiowana w
NativeDevice
.
aby sprawdzić, czy proces system_server
został ponownie uruchomiony.
Każda operacja zwraca
StatusCheckerResult
Dzięki temu możemy określić, czy dodatkowe informacje, takie jak raport o błędzie,
ujęć.
Gdzie są zdefiniowane w narzędziu 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 narzędzia do 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 dowiesz się, po którym module został wygenerowany raport o błędzie.
Można utworzyć raport narzędzia do sprawdzania systemu jako błąd testu,
ustawiam opcję --report-system-checkers
na true
. Dzięki temu uzyskasz
uruchomienie testu wyświetla się jako nieudane, a narzędzie do sprawdzania stanu wskazuje przyczynę niepowodzenia
konkretnego sprawdzenia.