AI 自动生成测试用例的边界与最佳实践

一、一个被反复提及的期待

“把需求丢给大模型，让它像真正的测试工程师一样思考：这个功能有哪些正常场景？边界值在哪里？异常路径怎么走？”这是近几年测试领域最常被讨论的设想之一。随着大模型能力的持续增强，许多团队开始尝试用 AI 自动生成测试用例，甚至有人提出：既然模型已经能理解需求，为什么不干脆让它一键产出所有用例？

这个问题的答案并不简单。AI 在测试用例生成上确实展现了令人惊喜的能力，但把它当作“终极解决方案”，往往会让人踩进成本、速度和覆盖确定性的三重陷阱。本文将从实际工程视角出发，分析 AI 与规则引擎各自的能力边界，并给出可落地的协同策略与 Prompt 设计经验。

二、AI 不能独自承担一切：三个硬约束

很多人初次接触 AI 生成用例时的第一反应是：“规则引擎出来的用例那么模板化、那么水，直接用大模型不就行了？”实际工程中，这个判断忽略了三个关键约束。

1. 成本：规模化后不可忽视

一份中等规模的需求文档，通常可以拆解出 20 到 50 个功能点。如果每个功能点都调用一次大模型，按常见的 API 计价区间估算，单次调用成本约 0.05 到 0.1 元，那么一份需求文档的生成成本就在 1 到 5 元之间。这看起来不多，但企业级项目动辄上千个需求，累积成本会迅速放大。更关键的是，很多标准场景（比如 CRUD、权限校验、常规边界值）本可以用零成本的方式覆盖，全部交给 AI 属于资源浪费。

2. 速度：交互体验的分水岭

大模型调用存在明显的延迟，通常在 5 到 30 秒之间，而规则引擎的处理时间往往是毫秒级。用户点击“生成”按钮后，等待 30 秒和等待 0.01 秒，体验完全不同。在高频使用的测试平台上，这种延迟会直接影响工程师的工作节奏，甚至导致工具被弃用。对于需要快速迭代的敏捷团队，速度往往是决定工具能否真正落地的关键因素。

3. 确定性覆盖：AI 的“随机性”是把双刃剑

规则引擎的最大优势在于确定性。对于 CRUD、权限控制、标准边界值这类场景，规则引擎可以保证 100% 覆盖，不会遗漏。而大模型本质上是概率生成模型，它的输出具有随机性。即使 Prompt 设计得再好，也不能保证每次都能完整覆盖所有标准场景。在测试领域，“可能漏掉”是一个致命的缺陷，因为漏测往往意味着线上事故。

三、重新定位：规则引擎保底，AI 锦上添花

基于上述三个约束，更合理的定位是：

• 规则引擎负责保底：快、免费、稳定、覆盖标准场景。它是测试用例生成的基础设施，确保核心场景不遗漏。
• AI 负责锦上添花：创意、深入、覆盖边缘场景。它擅长发现人类容易忽略的异常路径、组合场景和探索性测试点。

两者配合，才能在效率和成本之间取得平衡。规则引擎先快速产出标准用例，AI 在此基础上补充创意用例，最终由测试工程师进行审核和细化。这种分层策略既保证了覆盖率，又控制了成本和延迟。

四、Prompt 设计：决定 AI 生成质量的关键

需要强调的是，AI 并不是“丢一句话就完事”。Prompt 设计得好，生成的用例可以直接使用；设计得烂，生成的内容连看都不想多看一眼。经过多轮调优，尤其是加入历史参考用例进行风格对齐后，生成质量会有明显提升。以下是几个关键经验。

1. 明确角色与任务

Prompt 开头需要明确告诉模型它的角色和任务。例如：“你是一个专业的测试工程师，请根据以下需求生成测试用例。”这能让模型进入正确的上下文，避免生成泛泛而谈的内容。

2. 提供历史参考用例

这是提升生成质量最有效的手段之一。通过将历史用例作为上下文传入，模型可以学习团队的用例风格、字段命名习惯和覆盖粒度，从而生成更符合团队规范的用例。示例代码如下：

def _build_prompt(self, requirement: str, context: Optional[Dict] = None) -> str:
    base_prompt = f"""
    你是一个专业的测试工程师。请根据以下需求生成测试用例。
    ## 需求描述
    {requirement}
    ## 历史参考用例
    {json.dumps(context, ensure_ascii=False, indent=2) if context else "无"}
    ## 输出格式要求
    请按以下 JSON 格式输出:
    {{
      "test_cases": [
        {{
          "title": "用例标题",
          "description": "用例描述",
          "priority": "P0/P1/P2/P3",
          "type": "functional/api/performance/security",
          "preconditions": ["前置条件 1", "前置条件 2"],
          "steps": [
            {{
              "step": 1,
              "action": "操作步骤",
              "expected": "预期结果"
            }}
          ],
          "test_data": "测试数据",
          "automation": true/false
        }}
      ]
    }}
    ## 生成要求
    1. 覆盖正常场景和异常场景
    2. 包含边界条件测试
    3. 优先级合理分配（P0 核心功能，P1 重要功能，P2 一般功能，P3 边缘功能）
    4. 步骤清晰可执行
    """
    return base_prompt

3. 约束输出格式

结构化输出（如 JSON）便于后续程序化处理和入库。在 Prompt 中明确字段含义和取值规范，可以大幅减少解析失败的情况。

4. 强调场景覆盖

在生成要求中明确列出需要覆盖的场景类型：正常场景、异常场景、边界条件。这能引导模型系统性地思考，而不是只生成几条显而易见的用例。

5. 优先级与自动化标记

要求模型为每条用例分配优先级（P0-P3），并标记是否适合自动化。这为后续的用例管理和执行策略提供了依据。

五、人机协同的落地流程

一个可落地的 AI 辅助测试用例生成流程通常包含以下步骤：

1. 需求解析：将需求文档拆解为功能点，识别标准场景和复杂场景。
2. 规则引擎生成：对标准场景快速生成基础用例，保证覆盖率。
3. AI 补充生成：对复杂场景和边缘场景，调用 AI 生成创意用例，并传入历史用例作为参考。
4. 人工审核与细化：测试工程师对 AI 生成的用例进行审核，修正不合理之处，补充业务特定的测试数据。
5. 入库与执行：将通过审核的用例纳入用例库，按优先级和自动化标记安排执行。

这个流程的核心思想是：AI 是助手，不是替代者。测试工程师的专业判断仍然是质量保障的最后一道防线。

六、总结

AI 自动生成测试用例不是测试工程师的终极解决方案，而是一个强大的辅助工具。它在创意场景和边缘场景的挖掘上有独特优势，但在成本、速度和确定性覆盖上存在明显短板。规则引擎负责保底，AI 负责锦上添花，两者协同才能实现效率与质量的最优平衡。同时，Prompt 设计的质量直接决定了 AI 生成内容能否直接使用，历史用例的风格对齐是提升质量的关键手段。

对于测试团队而言，与其纠结“是否要用 AI”，不如思考“如何用好 AI”。建立分层生成策略、优化 Prompt 模板、保留人工审核环节，才是让 AI 真正融入测试工作流、持续产生价值的正确路径。