测试流程图的评审标准：一张流程图该检查哪些信息

评审测试流程图，容易变成图形是否整齐的讨论。更该追问的是：没参加需求讨论的测试人员，能否只凭这张图知道从哪里开始、在哪个节点判断、失败后去哪里、结果记在哪里。四项里有一项答不上来，这张图就应先修订，再用于测试执行。

流程图评审标准，重点不在图形符号是否规范，而在流程能否执行。ISO/IEC/IEEE 29119-2:2021 将软件测试过程划分为三个层次：组织级测试过程、测试管理过程和动态测试过程；GB/T 38634.2-2020 修改采用 ISO/IEC/IEEE 29119-2:2013。从评审用途看，测试流程图通常同时涉及测试管理活动和动态测试活动，它既要承接测试策略和计划，也要与用例设计、执行和结果记录相互对应。

一、先明确评审对象和判定规则

1. 测试流程图指什么

本文说的测试流程图，通常指描述一次测试活动从开始到结束的路径图，不是业务流程图、页面跳转图或组织架构图。这里的评审，指跨角色走读并形成结论，不是走审批。

先把产品、版本或迭代范围标在图上，再进入检查。范围不清楚，评审容易在某个节点要不要画上反复讨论。

2. 评审前准备哪些输入

建议准备五类材料：版本说明、测试计划、用例集、历史 Bug 和环境说明。参会人提前看图，把问题写在清单上，会上集中讨论分歧。

测试负责人、用例设计者和执行者应到场；涉及进入测试的条件、Bug 判定或发布标准时，再请开发和产品参加。

3. 什么情况判为不通过

先约定判定规则，再开始评审，讨论会更有边界。

评审发现的问题按影响分为三级：阻断指流程无法执行或关键分支缺失；重要指角色、输入输出或异常处理不清；建议指命名、布局和可读性优化。

评审中只要出现阻断问题，结论通常应退回。 没有阻断但有重要问题，可判为有条件通过，写明责任人和复核日期；重要问题较多，或图中缺少关键角色、关键证据时，也可退回。只剩建议项时，可判定通过。分级用于决定修订顺序，不是给流程图打分。

二、测试流程图的六类检查信息

六类检查从流程骨架延伸到执行证据，顺序与测试实际发生的过程一致。下面的检查项是按评审用途做的整理，不是标准条款复述，可作为测试流程图检查清单的主干。

1. 入口、出口与适用范围

入口写触发事件和前置条件：谁在什么状态下发起测试，依赖哪个版本、环境和进入测试的条件。出口写结束状态，例如测试单关闭或报告归档；不通过时退回开发。

只有开始和结束两个节点，没有触发条件和结束标准，执行者仍然不知道该在什么时候进场、什么情况下可以离场。

2. 节点动作与输入输出

一个节点只表达一个动作，名称用动词加对象。节点只写测试执行，信息不够，可改为执行用例并记录结果；只写Bug 处理，可拆成提交 Bug、确认 Bug、验证关闭。

关键节点还要能回答：输入从哪里来，输出交给谁。输入可能是需求、版本、用例集或测试数据；输出可能是执行记录、Bug 单、测试报告。节点没有输入输出，流程图就无法指导执行。

3. 判断条件与分支去向

判断框写成可回答的问题，例如用例是否全部执行完、阻塞项是否已解除。每条出线写清条件，不宜只标是或否，却不说明判断依据。

每个判断节点重点检查三类结果：通过、不通过、阻塞。三类结果都要有明确去向；循环要有退出条件，避免流程无法继续。

4. 异常、回退与超时

环境不可用、测试数据缺失、权限不足、用例被阻塞、回归范围扩大，这些情况需要在图上有对应位置。

失败分支后写恢复动作：重试、补数据、转 Bug、转人工、升级或终止，并写清触发条件和处理人。回退要写清退回哪个节点、已有执行结果是否保留；超时要写清判定时限、提醒对象和超时后的处理动作。异常分支没有恢复动作，执行容易依赖个人沟通。

5. 角色、交接与系统边界

按角色分区画泳道，或用责任标注写清：谁提交版本并创建测试单、谁接收测试单或认领测试任务、谁执行用例、谁确认 Bug、谁生成报告。跨角色交接处标出交付物，不宜用一个箭头代替版本和用例的交接。

人工动作与系统动作也要分开。系统生成测试单，不等于测试人员已经接收；两者混在一起，责任容易在交接处变得模糊。

6. 数据、证据与追溯

给关键节点编号，并让编号能对应到测试单、用例、Bug 和测试报告。评审意见可引用节点 T03，执行记录也能反查它来自哪条流程。

