简介面向测试工程师的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编排我调研了三类技术路线实际对比后选了性价比最高的一种技术路线优点缺点适合场景纯提示词工程开发成本低迭代快随时调整依赖模型能力风格有波动大多数团队的第一选择模型微调Fine-tuning输出风格高度统一更贴合内部规范需要大量高质量标注数据维护成本高用例风格极度统一的成熟团队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/P2case_type只能取功能测试/接口测试/安全测试/边界测试。 总共生成不超过{max_cases}条用例直接输出JSON不要输出Markdown代码块。 2.3 输入信息越结构化生成结果越可用大模型本质上是在做概率预测输入的信息越明确输出就越稳定。同样是“用户登录”这个需求纯文本描述“用户可以使用手机号和验证码登录”和结构化描述“登录接口POST /api/login入参phonestring11位手机号、codestring6位验证码验证码有效期5分钟同一手机号60秒内只能发送一次”生成的结果质量完全不同。实操中我会把接口文档的关键信息路径、请求方法、入参、出参、校验规则拼到需求文本后面再让AI生成测试用例。这样不仅功能用例能生成还能顺带产出接口测试用例甚至能识别出SQL注入、越权这类安全场景的测试输入。注意不要把未经脱敏的生产环境数据直接塞给大模型接口。建议先用脱敏后的需求快照测试或者在内网部署的模型环境中跑。3. 实操落地一份可直接运行的Python源码方案3.1 环境准备与依赖安装我用的是Python 3.10配合openai库调用兼容OpenAI格式的通用大模型API。之所以强调“兼容OpenAI格式”是因为现在不少模型服务商都提供了OpenAI兼容端点换模型时只需要改base_url和api_key代码可以不用动。pip install openai1.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_urlos.getenv(LLM_BASE_URL, https://api.example.com/v1), api_keyos.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( modulemodule, requirement_textrequirement_text, business_rulesbusiness_rules, max_casesmax_cases ) resp client.chat.completions.create( modelos.getenv(LLM_MODEL, gpt-4o-mini), messages[ {role: system, content: 你是一个严谨的测试用例设计专家。}, {role: user, content: prompt}, ], temperaturetemperature, ) 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 请求参数phonestring11位手机号codestring6位验证码 业务规则 1. 手机号必须是11位以1开头 2. 验证码有效期5分钟错误5次后失效 3. 同一手机号60秒内只能发送一次验证码 4. 登录成功后返回token有效期2小时 cases generate_test_cases(登录模块, requirement, max_cases18) cases deduplicate(cases) for case in cases[:5]: print(json.dumps(case, ensure_asciiFalse, indent2)) 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生成用例的质量不能只看“生成结果像不像用例”要看能不能发现问题、能不能被执行。我自己的做法是三个维度交叉验证维度检查方法通过标准规范性是否包含全部必填字段枚举值是否合法100%通过可执行性随机抽取20%用例按步骤人工走一遍可执行率不低于90%有效性用历史缺陷场景反测看能否生成对应回归用例覆盖已确认缺陷场景的70%以上第三个维度很值得投入。我会把最近半年的线上Bug描述做一个脱敏清单每隔一段时间喂给模型看它能“复现”出多少条有效回归用例。这个数据比单纯看“AI生成了多少条用例”更真实因为用例的价值不止是数量而是能不能发现缺陷。5. 最后再分享一个实操细节整个方案跑通之后我发现最容易被忽视的是对生成结果的“可追溯性”。也就是当AI生成了一条用例你能不记得这条用例是依据需求里的哪条规则推导出来的。我的处理方式是让模型在输出用例时额外加一个字段reason字段值为这个用例的来源规则或设计依据。比如“手机号格式错误用例”的reason就是“手机号必须是11位以1开头”。这个字段不需要进入最终用例库但评审时会非常有用——如果发现AI某一类用例设计得不对可以直接定位是提示词里的哪条约束没写清楚而不是漫无目的地改提示词。目前这套方案已经跑进我自己的日常工作流接上需求文档解析、生成测试用例、自动去重、导出到表格。后续还在考虑把用例执行结果回传给模型让AI基于失败用例自动补充异常场景。这条路刚起步但方向已经验证过了——AI生成测试用例不是用来替代测试工程师的而是把重复繁琐的设计工作接下来让人把时间花在真正需要业务判断的地方。本文还有配套的精品资源点击获取 
长河君 · 2026/9/1 4:43:29 · 阅读 1.2k 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编排我调研了三类技术路线实际对比后选了性价比最高的一种技术路线优点缺点适合场景纯提示词工程开发成本低迭代快随时调整依赖模型能力风格有波动大多数团队的第一选择模型微调Fine-tuning输出风格高度统一更贴合内部规范需要大量高质量标注数据维护成本高用例风格极度统一的成熟团队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/P2case_type只能取功能测试/接口测试/安全测试/边界测试。 总共生成不超过{max_cases}条用例直接输出JSON不要输出Markdown代码块。 2.3 输入信息越结构化生成结果越可用大模型本质上是在做概率预测输入的信息越明确输出就越稳定。同样是“用户登录”这个需求纯文本描述“用户可以使用手机号和验证码登录”和结构化描述“登录接口POST /api/login入参phonestring11位手机号、codestring6位验证码验证码有效期5分钟同一手机号60秒内只能发送一次”生成的结果质量完全不同。实操中我会把接口文档的关键信息路径、请求方法、入参、出参、校验规则拼到需求文本后面再让AI生成测试用例。这样不仅功能用例能生成还能顺带产出接口测试用例甚至能识别出SQL注入、越权这类安全场景的测试输入。注意不要把未经脱敏的生产环境数据直接塞给大模型接口。建议先用脱敏后的需求快照测试或者在内网部署的模型环境中跑。3. 实操落地一份可直接运行的Python源码方案3.1 环境准备与依赖安装我用的是Python 3.10配合openai库调用兼容OpenAI格式的通用大模型API。之所以强调“兼容OpenAI格式”是因为现在不少模型服务商都提供了OpenAI兼容端点换模型时只需要改base_url和api_key代码可以不用动。pip install openai1.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_urlos.getenv(LLM_BASE_URL, https://api.example.com/v1), api_keyos.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( modulemodule, requirement_textrequirement_text, business_rulesbusiness_rules, max_casesmax_cases ) resp client.chat.completions.create( modelos.getenv(LLM_MODEL, gpt-4o-mini), messages[ {role: system, content: 你是一个严谨的测试用例设计专家。}, {role: user, content: prompt}, ], temperaturetemperature, ) 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 请求参数phonestring11位手机号codestring6位验证码 业务规则 1. 手机号必须是11位以1开头 2. 验证码有效期5分钟错误5次后失效 3. 同一手机号60秒内只能发送一次验证码 4. 登录成功后返回token有效期2小时 cases generate_test_cases(登录模块, requirement, max_cases18) cases deduplicate(cases) for case in cases[:5]: print(json.dumps(case, ensure_asciiFalse, indent2)) 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生成用例的质量不能只看“生成结果像不像用例”要看能不能发现问题、能不能被执行。我自己的做法是三个维度交叉验证维度检查方法通过标准规范性是否包含全部必填字段枚举值是否合法100%通过可执行性随机抽取20%用例按步骤人工走一遍可执行率不低于90%有效性用历史缺陷场景反测看能否生成对应回归用例覆盖已确认缺陷场景的70%以上第三个维度很值得投入。我会把最近半年的线上Bug描述做一个脱敏清单每隔一段时间喂给模型看它能“复现”出多少条有效回归用例。这个数据比单纯看“AI生成了多少条用例”更真实因为用例的价值不止是数量而是能不能发现缺陷。5. 最后再分享一个实操细节整个方案跑通之后我发现最容易被忽视的是对生成结果的“可追溯性”。也就是当AI生成了一条用例你能不记得这条用例是依据需求里的哪条规则推导出来的。我的处理方式是让模型在输出用例时额外加一个字段reason字段值为这个用例的来源规则或设计依据。比如“手机号格式错误用例”的reason就是“手机号必须是11位以1开头”。这个字段不需要进入最终用例库但评审时会非常有用——如果发现AI某一类用例设计得不对可以直接定位是提示词里的哪条约束没写清楚而不是漫无目的地改提示词。目前这套方案已经跑进我自己的日常工作流接上需求文档解析、生成测试用例、自动去重、导出到表格。后续还在考虑把用例执行结果回传给模型让AI基于失败用例自动补充异常场景。这条路刚起步但方向已经验证过了——AI生成测试用例不是用来替代测试工程师的而是把重复繁琐的设计工作接下来让人把时间花在真正需要业务判断的地方。本文还有配套的精品资源点击获取