简介这是一款面向测试人员、产品经理及业务分析人员的 Windows 桌面工具用于将 PRD、自然语言需求、Office/PDF 文档及图片需求自动转换为结构化功能测试用例。工具支持 DeepSeek、豆包、千问、智谱 GLM 及 OpenAI 兼容接口内置本地 OCR、需求点预分析、长文档自动分段、需求覆盖矩阵、用例质量评分、缺口补齐、历史版本对比与多格式导出等能力。资源包含 1 个 docx 操作手册约 7.4MB内容覆盖安装启动、模型配置、文档导入、OCR 识别、生成结果查看、用例编辑补齐、历史对比及导出说明并附常见问题排查方法。该手册面向实际使用场景步骤清晰、截图完整便于快速上手与落地部署目前已有 179 人学习下载适合需要在本地搭建 AI 测试用例生成流程的团队或个人参考。1. 需求文档自动转测试用例先看看这块“AIQA”能做多深前阵子接了个紧急版本需求文档一百多页光“用户点击分享后生成链接”这种半句话评审会上就能吵十分钟。以前拉测试用例一个人对着文档坐一下午产出还老漏场景。我把这套“AI自动化识别需求文档生成测试用例工具”跑了一遍需求文档先按章节切块再交给本地部署的AI接口识别关键信息最后按统一模板批量生成用例初稿。核心思路是规则做约束、AI做语义理解生成结果不直接上回归而是当人工审核的加速器。如果你是测试工程师、测试开发或者被大量PRD逼疯的质量负责人这篇文章值得往下看。下面按“原理—预处理—生成—排查—进阶”的顺序把每个环节的参数和坑都拆开。2. 核心原理规则与LLM双路线为什么我选了LLM主导2.1 先把“自动化识别需求文档”这件事拆开所谓“AI识别需求文档”本质上做的是两件事第一是从非结构化文本里抽信息第二是把抽出来的信息补成测试用例需要的结构。前一件靠格式解析后一件靠语义理解。需求文档通常是Word或Markdown里面混杂了目录、修订记录、业务背景、接口说明、操作步骤。要让AI稳定产出用例第一步就得让文档变得“像食材一样干净”。规则驱动是很多老测试工具的思路写死一堆正则比如“点击”“输入”“选择”“应显示”“预期”这些关键词一旦出现就把它所在的句子抓出来当操作步骤或预期结果。这种方法在格式高度统一的PRD里非常好用零幻觉执行速度快早期常见做法就是纯正则抓取抓一个“步骤”“预期结果”这种带标签的段落几乎百发百中。但一旦需求写成大白话比如“用户在列表页勾选多条数据后点击批量导出按钮系统要能正常生成文件”传统正则就抓瞎了。import re # 理想情况需求按“步骤xxx”和“预期xxx”写 step_pattern re.compile(r(?:步骤|操作)[:]\s*(.)) exp_pattern re.compile(r(?:预期|预期结果|验证点)[:]\s*(.)) text 步骤点击批量导出按钮\n预期系统生成Excel文件 step_match step_pattern.search(text) exp_match exp_pattern.search(text) print(step_match.group(1) if step_match else None) # 点击批量导出按钮 print(exp_match.group(1) if exp_match else None) # 系统生成Excel文件这段代码的逻辑很清楚用两个正则分别匹配“步骤”“预期”两个关键字后面的内容。参数上需要注意中文需求文档里冒号经常混用全角“”和半角“:”正则里要把两种都写进去如果文档里写的是“操作要求”“结果校验”这类变体标签这段正则立刻失效。它的定位是给LLM做“兜底”而不是单独扛起整个解析任务。2.2 LLM理解能力强但必须给它套上笼头LLM路线的优势在“语义补全”。同样一句“用户点击分享后生成链接”规则只能拆出“点击分享”和“生成链接”两个动作但如果有经验的测试看到这句话一定会追问链接有效期多久无权限用户点分享会怎样链接被多次复制会不会失效这些补充场景靠正则写不出来只能靠模型推理。我在这套工具里的默认策略是“LLM主导生成、规则兜底校验”。生成侧把需求片段和一段结构化的系统提示词一起发给模型让它输出固定格式的JSON数组校验侧先做JSON格式解析再做必填字段检查步骤为空或预期结果为空的条目一律返回重试重试一次仍失败就标记成“人工补充队列”绝不让脏数据混进导出文件。# 调用OpenAI兼容接口的示意代码 client OpenAICompatClient(base_urlhttp://localhost:8080/v1, api_keylocal) resp client.chat.completions.create( modellocal-llm, messages[ {role: system, content: SYSTEM_PROMPT}, {role: user, content: block_text} ], temperature0.2, top_p0.9, max_tokens1500, ) raw resp.choices[0].message.content参数选型上temperature设0.2是为了让模型尽量贴着原文生成不要自由发挥太远max_tokens设1500是给一次生成3到8条用例留足空间如果片段特别长可以提到2000。top_p保持0.9属于“允许一点发散但不失控”的折中值。常见误用是拿默认对话模型的temperature0.7直接跑结果同一段需求两次生成完全不一样后面去重时头大。2.3 工具整体工作流与各模块边界整个流程分成六段文档解析、文本清洗、场景切块、LLM生成、格式校验、结果导出。文档解析负责把Word/PDF/Markdown统一转成纯文本文本清洗负责去掉目录、页眉、修订记录这类噪音场景切块决定哪些文本作为一个整体送给模型LLM生成负责任务的语义理解和用例初稿格式校验把模型的自由输出拉回标准结构导出模块把用例写成Excel或JSON方便人工审核和后续导入用例管理平台。阶段输入输出主要风险文档解析原始PRD纯文本图片型PDF文字丢失文本清洗纯文本干净文本把正文当页眉删掉场景切块干净文本文本块切块切碎业务场景LLM生成文本块JSON数组幻觉、重复、格式乱格式校验JSON数组结构化用例字段缺、步骤空结果导出结构化用例Excel/JSON编码错、字段映射错这套工作流的边界感很重要切块决定了模型“看什么”Prompt决定模型“怎么写”校验决定“能不能出去”。很多翻车不是模型不够聪明而是前一步切块把场景切碎了或者后一步校验没拦住脏数据。3. 需求文本预处理清洗、切块与关键信息抽取3.1 文档清洗先把PRD里的噪音清掉我不建议直接把Word转出来的原文丢给模型。PRD里普遍有目录、页码、修订历史、评审意见、密级页这些内容跟业务功能没有关系模型读到后容易把“作者某某”“版本V1.2”当成用例素材。清洗做得好后面的生成质量能提升一个档。最常用的清洗手段是按行过滤配合少量关键词规则。def clean_doc_text(raw: str) - str: lines raw.splitlines() cleaned [] for line in lines: s line.strip() if not s: continue # 去掉“1.1 概述 .... 5”这类目录行 if re.search(r^[\d\.]\s\S.*\.{2,}\s*\d$, s): continue # 去掉页眉页脚与安全声明 if s.startswith((项目编号, 文档密级, 修订记录, 审批记录)): continue # 删除评审意见里的“【评审】”段落 if s.startswith(【评审】): continue cleaned.append(s) return \n.join(cleaned)这段代码的过滤顺序是有讲究的先删空行再删目录再删文档元信息最后删评审痕迹。目录行的特征是标题文字和页码之间有一串省略号正则里用\.{2,}匹配页眉页脚固定前缀可以做成配置列表因为不同项目的PRD模板不一样。特别提醒不要用全局正则把所有“版本”字样都删掉正文里出现“版本升级后”就是正常业务描述误删会直接丢功能信息。3.2 按业务场景切块chunk_size和overlap的参数怎么选清洗完之后是切块。切块的目的是让每次喂给模型的文本足够聚焦同时不超出模型的上下文窗口。实际项目中我常用“先按标题切再按长度兜底”的两级策略如果需求文档有明确的章节结构直接按一级标题、二级标题把文本拆成业务块如果文档是流水账式描述就按句号和换行做分段再用最大长度做二次强制切割。def split_into_blocks(text, max_chunk800, overlap80): # 匹配“第一章”或“1.1 概述”两种标题写法 headings list(re.finditer(r(?m)^(第[一二三四五六七八九十][章节]|[\d\.]\s\S), text)) blocks [] for i in range(len(headings)): start headings[i].start() end headings[i 1].start() if i 1 len(headings) else len(text) seg text[start:end].strip() if len(seg) max_chunk: # 超长块按句号二次切分 for sub in re.split(r(?[。]), seg): if sub.strip(): blocks.append(sub.strip()[:max_chunk]) else: blocks.append(seg) # 相邻块拼接时保留overlap避免上下文断层 merged [] for b in blocks: if merged and len(merged[-1]) len(b) max_chunk overlap: merged[-1] \n b else: merged.append(b) return merged参数上max_chunk设800字是我在本地部署模型上的习惯值上下文窗口小一点的模型就降到500窗口大的可以放到1500但要考虑生成时max_tokens也要跟着调整。overlap设80字作用是把上一段的结尾带进下一段防止模型切断了上一段的逻辑。常见误用是把overlap设为0结果“点击提交按钮系统校验通过后跳转详情页”被切在两块里第二块只有“跳转详情页”生成用例时完全没有操作入口。3.3 关键信息抽取哪些字段该用正则哪些该交给模型切块之后还需要给每块补上“元信息”需求编号、所属模块、需求标题、前置条件、操作步骤、预期结果、用例类型、优先级。这里的原则是“能正则就正则正则认不出来再交给模型”。def extract_fields(block_text, module_name默认模块): fields { module: module_name, req_id: None, title: None, precondition: None, steps: [], expected: [], } # 需求编号通常是“REQ-2024-001”这类格式 req_id re.search(r(REQ[-_]\d{4}[-_]\d{3,}), block_text) if req_id: fields[req_id] req_id.group(1) # 步骤优先匹配带编号的“1. 点击xxx”列表 steps re.findall(r(?m)^\s*\d[\.、]\s*(.), block_text) if steps: fields[steps] steps return fields这里我用正则先抓需求编号和编号列表步骤抓不到的部分在后续生成阶段会由Prompt里的规则补。为什么不全部交给模型因为模型抽取字段的延迟和成本比正则高得多而且对“REQ-2024-005”这种固定格式正则100%命中模型偶尔还会写错成“REQ2024005”。反过来前置条件和隐含分支这种正则永远写不出来的字段就必须靠模型补全。实际经验是固定格式字段10个里9个用正则可以搞定剩下一个正则搞不定的往往是文档里同时出现多个需求编号模型在这里反而比正则灵活。4. 测试用例批量生成Prompt设计、参数配置与输出校验4.1 Prompt模板把用例结构焊死在系统提示词里AI生成用例决定输出质量的第一因素不是模型而是Prompt。一个松散的Prompt会让模型自由发挥输出“验证一下XX功能”这种毫无操作性的废话而把用例结构、覆盖策略、禁止事项全部写清楚模型才会老老实实输出可执行的用例。我在工具里用的系统提示词大致是这个样子SYSTEM_PROMPT 你是资深测试工程师请根据需求片段生成测试用例。 只输出JSON数组不要输出解释或Markdown。 每个用例包含以下字段 case_title: 用例标题 case_type: 正常流/异常流/边界流 precondition: 前置条件可为空字符串 steps: 操作步骤数组每步必须是可执行的操作 expected_result: 预期结果 priority: P0/P1/P2 要求 1. 每个片段生成3到8条用例优先覆盖正常流、异常流、边界流 2. 所有步骤和预期结果必须能在需求片段中找到依据 3. 找不到依据的预期结果写“待确认”不要编造功能 4. 没有操作内容的需求片段输出空数组。这个模板有几个关键设计。第一把“case_type”限定为三种固定值便于后续统计和过滤第二明确“找不到依据写待确认”有效压制幻觉第三允许输出空数组避免背景章节强行生成用例。很多新手会在system里写一堆形容词比如“请仔细分析需求并生成高质量用例”模型无法精确理解什么叫“高质量”不如直接限定格式和数量。4.2 模型生成参数temperature、top_p、max_tokens怎么设参数推荐值说明设置过高/过低的后果temperature0.2控制随机性过高用例重复发散、过低照抄原文不补场景top_p0.9控制候选词范围过高胡说八道、过低丢失边界场景max_tokens1500~2000单次输出长度上限过短步骤被截断、JSON被截成残文frequency_penalty0.3抑制重复词过高术语被改写、过低步骤反复出现temperature是这里最值得调的参数。用例生成本质上是要在“忠于原文”和“适当补全”之间找平衡我实际跑下来0.2到0.3是最稳的区间。调到0.7以上模型有时会把同一条用例换个说法输两遍或者为“点击按钮”脑补出“点击后弹窗确认”这种需求里没有的交互。max_tokens的设置要跟切块长度联动800字的需求片段配1500的max_tokens一般够用但如果提示词里要求覆盖异常流和边界流单次输出8条用例可能会超保险起见给到2000。4.3 批量生成与导出循环、重试、字段校验批量生成的骨架是一个循环每个文本块依次调用模型接口解析返回结果做字段校验最后合并落盘。关键不在循环本身而在三个容易被忽略的点单块失败不能中断全流程、模型输出经常带Markdown代码块包裹、必填字段缺失必须能自动识别。def batch_generate(blocks): all_cases [] failed_blocks [] for idx, block in enumerate(blocks): try: raw call_llm(block, SYSTEM_PROMPT) cases parse_json_from_llm(raw) valid [] for c in cases: # 必填字段校验步骤和预期结果不能空 if not isinstance(c.get(steps), list) or len(c[steps]) 0: continue if not c.get(expected_result): c[expected_result] 待确认 valid.append(c) all_cases.extend(valid) except Exception as e: failed_blocks.append({idx: idx, error: str(e), block: block[:200]}) return all_cases, failed_blocks逻辑说明call_llm负责拼参数、调用接口、返回原文parse_json_from_llm专门处理模型输出可能带的json包裹或前后解释文字取第一个被方括号包住的片段做json.loads校验阶段用两步过滤第一步剔除steps为空的残条第二步把空预期结果替换成“待确认”。参数说明failed_blocks只保留前200字预览避免错误日志里塞满整段需求导致日志文件膨胀。校验通过的用例可以导出成Excel。导出时字段顺序固定为模块、需求编号、用例标题、用例类型、前置条件、步骤、预期结果、优先级。这样人工审核时只需要对照需求文档在Excel里逐行看不需要额外学习工具的输出格式。另外连接池和超时也值得单独说批量跑几百个块时把并发控制在3到5个单请求超时给到90秒超过就重试一次再失败进人工队列比一味把并发开到10然后整批超时稳定得多。5. 避坑排查生成结果错的五种典型翻车现场5.1 现象JSON解析一直失败批量任务卡在第一步初跑这套流程时批量生成跑到十几块就停日志报“json.decoder.JSONDecodeError: Expecting value”但单独调接口又是正常的。排查后发现模型返回的内容前后各包了一个json和json.loads直接看到的是反引号。这类输出是模型基于训练习惯带出来的跟模型版本和温度都有关系几乎不可避免。解决方式是在解析函数里先剥掉代码块标记再提取第一个完整数组片段。def parse_json_from_llm(raw): raw raw.strip() # 剥掉json ...包裹 if raw.startswith(): raw re.sub(r^[a-zA-Z]*\n?|\n?$, , raw) start, end raw.find([), raw.rfind(]) if start -1 or end start: raise ValueError(no array found) return json.loads(raw[start:end 1])这段代码先用正则去掉代码块包裹的开闭标记再用首尾方括号截出数组主体。经验是不要一上来就全套json.loads先把最外层的Markdown剥掉能解决九成解析失败。5.2 现象模型把“需求背景”当功能生成了一堆重复用例某次处理一个后台系统的PRD第一章叫“项目背景”里面写了几段业务目标。模型把“系统需要支持高并发访问”这句话理解成需求生成了一堆“验证系统在高并发下的表现”这种无法直接执行的用例而且好几条内容几乎一样。原因是切块时没有过滤背景类章节模型拿到无操作内容的文本又被要求“生成3到8条用例”只能硬编。解决分两步清洗阶段维护一个标题黑名单把“项目背景”“名词解释”“非功能需求”这类常见章节过滤掉Prompt里同时加上“没有操作内容的需求片段输出空数组”这条硬约束。双保险后这类重复基本绝迹。5.3 现象长文档后半段用例整体缺失只看到前置条件没有步骤还有一次是处理一份超过2万字的需求文档切块时max_chunk设到了1500结果后半段的块经常只有前置条件没有操作步骤甚至出现一个块只输出一条用例的情况。检查发现模型的上下文窗口被长片段撑满输出被截断JSON在“steps”字段处断掉校验时把steps非空的残条也放行了。解决方式是降低max_chunk到700overlap提到100同时在校验逻辑里增加一条steps为空或只有一条的用例强制加入人工复核队列。从此之后长文档的丢失率从三成降到个位数。5.4 现象模型编造功能把“应提示”脑补成“弹窗确认”需求原文写的是“输入非法格式时系统应提示错误”模型生成的预期结果却是“系统弹出确认弹窗用户在弹窗中点击确认后关闭页面”。这种幻觉很隐蔽表面看流程完整实际上加了需求里根本不存在的交互回归时照着用例做反而会把系统带偏。原因在于Prompt里没有对“依据”做限制模型默认按常见产品交互补全。解决方式是在system里写明“所有步骤与预期结果必须能在需求片段中找到依据找不到依据的预期结果写‘待确认’”同时在审核状态下增加一个“AI补全标记”字段凡是模型自己补出来的前置条件和分支导出时就标成黄色人工审核时重点看黄色行。5.5 现象批量跑批超时生成率只有六成还不报错跑一个包含两百个文本块的需求集耗时半小时过程没报错结果只导出了六成用例。排查后发现问题出于并发过大同时开10个请求本地模型接口连接被重置异常被外层循环捕获后记录进failed_blocks但日志没细看导致生成流程“假成功”。解决方式是引入并发信号量限制为3并把失败重试逻辑改成先休眠再重试最多两轮仍然失败才进人工队列。另外把每批结果实时落盘成JSON即使中途进程被杀已经生成的用例也不会丢。后来我每次跑批都会盯三个数字成功块数、失败块数、重试次数三者加不拢就说明有静默丢弃。6. 进阶玩法把生成的用例变成可持续复用的回归资产单次批量生成只是第一步用例资产要能跨版本复用还得做三件事。第一给每条用例打上“需求编号版本号”标签。需求文档不是一成不变的下一版本只改一个字段全量重跑会生成大量重复用例。我在工具里约定录入新版本时先做文本差异diff只把变更的文本块重新喂给AI生成旧版本的用例保留在回归集里。第二对跨版本积累的用例做去重合并。Excel里常有两个版本生成出标题不同但步骤完全相同的用例我用“模块步骤列表的hash值”做判重步骤完全一致就直接合并保留优先级高的那一条避免回归集越来越大全是重复。第三把人工审核状态沉淀成字段已审核、待审核、AI待确认每次提测前强制过滤“待确认”用例。在用例管理平台导入时按模块字段自动映射到对应测试计划目录省掉手动调整目录层级的时间。字段生成初值审核后改需求编号正则抽取人工修正版本号当前文档版本后续版本迭代更新审核状态待审核已审核/待确认AI补全标记是/否人工复核后清除最后讲一件我自己的血泪教训一次回归测试图省事直接用了AI生成的初稿没做人工复核漏掉了“token过期”这个分支场景上线后线上才暴露出来。从那以后我每次跑新版本需求都强制走一遍“预处理—切块—生成—校验—人工标记”这套流程AI生成的结果只当第一版草稿绝不让它直接上回归。希望这套拆解和参数经验能帮你在测试用例生成这件事上少踩几个坑。本文还有配套的精品资源点击获取