简介《Req2TestCase 操作手册》是一份面向测试人员、产品经理、业务分析人员与实施人员的 AI 工具操作指南重点解决从 PRD、自然语言需求、Office/PDF 文档和图片中自动提取需求点并生成功能测试用例的问题。文档系统讲解了模型配置、需求文档导入与 OCR 识别、需求点预分析、长文档分段生成、需求覆盖矩阵、用例质量检查、缺口补齐、历史版本对比及多格式导出等完整流程。资源为单个 docx 文件大小约 7.4MB包含界面截图、配置表格和详细的步骤说明适合按手册边看边操作。已有 182 人学习下载。手册还针对常见问题提供了排查思路覆盖 DeepSeek、豆包、千问、智谱 GLM 等多模型接入以及本地 OCR 和扫描型 PDF 识别等关键能力可帮助读者快速上手工具提升测试用例编写效率与需求覆盖率。1. 从需求文档到测试用例为什么 AI 工具先该做“翻译”而不是“生成”需求文档几十页评审会上测试最难回答的问题从来不是“这个功能怎么测”而是“这条需求里到底藏着几件事”。AI 自动化识别需求文档并生成测试用例很多人以为是让大模型替人写步骤真正落地后你会发现它省下最多时间的环节是清点需求、对齐规则、补漏异常场景。下面要讲的就是把这条链路跑通的做法——先用确定性的结构切分再做字段级语义识别最后把结构化条目展开成可执行用例并且能在评审时拿得出手。适合手头有 PRD、用户故事、SRS 等来源、想用 AI 给测试做提效又不希望产出变成黑匣子的团队。2. AI 识别需求文档先分结构再谈语义2.1 需求文档为什么没法被“直接读懂”大多数团队的第一反应是把整份需求文档丢给大模型让它“读完”后直接输出用例。这个做法在 demo 上很惊艳放到真实项目里通常撑不过两轮评审。原因在于需求文档不是为机器设计的PRD 里大量使用自然语言、表格、流程图混排SRS 的约束往往藏在“应”条款的拗口表述里同一语义在不同文档里有完全不同的写法“必填”“不得为空”“不允许为空”指向同一个校验规则但字面差异极大。还有一类更难处理的隐性规则。比如“用户在提交订单时若余额不足则提示充值”这里“余额不足”是异常分支但文档可能只写了主流程再比如“管理员可修改角色权限但默认角色不可修改”后半句“默认角色不可修改”如果落在“其他说明”一节很多按标题顺序切分的解析方案会直接漏掉。直接全量读文档还会遇到长上下文漂移——同一角色在不同章节叫法不同“用户”“前端用户”“普通成员”其实指同一主体大模型在长文本里对齐这些实体并不稳定抽出来的字段前后矛盾。所以我的做法是把“识别”拆成两个阶段。第一阶段用确定性规则把文档切成有边界的小块保住结构第二阶段再用模型对每个小块做字段级语义抽取而不是让模型一次面对整篇文档。这样做的另一个好处是可审计任何一条生成结果都能追溯到原文的某个章节或某句话评审时有据可查。2.2 一个可复现的抽取框架从文档到需求条目四要素常见做法是先把文档统一成带标题层级的文本然后按标题切块再把每个块切成候选句。我一般会维护一个极简的四要素数据结构——角色、动作、业务规则、前置条件每一个候选句都往这四个槽位里填。下面这段代码是结构切分和候选句抽取的骨架能在本地直接跑通。import re from dataclasses import dataclass from typing import List dataclass class ReqItem: role: str # 谁用户 / 管理员 / 系统 action: str # 做什么提交 / 审批 / 下载 rule: str # 业务规则金额上限、必填约束 pre_cond: str # 前置条件登录态、角色权限 source_line: str # 原始句子便于回溯评审 ROLE_SEED [用户, 管理员, 财务, 客服, 系统] CONSTRAINT_HINT re.compile(r(必须|不允许|不得|需要)) ACTION_HINT re.compile(r(提交|查询|下载|上传|审批|拒绝|发起)) def split_doc_by_heading(md_text: str) - List[str]: 按 Markdown 标题层级把整篇文档切成小节块 lines md_text.splitlines() blocks, cur [], [] for ln in lines: if ln.startswith(#): if cur: blocks.append(\n.join(cur)) cur [] cur.append(ln) if cur: blocks.append(\n.join(cur)) return blocks def extract_candidates(block: str, role_words: List[str] ROLE_SEED) - List[ReqItem]: 把一个小节切成候选需求条目只保留有动作或约束的句子 sents re.split(r[。\n], block) items [] for s in sents: # 强约束词优先命中“可以”多为说明性文字先跳过 if CONSTRAINT_HINT.search(s): pass elif ACTION_HINT.search(s) and 可以 in s: continue elif ACTION_HINT.search(s): pass else: continue role_hit [w for w in role_words if w in s] role role_hit[0] if role_hit else 未识别角色 items.append(ReqItem( rolerole, actions.strip(), rule, pre_cond, source_lines.strip(), )) return items逻辑上要注意几点。切块这一步解决的是上下文边界问题模型不需要读完整份文档只需要读一个小节这能显著减少实体错乱。候选句过滤用“强约束词优先、动作词兜底”的策略是因为需求文档里“点击后可以查看”“用户可以浏览”这类说明性句子数量庞大如果全部收进来后面的生成阶段会被无效条目淹没。ROLE_SEED 不能照抄要按自己团队的领域词维护比如电商项目加“商家”“运营”金融项目加“复核员”“风控”。ACTION_HINT 里的词也不是越多越好动作词太泛会导致召回爆炸太窄又会漏需求建议从现有需求文档里统计出现频率最高的二十个动词作为初始表。注意这套粗切分对 Markdown 和 HTML 结构友好的文档有效。如果需求文档是扫描版 PDF先做 OCR 再进入管道否则小节的标题层级会丢失切块结果会乱。2.3 什么时候必须上模型做抽取确定性规则能切出结构但填不了四要素里的业务规则和前置条件。尤其是两种情况必须交给模型一是规则不在句子表面而是藏在表格或隐式默认里二是一个需求条目包含多个分支比如“若订单金额超过 500 元则走人工审批否则自动通过”这种句子必须拆成两条独立条目否则后续生成用例时分支会被并掉。这是我在字段抽取阶段常用的提示词模板按 JSON 数组输出方便直接接管道。你是一名测试需求分析师。下面是一段需求文字请抽取测试用例需要的四要素 角色、动作、业务规则、前置条件。 约束 1. 业务规则要单独列出不要混在动作描述里 2. 一个句子里有多个分支时拆成多条输出 3. 无法从原文确定的信息写“待确认”不许编造 4. 只输出 JSON 数组不要解释。 原文 {source_text}这里有两个设计是踩过坑后加上的。强制拆分支是为了防止模型把“如果 A 则 B否则 C”合并成一条用例一旦合并异常分支就永久丢失。强制写“待确认”则是为了防幻觉模型在信息不全时非常乐于补一个看似合理的前置条件而这种补全在评审会上根本站不住脚。结构化输出用 JSON 数组而不是带格式的文本是因为下一步的场景展开脚本需要稳定的字段入口。3. 从结构化条目到测试用例三视图生成与三个关键参数3.1 为什么不是“一条需求一条用例”如果上一步抽取出的需求条目有 120 条就直接生成 120 条用例这个方案在评审时会很快被推翻。因为需求条目描述的是“系统应该做什么”而测试用例描述的是“系统在各种条件下必须表现成什么样”。一条需求至少对应正常流、异常流、边界三种视角正常流验证主路径异常流验证约束被违反时系统是否有明确提示边界流验证数值、状态、权限的临界点。这个三视图模型不是新东西它等于等价类划分加边界值分析加异常流设计。真正的问题是绝大多数需求文档只写了正常流评审会也默认只聊正常流导致异常和边界长期靠测试个人的经验弥补。AI 生成的价值就在这里把展开异常场景变成默认动作而不是靠某个人想起来。3.2 用例生成的中间表示从需求条目到测试场景为了不让生成逻辑散落各处我一般会先用一个中间结构把需求条目映射成测试场景再做渲染。这个结构的核心是保留 trace——从用例到需求原文的溯源链路后面的覆盖率统计和评审都靠它。import json def build_scenario(role: str, action: str, rule: str, pre: str) - dict: 把一个需求条目展开为正常 / 异常 / 边界三个可执行场景 return { requirement_line: action, trace: { role: role, rule: rule, pre: pre, }, scenarios: [ { view: normal, steps: [f预置{pre or 待确认}, f{role}发起{action}], expected: f在满足[{pre or 待确认}]的前提下 f系统正常受理{action}按规则[{rule or 无}]返回结果, }, { view: abnormal, steps: [f预置{pre or 待确认}, f{role}发起{action}但违反约束条件], expected: 系统拒绝处理并给出明确提示不产生脏数据, }, { view: boundary, steps: [f预置{pre or 待确认}, f在边界值条件下发起{action}], expected: 系统按边界规则正确处理不产生越界结果, }, ], }中间表示的设计意图很直接scenarios 是按视图展开的用例雏形后续要对接测试管理平台时再从这里渲染用例标题、步骤、预期结果等字段没必要在一开始就生成全套用例字段那样只会让输出难读难维护。trace 字段是整条管道的锚点评审时任何一条用例都能反查到它来自哪句需求。边界场景里的“边界值条件”不会自己出现它来自 rule 字段里的数字约束。如果规则里写了“订单金额超过 500 元需人工审批”那么边界场景应该自动生成“金额恰为 500 元和 500.01 元”两条如果规则里没有数字边界场景就退化为“临界状态下的正常流程”。这一步目前没有完全通用的解法常见做法是在抽取阶段用正则把金额、次数、时长等数字约束单独提出来再在展开阶段生成边界值对。3.3 生成策略里最关键的三个参数同样是生成参数设置不同结果可能是“120 条用例覆盖完整”和“500 条用例没人看”的差别。下面是三个必须调整的参数。参数推荐初始值调参方向失衡表现分支拆分阈值一个句子出现 2 个及以上“或/若/否则”时强制拆条文档分支多但场景粒度粗时调低用例数量爆炸评审看不完边界值来源优先取需求原文中的数字约束上线后补充系统隐含限制只测文内数值漏测默认值边界去重键角色 动作 规则规则缺失时退化为角色 动作多条相同规则重复出用例分支拆分阈值是最容易失衡的参数。拆得太粗异常分支被并进正常流程生成结果看起来数量少覆盖率报表却很难看拆得太细一段“若 A 且 B 则 C”会被拆成多条近似的条目后续还要花额外成本去重。去重键改成“角色 动作 规则”三元组是为了防止两个动作不同但语义相同的需求被判重——比如“提交”和“递交”字面不同动作相同如果只按动作去重就会把两条需求误合并。4. 工程落地把工具链做成可审计的管道4.1 一条最小可复现的处理管道把前面几章拼起来就是一条五阶段的管道文档归一化、结构切分、字段抽取、场景展开、覆盖核验。第一步最容易被人跳过但也是翻车率最高的一步。docx、HTML、扫描 PDF 混在一起时不做归一化直接进切分标题层级和表格内容都会丢失。# 文档归一化把 docx 和 html 统一转成纯文本 pandoc -f docx -t plain requirements.docx -o requirements.txt # html 转成 gfm 而不是 plain保留标题层级给切分步骤用 pandoc -f html -t gfm requirements.html -o requirements.md # 转完先肉眼扫一遍乱码和表格丢失再进下一步转换完后要人工抽查一次重点看两项表格内容是否被压成一行导致单元格错位特殊符号是否变成乱码。这两类问题不会报错但会让后续抽取结果静默变差。结构切分和字段抽取分别复用 2.2 节的切块脚本和 2.3 节的提示词场景展开调用 3.2 节的 build_scenario最后做覆盖率核验。4.2 覆盖率怎么量化需求条目覆盖率与规则覆盖率覆盖率这个数字很容易造假所以要把口径定死。我一般统计两个指标需求条目覆盖率即有多少需求条目生成了可执行场景规则覆盖率即有多少业务规则被至少一条用例的预期结果捕获。第二个指标比第一个重要因为需求条目可以完整但规则漏光。def coverage_report(items: List[ReqItem], cases: List[dict]) - dict: # 需求条目覆盖率用“角色 动作”作为对齐键 total {i.role i.action for i in items} covered {c[trace][role] c[trace][action] for c in cases} item_rate len(covered total) / len(total) # 规则覆盖率所有非空的 rule 是否被任意一条用例的 trace 捕获 rule_untested [] for i in items: if not i.rule: continue hit any( c[trace][rule] and i.rule in c[trace][rule] for c in cases ) if not hit: rule_untested.append(i.rule) return { item_coverage: round(item_rate, 3), rule_untested: list(set(rule_untested)), }关键在 rule_untested 的输出。覆盖率报表里最值得看的就是这个列表它直接告诉你哪些业务规则没被任何用例断言覆盖。实际跑管道时经常出现需求条目覆盖率 100%、但 rule_untested 里躺着七八条金额和状态约束的情况——这些就是评审会上会被业务方追问的漏测点。对齐键用“角色 动作”而不是用例 ID是为了让统计不依赖外部测试管理平台纯本地脚本就能出数。4.3 质量门禁清单生成结果不能直接进用例库要先过一道质量门禁。我习惯把门禁做成一张检查表挂在管道末尾不通过就不允许入库。检查项通过标准需求条目覆盖率不低于 95%且不存在“未识别角色”的条目异常场景缺失所有含约束字的条目都有 abnormal 场景规则字段非空金额、状态、权限类规则的条目必须填 rule 字段来源可回溯每条用例能定位到原文小节或行号提示覆盖率是给人评审用的不是给机器看的。门禁不通过时不要自动入库宁可多一轮人工复核也不要让评审会上出现一条无法解释来源的用例。5. 避坑把 AI 生成用例推向团队时的四个现实问题5.1 同义词把两条不同需求合并成了一条现象去重时把“审批通过”和“审核通过”判定为重复需求结果只生成了一条用例。评审时被业务方指出这是两条独立流程一条走项目经理审批另一条走财务复核。原因最初为了控制用例数量用了文本相似度去重。两个动作词高度相似语义距离很小但它们在系统里指向完全不同的业务节点。解决去重键从“动作文本相似度”改成“角色 动作 规则”三元组。规则字段由模型显式输出不依赖原文词面。比如“审批通过”和“审核通过”如果角色不同、规则不同就不会被合并。这里要警惕的是三元组也有失效的时候——当某条需求的 rule 恰好为空时退化的二元组又会出现误合并风险所以门禁里加了一条规则字段缺失的条目单独抽查。5.2 生成的用例看起来对跑起来错现象AI 生成的用例步骤和预期结果写得很完整但测试照着执行时发现前置数据根本不存在。比如用例要求预置“已注册且完成实名认证的用户”而测试环境根本没有实名认证入口。原因抽取阶段没有解析出前置条件模型在生成时用隐含假设补了一个合理的 pre_cond。这个补全非常自然人眼根本看不出问题但对于执行环境的真实性没有保障。解决把 pre_cond 改为必填字段提示词里明确“无法从原文确定时写待确认”并在质量门禁中拦截任何 pre_cond 为空的用例。如果“待确认”字段大量出现说明需求文档本身缺失前置条件信息这时候应该回填文档而不是放行用例。5.3 需求文档一换模板工具就翻车现象团队把需求文档从“角色-动作”叙述式 PRD 换成表格化的 SRS 后抽取命中率从九成骤降到五成大量需求行直接消失。原因结构切分规则绑定了 Markdown 标题层级按一级标题和二级标题切块。表格化 SRS 的需求行都在表格单元格里根本没有标题层级切块阶段就把它们丢弃了。解决解析层把表格内容也纳入候选输入源。具体做法是在切块之前先做一步表格展开把每行的结构转成“角色-动作-规则”的候选三元组再进入后续流程。这个改动要从模板层面固化需求模板一旦确定解析规则就跟着模板走不要指望一套切分规则兼容所有文档格式。5.4 强行全自动导致没人敢接手现象管道跑通后直接把生成结果批量导入了用例库评审会上每个人都在追问“这条用例哪来的”“这个预期结果谁写的”最后全部回滚。原因缺少可审计的溯源链路。生成结果虽然正确但用例库里的每条用例没有指向原文的链接评审会无法验证工具变成了一个不可信的黑匣子。解决trace 字段和来源行号要一直在管道里传递最终落到用例库的自定义字段上。门禁检查不只看覆盖率还要看“每条用例是否有原文链接”。首次上线建议拿一个模拟项目 X 的旧需求文档做回归试点先跑一批对照数据让团队看到生成结果和人工用例的差异在可接受范围内再铺开到正式项目。6. 验证生成质量两表核对法堵住“看起来覆盖了”的漏洞覆盖率数字并不能说服评审。真正有用的验证方法是两表核对法把生成结果重新聚合成两张表人工只看聚合后的行不看原始用例列表。表关键字段作用需求条目清点表需求 ID、角色、动作、关键规则、生成用例数确认需求清单和 AI 识别结果是同一本账用例溯源表用例 ID、场景视图、需求 ID、断言要点核对每个需求展开了哪几类场景做法是把生成用例按需求 ID 重新聚合。清点表里的“生成用例数”一列能快速暴露漏测正常的需求至少对应三条用例如果一个需求只有一条 normal 场景没有 abnormal 和 boundary那它几乎一定有问题。溯源表里的“场景视图”则用来核对异常分支是否真的拆开了——如果某条需求在抽取阶段被拆成了两个分支但溯源表里只出现一条记录说明分支被合并了需要回查提示词。两表的读取顺序是先看清点表找出“生成用例数为 0 或为 1”的需求再看溯源表对照“关键规则”列确认每条数字约束都被某条用例的断言要点捕获。这个核对过程十分钟就能完成但能挡住九成以上的漏测和误合并。我刚开始推这套方案时迷信全自动第一周就被业务追着一个漏掉的异常场景问了两轮后来把“先出清点表、再过溯源表”变成固定动作工具才算真正在评审会上站得住脚。这个习惯保留至今也建议你从第一天就养成。希望帮到你。本文还有配套的精品资源点击获取