测试管理工具常见问题：测试用例该由谁写、谁来评审

需求已经提测，用例还没写完，也没人说得清该由谁组织评审。这是测试负责人常遇到的场景。往下追，问题通常不在能力，而在编写责任和评审责任从来没有被明确下来：产品以为测试会写，测试以为产品会先给验收标准，开发认为自己只管代码。

在测试管理工具的落地过程中，测试用例该由谁写、谁来评审会被反复问到，因为它没有一个脱离团队条件的通用答案。判断条件是存在的：需求由谁定义、有没有独立测试角色、质量风险有多高、交付节奏有多紧。接下来按这四个条件，拆开编写责任、评审角色和评审颗粒度，并说明什么情况下该换一种分工。

一、先给判断：编写与评审责任由四个条件决定

在多数中大型研发团队里，测试人员主写用例、产品与开发参与评审，可以作为默认起点。它成立的前提是需求已经过评审并相对稳定，被测对象以业务功能和系统行为为主。

条件一变，默认分工就要调整。判断时重点看四点：

• 需求由谁定义：产品与业务主导的需求，验收标准应由产品给出；接口、算法、性能这类技术需求，由开发提供输入。

• 是否有独立测试角色：有专职测试岗位时，编写与执行容易形成闭环；测试与开发混岗时，需要指定一名兼岗负责人。

• 质量风险与合规要求：涉及资金、权限、对外承诺、验收交付的范围，编写与评审都要留痕。

• 交付节奏：短迭代团队不必要求每条用例都开会逐条过，异步预审加抽样评审更现实。

条件与分工的对应关系并不复杂。测试与开发混岗、需求高频变动的团队，可以按模块把编写责任分摊给最熟悉该模块的人，评审改为异步预审加抽样，把跨角色会议留给高风险范围。

二、测试用例该由谁写：三类责任模式的适用边界

写用例并不只是一个动作，它对应标准里的一组文档。国家标准 GB/T 9386-2008《计算机软件测试文档编制规范》把测试文档分为测试计划、测试说明和测试报告三类，测试说明下又包含测试设计说明、测试用例说明和测试规程。把编写责任集中交给一个角色，通常会在某个环节出现遗漏。

三类责任模式的适用条件与需要留意的风险，可以先看一张表。

三种模式并不互斥。同一个项目里，系统用例由测试写、单元测试由开发写、验收标准由产品写，是较为稳妥的组合。分界线不是角色，而是测试对象处在哪一层。

1. 测试人员主写：适合需求相对稳定的系统测试

测试人员写系统级用例，理由可以核实：用例要覆盖正常流程、异常流程和边界条件，需要用到等价类划分、边界值分析、场景法等测试设计方法，这属于测试岗位的专业内容；用例同时是测试执行和回归的基准，由执行者编写更容易保证可执行性。

前提是需求输入足够清楚。如果需求评审后验收标准仍然模糊，用例容易退化为按界面元素罗列步骤，无法验证业务规则。这时更有效的做法是让产品先补齐验收标准，而不是让测试自行推测。

2. 开发人员写：单元测试、接口层与自动化脚本

实行测试驱动开发的团队，单元测试一般由代码作者编写：作者更了解代码目的、实现约束和可测性设计，重构时也更容易同步维护测试。

这条规则有明确边界，它适用于实现层的验证，不等同于把系统测试用例交给开发写。业务场景、用户路径、异常分支的覆盖仍然需要测试视角。团队如果没有自动化测试基础设施，却要求开发承担系统级用例的编写，产出往往只停留在接口能调通的程度。

3. 产品与业务角色写：验收标准与业务规则

产品经理通常不写测试步骤，但应负责写清楚验收标准和业务规则，例如订单金额超过阈值必须走二次审批。测试再据此设计输入数据、操作步骤和预期结果。