还要看状态是否可追溯：用例执行结果由谁修改、Bug 何时关闭、报告对应哪个版本。图上不要求复制系统字段，但应说明这些信息在哪里留存。

六类信息可整理成一张速查表，评审时逐行核对。

表格用于统一讨论依据，不替代评审结论。某一行答不上来，就转成具体问题，并写清责任人和复核方式。

三、按一条真实需求做测试流程评审

1. 走图步骤

评审不必从第一个框逐个念。选一条已交付或即将交付的需求，按真实路径走一遍，效率更高。

1. 定样本：选一条覆盖主流程和至少一个异常场景的需求，带上版本、用例和测试单。
2. 走主路径：从触发事件走到结束状态，记录每个节点需要什么输入、产出什么结果。
3. 查判断节点：逐个追问条件不满足时去哪，检查每条出线是否有明确去向。
4. 查交接：在跨角色节点停下来，确认交付物、接收人和系统状态。
5. 复走异常：用环境故障、数据缺失或权限不足的场景再走一遍，看流程是否还能继续。
6. 给结论：输出通过、有条件通过或退回，并附可关闭的问题清单。

2. 验证与记录

示例：某次版本测试的图中，提交测试直接连到执行用例，缺少测试单关联用例和环境准备；判断框只画了通过，环境不可用没有去向。走读后记录节点 T02、T05 上的两个阻断问题，结论为退回。

走完后做一次验证：请没参与绘制的人按图复述下一步动作。复述时卡住的位置，就是评审要记录的问题位置。

四、评审结论要能关闭

1. 问题记录包含什么

问题清单至少包含六项：问题级别、节点编号与问题描述、影响、修改建议、责任人、复核方式。描述要能定位到图上的具体节点，避免只写流程需要完善。

2. 问题级别怎么用

评审时先列阻断，再列重要，最后列建议。阻断问题关闭前，不宜按这张图进入测试执行；重要问题可限期修订；建议项可排入后续优化。

3. 如何复核

修订完成后，由原评审人或其指定人按节点复核，确认问题关闭，并把结论关联到流程图版本。下一次评审先看上一轮问题是否关闭，再进入新增内容。

五、让流程图和测试执行保持一致

评审结论确认后，还要让图上的路径能在系统里找到对应记录。

1. 图与系统各管什么

图负责路径，系统负责状态。 图里标出执行用例，系统里应有测试单、用例和执行结果；图里标出转 Bug，系统里应有 Bug 单和验证记录。

2. 禅道中的对应关系

在禅道测试管理中，版本提交测试后可生成测试单。测试单关联用例，执行失败的用例可转 Bug；研发解决后回归验证，测试完成后可生成测试报告。评审时可在测试单描述或用例说明中补充节点编号，让图上的节点与系统记录对得上。具体功能与字段以所用禅道版本为准。

禅道质量管理、禅道最简使用流程、禅道使用手册可查看对应说明。

3. 变更时如何同步

流程变更后，与变更相关的图、用例和测试单应同步更新。如果变更影响执行路径，却只改图而不更新用例，下一次执行仍会按旧路径走；只改用例而不更新图，新成员看到的还是旧流程。同步更新要写进流程，不宜依赖记忆。

六、常见问题

1. 流程图评审和测试用例评审，能不能只做一项？

通常不能互相替代。流程图评审看测试活动怎么走、谁交接、异常怎么处理；测试用例评审看单条用例的步骤、数据和预期结果。前者发现路径缺口，后者发现覆盖缺口。

2. 版本马上要发，流程图还有阻断问题，怎么办？

先判断问题是否影响本次范围。影响进入测试或结果判定的，补临时控制措施，例如增加人工检查、缩小发布范围或补充回归用例，并明确整改责任人和剩余风险的接受人；不影响本次的，记录为待办并约定复核日期。不宜用口头约定替代记录。

3. 远程团队怎么评审效率更高？

会前把图、版本说明和一条真实需求发给参会人，收集书面问题；会上只走这条需求，指定一人记录，当天发出问题清单。提前设定结束时间，避免逐节点念图。

4. 流程图需要每个版本重画吗？

通常不需要。主流程稳定时，用版本化方式维护同一张图，变更处标注版本和生效范围；流程重构或跨产品复用时，可另起一张。

一张测试流程图是否合格，不看它画了多少框，而看执行者能否不追问、问题能否追溯、变更能否复核。下一次评审，带一条真实需求和一张问题清单，从入口走到异常分支，再把每条意见落到节点和责任人。