Средства проверки состояния системы (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 . Это приведет к тому, что тестовый прогон будет показан как неудачный, а причиной сбоя будет конкретная проверка средства проверки состояния.
Средства проверки состояния системы (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 . Это приведет к тому, что тестовый прогон будет показан как неудачный, а причиной сбоя будет конкретная проверка средства проверки состояния.