📚 课程目录第4章 VTS测试执行流程

4. VTS 测试执行流程：测试用例选择、测试执行命令、测试结果输出与解读

VTS (Vendor Test Suite) 测试执行是 HAL 层开发与验证的核心环节。本章节将系统讲解从测试用例选择、命令执行到结果解析的完整流程，帮助开发者精准定位 HAL 层问题。

4.1 测试用例选择策略

VTS 测试用例的选择直接影响验证效率与覆盖范围。根据测试目标，通常采用以下三种策略：

策略类型	适用场景	选择命令/方法	覆盖范围
模块级全量	HAL 模块首次集成或重大重构后	`run vts -m <module_name>`	该模块所有测试用例
用例级精准	修复特定 HAL 接口后回归验证	`run vts -m <module> -t <test_case>`	单个或少数关联用例
计划级组合	版本发布前的合规性验证	`run vts -p <plan_name>`	预定义的测试计划集合

实践建议：在 HAL 层补丁验证阶段，优先使用用例级精准策略，仅执行与修改接口相关的失败用例，可大幅缩短验证周期。待补丁稳定后，再执行模块级全量测试确保无回归。

4.2 测试执行命令详解

VTS 测试基于 TradeFed 自动化测试框架，核心命令格式如下：

# 基本命令格式
run vts [options]

# 常用参数组合
run vts -m android.hardware.camera.provider -t CameraProviderTest#testOpenCamera

# 带重试与日志级别的执行
run vts -m android.hardware.audio -t AudioTest#testRecord --retry 3 --log-level VERBOSE

# 指定测试计划（适用于 CTS/VTS 联合验证）
run vts -p vts10 -s <device_serial>

关键参数说明：

-m / --module：指定测试模块名称，对应 HAL 接口的测试套件
-t / --test：指定具体测试用例，格式为 类名#方法名
--retry：失败后自动重试次数，默认 0
--log-level：日志输出级别，DEBUG/VERBOSE 可获取更详细的 HAL 调用栈
-s：指定设备序列号，多设备测试时必填

常见错误：执行 run vts 前未设置 ANDROID_PRODUCT_OUT 环境变量，或设备未正确进入 adb 模式，会导致 "Device not found" 错误。请确保执行 source build/envsetup.sh && lunch <target> 完成环境初始化。

4.3 测试结果输出结构

VTS 测试完成后，结果以结构化目录形式输出，默认路径为 /tmp/test_result/<timestamp>/。核心文件与目录如下：

4.4 测试结果解读方法

4.4.1 test_result.xml 关键字段

打开 test_result.xml，核心结构如下：

<?xml version="1.0" encoding="utf-8"?>
<TestResult>
  <Summary>
    <Passed>42</Passed>
    <Failed>3</Failed>
    <Skipped>1</Skipped>
    <Total>46</Total>
  </Summary>
  <Module name="android.hardware.audio">
    <TestCase name="AudioTest">
      <Test name="testRecord" result="fail">
        <Failure message="java.lang.AssertionError: Expected: not null, but was: null">
          <StackTrace>
            at android.hardware.audio.VtsHalAudioTest.testRecord(AudioTest.java:142)
            at android.hardware.audio.AudioHalWrapper.getRecordBuffer(AudioHalWrapper.java:87)
          </StackTrace>
        </Failure>
      </Test>
    </TestCase>
  </Module>
</TestResult>

解读要点：

Summary 统计：快速了解整体通过率，Failed 数量是重点关注对象
Failure message：直接描述断言失败原因，如 Expected: not null, but was: null 表示 HAL 返回了空指针
StackTrace：调用栈信息，从测试框架层向下追溯到 HAL 实现层，是定位代码行的关键

4.4.2 日志文件分析路径

日志文件	内容特征	HAL 层分析价值
`device_logcat/invocation_logcat.txt`	设备端完整 logcat，包含 HAL 服务进程日志	定位 HAL 服务崩溃、ANR、权限拒绝等运行时错误
`host_log/invocation.log`	Host 端 TradeFed 执行日志	查看测试用例调度过程、设备连接状态、超时信息
`instrumentation_output/<test_case>.txt`	单个用例的详细 instrumentation 输出	获取 HAL 接口调用的参数与返回值细节

  实战技巧：当 test_result.xml 中 Failure message 不够明确时，使用 grep -rn "ERROR\|FATAL\|CRASH" device_logcat/invocation_logcat.txt 快速过滤 HAL 层异常日志。对于 native 崩溃，重点关注 libc 或 signal 11 (SIGSEGV) 相关条目。

4.5 测试执行流程全景图

以下 SVG 图展示了从用例选择到结果解读的完整执行流程：

4.6 常见结果状态与处理建议

结果状态	含义	HAL 层常见原因	处理建议
pass	测试通过	—	无需处理
fail	断言失败或异常抛出	HAL 返回错误码、空指针、数据格式不匹配	分析 StackTrace 定位 HAL 实现行，检查返回值与契约一致性
skip	测试被跳过	HAL 功能未实现、设备不支持、条件不满足	检查 `android.hardware.<module>.feature` 配置，确认 HAL 版本声明
assume_failure	前提条件不满足	HAL 服务未注册、权限未授予、依赖模块缺失	检查 `device_logcat` 中服务注册日志，确认 HAL 服务正常启动

效率提升：在 HAL 层补丁验证阶段，建议编写自动化脚本解析 test_result.xml，自动提取 fail 用例的 Failure message 和 StackTrace，并关联到对应的 HAL 源码文件。例如使用 Python 的 xml.etree.ElementTree 库进行解析，可大幅减少人工翻阅日志的时间。