Средства проверки состояния системы (SSC) определяются на уровне конфигурации пакета и запускаются между каждым модулем. Они выполняют проверки, чтобы определить, изменился ли модуль и не восстановил ли некоторые заданные состояния, например, изменив значение системного свойства.
SSC в основном используются для того, чтобы авторы модулей не забывали выполнять очистку после тестов; но если они это сделают, предоставьте их след, чтобы их можно было устранить.
Вторичное использование — также восстановить исходное состояние, когда это возможно, например, закрыть защиту клавиатуры, если она осталась открытой.
XML-определение средства проверки состояния системы
<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 определяются в теге system_checker
в XML-файле конфигурации Tradefed.
Выполнение
Каждый SSC должен реализовать интерфейс ISystemStatusChecker
, который предоставляет два основных метода preExecutionCheck
и postExecutionCheck
, которые запускаются до и после выполнения каждого модуля.
Программа проверки может реализовать только один из двух или реализовать оба, если необходимо проверить состояние до модуля и сравнить его с состоянием после модуля.
В Tradefed существует несколько примеров реализации . В каждой реализации рекомендуется сосредоточиться на одной проверке, чтобы улучшить возможность повторного использования. Например, SystemServerStatusCheck
проверяет, перезапустился ли процесс system_server
на устройстве во время выполнения набора тестов. В postExecutionCheck
он вызывает deviceSoftRestarted
, который определен в NativeDevice
, чтобы проверить, перезапустился ли процесс system_server
.
Каждая операция возвращает StatusCheckerResult
, который позволяет системе решить, следует ли собирать дополнительную информацию, например отчет об ошибке.
Где они определены в CTS?
Средства проверки состояния системы CTS определены в /test/suite_harness/tools/cts-tradefed/res/config/cts-system-checkers.xml .
Как найти сбои в чекере
По умолчанию сбои средства проверки системы отображаются только в журналах и отчетах об ошибках, записанных для вызова с именем в формате bugreport-checker-post-module-<module name>.zip
.
Это позволяет узнать, после какого модуля был создан отчет об ошибке.
Можно сделать так, чтобы средство проверки системы сообщало о сбое теста, установив для параметра --report-system-checkers
значение true
. В результате тестовый запуск отображается как неудачный, а причиной неудачи является конкретная проверка средства проверки состояния.
Средства проверки состояния системы (SSC) определяются на уровне конфигурации пакета и запускаются между каждым модулем. Они выполняют проверки, чтобы определить, изменился ли модуль и не восстановил ли некоторые заданные состояния, например, изменив значение системного свойства.
SSC в основном используются для того, чтобы авторы модулей не забывали выполнять очистку после тестов; но если они это сделают, предоставьте их след, чтобы их можно было устранить.
Вторичное использование — также восстановить исходное состояние, когда это возможно, например, закрыть защиту клавиатуры, если она осталась открытой.
XML-определение средства проверки состояния системы
<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 определяются в теге system_checker
в XML-файле конфигурации Tradefed.
Выполнение
Каждый SSC должен реализовать интерфейс ISystemStatusChecker
, который предоставляет два основных метода preExecutionCheck
и postExecutionCheck
, которые запускаются до и после выполнения каждого модуля.
Программа проверки может реализовать только один из двух или реализовать оба, если необходимо проверить состояние до модуля и сравнить его с состоянием после модуля.
В Tradefed существует несколько примеров реализации . В каждой реализации рекомендуется сосредоточиться на одной проверке, чтобы улучшить возможность повторного использования. Например, SystemServerStatusCheck
проверяет, перезапустился ли процесс system_server
на устройстве во время выполнения набора тестов. В postExecutionCheck
он вызывает deviceSoftRestarted
, который определен в NativeDevice
, чтобы проверить, перезапустился ли процесс system_server
.
Каждая операция возвращает StatusCheckerResult
, который позволяет системе решить, следует ли собирать дополнительную информацию, например отчет об ошибке.
Где они определены в CTS?
Средства проверки состояния системы CTS определены в /test/suite_harness/tools/cts-tradefed/res/config/cts-system-checkers.xml .
Как найти сбои в чекере
По умолчанию сбои средства проверки системы отображаются только в журналах и отчетах об ошибках, записанных для вызова с именем в формате bugreport-checker-post-module-<module name>.zip
.
Это позволяет узнать, после какого модуля был создан отчет об ошибке.
Можно сделать так, чтобы средство проверки системы сообщало о сбое теста, установив для параметра --report-system-checkers
значение true
. В результате тестовый запуск отображается как неудачный, а причиной неудачи является конкретная проверка средства проверки состояния.