简介这是一份面向测试工程师与自动化测试开发者的AI测试用例生成系统源码基于LLM与文档解析技术实现从PDF/Word中提取文本、表格和图片内容并通过定制提示词自动生成多样化测试用例。资源共13个文件压缩包仅24KB以5个Python源码为核心覆盖文档解析、OCR识别、多LLM平台集成、格式转换JSON/Excel/XMind等模块同时包含前端页面与配置文件便于快速运行与二次开发。已有309人学习下载。通过该系统读者可掌握文档结构保持、表格嵌套解析、大模型参数调优等关键实现细节并直接复用token消耗统计与用例分布分析功能提升测试用例生成的自动化程度与覆盖面。 你写测试用例的时候有没有一打开需求文档就头皮发麻的感觉功能测试用例、接口测试用例、异常流、边界值、权限校验……同一套逻辑在不同模块里反复套写多了自己都分不清是在做测试还是在做文字填空。我前阵子花了两天时间把“AI生成测试用例”这套流程完整跑通了从需求文本进去规范的结构化用例出来还整理了一份可以直接改改就用的源码。这篇东西就把整个项目的思路、核心实现、完整代码和踩坑记录都翻出来给同样被用例淹没的测试同学一个能直接上手的参照。这个项目本质上解决一个问题让大模型替你完成用例设计里最耗时的“翻译”工作——把自然语言描述的需求翻译成结构清晰、覆盖面完整、格式统一的测试用例。它不是一个花哨的Demo而是一条能接入日常工作的管线输入功能描述调用大模型接口解析结构化输出最后落成表格或自动化脚本。适合三类人看天天写功能用例的测试工程师、想给测试团队做提效工具的测试开发、以及刚入门想知道AI在测试领域到底能干什么的新人。1. 项目整体设计思路为什么非得用大模型来写用例1.1 传统用例编写的三个老毛病做了这么多年测试我觉得手工编写测试用例最大的问题不是“不会写”而是“性价比太低”。第一重复劳动太多。登录、注册、列表查询、数据导入导出这些模块的业务逻辑不一样但用例设计套路几乎一样正常路径一条、必填项校验、边界值、异常输入、权限拦截。每来一个新项目就要把这些套路重写一遍时间长了纯粹是体力活。第二覆盖完整性完全依赖个人经验。老手能靠直觉补出各种极端场景新手照着需求文档写经常漏掉“空值”“超长字符”“并发重复提交”这类一看就知道该测、但需求文档里不会写的内容。第三需求变更后同步成本高。产品改了交互逻辑测试用例要跟着逐条改漏改一条就可能让隐藏缺陷流入线上。这三个问题叠加在一起说明我们缺的不是“写用例的人”而是一个能把需求文本快速转化为候选用例、再由人来筛选完善的辅助层。1.2 大模型相比规则引擎和历史数据复用的优势可能有人会问这活儿用规则模板或者直接翻历史用例不就行了吗我在早期尝试过这两种方案效果都不太理想。规则模板的痛点是“写规则比写用例还累”。你要为每个业务模块梳理字段类型、必填项、取值范围然后编写对应的生成逻辑。一旦业务复杂规则之间的组合爆炸让你根本维护不过来。历史用例复用的问题在于“只能覆盖存量”。MySQL里攒了几万条用例但新需求往往是旧场景的组合或变更按相似度匹配出来的用例要么过时、要么不完整依旧需要大量人工改写。大模型不一样。它本质上是一个“读过海量软件工程资料、理解常见业务逻辑”的生成器。你给它一句话的功能描述它能基于通用的测试设计方法论——等价类划分、边界值分析、场景法、错误推测法——直接产出覆盖正常流和异常流的用例。它不一定比你团队里的资深测试想得全但它的产出速度和稳定性远超人工而且“经验”是内置的不需要额外编写规则。1.3 整个方案的技术形态整个项目的处理链路非常清晰就四步接收需求文本可以是一段PRD描述、一个接口文档片段或者一句功能简介。构造Prompt并调用模型把“需求文本 用例格式要求 测试设计方法指令”一起发给大模型。解析结构化输出要求模型返回固定JSON结构再通过代码清洗、校验、转换。落盘为可用产物输出Excel表格或Pytest测试脚本模板。“源码”部分的重点就在第二步和第三步。Prompt决定用例质量的上限而解析代码决定整个流程能不能稳定跑起来。后面我会把两部分都展开讲。2. 核心细节解析测试设计方法怎么“塞”进Prompt里2.1 用例结构先定义好模型才有章可循很多AI生成用例翻车不是因为模型不够聪明而是因为它根本不知道你要什么格式。你只说“帮我写几个测试用例”模型就会自由发挥给你一坨格式混乱、字段缺失的文本根本没法直接用。我在项目里先定义了一套标准用例字段再用JSON Schema约束模型的输出结构。这套字段覆盖了日常功能用例和接口用例的核心信息字段含义示例case_id用例编号模块前缀加数字LOGIN_001module所属模块登录模块title用例标题一句话说清测什么验证用户名或密码错误时的提示信息priority优先级P0到P3P1precondition前置条件用户已注册且账号状态正常steps操作步骤数组格式[打开登录页, 输入用户名, 输入密码, 点击登录按钮]test_data测试数据{username: zhangsan, password: wrong_pass}expected预期结果页面提示“用户名或密码错误”停留在登录页把字段定义清楚之后我看到的最大变化是模型输出从“写作文”变成了“填表格”后续解析代码只需要做JSON清洗和字段校验不需要面对各种格式的“散文”。2.2 提示词里必须点名的测试设计方法直接让模型写用例它大概率只给你写“正常流程 密码错误”这种浅层用例。为了逼它写出有测试价值的用例我在Prompt里明确列出了要使用的测试设计方法每个方法后面都跟了一句触发条件。这是整个项目最核心的Prompt设计你是一名资深测试工程师请根据以下功能需求描述设计完整的测试用例。 需求描述 {requirement} 要求 1. 覆盖正常路径、异常路径和边界条件。 2. 必须使用等价类划分法设计有效等价类和无效等价类用例。 3. 必须使用边界值分析法覆盖上点、离点、内点。 4. 如果涉及状态转换如订单状态流转使用场景法覆盖主场景和备选场景。 5. 如果涉及多字段组合校验使用判定表法覆盖典型组合。 6. 前置条件要完整测试步骤要具体到页面或接口操作级别。 7. 预期结果必须可验证不能出现“系统正常”“无异常”这类模糊描述。 输出要求 以JSON数组返回测试用例列表每个用例包含以下字段 case_id, module, title, priority, precondition, steps, test_data, expected。 只输出JSON不要输出额外的解释文字。你可能觉得这些要求没什么稀奇的但就是这简单几行直接决定了生成用例的深度。我对比过不写这些方法和写了之后的结果不写时模型给15条用例写完之后模型能稳定给出30条以上而且边界值和异常流的占比明显提高。2.3 设计方法论与Prompt指令的对应关系为了让这些测试方法在Prompt里真正生效我建议把它们跟具体的触发场景绑定而不是机械地全塞进去。比如测试设计方法Prompt里的触发指令典型应用场景等价类划分按有效等价类和无效等价类分别设计用例表单校验、输入框校验边界值分析覆盖上点、离点、内点数值范围、长度限制场景法覆盖主场景、备选场景和异常场景订单流转、审批流、状态机判定表覆盖字段组合的典型规则多条件组合查询、优惠叠加规则错误推测法从用户误操作、数据异常角度补充用例重复提交、连点、断网、后端超时这个方法绑定触发场景的思路本质上是在用规则弥补大模型对“测试重点”感知不稳定的问题。你把方法论写进Prompt模型就知道该往哪个方向多想一步。3. 实操过程与核心环节实现三步跑通AI用例生成3.1 模型选型商业API还是本地部署这个项目里模型选择是第一步也是最容易纠结的一步。我的建议很简单有数据隐私要求就本地部署没有就先用API跑通流程。我测试了三种方案列成表格供你参考方案部署方式优点适合场景国产商业大模型API如通义千问、DeepSeek、智谱等API调用中文理解好、接口稳定、接入快没有私有化要求的中小团队开源模型本地部署如Qwen系列本地GPU推理数据不出内网、可微调、长期成本可控对数据安全敏感的企业OpenAI兼容接口的各类平台API调用生态好、兼容性强、切换模型简单已有API调用基建的团队我实际跑通用的是OpenAI兼容接口格式这样好处是无论你最后选哪个服务商代码都不用大改。下面这段核心调用代码就是基于这种兼容格式写的复制到你的Python环境里把base_url和api_key换成你自己的就能跑。3.2 核心源码从调用模型到结构化用例落盘整个项目的源码拆开看只有三个函数调用模型、清洗JSON、保存结果。单独看任何一个都不复杂但组合起来就是一条完整的AI用例生成管线。import json import re from openai import OpenAI import pandas as pd client OpenAI( base_urlhttps://your-api-endpoint.com/v1, # 换成你的模型服务地址 api_keyyour-api-key # 换成你的密钥 ) def generate_test_cases(requirement: str, model: str qwen-plus) - list: 根据需求描述调用大模型生成测试用例列表。 返回解析后的用例字典列表。 prompt f 你是一名资深测试工程师请根据以下功能需求描述设计完整的测试用例。 需求描述 {requirement} 要求 1. 覆盖正常路径、异常路径和边界条件。 2. 必须使用等价类划分法设计有效等价类和无效等价类用例。 3. 必须使用边界值分析法覆盖上点、离点、内点。 4. 如果涉及状态转换如订单状态流转使用场景法覆盖主场景和备选场景。 5. 如果涉及多字段组合校验使用判定表法覆盖典型组合。 6. 前置条件要完整测试步骤要具体到页面或接口操作级别。 7. 预期结果必须可验证不能出现“系统正常”“无异常”这类模糊描述。 输出要求 以JSON数组返回测试用例列表每个用例包含以下字段 case_id, module, title, priority, precondition, steps, test_data, expected。 只输出JSON不要输出额外的解释文字。 response client.chat.completions.create( modelmodel, messages[{role: user, content: prompt}], temperature0.3 # 低温保证输出稳定 ) raw_content response.choices[0].message.content return clean_json(raw_content) def clean_json(raw_content: str) - list: 清洗模型返回的文本提取JSON数组。 主要处理模型常见的问题markdown代码块包裹、前后有多余文字。 # 去除markdown代码块标记 json_match re.search(r\[.*\], raw_content, re.DOTALL) if not json_match: raise ValueError(模型输出中未找到JSON数组) json_str json_match.group() try: cases json.loads(json_str) except json.JSONDecodeError as e: # 如果json解析失败尝试修复常见的末尾逗号问题 json_str re.sub(r,\s*}, }, json_str) json_str re.sub(r,\s*\], ], json_str) cases json.loads(json_str) return cases def save_to_excel(cases: list, output_path: str test_cases.xlsx): 将用例列表保存为Excel文件方便测试同学评审和导入管理工具。 if not cases: print(没有生成任何用例请检查输入) return df pd.DataFrame(cases) # 调整列顺序让关键信息靠前 column_order [case_id, module, title, priority, precondition, steps, test_data, expected] df df[[col for col in column_order if col in df.columns]] df.to_excel(output_path, indexFalse) print(f已生成 {len(cases)} 条用例保存至 {output_path})这段代码里有两个细节我特别想说一下。第一temperature参数我设成了0.3。生成用例不是写诗不需要模型有太多创造性。温度调低可以显著减少模型“天马行空”的概率让输出更贴近测试用例该有的规范性。实测下来0.2到0.4之间是一个比较稳的区间太低会显得机械化太高容易跑偏。第二clean_json这个函数看似不起眼但它解决了实际使用中最常遇到的痛。大模型输出JSON时经常会在外层套一个markdown的json代码块或者在JSON前后加“以下是生成的用例”这种废话。如果不做清洗json.loads直接报错你的管线就会卡死在第一步。用正则提取最早出现的[到最后的]这段内容再做解析是成本最低、最稳的做法。3.3 完整实例用登录功能跑一遍全流程理论说了这么多直接看一个实际跑通的例子。我输入的需求描述只有一句话用户通过用户名和密码登录系统输入正确后跳转到首页输入错误时提示“用户名或密码错误”连续输错5次账号锁定30分钟。模型返回的用例列表中我挑几条有代表性的展示一下case_idtitlepriority关键步骤预期结果LOGIN_001正确用户名密码登录成功P0输入有效用户名和正确密码点击登录跳转到首页登录状态生效LOGIN_002用户名正确密码错误P1输入有效用户名和错误密码点击登录提示“用户名或密码错误”停留在登录页LOGIN_003用户名为空P1用户名留空密码正确点击登录用户名输入框下方提示“请输入用户名”LOGIN_004密码长度边界值测试P2输入长度为8位和9位的密码8位密码无法提交9位密码提交成功LOGIN_005连续输错5次触发锁定P1连续5次输入错误密码第6次提交时提示“账号已锁定请30分钟后再试”LOGIN_006锁定到期后自动解锁P2等待30分钟后再次尝试登录可正常登录无需额外操作能看到吗这里用到了等价类正确/错误/为空、边界值密码长度8/9位、场景法连续输错触发锁定、异常流锁定后自动解锁。如果让人工来写这些用例可能一条不落但写完全部用例至少需要半小时而模型生成只花了不到20秒。3.4 从“能用”到“好用”的后处理模型生成的用例不能直接拿去执行至少需要做两步后处理。第一步是去重和合并。模型有时会把同一场景用不同措辞重复生成比如“密码错误”和“密码输入不正确”本质是同一个用例。我通常的做法是在Excel里按title列去重或者用steps的相似度简单过滤。第二步是补测试数据。模型给出的test_data往往是个示意你需要在真正执行的时候替换成环境里真实存在的数据。比如登录用例里的用户名和密码模型生成的是zhangsan/wrong_pass但你的测试环境里可能根本没有这个账号。所以我把test_data字段定位为“数据模板”执行前必须人工确认。我的建议是模型负责设计和骨架人工负责数据和决策。AI把用例设计中最耗时间的60%工作量干完剩下的40%留给测试工程师做专业判断这才是最高效的分工方式。4. 常见问题与排查技巧实录4.1 模型返回的不是合法JSON怎么办这是整个项目里最常遇到的问题。模型偶尔会在JSON外面套一层注解或者混入一些非JSON字符。我从实践中总结了一套由浅入深的处理策略先尝试用正则提取内容中的JSON数组片段我上面的代码已经实现了。如果提取后解析失败去掉JSON里的末尾逗号再试一次。如果还不行就把原始输出原样打印出来检查是不是字段值里包含了未转义的引号或换行符。终极方案在Prompt里加一句“确保返回内容能被Python的json.loads直接解析”这句话能大幅降低出错率。你要记住一点大模型不是数据库它的输出天然有一定的不确定性。你的代码必须对“格式不完美”有容忍度该清洗清洗该重试重试。4.2 生成的用例太“平”缺乏深度场景我最早测试的时候模型生成的用例基本都是“输入正确→成功”“输入错误→提示”这种最基础的路径。后来我发现问题出在Prompt本身——我没有告诉模型要往深处想。解决方案就是在Prompt里加一个“错误推测”的指令从以下角度补充异常场景 - 用户重复点击提交按钮 - 后端接口超时或返回500 - 网络中断后恢复 - 并发操作两个用户同时操作同一数据加了这个指令之后生成的用例里就开始出现“重复点击提交”“后端超时提示友好错误”这类真正有测试价值的场景。这其实是在用Prompt让模型调用它的“错误推测经验库”比你让它自由发挥要精准得多。4.3 接口测试用例和功能测试用例混在一起这个项目最初的版本只针对页面功能测试但你在实际项目中经常要同时产出接口用例。后来我调整了Prompt策略在需求描述后面加一个字段标识“用例类型”取值为功能测试或接口测试然后根据类型切换Prompt模板中的细节要求。接口用例模板的关键差异有三点步骤里明确请求方法、URL和请求头。测试数据里区分params、path和body。预期结果里明确HTTP状态码和响应体结构。用例类型步骤格式测试数据格式预期结果格式功能用例页面操作步骤表单字段页面文案、跳转页面接口用例GET/POST URL Headerparams/bodyHTTP状态码 响应结构这部分的代码实现不复杂就是在生成用例时多了一个分支判断。但做完整之后整个工具从“只能写页面用例”变成了“页面和接口通吃”实用性提升了一个量级。4.4 提示词里的需求描述写多详细合适很多人在这一步走了极端要么只写一句话要么把整个PRD贴进去。我的经验是需求描述越具体生成用例的质量越高但有上限。实测下来把下面这四类信息写清楚就足够了功能核心流程用户能做什么。核心规则什么条件允许、什么条件不允许。关键限制超时时间、长度限制、次数限制。涉及的异常提示语如果产品已经定义。如果只有一句话“用户登录系统”模型只能给你常规登录用例如果你补充“连续输错5次锁定30分钟”“密码长度8到20位”模型就能精准生成边界值用例。记住你给模型的信息质量直接决定用例质量。AI不是神仙它也需要原料原料越精细成品越靠谱。4.5 大批量生成时怎么控制成本和频次测试用例动辄几百上千条如果全部靠API生成成本需要算清楚。我把一个需求描述控制在300字以内一次生成约30条用例消耗的token大约在1500到2500之间。换算下来生成1000条用例的成本通常不超过十块钱人民币比人工省下的时间成本划算太多。如果还要控制得更精细可以用一个技巧先让模型生成用例标题和模块人工筛选后再让模型补全步骤和预期结果。这个“两步生成法”能把无效token消耗降低40%左右因为很多被筛掉的用例不需要生成详细的步骤描述。整套流程跑下来我个人最深的体会是AI生成测试用例这件事技术门槛其实不高真正的分水岭在Prompt设计和输出解析是否扎实。你花一小时把提示词调好后面每天都能省下两三个小时重复劳动。现在我的做法是把这条管线做成一个Web服务测试同学在页面上粘贴需求描述点一下按钮就拿到Excel用例包。如果你也想复用这套逻辑建议先按文章里的代码跑通单条用例再逐步加上批量处理、模板切换这些外围功能。踩过几次坑之后你会发现AI不是要取代测试工程师而是帮我们把时间从“写用例”挪到“想测试策略”上去。本文还有配套的精品资源点击获取
简介这是一份面向测试工程师与自动化测试开发者的AI测试用例生成系统源码基于LLM与文档解析技术实现从PDF/Word中提取文本、表格和图片内容并通过定制提示词自动生成多样化测试用例。资源共13个文件压缩包仅24KB以5个Python源码为核心覆盖文档解析、OCR识别、多LLM平台集成、格式转换JSON/Excel/XMind等模块同时包含前端页面与配置文件便于快速运行与二次开发。已有309人学习下载。通过该系统读者可掌握文档结构保持、表格嵌套解析、大模型参数调优等关键实现细节并直接复用token消耗统计与用例分布分析功能提升测试用例生成的自动化程度与覆盖面。 你写测试用例的时候有没有一打开需求文档就头皮发麻的感觉功能测试用例、接口测试用例、异常流、边界值、权限校验……同一套逻辑在不同模块里反复套写多了自己都分不清是在做测试还是在做文字填空。我前阵子花了两天时间把“AI生成测试用例”这套流程完整跑通了从需求文本进去规范的结构化用例出来还整理了一份可以直接改改就用的源码。这篇东西就把整个项目的思路、核心实现、完整代码和踩坑记录都翻出来给同样被用例淹没的测试同学一个能直接上手的参照。这个项目本质上解决一个问题让大模型替你完成用例设计里最耗时的“翻译”工作——把自然语言描述的需求翻译成结构清晰、覆盖面完整、格式统一的测试用例。它不是一个花哨的Demo而是一条能接入日常工作的管线输入功能描述调用大模型接口解析结构化输出最后落成表格或自动化脚本。适合三类人看天天写功能用例的测试工程师、想给测试团队做提效工具的测试开发、以及刚入门想知道AI在测试领域到底能干什么的新人。1. 项目整体设计思路为什么非得用大模型来写用例1.1 传统用例编写的三个老毛病做了这么多年测试我觉得手工编写测试用例最大的问题不是“不会写”而是“性价比太低”。第一重复劳动太多。登录、注册、列表查询、数据导入导出这些模块的业务逻辑不一样但用例设计套路几乎一样正常路径一条、必填项校验、边界值、异常输入、权限拦截。每来一个新项目就要把这些套路重写一遍时间长了纯粹是体力活。第二覆盖完整性完全依赖个人经验。老手能靠直觉补出各种极端场景新手照着需求文档写经常漏掉“空值”“超长字符”“并发重复提交”这类一看就知道该测、但需求文档里不会写的内容。第三需求变更后同步成本高。产品改了交互逻辑测试用例要跟着逐条改漏改一条就可能让隐藏缺陷流入线上。这三个问题叠加在一起说明我们缺的不是“写用例的人”而是一个能把需求文本快速转化为候选用例、再由人来筛选完善的辅助层。1.2 大模型相比规则引擎和历史数据复用的优势可能有人会问这活儿用规则模板或者直接翻历史用例不就行了吗我在早期尝试过这两种方案效果都不太理想。规则模板的痛点是“写规则比写用例还累”。你要为每个业务模块梳理字段类型、必填项、取值范围然后编写对应的生成逻辑。一旦业务复杂规则之间的组合爆炸让你根本维护不过来。历史用例复用的问题在于“只能覆盖存量”。MySQL里攒了几万条用例但新需求往往是旧场景的组合或变更按相似度匹配出来的用例要么过时、要么不完整依旧需要大量人工改写。大模型不一样。它本质上是一个“读过海量软件工程资料、理解常见业务逻辑”的生成器。你给它一句话的功能描述它能基于通用的测试设计方法论——等价类划分、边界值分析、场景法、错误推测法——直接产出覆盖正常流和异常流的用例。它不一定比你团队里的资深测试想得全但它的产出速度和稳定性远超人工而且“经验”是内置的不需要额外编写规则。1.3 整个方案的技术形态整个项目的处理链路非常清晰就四步接收需求文本可以是一段PRD描述、一个接口文档片段或者一句功能简介。构造Prompt并调用模型把“需求文本 用例格式要求 测试设计方法指令”一起发给大模型。解析结构化输出要求模型返回固定JSON结构再通过代码清洗、校验、转换。落盘为可用产物输出Excel表格或Pytest测试脚本模板。“源码”部分的重点就在第二步和第三步。Prompt决定用例质量的上限而解析代码决定整个流程能不能稳定跑起来。后面我会把两部分都展开讲。2. 核心细节解析测试设计方法怎么“塞”进Prompt里2.1 用例结构先定义好模型才有章可循很多AI生成用例翻车不是因为模型不够聪明而是因为它根本不知道你要什么格式。你只说“帮我写几个测试用例”模型就会自由发挥给你一坨格式混乱、字段缺失的文本根本没法直接用。我在项目里先定义了一套标准用例字段再用JSON Schema约束模型的输出结构。这套字段覆盖了日常功能用例和接口用例的核心信息字段含义示例case_id用例编号模块前缀加数字LOGIN_001module所属模块登录模块title用例标题一句话说清测什么验证用户名或密码错误时的提示信息priority优先级P0到P3P1precondition前置条件用户已注册且账号状态正常steps操作步骤数组格式[打开登录页, 输入用户名, 输入密码, 点击登录按钮]test_data测试数据{username: zhangsan, password: wrong_pass}expected预期结果页面提示“用户名或密码错误”停留在登录页把字段定义清楚之后我看到的最大变化是模型输出从“写作文”变成了“填表格”后续解析代码只需要做JSON清洗和字段校验不需要面对各种格式的“散文”。2.2 提示词里必须点名的测试设计方法直接让模型写用例它大概率只给你写“正常流程 密码错误”这种浅层用例。为了逼它写出有测试价值的用例我在Prompt里明确列出了要使用的测试设计方法每个方法后面都跟了一句触发条件。这是整个项目最核心的Prompt设计你是一名资深测试工程师请根据以下功能需求描述设计完整的测试用例。 需求描述 {requirement} 要求 1. 覆盖正常路径、异常路径和边界条件。 2. 必须使用等价类划分法设计有效等价类和无效等价类用例。 3. 必须使用边界值分析法覆盖上点、离点、内点。 4. 如果涉及状态转换如订单状态流转使用场景法覆盖主场景和备选场景。 5. 如果涉及多字段组合校验使用判定表法覆盖典型组合。 6. 前置条件要完整测试步骤要具体到页面或接口操作级别。 7. 预期结果必须可验证不能出现“系统正常”“无异常”这类模糊描述。 输出要求 以JSON数组返回测试用例列表每个用例包含以下字段 case_id, module, title, priority, precondition, steps, test_data, expected。 只输出JSON不要输出额外的解释文字。你可能觉得这些要求没什么稀奇的但就是这简单几行直接决定了生成用例的深度。我对比过不写这些方法和写了之后的结果不写时模型给15条用例写完之后模型能稳定给出30条以上而且边界值和异常流的占比明显提高。2.3 设计方法论与Prompt指令的对应关系为了让这些测试方法在Prompt里真正生效我建议把它们跟具体的触发场景绑定而不是机械地全塞进去。比如测试设计方法Prompt里的触发指令典型应用场景等价类划分按有效等价类和无效等价类分别设计用例表单校验、输入框校验边界值分析覆盖上点、离点、内点数值范围、长度限制场景法覆盖主场景、备选场景和异常场景订单流转、审批流、状态机判定表覆盖字段组合的典型规则多条件组合查询、优惠叠加规则错误推测法从用户误操作、数据异常角度补充用例重复提交、连点、断网、后端超时这个方法绑定触发场景的思路本质上是在用规则弥补大模型对“测试重点”感知不稳定的问题。你把方法论写进Prompt模型就知道该往哪个方向多想一步。3. 实操过程与核心环节实现三步跑通AI用例生成3.1 模型选型商业API还是本地部署这个项目里模型选择是第一步也是最容易纠结的一步。我的建议很简单有数据隐私要求就本地部署没有就先用API跑通流程。我测试了三种方案列成表格供你参考方案部署方式优点适合场景国产商业大模型API如通义千问、DeepSeek、智谱等API调用中文理解好、接口稳定、接入快没有私有化要求的中小团队开源模型本地部署如Qwen系列本地GPU推理数据不出内网、可微调、长期成本可控对数据安全敏感的企业OpenAI兼容接口的各类平台API调用生态好、兼容性强、切换模型简单已有API调用基建的团队我实际跑通用的是OpenAI兼容接口格式这样好处是无论你最后选哪个服务商代码都不用大改。下面这段核心调用代码就是基于这种兼容格式写的复制到你的Python环境里把base_url和api_key换成你自己的就能跑。3.2 核心源码从调用模型到结构化用例落盘整个项目的源码拆开看只有三个函数调用模型、清洗JSON、保存结果。单独看任何一个都不复杂但组合起来就是一条完整的AI用例生成管线。import json import re from openai import OpenAI import pandas as pd client OpenAI( base_urlhttps://your-api-endpoint.com/v1, # 换成你的模型服务地址 api_keyyour-api-key # 换成你的密钥 ) def generate_test_cases(requirement: str, model: str qwen-plus) - list: 根据需求描述调用大模型生成测试用例列表。 返回解析后的用例字典列表。 prompt f 你是一名资深测试工程师请根据以下功能需求描述设计完整的测试用例。 需求描述 {requirement} 要求 1. 覆盖正常路径、异常路径和边界条件。 2. 必须使用等价类划分法设计有效等价类和无效等价类用例。 3. 必须使用边界值分析法覆盖上点、离点、内点。 4. 如果涉及状态转换如订单状态流转使用场景法覆盖主场景和备选场景。 5. 如果涉及多字段组合校验使用判定表法覆盖典型组合。 6. 前置条件要完整测试步骤要具体到页面或接口操作级别。 7. 预期结果必须可验证不能出现“系统正常”“无异常”这类模糊描述。 输出要求 以JSON数组返回测试用例列表每个用例包含以下字段 case_id, module, title, priority, precondition, steps, test_data, expected。 只输出JSON不要输出额外的解释文字。 response client.chat.completions.create( modelmodel, messages[{role: user, content: prompt}], temperature0.3 # 低温保证输出稳定 ) raw_content response.choices[0].message.content return clean_json(raw_content) def clean_json(raw_content: str) - list: 清洗模型返回的文本提取JSON数组。 主要处理模型常见的问题markdown代码块包裹、前后有多余文字。 # 去除markdown代码块标记 json_match re.search(r\[.*\], raw_content, re.DOTALL) if not json_match: raise ValueError(模型输出中未找到JSON数组) json_str json_match.group() try: cases json.loads(json_str) except json.JSONDecodeError as e: # 如果json解析失败尝试修复常见的末尾逗号问题 json_str re.sub(r,\s*}, }, json_str) json_str re.sub(r,\s*\], ], json_str) cases json.loads(json_str) return cases def save_to_excel(cases: list, output_path: str test_cases.xlsx): 将用例列表保存为Excel文件方便测试同学评审和导入管理工具。 if not cases: print(没有生成任何用例请检查输入) return df pd.DataFrame(cases) # 调整列顺序让关键信息靠前 column_order [case_id, module, title, priority, precondition, steps, test_data, expected] df df[[col for col in column_order if col in df.columns]] df.to_excel(output_path, indexFalse) print(f已生成 {len(cases)} 条用例保存至 {output_path})这段代码里有两个细节我特别想说一下。第一temperature参数我设成了0.3。生成用例不是写诗不需要模型有太多创造性。温度调低可以显著减少模型“天马行空”的概率让输出更贴近测试用例该有的规范性。实测下来0.2到0.4之间是一个比较稳的区间太低会显得机械化太高容易跑偏。第二clean_json这个函数看似不起眼但它解决了实际使用中最常遇到的痛。大模型输出JSON时经常会在外层套一个markdown的json代码块或者在JSON前后加“以下是生成的用例”这种废话。如果不做清洗json.loads直接报错你的管线就会卡死在第一步。用正则提取最早出现的[到最后的]这段内容再做解析是成本最低、最稳的做法。3.3 完整实例用登录功能跑一遍全流程理论说了这么多直接看一个实际跑通的例子。我输入的需求描述只有一句话用户通过用户名和密码登录系统输入正确后跳转到首页输入错误时提示“用户名或密码错误”连续输错5次账号锁定30分钟。模型返回的用例列表中我挑几条有代表性的展示一下case_idtitlepriority关键步骤预期结果LOGIN_001正确用户名密码登录成功P0输入有效用户名和正确密码点击登录跳转到首页登录状态生效LOGIN_002用户名正确密码错误P1输入有效用户名和错误密码点击登录提示“用户名或密码错误”停留在登录页LOGIN_003用户名为空P1用户名留空密码正确点击登录用户名输入框下方提示“请输入用户名”LOGIN_004密码长度边界值测试P2输入长度为8位和9位的密码8位密码无法提交9位密码提交成功LOGIN_005连续输错5次触发锁定P1连续5次输入错误密码第6次提交时提示“账号已锁定请30分钟后再试”LOGIN_006锁定到期后自动解锁P2等待30分钟后再次尝试登录可正常登录无需额外操作能看到吗这里用到了等价类正确/错误/为空、边界值密码长度8/9位、场景法连续输错触发锁定、异常流锁定后自动解锁。如果让人工来写这些用例可能一条不落但写完全部用例至少需要半小时而模型生成只花了不到20秒。3.4 从“能用”到“好用”的后处理模型生成的用例不能直接拿去执行至少需要做两步后处理。第一步是去重和合并。模型有时会把同一场景用不同措辞重复生成比如“密码错误”和“密码输入不正确”本质是同一个用例。我通常的做法是在Excel里按title列去重或者用steps的相似度简单过滤。第二步是补测试数据。模型给出的test_data往往是个示意你需要在真正执行的时候替换成环境里真实存在的数据。比如登录用例里的用户名和密码模型生成的是zhangsan/wrong_pass但你的测试环境里可能根本没有这个账号。所以我把test_data字段定位为“数据模板”执行前必须人工确认。我的建议是模型负责设计和骨架人工负责数据和决策。AI把用例设计中最耗时间的60%工作量干完剩下的40%留给测试工程师做专业判断这才是最高效的分工方式。4. 常见问题与排查技巧实录4.1 模型返回的不是合法JSON怎么办这是整个项目里最常遇到的问题。模型偶尔会在JSON外面套一层注解或者混入一些非JSON字符。我从实践中总结了一套由浅入深的处理策略先尝试用正则提取内容中的JSON数组片段我上面的代码已经实现了。如果提取后解析失败去掉JSON里的末尾逗号再试一次。如果还不行就把原始输出原样打印出来检查是不是字段值里包含了未转义的引号或换行符。终极方案在Prompt里加一句“确保返回内容能被Python的json.loads直接解析”这句话能大幅降低出错率。你要记住一点大模型不是数据库它的输出天然有一定的不确定性。你的代码必须对“格式不完美”有容忍度该清洗清洗该重试重试。4.2 生成的用例太“平”缺乏深度场景我最早测试的时候模型生成的用例基本都是“输入正确→成功”“输入错误→提示”这种最基础的路径。后来我发现问题出在Prompt本身——我没有告诉模型要往深处想。解决方案就是在Prompt里加一个“错误推测”的指令从以下角度补充异常场景 - 用户重复点击提交按钮 - 后端接口超时或返回500 - 网络中断后恢复 - 并发操作两个用户同时操作同一数据加了这个指令之后生成的用例里就开始出现“重复点击提交”“后端超时提示友好错误”这类真正有测试价值的场景。这其实是在用Prompt让模型调用它的“错误推测经验库”比你让它自由发挥要精准得多。4.3 接口测试用例和功能测试用例混在一起这个项目最初的版本只针对页面功能测试但你在实际项目中经常要同时产出接口用例。后来我调整了Prompt策略在需求描述后面加一个字段标识“用例类型”取值为功能测试或接口测试然后根据类型切换Prompt模板中的细节要求。接口用例模板的关键差异有三点步骤里明确请求方法、URL和请求头。测试数据里区分params、path和body。预期结果里明确HTTP状态码和响应体结构。用例类型步骤格式测试数据格式预期结果格式功能用例页面操作步骤表单字段页面文案、跳转页面接口用例GET/POST URL Headerparams/bodyHTTP状态码 响应结构这部分的代码实现不复杂就是在生成用例时多了一个分支判断。但做完整之后整个工具从“只能写页面用例”变成了“页面和接口通吃”实用性提升了一个量级。4.4 提示词里的需求描述写多详细合适很多人在这一步走了极端要么只写一句话要么把整个PRD贴进去。我的经验是需求描述越具体生成用例的质量越高但有上限。实测下来把下面这四类信息写清楚就足够了功能核心流程用户能做什么。核心规则什么条件允许、什么条件不允许。关键限制超时时间、长度限制、次数限制。涉及的异常提示语如果产品已经定义。如果只有一句话“用户登录系统”模型只能给你常规登录用例如果你补充“连续输错5次锁定30分钟”“密码长度8到20位”模型就能精准生成边界值用例。记住你给模型的信息质量直接决定用例质量。AI不是神仙它也需要原料原料越精细成品越靠谱。4.5 大批量生成时怎么控制成本和频次测试用例动辄几百上千条如果全部靠API生成成本需要算清楚。我把一个需求描述控制在300字以内一次生成约30条用例消耗的token大约在1500到2500之间。换算下来生成1000条用例的成本通常不超过十块钱人民币比人工省下的时间成本划算太多。如果还要控制得更精细可以用一个技巧先让模型生成用例标题和模块人工筛选后再让模型补全步骤和预期结果。这个“两步生成法”能把无效token消耗降低40%左右因为很多被筛掉的用例不需要生成详细的步骤描述。整套流程跑下来我个人最深的体会是AI生成测试用例这件事技术门槛其实不高真正的分水岭在Prompt设计和输出解析是否扎实。你花一小时把提示词调好后面每天都能省下两三个小时重复劳动。现在我的做法是把这条管线做成一个Web服务测试同学在页面上粘贴需求描述点一下按钮就拿到Excel用例包。如果你也想复用这套逻辑建议先按文章里的代码跑通单条用例再逐步加上批量处理、模板切换这些外围功能。踩过几次坑之后你会发现AI不是要取代测试工程师而是帮我们把时间从“写用例”挪到“想测试策略”上去。本文还有配套的精品资源点击获取