这一步做实，收益在评审阶段就能看到：用例评审时争论的往往不是步骤细节，而是这条规则当初是如何确定的。规则有出处，评审时间会明显缩短。

三类模式放在一起看，分工逻辑是按测试对象分层，而不是按谁更专业整体分配。

三、用例评审该由谁来评：必到角色与角色分工

评审叫谁参加，取决于谁需要为这份用例的判断结果负责。

1. 必到角色与可选角色

• 必到：需求提出方（产品与业务）、实现方（开发）、用例作者（测试）。三方到齐，评审才能同时确认需求理解是否一致、用例是否可执行、实现层面是否存在可测性障碍。

• 可选：架构或接口负责人（涉及性能与兼容性时）、运维与安全（涉及上线门槛时）、用例库维护者（涉及跨项目复用时）。

参会人数不必求多。角色齐了但每人都在处理自己的工作，评审质量同样会下降。

2. 评审中的四类角色：作者、主持人、评审员、记录者

这里的角色指评审过程中的分工，与上一小节的参会方不是同一个维度。

ISTQB 基础级大纲在静态测试部分区分了非正式评审、走查、技术评审、审查等评审类型，同行评审中常见的角色分工包括作者、主持人、评审员和记录者。落到用例评审上，四类角色的职责可以这样理解：

• 作者：讲解用例设计思路与被测需求的对应关系。

• 主持人：控制节奏，确保讨论不偏离范围，逐条确认争议项。

• 评审员：负责查漏，重点看覆盖缺口与预期结果是否唯一。

• 记录者：把结论写进系统，而不是停留在会议纪要里。

兼岗团队可以由同一人承担多个角色，但不应省略记录结论这一环。

3. 谁对评审结论负责

需要区分两件事：评审通过，是对用例设计质量的结论；剩余风险是否接受，由项目或产品负责人决策，测试负责人负责给出风险评估结论。把两者混为一谈，容易出现评审都通过却仍然出问题的争论，也会让评审变成走形式的确认环节。

四、评审的时机与颗粒度：哪些用例逐条过，哪些可以抽样

在需求相对稳定的团队里，较为通行的做法是：用例评审安排在开发提测之前，先由测试组内部互查一遍，再召集跨角色评审；会前提前一到两天把用例、原型和需求文档分发给参与者，标注优先级和疑问点，让大家先异步看一遍。这样会议时间主要花在争议项上，而不是从头念用例。

颗粒度需要分流。不是所有用例都值得逐条评审，尤其是回归用例和长期稳定的老功能用例。评审强度可以按触发条件分配。

下表按用例的风险高低与变更幅度，给出对应的评审方式与主要产出。

分流之后，逐条评审的会议时间能集中到高风险范围，常规用例通过异步方式完成确认。判断评审是否有效，看一个可观察结果：评审结束后，有争议的需求理解变成了明确结论，并落到了系统里。

五、四个常见争议，在什么条件下成立

关于用例编写与评审，流传较广的四句话都有各自的成立条件。把它们说清楚，比笼统地强调协作更有用。

争议一：用例是测试的事，开发不用参与。 当被测对象是纯技术实现，比如加解密算法和内部接口，这条有道理。但系统测试涉及业务规则和用户路径时，开发缺席会让实现层面的约束没人确认，用例可能写出无法执行或无法观测的预期结果。

争议二：需求还没定稿，用例审了也要返工。 需求未定稿时，评审对象应换成测试范围和测试点清单，先确认测试范围；等到需求冻结再评审完整用例。评审对象选错时，返工概率会明显上升。

争议三：评审就是走形式，读完一遍没人说话。 走形式通常有三个信号：会前没有分发材料、评审没有明确产出要求、结论不落到系统里。补齐其中任意一项，评审质量都会有变化。

争议四：用例写完就归档，和 Bug 没有关系。 用例库如果只进不出，回归测试就失去基准。更合理的做法是让 Bug 与对应用例、版本关联，修复验证时直接指向触发问题的用例。

