告别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参数看似简单，实则暗藏玄机。通过大量实验，我们总结出不同设备规模的配置建议：

实际案例：在某次CTS验证中，使用10台设备设置--shard-count 8，测试时间从18小时降至3.2小时。但超过12个分片会导致设备资源争用，反而降低效率。

2.2 动态负载均衡方案

单纯的设备数量不等于并行效率，需要配合科学的任务分配策略：

1. 按模块耗时预分组：

   # 获取历史模块耗时数据 python analyze_results.py --time-report last_10_runs.json

2. 混合部署策略：

   • 将长耗时模块（如CtsMediaTestCases）单独分配专用设备
   • 短耗时模块合并分配到同一设备
   • 动态调整分片数量（基于实时设备状态）

3. 异常处理机制：

   # 监控命令示例 adb devices | awk 'NR>1 {print $1}' | xargs -I {} adb -s {} shell dumpsys battery

3. 智能重试机制设计

3.1 retry命令的进阶用法

常规的run retry --retry <session_id>只能解决简单问题，我们开发了多层重试策略：

1. 基础重试（适用于偶发失败）：

   run retry --retry 42 --disable-reboot

2. 带环境重置的重试：

   run retry --retry 42 --precondition-check-level medium

3. 组合重试策略：

   # 先尝试快速重试 run retry --retry 42 --skip-preconditions # 若仍失败则完整重跑 run retry --retry 42 --retry-type full

3.2 失败模式识别系统

建立失败特征库，自动匹配最佳重试策略：

实现代码片段：

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个不同模块

1. 快速分类：

   # 提取关键错误特征 grep -r "FAILED" results/ | awk -F'[()]' '{print $2}' | sort | uniq -c

2. 分级处理：

   • 15个相同错误：创建针对性subplan
   • 10个偶发失败：启用智能重试
   • 7个新问题：隔离设备单独调试

3. 并行执行：

   # 在4台设备上并行处理 run cts --subplan critical_fixes.xml --shard-count 4 & run retry --retry 43 --shard-count 2 &

4.2 效率提升数据对比

某项目实际优化效果：

这套方法在Android S及后续版本中表现尤为突出，特别是针对CTS-V和GTS的复杂测试场景。一个鲜为人知的技巧是结合--skip-preconditions和subplan使用，可以绕过不必要的环境检查，进一步节省15-20%的时间成本。