| name | adb-vehicle-testing |
| description | 基于 ADB 的 Android/车机实车测试技能。USE FOR: 根据需求文档和测试用例执行真机/实车测试，采集 adb shell、logcat、dumpsys、截图与录屏证据，输出结构化测试报告。关键词: adb、实车测试、车机测试、真机测试、Android Automotive、测试报告、requirements、test cases。 |
| globs | ["**/*.md","**/*.yaml","**/*.json"] |
ADB 实车测试 Skill
本 Skill 用于把“需求文档 + 测试用例”转成一轮可执行的 ADB 实车测试流程，并最终产出一份结构化测试报告。
适用场景：
- Android 车机 / Android Automotive / 带 adb 能力的 Android 终端
- 输入已有需求文档和测试用例
- 需要边执行边采集系统证据，并沉淀为正式报告
不适用场景：
- 无 adb 连接能力
- 纯后端接口测试
- 需要 HIL 台架控制但当前环境没有相关控制链路
1. 输入与输出
输入
requirements_doc: 需求文档路径test_cases_doc: 测试用例文档路径target_package: 待测应用包名，可选target_activity: 启动 Activity，可选device_id: adb 设备序列号，可选；多设备时必填artifacts_dir: 测试证据输出目录，可选，默认 runs/adb-vehicle-test-<timestamp>/
输出
TEST_REPORT.md: 测试报告summary.json: 结构化测试结果摘要artifacts/:
device_info.txtlogcat.txtdumpsys_<service>.txtscreenshots/screenrecords/bugreports/（如需要）
2. 执行原则
2.1 安全优先
- 涉及车辆行驶状态的测试，默认要求车辆静止、驻车并满足现场安全条件
- 涉及驾驶、安全、制动、转向、ADAS、OTA 等能力时，先在报告中明确测试边界
- 不具备安全前提时，不执行高风险动作，只输出阻塞原因与待确认项
2.2 证据先于结论
- 每个测试结论必须尽量绑定至少一种证据：logcat、截图、录屏、dumpsys、界面观察记录
- 无证据时，可记录“人工观察通过/失败”，但必须在报告里显式标记置信度较低
2.3 需求可追溯
- 每条测试结果都要回链到需求编号和测试用例编号
- 报告中必须包含“需求 -> 用例 -> 结果 -> 证据”矩阵
3. 标准流程
Step 1: 解析输入
从需求文档中提取：
从测试用例中提取：
- 用例编号
- 用例标题
- 前置条件
- 操作步骤
- 预期结果
- 优先级
如果文档缺字段，先在报告中生成“输入缺口”小节，不要自行编造。
Step 2: 建立测试会话目录
建议目录结构：
runs/adb-vehicle-test-<timestamp>/
TEST_REPORT.md
summary.json
artifacts/
device_info.txt
logcat.txt
screenshots/
screenrecords/
bugreports/
Step 3: 检查 adb 与设备状态
优先执行：
adb devices -l
adb -s <device_id> get-state
adb -s <device_id> shell getprop ro.build.fingerprint
adb -s <device_id> shell getprop ro.product.model
adb -s <device_id> shell getprop ro.build.version.release
adb -s <device_id> shell settings get global device_name
记录：
- 设备 ID
- 型号
- Android 版本
- 构建指纹
- 当前连接状态
如存在多个设备且未指定 device_id，立即停止执行并提示用户指定目标设备。
Step 4: 准备日志与证据采集
执行前建议：
adb -s <device_id> logcat -c
adb -s <device_id> shell date
adb -s <device_id> shell dumpsys activity activities
adb -s <device_id> shell dumpsys window windows
长日志采集建议异步：
adb -s <device_id> logcat -v threadtime
需要界面证据时：
adb -s <device_id> exec-out screencap -p > screenshot.png
adb -s <device_id> shell screenrecord /sdcard/test_case.mp4
adb -s <device_id> pull /sdcard/test_case.mp4 ./screenrecords/
Step 5: 执行用例
逐条执行测试用例，并按以下粒度记录：
PASS: 实际结果符合预期FAIL: 实际结果不符合预期BLOCKED: 环境、权限、依赖、硬件条件不满足NOT_RUN: 本轮未执行
每条用例至少记录：
- 需求编号
- 用例编号
- 前置条件是否满足
- 实际步骤摘要
- 实际结果
- 结论
- 证据路径
Step 6: 采集故障信息
失败用例建议追加：
adb -s <device_id> shell dumpsys activity top
adb -s <device_id> shell dumpsys package <target_package>
adb -s <device_id> shell pidof <target_package>
adb -s <device_id> bugreport
若关注性能，可补充：
adb -s <device_id> shell dumpsys meminfo <target_package>
adb -s <device_id> shell dumpsys gfxinfo <target_package>
adb -s <device_id> shell top -n 1
Step 7: 输出报告
报告必须包含：
- 测试范围
- 设备与环境
- 用例执行结果汇总
- 逐条用例明细
- 缺陷与风险
- 需求覆盖情况
- 结论与建议
优先使用本 Skill 附带模板：
templates/TEST_REPORT_TEMPLATE.mdtemplates/CASE_RESULT_TEMPLATE.md
4. 推荐命令清单
4.1 连接与设备识别
adb devices -l
adb -s <device_id> get-state
adb -s <device_id> shell getprop
4.2 应用生命周期
adb -s <device_id> shell am start -n <package>/<activity>
adb -s <device_id> shell am force-stop <package>
adb -s <device_id> shell monkey -p <package> -c android.intent.category.LAUNCHER 1
4.3 输入注入
adb -s <device_id> shell input tap <x> <y>
adb -s <device_id> shell input swipe <x1> <y1> <x2> <y2> <duration_ms>
adb -s <device_id> shell input text '<text>'
adb -s <device_id> shell input keyevent <keycode>
4.4 系统状态采集
adb -s <device_id> shell dumpsys activity
adb -s <device_id> shell dumpsys window
adb -s <device_id> shell dumpsys package <package>
adb -s <device_id> shell dumpsys meminfo <package>
adb -s <device_id> shell dumpsys gfxinfo <package>
4.5 日志与证据
adb -s <device_id> logcat -c
adb -s <device_id> logcat -d
adb -s <device_id> exec-out screencap -p
adb -s <device_id> shell screenrecord /sdcard/<name>.mp4
adb -s <device_id> pull /sdcard/<name>.mp4 <local_path>
5. 报告生成要求
生成 TEST_REPORT.md 时，遵守以下规则：
- 先给执行摘要，再给逐条明细
- 所有失败项必须有“现象 + 预期 + 初步定位 + 证据”
- 所有阻塞项必须写清楚阻塞原因和解阻条件
- 不确定的结论使用“待确认”，不要伪造 PASS
- 结论必须显式区分：功能结果、稳定性结果、风险结果
summary.json 至少包含：
{
"session_id": "adb-vehicle-test-20260411-120000",
"device_id": "emulator-5554",
"package": "com.example.app",
"total_cases": 10,
"passed": 8,
"failed": 1,
"blocked": 1,
"not_run": 0,
"report_path": "runs/adb-vehicle-test-20260411-120000/TEST_REPORT.md"
}
6. 使用方式
当用户请求“基于需求文档和测试用例做 adb 实车测试并输出测试报告”时：
- 读取需求文档和测试用例
- 建立需求与用例映射
- 检查 adb 连接与目标设备
- 建立证据采集目录
- 逐条执行或半自动辅助执行用例
- 生成
TEST_REPORT.md 和 summary.json
如果当前环境没有真实设备或不能执行 adb：
- 仍可先生成“测试执行计划 + 报告骨架”
- 明确标记为
Dry Run 或 Pending Device Execution
7. 最终输出格式
最终对用户回复时，优先包含：
- 本轮测试范围
- 设备信息
- 执行结果统计
- 关键失败/阻塞项
- 报告路径
不要只给口头结论，必须落地生成报告文件。
