一、前言
禅道是一个
测试管理工具，可以在里面进行
项目管理以及
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的生命周期。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
21天更文挑战，赢取价值500元大礼，还有机会成为签约作者！
原文地址：http://www.51testing.com/?action-viewnews-itemid-7789400
免责声明：本文来源于互联网，版权归合法拥有者所有，如有侵权请公众号联系管理员
* 本站提供的一些文章、资料是供学习研究之用，如用于商业用途，请购买正版。
