说实话这个需求我太熟悉了。测试同学每周都要干同一件事拿到一份几十页的需求文档咬着牙一句句抠功能点再手动整理成测试点最后用 XMind 画成思维导图去参加用例评审。这个过程非常消耗时间而且重复性极高——大部分工作并不是在“设计”测试点而是在“搬运”需求描述、转换格式。我这个项目想解决的问题就是把最后这个“搬运转换”环节交给 AI 去完成。项目用到的链路是Python 做流程编排Coze扣子做大模型拆解XMind 文件作为测试点输出载体。也就是说我负责把需求文档交给 Coze 的 Agent让它按测试设计的逻辑把功能点拆成结构化的测试用例数据然后写 Python 脚本把这些数据转成一张可以直接在 XMind 里打开、继续编辑的思维导图。整个过程跑通之后一份中等复杂度的需求文档从拿到手到生成初版测试点 XMind基本能控制在几分钟以内。这篇文章我不打算只给结论我会把完整的思路、规划、坑点和实测结果都摊开来说。适合哪些人看第一类是测开工程师想把“用例设计初稿”这个环节工具化第二类是刚接触 Python 和 AI 生态、想做一个能落地的小工具的同学第三类是好奇 Coze 工作流到底怎么跟外部脚本调通的开发者。内容会涉及一些代码但不难跟着走一遍基本都能跑起来。1. 需求文档到测试点为什么一直是效率黑洞先把这个问题的本质拆清楚。测试点整理这件事困难点根本不是最后画图那一步而是从自然语言的需求描述中做“语义提取”和“逻辑补全”。人工做的时候实际上是在执行一个非常隐式的规则找出每个功能模块、每个功能的正常路径、异常分支、边界条件、权限维度、数据约束。1.1 传统人工模式的三个痛点第一是信息损耗。需求文档往往不是一个人写的格式混乱、颗粒度不一有的写得很细有的只有一句话“支持第三方登录”具体指微信、QQ还是全部要测试人员自己去追问产品经理。这时候整理测试点考验的不是测试技能是对文档的“考古”能力。第二是表达不一致。同一个测试点不同测试人员写出来风格差很多。有人喜欢“验证账号为空时点击登录给出提示”有人写“空账号登录场景”。一旦到了用例评审阶段产品和技术要就着 XMind 图反复确认语义沟通成本很高。第三是模板化劳动占比过高。真正需要测试设计能力去构思的场景可能只占 20%剩下 80% 是“把需求描述翻译成 Given-When-Then 结构”的机械操作。而这 80% 恰好是 LLM 最擅长的工作。1.2 为什么选 XMind 作为测试点载体很多团队内部其实不强制要求 XMind有的用 Excel 用例模板有的用在线文档表格。但从评审场景来看XMind 这种树状结构天然比二维表格更适合“先看全貌、再逐点细化”的阅读习惯。评审测试点的时候评审者需要先理解模块之间的逻辑关系再下钻到具体场景。XMind 的层级结构正好能表达“模块 → 子功能 → 测试点 → 步骤与预期”这种四层信息信息密度高展开收起也方便。另外 XMind 文件本身是结构化的这意味着我们完全可以用程序生成它而不是通过 GUI 去手动画。关键问题是怎么让程序高效生成一个真正的.xmind文件同时保证生成的图在 XMind 里打开后结构不乱、能正常编辑。后面我会单独开一节详细讲这个部分这里先留个引子。2. 整体方案设计Coze 当“拆解大脑”Python 做“落地双手”方案设计的核心决策是分工。我不是让 AI 一口气把“需求文档 → XMind 文件”全部做完而是分成两段Coze 负责从需求文档到结构化测试点数据Python 负责从数据到 XMind 文件。这样分开有几个现实原因。2.1 为什么中间要加一层“结构化数据”一开始我试过让大模型直接输出 Markdown 格式的思维导图文本然后写脚本把 Markdown 转成 XMind。效果不理想原因有两个一是大模型以 Markdown 输出时层级容易混乱脑子想的层级和实际输出的#、##、-数量经常对不上二是后续没法做二次处理——比如我要按优先级筛选测试点、按模块排序、统计用例数量文本格式处理起来非常痛苦。正确的做法是让模型输出JSON。JSON 本身就是层级化的天然适配“模块 → 用例 → 步骤/预期”的结构。只要模型按约定的 schema 输出代码这边就能稳定解析后续想过滤、排序、合并都非常顺手。2.2 Coze 在这个链路里的精确角色很多人一听到 Coze扣子第一反应是“那个搭聊天机器人的平台”。对但它远不止聊天机器人。Coze 的核心价值在于可以把大模型、工作流节点、插件、知识库和外部 API 编排成一个可复用的应用并且对外提供 API 接口供程序调用。在我这个项目里Coze 承担的职责是接收Python 端传过来的需求文档全文分段截断后扮演资深测试专家角色按设定的思维框架拆解需求输出符合约定 schema 的 JSON 测试点数据。它像一个“拆解大脑”把非结构化的需求文本转成结构化的用例描述。Python 端不直接调大模型的原始接口而是调 Coze 的工作流 API这样有几个好处Prompt、模型参数、输出格式校验都在 Coze 平台上管理Python 端代码更简单后续调整拆解规则也不需要改代码。2.3 为什么不用编程语言直接解析需求文档懂自然语言处理的同学可能会问为什么不写规则、用正则或者传统 NLP 方法解析需求文档我的回答是能但效果天花板很低。需求文档的表述太灵活了。“用户点击登录后若手机号未注册则提示错误”和“未注册账号不允许登录并给出对应提示”逻辑上是同一件事但表达模式完全不同。规则系统能识别少量固定句式一旦文档风格变化就得改规则维护成本无穷无尽。大模型在语义理解上降维打击了这类问题所以选择大模型是正确的路径。3. Coze 工作流的搭建从需求文档到结构化测试点 JSONCoze 工作流的搭建是核心环节。这块做得好不好直接决定下游生成 XMind 的质量。我把工作流拆成四个节点文档接收、拆解指令、结构校验、结果输出。3.1 工作流节点的顺序与作用第一个节点是“需求文本接收”。它接收 Python 端传来的{ doc_text: ... }参数这没什么技术含量但要特别注意长度限制。Coze 工作流对单次输入的 token 长度是有限制的需求文档很长时必须先在 Python 端做好分段然后分多次调用工作流最后在 Python 侧合并结果。第二个节点是“测试点拆解”这是 LLM 节点。Prompt 是成败关键我最终版本的拆解指令如下按实际使用微调你是一名资深测试设计专家请根据输入的需求文档片段识别出可测试的功能点并按模块分组输出。 每个测试点必须覆盖以下角度之一或组合 1. 正常流程功能的主要成功路径 2. 异常流程输入错误、条件不满足、服务异常等情况 3. 边界场景数据临界值、时间临界值、并发临界值 4. 权限维度不同角色、不同登录态 5. 业务规则文档中明确描述的约束条件。 你的输出必须严格为 JSON不要包含任何解释性文字、Markdown 代码块标记或额外字段。 JSON 结构 { modules: [ { module_name: 模块名称, test_cases: [ { title: 测试点标题一句话描述场景, category: 正常流程/异常流程/边界场景/权限维度/业务规则, priority: P0/P1/P2, precondition: 前置条件没有则写无, steps: [步骤1, 步骤2], expected: 预期结果 } ] } ] } 要求 - 不遗漏文档中的明确功能描述 - 标题务必能独立理解不依赖模块名 - 每个模块下至少拆分出 3 个测试点 - 涉及表单输入的场景必须包含边界和异常分支。这里有一个很重要的经验AI 拆解出的测试点宁可“多而全”不要“少而精”。因为下游生成的是初稿测试人员后续要做的是删减和标注而不是费劲补内容。AI 漏掉一个点相当于全流程白做AI 多列一个点评审时划掉也就一秒钟的事。第三个节点是“结构化校验”。我在 Coze 里加了一个代码节点用来检查 LLM 节点输出的字符串能不能被json.loads解析并且校验modules是否存在、每个test_cases是否包含必填字段。校验失败就回到 LLM 节点重新生成重试两次还失败就原样输出错误信息方便排查。第四个节点是“结果输出”把校验通过的 JSON 以字符串形式作为工作流最终输出。3.2 为什么需要固定输出 Schema这里必须强调一下跟大模型交互输出格式的约束远比输入格式的约束更重要。大模型很聪明地在语义上理解你但在格式上经常“自由发挥”。如果不做强约束你可能会收到 Markdown、带注释的 JSON、甚至把 JSON 拆成好几句自然语言夹带输出。我应对的方法有三层第一层是 Prompt 里写死结构第二层是工作流里加代码节点强校验第三层是 Python 端解析时做容错处理。三层都上整条链路的稳定性才能达到“可以交给同事用”的水平。3.3 长文档的分段策略实际调试时发现需求文档超过一定长度后即使没超 token 上限拆解质量也会明显下降。模型会把后面的内容“敷衍”掉生成的测试点越来越粗糙。我后来在 Python 端做了分段处理按 2000 字左右切成段落片段保留标题作为上下文前缀分段调用 Coze 工作流最后按模块合并 JSON。分段的时候要尽量在“章节边界”处切断别在句子中间硬切。最简单的做法是按\n\n或“第X章”这类标记切。切完每段前面加上[文档章节xxx]的标注能有效提醒模型当前语境。4. Python 侧调用与数据清洗把 LLM 的输出变成可靠数据Coze 那边工作流搭好了接下来就是 Python 这边的活了。整个 Python 脚本我分成了三块配置与鉴权、调用工作流、解析与合并结果。这里面的坑比想象的多。4.1 环境准备与依赖我的开发环境是 Python 3.10Windows 11用到的依赖很少pip install requests pip install xmindrequests不用多说xmind是 Python 下写 XMind 文件的开源库后面会详细讲。为了让代码清晰我把敏感配置放到环境变量里import os COZE_API_TOKEN os.getenv(COZE_API_TOKEN) COZE_WORKFLOW_ID os.getenv(COZE_WORKFLOW_ID)不建议把 Token 硬编码在脚本里容易在分享代码的时候把密钥泄露出去。哪怕只是自己本机用也建议养成环境变量的习惯。4.2 Coze 工作流 API 的调用方式Coze 平台会为每个发布的工作流分配一个 Workflow ID。调用接口的大致结构是 POST 到工作流执行端点请求体里带上workflow_id、parameters即工作流的输入参数和用户标识。我用的是requests直接调不引入 Coze 官方 SDK减少依赖import requests import json def run_coze_workflow(doc_text: str) - str: url https://api.coze.com/v1/workflow/run headers { Authorization: fBearer {COZE_API_TOKEN}, Content-Type: application/json } payload { workflow_id: COZE_WORKFLOW_ID, parameters: { doc_text: doc_text[:2000] # 单段截断具体长度以实际限额为准 } } resp requests.post(url, headersheaders, jsonpayload, timeout120) resp.raise_for_status() result resp.json() # result[data] 通常是一个 JSON 字符串而不是对象 return result[data].get(output, )这里有个非常容易踩的坑Coze 工作流 API 返回的data字段经常是序列化后的字符串而不是可以直接用来取属性的对象。我第一次调试的时候直接result[data][output]结果报 TypeError后来打印出来才发现返回的是字符串里面还包着一层 JSON 字符串。所以解析的时候要连续json.loads两次甚至三次直到拿到真正的字典为止。4.3 调用端的容错与重试大模型调用不可避免会遇到偶发失败网络超时、服务端 5xx、返回内容不符合 schema。我写了一个带重试的包装函数import time def call_with_retry(doc_text: str, max_retries3): for attempt in range(max_retries): try: raw run_coze_workflow(doc_text) data json.loads(raw) validate_structure(data) # 自定义校验函数 return data except Exception as e: print(f[第{attempt 1}次调用失败] {e}) if attempt max_retries - 1: raise time.sleep(2 * (attempt 1)) # 退避等待重试的退避时间用指数退避策略第一次失败等 2 秒第二次等 4 秒避免在服务端已经过载时仍高频打请求。测试下来三次重试能覆盖绝大多数偶发失败场景。4.4 多段结果的合并策略多段文档分别调用后会得到多个 JSON 对象每个对象里有若干模块。合并的时候要注意两个问题一是模块重名比如两段文档都提到“登录模块”二是同一模块下的测试点分散在多次返回中。我的合并逻辑是遍历所有返回结果以module_name为 key 合并test_cases列表合并前对测试点标题做一次去重判断标题完全相同的视为重复。去重逻辑如下def merge_results(results: list) - dict: merged {} seen_titles set() for data in results: for module in data.get(modules, []): name module[module_name] merged.setdefault(name, {module_name: name, test_cases: []}) for case in module.get(test_cases, []): if case[title] in seen_titles: continue seen_titles.add(case[title]) merged[name][test_cases].append(case) return list(merged.values())合并完后我会输出一份test_points.json先在编辑器里肉眼快速扫一遍。这一步很关键因为后续生成 XMind 完全依赖这份数据数据不对图必然不对。5. 生成 XMind 文件的完整实现与踩坑记录前面说了测试点的信息层级是“文档 → 模块 → 测试点 → 步骤/预期”。在 XMind 里对应的就是“中心主题 → 一级主题模块→ 二级主题测试点→ 三级主题步骤/预期”。我最终实现的函数并不复杂但这一步踩的坑比前面所有步骤加起来都多。5.1 用 python-xmind 库生成文件xmind库的基本用法是初始化一个工作簿、拿到画布、设置根主题、逐级添加子主题。我封装了一个build_xmind()函数import xmind from xmind.core.topic import TopicElement def build_xmind(test_modules: list, output_path: str): workbook xmind.Workbook() sheet workbook.getPrimarySheet() root sheet.getRootTopic() root.setTitle(测试点概览) for module in test_modules: module_topic TopicElement() module_topic.setTitle(module[module_name]) root.addSubTopic(module_topic) for case in module[test_cases]: case_topic TopicElement() priority_tag f[{case[priority]}] category_tag f({case[category]}) case_topic.setTitle(f{priority_tag}{category_tag}{case[title]}) module_topic.addSubTopic(case_topic) steps_topic TopicElement() steps_topic.setTitle(步骤) case_topic.addSubTopic(steps_topic) for step in case[steps]: step_topic TopicElement() step_topic.setTitle(step) steps_topic.addSubTopic(step_topic) expected_topic TopicElement() expected_topic.setTitle(预期) expected_topic.setTitle(case[expected]) case_topic.addSubTopic(expected_topic) xmind.save(workbook, output_path)这段代码的逻辑很简单先建模块分支再在模块下建测试点分支测试点下再挂步骤和预期。每个测试点的标题带上优先级和分类标签这样评审的时候不用点进去就能快速判断用例级别。5.2 第一个大坑python-xmind 生成的 .xmind 新版本打不开诚实说这个坑让我折腾了一个晚上。python-xmind 这个库存在得比较早实现方式是基于旧版 XMind 文件结构。它生成的.xmind文件用 XMind 8 打开没问题但用 XMind 2020 之后的版本打开时有概率出现“文件格式不支持”或内容不显示的问题。排查过程是这样的我先确认了.xmind文件本质上是个 zip 包于是用压缩工具解开看里面的结构。旧版结构是content.xml加一堆附件新版结构是content.json加metadata.json。python-xmind 库默认生成的是旧 XML 结构新版 XMind 虽然兼容旧格式但兼容层有漏洞某些标签写得不严格就导致解析失败。5.3 规避方案中转 FreeMind 格式让 XMind 自己导入我没有去改写库的内容生成逻辑工作量太大性价比太低而是换了个思路先让 Python 生成 FreeMind 格式的.mm文件再用 XMind 的“导入”功能打开。XMind 对 FreeMind 格式的兼容性做得非常好导出导入基本无损还不会触发新版格式兼容问题。FreeMind 格式本质是 XML语法比 XMind 文件简单得多。核心就这么几行map version1.0.1 node TEXT测试点概览 node TEXT登录模块 node TEXT[P1] (正常流程) 验证正确手机号和密码登录成功 node TEXT步骤 node TEXT输入正确手机号 / node TEXT输入正确密码 / /node node TEXT预期 node TEXT登录成功跳转首页 / /node /node /node /node /map用 Python 的xml.etree.ElementTree生成它就是几行代码的事而且因为格式简单几乎不会踩到格式兼容的地雷。我自己封装了一个build_freemind()函数最终输出.mm文件然后在 XMind 里通过“文件 → 导入 → FreeMind”打开。5.4 为什么推荐把标题写得“自带上下文”还有一个细节可能很多人会忽略XMind 图里的节点如果只写“输入正确手机号”脱离模块后别人看不懂。AI 拆解出的测试点标题要尽量包含场景和动作比如“验证输入正确手机号与正确密码时登录成功并跳转首页”这个标题即使脱离模块上下文也能读懂含义。我在 Prompt 里专门加了一句“标题务必能独立理解”效果提升非常明显。这也是 AI 生成的测试点和人工写的测试点的一个重要差异人工写的时候默认看的人就是自己或同事上下文缺失问题不大AI 如果不刻意要求也会默认写得很省略。所以 Prompt 里这类对输出质量的隐性要求一定要显式说出来。6. 实测效果、适用范围与必须正视的边界问题工具写完以后我在团队内挑了三份需求文档做了实测。结果是惊喜和失望并存的这里我把真实数据摆出来。6.1 实测数据与质量表现拿一份中等复杂度的管理后台需求文档约 30 页涵盖用户管理、角色权限、操作日志三个模块来测试指标人工整理本工具生成总耗时约 90 分钟约 6 分钟其中人工检查 5 分钟测试点总数4255评审后保留数4041漏点数量-明显少于人工初稿从数量上看AI 生成的初稿比人工还多一些很多点我们评审时划掉了因为属于“过度设计”比如把不存在的边界情况也补上了。但真正有价值的是漏点变少了AI 不会像人一样疲劳到把某段需求整个看漏。这个结果是符合预期的。6.2 哪些文档适合、哪些不适合实测下来适合这个方案的文档有这些特征功能点列表清晰、每段描述围绕一个明确业务动作、包含“若则、当、否则、异常、权限”等词汇。典型是后台管理系统、企业服务软件、Web 平台的功能需求文档。不适合的情况也很明显一类是高度依赖行业业务知识的文档比如金融计算规则、医疗流程AI 缺乏领域背景生成的点容易流于表面另一类是文档本身写得很含糊、大量使用“等”“相关”“后续支持”这类模糊表述这种情况下模型只会“脑补”需求产出质量严重依赖文档自身质量。建议这类文档先用人工梳理出明确规则再拿给 AI 做展开。6.3 生成后的标准化人工复核流程工具能提效但不能完全替代人。我把使用流程固化成了四步生成的.mm文件导入 XMind 后先按模块过一遍看有没有漏模块检查每个测试点的expected是否和需求描述一致特别是业务规则类场景标记优先级和分类不合理的点直接在图里改文本就行最后做一次“反向追溯”从测试点回看需求文档确认每条需求至少能对应一个测试点。这个过程在实测中能控制在 10 分钟以内相比纯人工的 90 分钟已经是数量级的提升。6.4 后续扩展的两个方向和一点提醒我现在正在做的扩展有两个方向。一是把合并后的test_points.json再转成 Excel 用例模板方便不想用思维导图的同事直接用表格二是尝试让 Coze 在输出测试点的同时输出对应的自动化测试脚本描述生成 XMind 后再据此生成 Python 测试脚本骨架。最后提醒一点不要让这条链路变成“无人值守”的自动化流水线。大模型输出的东西现阶段必须有人工审阅环节。把它定位成一个能力极强的测试设计助理而不是替代测试工程师的机器才是这个工具的正确用法。我自己现在的习惯是每次跑完工具都先把生成结果发给需求文档的作者扫一眼确认理解一致后再进入用例评审。这个习惯已经帮我挡掉了好几次因为 AI 误读需求而差点酿成的返工。