AI生成测试用例实战：提示词工程与结构化输出设计

简介：面向测试工程师的AI生成测试用例系统源码，以Python实现，聚焦从PDF/Word文档中自动提取文本、表格和图片内容，并通过多LLM平台集成与定制提示词生成多样化测试用例。系统涵盖文档结构解析、pytesseract与PaddleOCR图片识别、嵌套表格解析、JSON/Excel/XMind格式转换、token消耗统计与用例分布分析，适合希望用大模型技术提升测试自动化效率的研发和测试人员。资源共13个文件，以Python脚本为主，包含5个py文件，另有配置文件、前端HTML/CSS/JS、依赖清单及说明文档，压缩包仅24KB，结构轻量便于直接阅读和二次开发。目前已有309人学习下载。读者可基于源码搭建自己的智能测试用例生成流程，理解文档解析、OCR、多模型调参与格式转换的完整链路，也可参考其中提示词设计和参数调整思路，快速应用于实际项目中的用例设计与测试管理。 最近在折腾AI生成测试用例技术，前后写了五版源码，把一个“把需求丢给大模型、让它输出测试用例”的粗糙想法，落地成了能直接对接测试管理平台的工具。整个过程踩的坑不少，但沉淀下来的这套方案，可以稳定生成结构化的功能测试用例、接口测试用例，甚至能挖出一部分安全角度的用例（比如针对登录接口的注入类场景）。这篇文章把我的完整设计思路、源码实现和排查经验一次性讲清楚，给正在做AI辅助编写测试用例、或者想自建AI测试用例生成平台的朋友一份参考。

先说结论：AI生成测试用例这件事，真正的难点不在调用大模型，而在怎么设计提示词、怎么定义输出结构、怎么验证生成质量。这三个问题想清楚了，工具半天就能搭出第一版，剩下的精力全部用来打磨和避坑。

1. 整体设计与方案选型：为什么AI替代的是一部分测试设计工作

1.1 测试用例生成场景的核心难点

测试用例本质上是从“需求描述”到“验证路径”的一组映射。手工编写时，我们依赖业务经验、历史缺陷和测试设计方法，把一句话需求拆成正常流、异常流、边界条件、数据约束等维度。

这个过程的难点在于信息提取和逻辑推导，正好是大模型擅长的。比如一条需求是“用户可以使用手机号和验证码登录”，老测试会想到：

• 手机号格式校验（11位、以1开头）
• 验证码有效期、错误验证码
• 频繁发送验证码的风控限制
• 正确的验证码过期后是否还能用
• 接口层面是否存在注入风险

大模型只要被正确引导，也能完成类似推导。但它有两个天然短板：一是缺少真实业务上下文，容易生成“正确的废话”；二是风格不稳定，可能两次生成的结果差异很大。所以方案设计的核心，就是通过提示词和结构化约束，把这两个短板拉回来。

1.2 三条技术路线：提示词工程、微调模型还是Agent编排

我调研了三类技术路线，实际对比后选了性价比最高的一种：

我最终选了“提示词工程+轻量Agent编排”，先让AI生成测试用例，后面再接自动化执行。这里多说一句：很多团队一上来就想微调模型，但微调前连一百条高质量“种子用例”都凑不齐，效果反而很差。提示词先把流程跑通，等积累了几千条经过验证的用例，再考虑微调，路径会更稳。

2. 核心细节拆解：好的AI用例生成器，赢在提示词和输出结构

2.1 先定义机器可读的用例结构，再让AI去生成

这是我在第一版踩的最大坑：直接让AI“生成测试用例”，它给你输出一长串Markdown格式的文本，读起来像那么回事，但计算机没法直接解析，想接入测试平台还得做大量清洗。

正确做法是先定义统一的用例数据模型，让AI往这个结构里填内容。我用的字段是这样一套：

{ "case_id": "LOGIN_001", "module": "登录模块", "title": "验证手机号格式不正确时登录失败", "preconditions": "用户未登录，处于登录页面", "steps": ["输入错误格式手机号12345", "输入正确验证码", "点击登录按钮"], "test_data": "手机号=12345，验证码=123456", "expected_result": "提示手机号格式不正确，登录失败", "priority": "P1", "case_type": "功能测试", "design_method": "等价类划分" }

把“生成用例”变成“生成JSON对象”，后面的入库、去重、统计全部变成了普通的数据处理。这里有个小技巧：提示词里要写明白每个字段的取值规范。比如priority只能从P0/P1/P2里选，case_type只能从“功能测试/接口测试/安全测试/边界测试”里选，否则模型就会自由发挥，给你整出一堆无法统计的杂数据。

2.2 提示词分层设计，四层结构缺一不可

提示词我分了四层，每一层解决一个独立问题：

• 第一层，角色设定。告诉模型“你是一名有10年经验的测试开发工程师”，约束它的专业视角。
• 第二层，业务上下文。把需求文档、接口定义、页面描述等输入信息放进来，并明确业务规则。
• 第三层，设计方法指令。显式要求模型使用等价类划分、边界值分析、错误推测法、场景法等来设计用例。这一步非常关键，不写的话模型默认只用“正常流+一条异常流”的简单套路。
• 第四层，输出约束。规定输出为JSON数组、字段名大小写、枚举值范围、用例条数上限。

