システムステータスの確認、システムステータスの確認、システムステータスの確認

システムステータスチェッカー(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は、Tradefed構成XMLのsystem_checkerタグの下で定義されます。

実装

すべてのSSCは、 ISystemStatusCheckerインターフェイスを実装する必要があります。これは、各モジュールの実行の前後に実行される2つの主要なメソッドpreExecutionCheckpostExecutionCheckを提供します。

チェッカーは、2つのうちの一方のみを実装するか、モジュールの前の状態をチェックしてモジュールの後の状態と比較する必要がある場合は両方を実装することができます。

Tradefedにはいくつかの実装例があります。各実装は、再利用性を向上させるために単一のチェックに焦点を当てることをお勧めします。たとえば、 SystemServerStatusCheckは、テストスイートの実行中にsystem_serverプロセスがデバイスで再起動したかどうかを確認します。 postExecutionCheckでは、 NativeDeviceで定義されているdeviceSoftRestartedを呼び出して、 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は、Tradefed構成XMLのsystem_checkerタグの下で定義されます。

実装

すべてのSSCは、 ISystemStatusCheckerインターフェイスを実装する必要があります。これは、各モジュールの実行の前後に実行される2つの主要なメソッドpreExecutionCheckpostExecutionCheckを提供します。

チェッカーは、2つのうちの一方のみを実装するか、モジュールの前の状態をチェックしてモジュールの後の状態と比較する必要がある場合は両方を実装することができます。

Tradefedにはいくつかの実装例があります。各実装は、再利用性を向上させるために単一のチェックに焦点を当てることをお勧めします。たとえば、 SystemServerStatusCheckは、テストスイートの実行中にsystem_serverプロセスがデバイスで再起動したかどうかを確認します。 postExecutionCheckでは、 NativeDeviceで定義されているdeviceSoftRestartedを呼び出して、 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は、Tradefed構成XMLのsystem_checkerタグの下で定義されます。

実装

すべてのSSCは、 ISystemStatusCheckerインターフェイスを実装する必要があります。これは、各モジュールの実行の前後に実行される2つの主要なメソッドpreExecutionCheckpostExecutionCheckを提供します。

チェッカーは、2つのうちの一方のみを実装するか、モジュールの前の状態をチェックしてモジュールの後の状態と比較する必要がある場合は両方を実装することができます。

Tradefedにはいくつかの実装例があります。各実装は、再利用性を向上させるために単一のチェックに焦点を当てることをお勧めします。たとえば、 SystemServerStatusCheckは、テストスイートの実行中にsystem_serverプロセスがデバイスで再起動したかどうかを確認します。 postExecutionCheckでは、 NativeDeviceで定義されているdeviceSoftRestartedを呼び出して、 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に設定することにより、システムチェッカーがテストの失敗自体としてレポートするようにすることができます。これにより、テスト実行が失敗したと表示され、失敗の理由はステータスチェッカーの特定のチェックになります。