六、把分工固化到工具里：禅道中的用例、测试单与 Bug 闭环

分工写在文档里容易失效，写进系统里才会被流程推着走。禅道项目管理软件以需求池、需求、用例、任务、Bug、代码、反馈、工单八个核心概念组织研发链路，测试管理相关能力覆盖用例库、测试单、Bug 与测试报告，对应前文提到的几处断点。

• 用例与需求关联：需求发生变更时，可以直接查出哪些用例受影响，避免改了需求却漏改用例。相关过程可以配合需求管理的变更记录一起追溯。

• 测试单承载提测与执行：开发提测后生成测试单，把用例关联到测试单，再按人或按模块指派执行。禅道使用手册中的测试版本管理说明，用例可以指派给具体执行人，也支持多人分工领取。

• Bug 与用例、版本关联：复现步骤和回归验证有统一基准，修复后回到对应用例复测，减少同一问题反复出现。

• 用例库与文档沉淀：用例库支持跨库导入用例，便于共性场景复用；评审结论与测试规则可以沉淀到文档管理中，新人接手时有据可查。

• 流程与权限可配置：评审节点、状态流转和角色权限可以通过工作流按团队规则配置，让编写、评审、确认三类责任落到明确的负责人。

据禅道官方资料，禅道项目管理软件已为国内 100 万以上团队提供支持；在《2025 年软件测试行业现状调查报告》的统计中，禅道连续多年位列常用测试管理工具首位。工具本身不解决分工问题，但能让分工的每一步都有记录可查。

七、怎么判断这套分工在起作用：四个可观察信号

分工是否有效，不需要凭感觉判断。四个信号都能在系统里查到。

1. 需求、用例、Bug 可以互相追溯：打开一条需求能看到对应用例；打开一条 Bug 能找到触发的用例和所属版本。

2. 需求变更后用例有更新记录：变更落地后，受影响用例的状态、版本或内容发生了对应变化。

3. 评审材料会前分发、结论会后落地：评审材料在会前分发，争议项在系统里留下结论和负责人。

4. 上线后暴露的问题类型在变化：观察一段时间内上线后暴露的问题集中在哪些模块、哪些类型，用于判断用例设计的薄弱环节。这是趋势观察，不作为因果结论。

八、常见问题

1. 用例评审需要几轮才够？

可以按两轮安排：测试组内互查一轮，跨角色评审一轮。涉及高风险或合规要求的范围，可以再追加一轮专项确认。轮次过多通常不会提高覆盖率，反而会推迟提测时间。

2. 用例写到什么颗粒度才算够用？

判断标准是其他人拿着用例能不能独立执行：前置条件、测试数据、操作步骤和预期结果写清楚即可，不必把每一步鼠标操作都写进用例。预期结果必须唯一，避免使用可能、视情况这类模糊描述。

3. 存量用例谁维护、多久更新一次？

建议按模块指定维护人，并与需求变更和 Bug 复盘绑定更新。需求变更落地时同步修改对应用例，出现漏测问题时补充对应用例。定期全量重写老用例的收益通常有限，按变更触发更新更实际。

4. 自动化用例要不要和手工用例一起评审？

不必放在同一场评审里。自动化用例更适合由开发与测试共同做代码评审，关注可维护性、稳定性和断言是否有效；手工用例评审关注需求覆盖和场景完整性。两者的评审标准和参与角色并不相同。

5. 新人和外部协作方写的用例能直接入库吗？

建议先经过组内预审和作者确认再入库。入库标准写成可检查的几条，例如需求点有对应用例、步骤可执行、预期结果唯一，可以避免评审标准随人变化。

把这套分工落到团队里，可以按四步走：按测试对象分层确定编写责任人；确定每次评审的必到角色；按风险确定评审颗粒度；把评审节点和结论固化到测试管理工具中。条件变了，分工跟着调整，这比追求一套通用答案更接近实际。