Os verificadores de status do sistema (SSCs) são definidos na configuração de nível de suíte e executados entre cada módulo. Eles realizam verificações para determinar se o módulo mudou e não restaurou alguns estados, por exemplo, alterando um valor de propriedade do sistema.
Os SSCs são usados principalmente para garantir que os criadores de módulos não se esqueçam de limpar após seus testes; mas se o fizerem, forneça um rastro dele para que possa ser resolvido.
Um uso secundário é também restaurar o estado original quando possível, por exemplo, descartando o keyguard se ele for deixado aberto.
Definição XML do verificador de status do 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" />
Os SSCs são definidos na tag system_checker no XML de configuração Tradefed.
Implementação
Todo SSC deve implementar a interface ISystemStatusChecker , que fornece os dois métodos principais preExecutionCheck e postExecutionCheck executados antes e depois da execução de cada módulo.
É possível que um verificador implemente apenas um dos dois, ou implemente ambos se houver necessidade de verificar o estado antes do módulo e compará-lo com o estado após o módulo.
Existem várias implementações de exemplo no Tradefed. Recomenda-se que cada implementação se concentre em uma única verificação para melhorar a reutilização. Por exemplo, SystemServerStatusCheck verificará se o processo system_server foi reiniciado no dispositivo durante a execução do conjunto de testes. No postExecutionCheck ele chama deviceSoftRestarted que é definido em NativeDevice para verificar se o processo system_server foi reiniciado.
Cada operação retorna um StatusCheckerResult que permite ao chicote decidir se informações adicionais, como um relatório de bug, devem ser capturadas.
Onde eles são definidos no CTS?
Os verificadores de status do sistema CTS são definidos em: /test/suite_harness/tools/cts-tradefed/res/config/cts-system-checkers.xml
Como encontrar falhas no verificador
Por padrão, as falhas do verificador do sistema são exibidas apenas nos logs e como relatórios de bugs capturados para a invocação com o nome seguindo o formato: bugreport-checker-post-module-<module name>.zip
Isso permite que você descubra depois de qual módulo o relatório de bug foi gerado.
É possível fazer o relatório do verificador do sistema como uma falha de teste configurando a --report-system-checkers como true . Isso resultará em uma execução de teste mostrando como falha com o motivo da falha sendo a verificação específica do verificador de status.
Os verificadores de status do sistema (SSCs) são definidos na configuração de nível de suíte e executados entre cada módulo. Eles realizam verificações para determinar se o módulo mudou e não restaurou alguns estados, por exemplo, alterando um valor de propriedade do sistema.
Os SSCs são usados principalmente para garantir que os criadores de módulos não se esqueçam de limpar após seus testes; mas se o fizerem, forneça um rastro dele para que possa ser resolvido.
Um uso secundário é também restaurar o estado original quando possível, por exemplo, descartando o keyguard se ele for deixado aberto.
Definição XML do verificador de status do 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" />
Os SSCs são definidos na tag system_checker no XML de configuração Tradefed.
Implementação
Todo SSC deve implementar a interface ISystemStatusChecker , que fornece os dois métodos principais preExecutionCheck e postExecutionCheck executados antes e depois da execução de cada módulo.
É possível que um verificador implemente apenas um dos dois, ou implemente ambos se houver necessidade de verificar o estado antes do módulo e compará-lo com o estado após o módulo.
Existem várias implementações de exemplo no Tradefed. Recomenda-se que cada implementação se concentre em uma única verificação para melhorar a reutilização. Por exemplo, SystemServerStatusCheck verificará se o processo system_server foi reiniciado no dispositivo durante a execução do conjunto de testes. No postExecutionCheck ele chama deviceSoftRestarted que é definido em NativeDevice para verificar se o processo system_server foi reiniciado.
Cada operação retorna um StatusCheckerResult que permite ao chicote decidir se informações adicionais, como um relatório de bug, devem ser capturadas.
Onde eles são definidos no CTS?
Os verificadores de status do sistema CTS são definidos em: /test/suite_harness/tools/cts-tradefed/res/config/cts-system-checkers.xml
Como encontrar falhas no verificador
Por padrão, as falhas do verificador do sistema são exibidas apenas nos logs e como relatórios de bugs capturados para a invocação com o nome seguindo o formato: bugreport-checker-post-module-<module name>.zip
Isso permite que você descubra depois de qual módulo o relatório de bug foi gerado.
É possível fazer o relatório do verificador do sistema como uma falha de teste configurando a --report-system-checkers como true . Isso resultará em uma execução de teste mostrando como falha com o motivo da falha sendo a verificação específica do verificador de status.
Os verificadores de status do sistema (SSCs) são definidos na configuração de nível de suíte e executados entre cada módulo. Eles realizam verificações para determinar se o módulo mudou e não restaurou alguns estados, por exemplo, alterando um valor de propriedade do sistema.
Os SSCs são usados principalmente para garantir que os criadores de módulos não se esqueçam de limpar após seus testes; mas se o fizerem, forneça um rastro dele para que possa ser resolvido.
Um uso secundário é também restaurar o estado original quando possível, por exemplo, descartando o keyguard se ele for deixado aberto.
Definição XML do verificador de status do 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" />
Os SSCs são definidos na tag system_checker no XML de configuração Tradefed.
Implementação
Todo SSC deve implementar a interface ISystemStatusChecker , que fornece os dois métodos principais preExecutionCheck e postExecutionCheck executados antes e depois da execução de cada módulo.
É possível que um verificador implemente apenas um dos dois, ou implemente ambos se houver necessidade de verificar o estado antes do módulo e compará-lo com o estado após o módulo.
Existem várias implementações de exemplo no Tradefed. Recomenda-se que cada implementação se concentre em uma única verificação para melhorar a reutilização. Por exemplo, SystemServerStatusCheck verificará se o processo system_server foi reiniciado no dispositivo durante a execução do conjunto de testes. No postExecutionCheck ele chama deviceSoftRestarted que é definido em NativeDevice para verificar se o processo system_server foi reiniciado.
Cada operação retorna um StatusCheckerResult que permite ao chicote decidir se informações adicionais, como um relatório de bug, devem ser capturadas.
Onde eles são definidos no CTS?
Os verificadores de status do sistema CTS são definidos em: /test/suite_harness/tools/cts-tradefed/res/config/cts-system-checkers.xml
Como encontrar falhas no verificador
Por padrão, as falhas do verificador do sistema são exibidas apenas nos logs e como relatórios de bugs capturados para a invocação com o nome seguindo o formato: bugreport-checker-post-module-<module name>.zip
Isso permite que você descubra depois de qual módulo o relatório de bug foi gerado.
É possível fazer o relatório do verificador do sistema como uma falha de teste configurando a --report-system-checkers como true . Isso resultará em uma execução de teste mostrando como falha com o motivo da falha sendo a verificação específica do verificador de status.