测试用例管理流程图怎么画：从需求到用例评审的节点设计

画测试用例管理流程图，最容易犯的错是把图画成一条顺风路径：需求进来，用例写完，评审通过，结束。真正能用的图，必须回答三个问题：谁在什么条件下，把什么交付物交给下一步；哪一步可以退回；退回后由谁关闭。把这三件事画清楚，节点数量反而不重要。

先定边界：从需求评审开始，到用例入库结束

这张测试用例管理流程图建议从需求进入评审开始，到用例评审通过并入库结束。测试执行和 Bug 跟踪可作为下游子流程，不必全塞进一张图。

图里放三层信息：阶段节点、角色泳道、交付物与判断。圆角矩形表示处理，菱形表示判断，文档图标表示交付物，泳道表示角色，复杂分支拆成子流程。只画方框和箭头，读者知道顺序，却不知道谁负责、何时算完成。

ISO/IEC/IEEE 29119-2 在描述测试过程时，也把过程、输入输出和支持性流程图放在一起。这个思路可以直接借用：每个节点至少有输入、动作、输出、责任人和完成条件，缺一项，这个节点就只是墙上的方框。

图1：需求澄清不是旁听，测试要带着可测性问题进入评审。

六个核心节点：从需求到用例评审的顺序

节点按真实依赖排序，不要按部门顺序排。下面六个节点覆盖从需求到评审的主干，多产品、多版本的规模化研发团队可以在此基础上增加子流程。

节点1 需求接收与可测性检查

输入是需求说明、原型和验收标准；测试参与需求评审，检查需求是否可验证、边界和异常是否写清、依赖是否确定；输出是可测性结论和澄清清单，责任人是产品经理和测试负责人。

判断条件要写成能回答的问题，例如“验收标准能否用一条用例验证”“异常场景是否有明确处理”。答不上来就退回澄清，不要带着含糊需求进入用例设计。

节点2 测试需求分析与测试点拆解

把需求拆成测试点，输出测试点清单或需求—测试点矩阵。方法可以用场景法、功能拆解和风险分级：核心链路拆细，低风险配置项合并。

这一节点的完成条件不是“写了很多测试点”，而是关键需求都有对应测试点，且高风险场景有明确的测试策略。没有矩阵，后面的覆盖率就只能靠感觉。

节点3 测试计划与策略确认

输入是测试点、版本范围、环境、数据和人力；输出是测试范围、环境要求、数据准备、进度和准入准出标准。责任人是测试负责人，项目经理确认资源。

环境或数据没就绪，就在图里画一条回到计划调整的线，不要假装它能按时开始。很多流程图失效，就是因为把“等环境”这种真实分支删掉了。

节点4 用例设计与自检

测试工程师根据测试点设计用例，至少写清前置条件、步骤、预期结果、优先级和关联需求。设计方法按场景选择：等价类、边界值、场景法、错误推测，不必每个需求都全套用一遍。

在撰写用例时，可以把步骤拆开，每个步骤设置自己的预期结果。写完后先自检：步骤能否照着执行、预期是否可判定、是否覆盖异常和边界。自检不通过，退回设计；自检通过，才进入评审。

节点5 用例评审

评审由测试发起，产品经理和开发参与。正式评审前先做异步预审，会议只讨论覆盖、风险和判定标准。

评审重点看三件事：需求点有没有遗漏、用例有没有重复、预期结果是否可判定。覆盖看需求—用例矩阵，风险看核心链路和异常场景，判定标准抽查步骤和预期。

输出评审纪要、修改清单和结论。结论至少分三种：通过、有条件通过、不通过。有条件通过要写清关闭条件和责任人。

在禅道里，用例评审功能默认关闭，可以在后台的自定义—用例—评审流程中开启；开启后新用例状态为待评审，有评审权限的用户可以评审或批量评审。

节点6 评审闭环与基线入库

评审会结束不等于流程结束。用例作者按意见修改，测试负责人逐条确认关闭，再把修订后的用例入库或纳入基线。

判断条件只有一个：评审意见是否全部关闭。 没有关闭的，继续修改；关闭后，记录版本和评审结论。