一个简化版的提示词模板长这样：

TEST_CASE_PROMPT = """ 你是一名资深测试开发工程师，请根据以下需求为{module}模块设计测试用例。 ## 需求描述 {requirement_text} ## 业务规则 {business_rules} ## 设计要求 1. 使用等价类划分、边界值分析、错误推测法设计用例 2. 覆盖正常流程、异常流程、边界条件、数据校验场景 3. 涉及接口时，考虑安全角度的输入校验场景 4. 每个用例的测试数据必须是具体值，不允许写“合法数据”“非法数据”这类占位 ## 输出格式 你必須输出一个JSON数组，数组内每个元素包含以下字段： case_id, module, title, preconditions, steps, test_data, expected_result, priority, case_type, design_method 其中priority只能取P0/P1/P2，case_type只能取功能测试/接口测试/安全测试/边界测试。 总共生成不超过{max_cases}条用例，直接输出JSON，不要输出Markdown代码块。 """

2.3 输入信息越结构化，生成结果越可用

大模型本质上是在做概率预测，输入的信息越明确，输出就越稳定。同样是“用户登录”这个需求，纯文本描述“用户可以使用手机号和验证码登录”和结构化描述“登录接口POST /api/login，入参phone（string，11位手机号）、code（string，6位验证码），验证码有效期5分钟，同一手机号60秒内只能发送一次”，生成的结果质量完全不同。

实操中我会把接口文档的关键信息（路径、请求方法、入参、出参、校验规则）拼到需求文本后面，再让AI生成测试用例。这样不仅功能用例能生成，还能顺带产出接口测试用例，甚至能识别出SQL注入、越权这类安全场景的测试输入。

注意：不要把未经脱敏的生产环境数据直接塞给大模型接口。建议先用脱敏后的需求快照测试，或者在内网部署的模型环境中跑。

3. 实操落地：一份可直接运行的Python源码方案

3.1 环境准备与依赖安装

我用的是Python 3.10，配合openai库调用兼容OpenAI格式的通用大模型API。之所以强调“兼容OpenAI格式”，是因为现在不少模型服务商都提供了OpenAI兼容端点，换模型时只需要改base_url和api_key，代码可以不用动。

pip install openai==1.35.0 python-dotenv

代码里我用环境变量管理密钥，避免把敏感信息硬编码到源码里。

3.2 核心源码实现：测试用例生成器

下面这段代码是整个工具的心脏。功能很简单：读一段需求文本，拼好提示词，调用模型，把返回的JSON解析成用例列表。

import json import os from openai import OpenAI from dotenv import load_dotenv load_dotenv() client = OpenAI( base_url=os.getenv("LLM_BASE_URL", "https://api.example.com/v1"), api_key=os.getenv("LLM_API_KEY", "your-api-key"), ) def extract_json(text: str) -> list: """从模型输出中提取JSON数组，容忍Markdown代码块和前后缀噪声""" text = text.strip() if text.startswith("```"): # 去掉markdown代码块标记 lines = text.splitlines() lines = [line for line in lines if not line.strip().startswith("```")] text = "\n".join(lines) start = text.find("[") end = text.rfind("]") if start == -1 or end == -1 or end < start: raise ValueError("输出中未找到JSON数组") raw = text[start:end + 1] return json.loads(raw) def generate_test_cases( module: str, requirement_text: str, business_rules: str = "", max_cases: int = 20, temperature: float = 0.3 ) -> list: prompt = TEST_CASE_PROMPT.format( module=module, requirement_text=requirement_text, business_rules=business_rules, max_cases=max_cases ) resp = client.chat.completions.create( model=os.getenv("LLM_MODEL", "gpt-4o-mini"), messages=[ {"role": "system", "content": "你是一个严谨的测试用例设计专家。"}, {"role": "user", "content": prompt}, ], temperature=temperature, ) content = resp.choices[0].message.content return extract_json(content) def deduplicate(cases: list) -> list: """对步骤+预期结果做MD5指纹去重""" seen = set() result = [] for case in cases: steps = "|".join(case.get("steps", [])) expected = case.get("expected_result", "") fingerprint = f"{steps}||{expected}" md5 = __import__("hashlib").md5(fingerprint.encode()).hexdigest() if md5 not in seen: seen.add(md5) result.append(case) return result if __name__ == "__main__": requirement = """ 功能：手机号+验证码登录 接口地址：POST /api/login 请求参数：phone（string，11位手机号），code（string，6位验证码） 业务规则： 1. 手机号必须是11位，以1开头 2. 验证码有效期5分钟，错误5次后失效 3. 同一手机号60秒内只能发送一次验证码 4. 登录成功后返回token，有效期2小时 """ cases = generate_test_cases("登录模块", requirement, max_cases=18) cases = deduplicate(cases) for case in cases[:5]: print(json.dumps(case, ensure_ascii=False, indent=2)) print(f"共生成 {len(cases)} 条用例")

