告别XTS测试效率焦虑：用subplan、shard-count和retry命令精准打击失败项
告别XTS测试效率焦虑：用subplan、shard-count和retry命令精准打击失败项
在Android生态系统的质量保障体系中，XTS测试套件扮演着至关重要的角色。但对于每天面对数千个测试用例的工程师来说，最痛苦的莫过于看到测试控制台不断刷新的失败日志，以及随之而来的漫长排查过程。我曾见过一个团队花费整整三天时间，只为定位CTS测试中一组相机相关的间歇性失败。这种低效的调试方式，在追求快速迭代的现代开发流程中显得格格不入。
本文将分享一套经过实战验证的XTS效率优化方案，重点解析三个核心命令的组合应用：通过--subplan实现外科手术式的精准重测，利用--shard-count将测试时间压缩到原来的1/4，配合retry机制处理偶发性失败。这些技巧帮助我们将某旗舰项目的XTS整体验证周期从72小时缩短到9小时，同时将问题定位效率提升300%。
1. 测试失败项的精准打击策略
1.1 解剖subplan的XML手术刀
当面对包含200+失败项的测试报告时，传统重测整个模块的方式无异于用大炮打蚊子。subplan机制允许我们像外科医生一样精确切除问题部位。以下是一个实战中高频使用的subplan模板：
<?xml version='1.0' encoding='UTF-8' standalone='no' ?> <SubPlan version="2.0"> <!-- 典型的多架构失败案例 --> <Entry include="arm64-v8a CtsGraphicsTestCases android.graphics.cts.BitmapTest#testGetColor"/> <Entry include="armeabi-v7a CtsMediaTestCases android.media.cts.MediaCodecTest#testAvcBaselineProfile"/> <!-- 跨模块关联性失败 --> <Entry include="x86 CtsSecurityTestCases android.security.cts.SELinuxTest#testKernelSELinuxPolicy"/> <Entry include="x86_64 CtsWindowManagerTestCases android.server.wm.AlertWindowTests#testAlertWindowPolicy"/> </SubPlan>关键技巧：
- 架构标记必填：明确指定arm64-v8a/armeabi-v7a/x86/x86_64，避免多设备环境下的执行混乱
- 失败聚类：将相同root cause的失败项编组（如都涉及权限问题的case）
- 版本控制：建议文件名包含日期和版本（如
cts_fix_v12_20230815.xml）
实际项目中，我们通过自动化脚本将Jenkins失败的测试项自动生成subplan文件，节省了90%的手动整理时间。
1.2 动态subplan生成技巧
手动编写XML效率低下，这里分享一个Python脚本片段，可从测试结果自动生成subplan：
import xml.etree.ElementTree as ET from xml.dom import minidom def generate_subplan(failures): subplan = ET.Element("SubPlan", version="2.0") for arch, module, test in failures: ET.SubElement(subplan, "Entry", include=f"{arch} {module} {test}") rough = ET.tostring(subplan, 'utf-8') return minidom.parseString(rough).toprettyxml(indent=" ")典型应用场景：
- 从
test_result.xml解析失败项 - 按失败类型自动分组（崩溃/超时/断言失败）
- 与历史失败记录比对，标记复现问题
2. 并行化测试的艺术
2.1 shard-count的黄金分割点
--shard-count参数看似简单，实则暗藏玄机。通过大量实验，我们总结出不同设备规模的配置建议：
| 设备数量 | 推荐shard-count | 预期加速比 | 适用场景 |
|---|---|---|---|
| 2-4台 | 设备数×1.5 | 1.8-3.2x | 功能验证阶段 |
| 5-8台 | 设备数×1.2 | 3.5-5x | 每日构建验证 |
| 9+台 | 设备数×0.8 | 4-6x | 发布前全量测试 |
实际案例：在某次CTS验证中，使用10台设备设置--shard-count 8，测试时间从18小时降至3.2小时。但超过12个分片会导致设备资源争用，反而降低效率。
2.2 动态负载均衡方案
单纯的设备数量不等于并行效率，需要配合科学的任务分配策略：
按模块耗时预分组：
# 获取历史模块耗时数据 python analyze_results.py --time-report last_10_runs.json混合部署策略：
- 将长耗时模块（如CtsMediaTestCases）单独分配专用设备
- 短耗时模块合并分配到同一设备
- 动态调整分片数量（基于实时设备状态）
异常处理机制：
# 监控命令示例 adb devices | awk 'NR>1 {print $1}' | xargs -I {} adb -s {} shell dumpsys battery
3. 智能重试机制设计
3.1 retry命令的进阶用法
常规的run retry --retry <session_id>只能解决简单问题，我们开发了多层重试策略：
基础重试（适用于偶发失败）：
run retry --retry 42 --disable-reboot带环境重置的重试：
run retry --retry 42 --precondition-check-level medium组合重试策略：
# 先尝试快速重试 run retry --retry 42 --skip-preconditions # 若仍失败则完整重跑 run retry --retry 42 --retry-type full
3.2 失败模式识别系统
建立失败特征库，自动匹配最佳重试策略：
| 失败特征 | 推荐策略 | 成功率提升 |
|---|---|---|
| JNI崩溃 | 带环境重置的重试 | 85% |
| 超时 | 增加超时阈值+快速重试 | 72% |
| 资源竞争 | 隔离设备执行 | 68% |
| 权限问题 | 重置权限数据库+完整重试 | 91% |
实现代码片段：
def select_retry_strategy(error_log): if "SIGSEGV" in error_log: return "--retry-type full --precondition-check-level high" elif "Timeout" in error_log: return "--retry-type quick --test-timeout-multiplier 2" else: return "--retry-type standard"4. 实战中的组合拳应用
4.1 典型问题处理流程
场景：CTS验证中发现32个失败项，涉及5个不同模块
快速分类：
# 提取关键错误特征 grep -r "FAILED" results/ | awk -F'[()]' '{print $2}' | sort | uniq -c分级处理：
- 15个相同错误：创建针对性subplan
- 10个偶发失败：启用智能重试
- 7个新问题：隔离设备单独调试
并行执行：
# 在4台设备上并行处理 run cts --subplan critical_fixes.xml --shard-count 4 & run retry --retry 43 --shard-count 2 &
4.2 效率提升数据对比
某项目实际优化效果：
| 指标 | 优化前 | 优化后 | 提升幅度 |
|---|---|---|---|
| 单次完整测试耗时 | 72小时 | 9小时 | 87.5% |
| 失败项定位时间 | 4小时/项 | 50分钟/项 | 79.2% |
| 设备利用率 | 35% | 82% | 134% |
| 人工干预频率 | 每2小时 | 每8小时 | 75% |
这套方法在Android S及后续版本中表现尤为突出，特别是针对CTS-V和GTS的复杂测试场景。一个鲜为人知的技巧是结合--skip-preconditions和subplan使用，可以绕过不必要的环境检查，进一步节省15-20%的时间成本。