入库后的用例不是静态文档。需求变更时，走一条子流程：影响分析—更新用例—重新评审—更新基线。子流程的返回点要画清楚，否则变更一到，图和用例库就会脱节。

三张图把节点画清楚：总览、泳道、评审门禁

这一章适合放三张信息图，因为它们分别回答不同问题：总览图回答“先后顺序”，泳道图回答“谁交接给谁”，评审门禁图回答“什么算通过”。三张图不要互相替代。

图2：六节点总览示意图，数字1—6对应需求、分析、计划、设计、评审、入库；菱形表示需要判断和退回的节点。

图3：泳道图把产品、测试、开发、项目的交接画在一条时间线上，橙色箭头表示跨角色流转和确认。

图4：评审门禁图，左侧五项检查对应需求覆盖、步骤可执行、预期可判定、异常场景和重复遗漏，右侧是三种评审结论。

画法顺序：先主干，再判断分支，再交付物，最后补角色泳道。一张图只回答一个主要问题，复杂分支拆成子流程。

常见画法问题：图很漂亮，但落不了地

• 只有正常路径。没有退回、变更、环境未就绪这些分支，图一遇到异常就失效。
• 把需求评审和用例评审画成一个节点。两者输入、参与人、输出都不同，合并后责任就模糊了。
• 只写动作，不写输入输出。“设计用例”四个字无法告诉执行者，上游要给什么、下游要接什么。
• 粒度过细或过粗。一张图三四十个节点，没人愿意看；只有三个大阶段，又无法指导执行。
• 图和工具两张皮。图上写“待评审”，工具里没有对应状态；评审结论只留在聊天记录里，追溯就断了。

把流程图落到禅道：节点、状态、字段对应

流程图不是挂在墙上的说明书，节点要能在工具里找到对应对象。禅道把需求、用例、任务和 Bug 组织在同一套结构中，规模化研发团队可以沿着同一条链路查关联。

需求阶段，用例关联到研发需求；用例设计在测试—用例下完成，字段包括所属产品、需求模块、用例类型、适用阶段、前置条件和步骤。常用用例可以导入用例库，做复用和版本管理。

评审阶段，按前面的评审流程开启评审、配置权限，让“待评审—评审通过或退回—修改—入库”和图上状态一致。

执行阶段，禅道的流程是创建构建、提交测试、执行测试单、生成测试报告。提交测试单时可以按需求或套件关联用例；执行用例、提交Bug时记录通过、失败、阻塞，失败用例可以直接转 Bug。

度量不要只看用例数量。更有用的指标是需求覆盖率、用例执行率、评审一次通过率、评审意见关闭率和 Bug 回归关闭率。指标要能回到节点，否则只是报表。

据《2025年软件测试行业现状调查报告》，禅道在常用测试管理工具中连续11年位列第一。这个结果可作为选型参考；流程是否有效，仍要看节点、状态和交付物是否跑通。

图5：需求、用例、Bug 的关联要能在同一套结构里查到，评审和回归才有依据。

一张可复用的落地顺序

第一步，统一字段和状态：用例要素、评审结论、Bug 严重程度和优先级用同一套口径。第二步，画主干和判断分支，先只画六个节点，不急着补所有细节。第三步，选一个迭代试跑，记录每次退回的原因。第四步，复盘并调整节点，把高频退回点前移。

角色也要写进图里：测试负责人维护流程图和评审规则，产品经理对需求可测性负责，开发参与评审并确认实现约束，项目经理看准入准出。

评审记录至少保留四项：结论、意见、责任人、关闭时间。

回到开头的问题：测试用例管理流程图怎么画？先画清六个节点和关键判断，再补角色和交付物，最后把状态落到工具里。 图不必复杂，但每条线都要有理由。

FAQ

流程图一定要用 BPMN 吗？

不必。内部对齐用泳道、判断和交付物就能说清；需要跨部门集成或系统建模时，再考虑 BPMN。

用例评审要开几次会？

常见做法是一次异步预审加一次正式评审。高风险需求可以增加专项评审，关键不是会议次数，而是意见是否逐条关闭。

流程可以简化到什么程度？

可以合并节点，但不能省掉输入、输出、判断和责任人。否则图只是装饰，遇到需求变更仍然会乱。