核心逻辑只有三层：拼提示词、调模型、解析JSON。我把temperature设成0.3，是实测下来的折中值。temperature太高（比如0.9），生成的用例花样多但稳定性差；太低（比如0），容易每轮都生成几乎相同的结果，缺乏发散性。如果面向回归测试，建议用0.2以下；面向探索性测试，可以调到0.5以上。

3.3 运行效果与质量验证

用上面这段登录需求跑一轮，我抽了三条生成结果实际看一下：

• LOGIN_001：手机号位数不足（输入12345），预期提示“手机号格式不正确”
• LOGIN_003：验证码错误5次，预期提示“验证码错误次数过多，请重新获取”
• LOGIN_010：验证码已过期，预期提示“验证码已过期，请重新获取”
• LOGIN_015：在phone字段尝试注入攻击，预期返回参数校验错误且不返回token

前两条属于常规功能用例，第三条覆盖了验证码时效边界，第四条则说明AI确实能结合错误推测法生成安全相关的输入校验用例。我拿这批生成结果做过一次小范围评审，让组里3个同事盲评“是否可以直接作为验收用例”，有效率达到85%。剩下15%的问题集中在预期结果描述不够精确，需要人工微调。

需要注意，AI生成的测试用例是“设计初稿”，不是“可直接验收终稿”。它在逻辑覆盖上能帮你省掉一大半时间，但涉及具体业务数值、数据权限、金额计算规则时，仍然需要人工确认。

4. 常见问题与排查技巧实录

4.1 生成的用例太泛、太模板化

这是用提示词方式最常遇到的问题。比如让AI为“用户登录”生成用例，它可能只输出“正确账号密码登录成功”“错误账号密码登录失败”两条，毫无业务深度。

排查思路不是去怪模型，而是看输入信息是否充分。如果你的需求文本只有一句话，AI只能按它臆想的业务生成。解决办法是把业务规则、字段约束、历史缺陷信息尽量塞进输入。比如明确“验证码有效期5分钟”“同一手机号60秒只能发送一次”“登录失败5次锁定账号”，生成结果立刻会细致一个档次。

4.2 模型输出JSON不稳定，解析频繁报错

实测中，大模型返回的内容偶尔会带Markdown代码块标记、解释性文字，甚至JSON中间出现截断。我的extract_json函数专门做了三层防御：去掉代码块标记、截取第一个[到最后一个]之间的内容、再用json.loads强制解析。如果解析失败，代码要支持自动重试一次，但重试时建议把temperature调低一点，让模型更“保守”。

如果遇到“JSON永远是截断的”，检查一下你的max_cases是不是设得太高。我之前试过让模型一次生成80条用例，输出被截断的概率直线上升，后来限制在15到20条，几乎没有截断问题。需要更多用例就分批生成，用module或case_type维度拆开。

4.3 用例重复率高，数量膨胀

AI生成的用例向量化程度很高，同一个场景换几个数据值就能生成七八条相似用例。我用“测试步骤+预期结果”的MD5指纹做去重，效果很好。另外，在提示词里加上“避免与已列出的场景重复，相同场景只保留最具代表性的用例”，也能从源头减少重复。

还有一个实用技巧：生成完后按case_type和design_method做分布统计。如果安全测试用例占比为0，说明提示词里的“安全角度校验”约束没有生效，需要单独补充安全相关的示例给模型看。

4.4 如何系统性地验证AI生成用例的质量

不能只看“生成结果像不像用例”，要看能不能发现问题、能不能被执行。我自己的做法是三个维度交叉验证：

第三个维度很值得投入。我会把最近半年的线上Bug描述做一个脱敏清单，每隔一段时间喂给模型看它能“复现”出多少条有效回归用例。这个数据比单纯看“AI生成了多少条用例”更真实，因为用例的价值不止是数量，而是能不能发现缺陷。

5. 最后再分享一个实操细节

整个方案跑通之后，我发现最容易被忽视的是对生成结果的“可追溯性”。也就是当AI生成了一条用例，你能不记得这条用例是依据需求里的哪条规则推导出来的。

我的处理方式是让模型在输出用例时，额外加一个字段reason，字段值为这个用例的来源规则或设计依据。比如“手机号格式错误用例”的reason就是“手机号必须是11位，以1开头”。这个字段不需要进入最终用例库，但评审时会非常有用——如果发现AI某一类用例设计得不对，可以直接定位是提示词里的哪条约束没写清楚，而不是漫无目的地改提示词。

目前这套方案已经跑进我自己的日常工作流：接上需求文档解析、生成测试用例、自动去重、导出到表格。后续还在考虑把用例执行结果回传给模型，让AI基于失败用例自动补充异常场景。这条路刚起步，但方向已经验证过了——AI生成测试用例不是用来替代测试工程师的，而是把重复繁琐的设计工作接下来，让人把时间花在真正需要业务判断的地方。

本文还有配套的精品资源，点击获取