Los verificadores de estado del sistema (SSC) se definen en la configuración de nivel de suite y se ejecutan entre cada módulo. Realizan verificaciones para determinar si el módulo cambió y no restauró algunos estados dados, por ejemplo, cambiar un valor de propiedad del sistema.
Los SSC se utilizan principalmente para garantizar que los escritores de módulos no se olviden de limpiar después de sus pruebas; pero si lo hacen, proporcione un rastro para que pueda ser abordado.
Un uso secundario es también restaurar el estado original cuando sea posible, por ejemplo, descartar el bloqueo de teclado si se dejó abierto.
Definición XML del comprobador de estado del sistema
<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" />
Los SSC se definen bajo la etiqueta system_checker en el XML de configuración de Tradefed.
Implementación
Cada SSC debe implementar la interfaz ISystemStatusChecker , que proporciona los dos métodos principales, preExecutionCheck y postExecutionCheck , que se ejecutan antes y después de la ejecución de cada módulo.
Es posible que un verificador implemente solo uno de los dos, o implemente ambos si es necesario verificar el estado antes del módulo y compararlo con el estado después del módulo.
Existen varias implementaciones de ejemplo en Tradefed. Se recomienda que cada implementación se centre en una única comprobación para mejorar la reutilización. Por ejemplo, SystemServerStatusCheck verificará si el proceso system_server se reinició en el dispositivo durante la ejecución del conjunto de pruebas. En postExecutionCheck llama a deviceSoftRestarted que está definido en NativeDevice para verificar si el proceso system_server se reinició.
Cada operación devuelve un StatusCheckerResult que permite que el arnés decida si se debe capturar información adicional, como un informe de errores.
¿Dónde se definen en CTS?
Los verificadores de estado del sistema CTS se definen en: /test/suite_harness/tools/cts-tradefed/res/config/cts-system-checkers.xml
Cómo encontrar fallas en el verificador
De manera predeterminada, las fallas del verificador del sistema solo se muestran en los registros y como informes de errores capturados para la invocación con un nombre que sigue el formato: bugreport-checker-post-module-<module name>.zip
Esto le permite averiguar después de qué módulo se generó el informe de errores.
Es posible hacer que el verificador del sistema informe como una falla de prueba configurando la --report-system-checkers en true . Esto dará como resultado una ejecución de prueba que se muestra como fallida y el motivo de la falla es la verificación particular del verificador de estado.
Los verificadores de estado del sistema (SSC) se definen en la configuración de nivel de suite y se ejecutan entre cada módulo. Realizan verificaciones para determinar si el módulo cambió y no restauró algunos estados dados, por ejemplo, cambiar un valor de propiedad del sistema.
Los SSC se utilizan principalmente para garantizar que los escritores de módulos no se olviden de limpiar después de sus pruebas; pero si lo hacen, proporcione un rastro para que pueda ser abordado.
Un uso secundario es también restaurar el estado original cuando sea posible, por ejemplo, descartar el bloqueo de teclado si se dejó abierto.
Definición XML del comprobador de estado del sistema
<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" />
Los SSC se definen bajo la etiqueta system_checker en el XML de configuración de Tradefed.
Implementación
Cada SSC debe implementar la interfaz ISystemStatusChecker , que proporciona los dos métodos principales, preExecutionCheck y postExecutionCheck , que se ejecutan antes y después de la ejecución de cada módulo.
Es posible que un verificador implemente solo uno de los dos, o implemente ambos si es necesario verificar el estado antes del módulo y compararlo con el estado después del módulo.
Existen varias implementaciones de ejemplo en Tradefed. Se recomienda que cada implementación se centre en una única comprobación para mejorar la reutilización. Por ejemplo, SystemServerStatusCheck verificará si el proceso system_server se reinició en el dispositivo durante la ejecución del conjunto de pruebas. En postExecutionCheck llama a deviceSoftRestarted que está definido en NativeDevice para verificar si el proceso system_server se reinició.
Cada operación devuelve un StatusCheckerResult que permite que el arnés decida si se debe capturar información adicional, como un informe de error.
¿Dónde se definen en CTS?
Los verificadores de estado del sistema CTS se definen en: /test/suite_harness/tools/cts-tradefed/res/config/cts-system-checkers.xml
Cómo encontrar fallas en el verificador
De manera predeterminada, las fallas del verificador del sistema solo se muestran en los registros y como informes de errores capturados para la invocación con un nombre que sigue el formato: bugreport-checker-post-module-<module name>.zip
Esto le permite averiguar después de qué módulo se generó el informe de errores.
Es posible hacer que el verificador del sistema informe como una falla de prueba configurando la --report-system-checkers en true . Esto dará como resultado una ejecución de prueba que se muestra como fallida y el motivo de la falla es la verificación particular del verificador de estado.
Los verificadores de estado del sistema (SSC) se definen en la configuración de nivel de suite y se ejecutan entre cada módulo. Realizan verificaciones para determinar si el módulo cambió y no restauró algunos estados dados, por ejemplo, cambiar un valor de propiedad del sistema.
Los SSC se utilizan principalmente para garantizar que los escritores de módulos no se olviden de limpiar después de sus pruebas; pero si lo hacen, proporcione un rastro para que pueda ser abordado.
Un uso secundario es también restaurar el estado original cuando sea posible, por ejemplo, descartar el bloqueo de teclado si se dejó abierto.
Definición XML del comprobador de estado del sistema
<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" />
Los SSC se definen bajo la etiqueta system_checker en el XML de configuración de Tradefed.
Implementación
Cada SSC debe implementar la interfaz ISystemStatusChecker , que proporciona los dos métodos principales, preExecutionCheck y postExecutionCheck , que se ejecutan antes y después de la ejecución de cada módulo.
Es posible que un verificador implemente solo uno de los dos, o implemente ambos si es necesario verificar el estado antes del módulo y compararlo con el estado después del módulo.
Existen varias implementaciones de ejemplo en Tradefed. Se recomienda que cada implementación se centre en una única comprobación para mejorar la reutilización. Por ejemplo, SystemServerStatusCheck verificará si el proceso system_server se reinició en el dispositivo durante la ejecución del conjunto de pruebas. En postExecutionCheck llama a deviceSoftRestarted que está definido en NativeDevice para verificar si el proceso system_server se reinició.
Cada operación devuelve un StatusCheckerResult que permite que el arnés decida si se debe capturar información adicional, como un informe de errores.
¿Dónde se definen en CTS?
Los verificadores de estado del sistema CTS se definen en: /test/suite_harness/tools/cts-tradefed/res/config/cts-system-checkers.xml
Cómo encontrar fallas en el verificador
De manera predeterminada, las fallas del verificador del sistema solo se muestran en los registros y como informes de errores capturados para la invocación con un nombre que sigue el formato: bugreport-checker-post-module-<module name>.zip
Esto le permite averiguar después de qué módulo se generó el informe de errores.
Es posible hacer que el verificador del sistema informe como una falla de prueba configurando la --report-system-checkers en true . Esto dará como resultado una ejecución de prueba que se muestra como fallida y el motivo de la falla es la verificación particular del verificador de estado.