第四章：测试用例结构设计

好，咱们进入第四章。这一章我特别想跟你聊聊——测试用例到底该怎么搭骨架。

你可能写过不少测试用例，但有没有想过：为什么有的用例一看就懂，有的却让人摸不着头脑？为什么有的用例能复用，有的只能写一次就扔？

说白了，就是结构设计的问题。

4.1 测试用例的组成要素

先说说一个完整的测试用例，到底该包含哪些东西。

我个人习惯把测试用例拆成三块：

• 标识信息——用例ID、名称、所属模块、版本号
• 执行信息——前置条件、测试步骤、预期结果
• 管理信息——作者、创建日期、优先级、标签

你可能会说：「这不就是标准模板吗？」对，但问题在于——很多人只填了前两块，第三块直接忽略。

我在项目中遇到过一件事：一个同事写了200条用例，全都没有优先级和标签。结果项目后期要回归测试，根本不知道先跑哪些。最后只能全部重跑，浪费了整整两天时间。

在CarMaker里，我通常这样组织用例要素：

# 用例模板示例
用例ID: CM_ACC_001
名称: 自适应巡航-前车切入场景
模块: ADAS/ACC
优先级: P0
前置条件: 自车速度60km/h，目标车道无车
步骤:
  1. 设置自车巡航速度80km/h
  2. 旁车道车辆以50km/h速度切入
  3. 保持切入后两车距离30m
预期结果: 自车自动减速至50km/h，保持安全跟车距离
标签: 功能测试, 场景测试, 高速

4.2 参数化设计思想

好，要素讲完了。接下来是重点——参数化。

为什么要参数化？你想想看，如果每个测试用例都写死一个值，比如「自车速度60km/h」，那你要测50km/h、70km/h、90km/h怎么办？

写三条用例？那如果还要测不同切入角度、不同相对速度呢？

嗯，这里要注意——用例数量会爆炸。

参数化的核心思想就一句话：把固定的值变成变量。

我举个例子：

# 非参数化（不推荐）
测试场景: 前车以50km/h匀速行驶，自车以60km/h跟车
测试场景: 前车以60km/h匀速行驶，自车以70km/h跟车
测试场景: 前车以70km/h匀速行驶，自车以80km/h跟车

# 参数化（推荐）
参数: 自车速度 = [60, 70, 80]
参数: 前车速度 = [50, 60, 70]
测试场景: 前车以{前车速度}km/h匀速行驶，自车以{自车速度}km/h跟车

你看，三条用例变成了一条用例加两个参数。如果我要加更多速度组合，只需要往参数列表里加值就行。

4.3 数据驱动测试模式

参数化是思想，数据驱动是落地方式。

什么叫数据驱动？说白了就是：测试逻辑写一次，测试数据单独管理。

在CarMaker里，我通常这样实现：

# 测试脚本（只写一次）
def run_test_case(test_data):
    # test_data 包含所有参数
    ego_speed = test_data['ego_speed']
    target_speed = test_data['target_speed']
    distance = test_data['distance']
    
    # 执行测试逻辑
    setup_scenario(ego_speed, target_speed, distance)
    run_simulation()
    check_result()

# 测试数据（单独管理）
test_data_list = [
    {'ego_speed': 60, 'target_speed': 50, 'distance': 30},
    {'ego_speed': 70, 'target_speed': 60, 'distance': 40},
    {'ego_speed': 80, 'target_speed': 70, 'distance': 50},
]

# 批量执行
for data in test_data_list:
    run_test_case(data)

这样做的好处很明显：

• 测试逻辑复用——改一个地方，所有用例都生效
• 数据易维护——加新场景只需要加数据，不用改代码
• 可追溯——每条用例的数据来源清晰，出了问题能快速定位

我记得有一次，客户要求把测试覆盖范围扩大一倍。如果是传统写法，我得改几十个脚本。但因为用了数据驱动，我只花了10分钟在数据文件里加了20行参数，就搞定了。

4.4 知识体系总览

说了这么多，咱们用一张图把这三块串起来：

4.5 实战中的避坑指南

最后，分享几个我踩过的坑：

1. 别把所有参数都参数化——有些参数是固定的，比如道路类型、天气条件。强行参数化只会增加复杂度。
2. 数据文件要有版本控制——我曾经因为数据文件被覆盖，导致整个测试批次结果异常。后来所有数据文件都纳入Git管理。
3. 参数取值范围要合理——不是所有组合都有意义。比如「自车速度200km/h + 前车速度10km/h」这种极端组合，测了也没用。
4. 别忘了边界值——参数化容易让人只关注「正常值」，而忽略边界。我习惯在参数列表里手动加入边界值。

好了，这一章就到这里。测试用例的结构设计，说白了就是三个字——搭骨架。骨架搭好了，后面的批量生成、自动化执行才能跑得起来。

---