自 2025 年 3 月 27 日起,我们建议您使用 android-latest-release
而非 aosp-main
构建 AOSP 并为其做出贡献。如需了解详情,请参阅 AOSP 的变更。
使用“套件重试”功能
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
套件往往包含多个测试模块,测试语料库也会变得相当大。例如,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>
这适用于扩展 CTS 的大多数套件,例如 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
,因为我们重试的是一个只涉及它的命令。
为使重试正常工作,需要以 proto 格式导出先前的结果。需要添加以下内容:
<result_reporter class="com.android.compatibility.common.tradefed.result.suite.CompatibilityProtoResultReporter" />
此内容需要添加到主命令的 XML 配置,这将导致在结果文件夹中创建 test-record.pb
文件。
然后,CTS 重试将从 test-record.pb
和现有 test_result.xml
的组合加载数据以准备重试调用。
本页面上的内容和代码示例受内容许可部分所述许可的限制。Java 和 OpenJDK 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC):2025-03-26。
[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["没有我需要的信息","missingTheInformationINeed","thumb-down"],["太复杂/步骤太多","tooComplicatedTooManySteps","thumb-down"],["内容需要更新","outOfDate","thumb-down"],["翻译问题","translationIssue","thumb-down"],["示例/代码问题","samplesCodeIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC):2025-03-26。"],[],[],null,["# Use suite retry\n\nA suite tends to include several test modules and can reach quite a large\ntest corpus size. For example, the [Android Compatibility Test Suite (CTS)](/docs/compatibility/cts)\nincludes hundreds of modules and hundreds of thousands test cases.\n\nIt becomes possible for a large amount of tests to fail due to poor isolation\nor devices going into a bad state.\n\nThe suite retry feature is meant to address those cases: It lets you retry\nthe failures only instead of the full suites in order to rule out flakiness and\npoor isolation. If a test is consistently failing, the retry also fails; and\nyou get a much stronger signal that there's a real issue.\n\nImplement suite retry\n---------------------\n\nThe retry of results involves reading the previous results and rerunning the\nprevious invocation.\n\nThe main interface driving the retry is [`ITestSuiteResultLoader`](https://android.googlesource.com/platform/tools/tradefederation/+/refs/heads/android16-release/src/com/android/tradefed/testtype/suite/retry/ITestSuiteResultLoader.java),\nwhich lets you load a previous result, and the previous command line.\n\n[`RetryRescheduler`](https://android.googlesource.com/platform/tools/tradefederation/+/refs/heads/android16-release/src/com/android/tradefed/testtype/suite/retry/RetryRescheduler.java)\nthen uses this information to recreate the previous command and populate some\nfilters in order to rerun only the previous failures or not executed tests.\n\nExample suite retry: CTS\n------------------------\n\nThe retry configuration in CTS is: \n\n \u003cconfiguration description=\"Runs a retry of a previous CTS session.\"\u003e\n \u003cobject type=\"previous_loader\" class=\"com.android.compatibility.common.tradefed.result.suite.PreviousResultLoader\" /\u003e\n \u003ctest class=\"com.android.tradefed.testtype.suite.retry.RetryRescheduler\" /\u003e\n\n \u003clogger class=\"com.android.tradefed.log.FileLogger\"\u003e\n \u003coption name=\"log-level-display\" value=\"WARN\" /\u003e\n \u003c/logger\u003e\n \u003c/configuration\u003e\n\nThis is applicable to most of the suites that extend it, for example\n[VTS](/docs/core/tests/vts).\n\nIt would be invoked with: \n\n cts-tradefed run retry --retry \u003csession\u003e\n\nThe session would be found by listing the previous results in the CTS console: \n\n cts-tf \u003e l r\n Session Pass Fail Modules Complete Result Directory Test Plan Device serial(s) Build ID Product\n 0 2092 30 148 of 999 2018.10.29_14.12.57 cts [serial] P Pixel\n\nThe exact original command will be reloaded and rerun with extra filters. This\nmeans that if your original command included some options, they are also\npart of the retry.\n\nFor example: \n\n cts-tradefed run cts-dev -m CtsGestureTestCases\n\nThe retry of the above is always bound to `CtsGestureTestCases` because\nwe are retrying a command that involved only it.\n\nConfigure retry for CTS-style suite\n-----------------------------------\n\nIn order for the retry to work, the previous results need to be exported in\nproto format. The following needs to be added: \n\n \u003cresult_reporter class=\"com.android.compatibility.common.tradefed.result.suite.CompatibilityProtoResultReporter\" /\u003e\n\nThis needs to be added to the XML configuration of the main command, and it\nresults in a `test-record.pb` file being created in the result folder.\n\nThe CTS retry then loads data from a combination of the `test-record.pb` and\nthe existing `test_result.xml` to prepare the retry invocation."]]