Системные проверки статуса (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 в конфигурации Tradefed XML.
Реализация
Каждый 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. В результате тестовый запуск будет отмечен как неудачный, а в качестве причины будет указана проверка статуса.