软件测试禅道是什么？项目管理工具详细解答（精细）吐血整理

---

一、前言

禅道是一个测试管理工具，可以在里面进行项目管理以及bug用例管理，是一个非常好用的管理工具

当测试环境搭建完成后，测试人员将在自己搭建的环境上执行测试用例，开展测试工作

测试人员在执行测试用例的过程中，如发现实际结果与预期结果不一致， 则意味着出现Bug (缺陷、错误、问题)。当测试人员发现了Bug之后，就需要把Bug提交给开发人员进行修复

二、目的

1. 量化评估

对个人的评估

把工作拆分成一个一个的最细粒度任务，可以详细到小时的单位，并分配给开发人员

任务分配者（比如迭代负责人）注意每个任务难度、复杂度相近。管理者可以通过任务的完成数量，完成时间，对开发者有一个量化的工作量评估

通过所完成任务的 bug 的率的统计，可以对开发人员的代码质量有一个大概的评估

工作量和工作质量可以作为绩效评估的参考项之一

对团队的评估

如果不能把握团队的工作量和完成情况，管理者往往只能靠感觉评估团队的需求处理能力

通过把所有的工作拆分成任务并在线上分配给开发人员，再结合一些统计报表，管理者对团队执行力可以有一个数据化的感知

方便管理者对外承诺，也可以作为团队是否需要扩张的参考依据

2、降低成本

流程化管理

标准流程可以大幅降低沟通成本

通过形成标准化的“产品需求管理”，“任务分配和追踪”，“测试用例管理”，“bug追踪”机制，可以省去大大小小的很多的沟通会议

有什么不明白的直接线上追踪就可以了

快速追踪

线上项目管理，把“文档”，“产品”，“模块”，“需求”，“测试例”，“bug”，“开发分支”进行关联

每一个环节都可以往前往后进行追踪。免去了测试人员不知道bug应该提给谁、开发人员找不到产品人员、不知道某开发分支关联了那些需求、需求变更历史无法追溯等一些问题

内部协调

各责任人根据“需求列表”为主线进行沟通协调。产品做完UE后，拆解成具体的的需求列表

测试人员可以根据需求列表中的每一项需求编写测试用例并执行；
迭代负责人可以通过需求列表进行任务的拆解和分配；
后端可以根据需求列表拆分成具体的API；
前端可以拆分页面上的功能点

打开持续优化通道

有了标准流程，并且执行过程可视化，才能不断的优化流程或优化团队人员，最终达到提高整体团队效率的终极目的

三、使用禅道达到上述目的

1、思想

禅道的基本设计思想是，产品、开发、测试三权分立

产品人员负责创建产品、拆分需求、制定发布计划并发布产品；迭代负责人负责创建迭代、关联该迭代需要完成的需求、分解任务指派到人、制定发布版本，并提交测试

开发人员执行任务并完成任务；测试人员编写测试用例，提交bug，追踪bug

2、核心概念

产品
产品：对外交付的完整产品，比如，xx内部管理系统

模块：产品拆分成的功能模块，比如财务模块

需求：模块继续拆分成具体的需求点

计划：产品人员对外承诺的发布计划。发布计划关联一份需求清单，大多数情况下，迭代跟发布计划一一对应

发布：项目结束后产品人员创建发布，目的是告知公司其他部门新版本的产品可以投入使用

开发
任务：根据需求拆分的开发任务

迭代：同敏捷开发的迭代(Sprint)

版本：任务执行完成之后，提测之前创建发布版本。根据版本提交测试单给测试人员。版本测试完成之后由产品人员进行发布

测试
用例：测试人员根据需求创建的测试用例

bug：测试用例转的bug，或测试过程中发现的bug

其他
文档库：保存相关的文档，UE、UI、架构设计、API设计等。文档可以是文件也可以是外部链接

统计报表：燃尽图等

组织：组织结构，可以根据自己部门的情况自定义，比如前端、后端、测试等

四、使用-主流程

1、产品人员

产品管理
创建产品：产品人员创建产品

产品包括：名称、代号、产品负责人、测试负责人、发布负责人等属性

导入需求：产品人员把整个产品拆分成大的功能模块，然后将功能模块拆分成详细的需求列表。需求可以分层，建议不超过三层

发布计划：产品人员创建发布计划，并关联本次计划需要完成的需求列表或计划修复的bug

发布版本：开发人员完成某次迭代后，生成可测试版本。该版本经过测试后，由产品进行验收并提交发布

需求管理
创建需求：需求包括需求来源、备注需求发起人、关联的产品、关联的模块、关联的计划、由谁评审等属性

变更需求：需求变更的时候，系统会记录下变更的内容

需求评审：指定评审人，由评审人员执行评审的操作

2、迭代负责人

创建迭代，并拆分成细粒度的任务列表，并分配任务给开发人员

开发过程中，通过燃尽图等及时关注任务的执行情况。检查是否跟理想状态有所偏差，及时发现问题，并处理异常情况

开发完成后，创建版本(或分支)，提交测试单给测试人员，测试人员会根据测试单进行测试

3、开发人员

开发人员需要参与需求评估和需求拆分的会议。需求被拆分成具体的任务后，由开发人员认领各自的任务，进行开发，并维护该任务的生命周期（开始、完成、挂起等）

4、测试人员

编写测试用例
在产品人员导入产品/需求之后，测试人员就可以开始在需求上编写针对于该需求的测试用例

在开发人员提交测试单后，执行所有测试单中的测试用例

提bug
提交bug给开发人员，根据需求所关联的开发人员，可以找到该bug指派的对象。bug创建后管理整个bug的生命周期

---