软件测试禅道是什么？如何使用？

lsekfe

　一、前言
　　禅道是一个测试管理工具，可以在里面进行项目管理以及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的生命周期。