スイートには複数のテスト モジュールが含まれる傾向があり、非常に大きなテスト コーパス サイズに達する可能性があります。たとえば、 Android 互換性テスト スイート (CTS)には、数百のモジュールと数十万のテスト ケースが含まれています。
分離が不十分であったり、デバイスが悪い状態になったりするために、大量のテストが失敗する可能性があります。
スイートの再試行機能は、これらのケースに対処することを目的としています。脆弱性や不十分な分離を排除するために、スイート全体ではなく失敗のみを再試行できます。テストが常に失敗する場合、再試行も失敗します。そして、本当の問題があるというより強いシグナルを受け取ります。
スイートの再試行を実装する
結果の再試行には、前の結果の読み取りと前の呼び出しの再実行が含まれます。
再試行を駆動する主なインターフェイスはITestSuiteResultLoaderで、以前の結果と以前のコマンド ラインを読み込むことができます。
RetryReschedulerは、この情報を使用して以前のコマンドを再作成し、いくつかのフィルターを設定して、以前の失敗または実行されなかったテストのみを再実行します。
スイートの再試行の例: CTS
CTS の再試行構成は次のとおりです。
<configuration description="Runs a retry of a previous CTS session.">
<object type="previous_loader" class="com.android.compatibility.common.tradefed.result.suite.PreviousResultLoader" />
<test class="com.android.tradefed.testtype.suite.retry.RetryRescheduler" />
<logger class="com.android.tradefed.log.FileLogger">
<option name="log-level-display" value="WARN" />
</logger>
</configuration>
これは、それを拡張するほとんどのスイート ( VTSなど) に適用できます)。
次の方法で呼び出されます。
cts-tradefed run retry --retry <session>
セッションは、CTS コンソールで以前の結果を一覧表示することで見つかります。
cts-tf > l r
Session Pass Fail Modules Complete Result Directory Test Plan Device serial(s) Build ID Product
0 2092 30 148 of 999 2018.10.29_14.12.57 cts [serial] P Pixel
正確な元のコマンドが再ロードされ、追加のフィルターで再実行されます。これは、元のコマンドにいくつかのオプションが含まれていた場合、それらも再試行の一部になることを意味します。
例えば：
cts-tradefed run cts-dev -m CtsGestureTestCases
上記の再試行は、常にCtsGestureTestCasesにバインドされます。これは、それのみを含むコマンドを再試行しているためです。
CTS スタイル スイートの再試行を構成する
再試行を機能させるには、以前の結果を proto 形式でエクスポートする必要があります。以下を追加する必要があります。
<result_reporter class="com.android.compatibility.common.tradefed.result.suite.CompatibilityProtoResultReporter" />
これをメイン コマンドの XML 構成に追加する必要があります。これにより、結果フォルダーにtest-record.pbファイルが作成されます。
次に、CTS 再試行は、 test-record.pbと既存のtest_result.xmlの組み合わせからデータをロードして、再試行の呼び出しを準備します。