温馨提示！由于新浪微博认证机制调整，您的新浪微博帐号绑定已过期，请重新绑定！&&|&& 希望你能喜欢我的博客,有事没事常来看看,互相学习,共同进步,和谐共享 \(^o^)/ LOFTER精选 网易考拉推荐 用微信&&“扫一扫” 将文章分享到朋友圈。 用易信&&“扫一扫” 将文章分享到朋友圈。 阅读(11557)| 用微信&&“扫一扫” 将文章分享到朋友圈。 用易信&&“扫一扫” 将文章分享到朋友圈。 历史上的今天 loftPermalink:'', id:'fks_', blogTitle:'项目管理、Bug管理软件工具:禅道，BugFree，Redmine', blogAbstract:'BugFree是借鉴' {list a as x} {if x.moveFrom=='wap'} {elseif x.moveFrom=='iphone'} {elseif x.moveFrom=='android'} {elseif x.moveFrom=='mobile'} ${a.selfIntro|escape}{if great260}${suplement}{/if} {list a as x} 推荐过这篇日志的人： {list a as x} {if !!b&&b.length>0} 他们还推荐了： {list b as y} 转载记录： {list d as x} {list a as x} {list a as x} {list a as x} {list a as x} {if x_index>4}{break}{/if} ${fn2(x.publishTime,'yyyy-MM-dd HH:mm:ss')} {list a as x} {if !!(blogDetail.preBlogPermalink)} {if !!(blogDetail.nextBlogPermalink)} {list a as x} {if defined('newslist')&&newslist.length>0} {list newslist as x} {if x_index>7}{break}{/if} {list a as x} {var first_option =} {list x.voteDetailList as voteToOption} {if voteToOption==1} {if first_option==false},{/if}&&“${b[voteToOption_index]}”&& {if (x.role!="-1") },“我是${c[x.role]}”&&{/if} &&&&&&&&${fn1(x.voteTime)} {if x.userName==''}{/if} 网易公司版权所有&& {list x.l as y} {if defined('wl')} {list wl as x}{/list}当前位置： >> 禅道使用手册 禅道使用说明禅道是第一款国产的优秀开源项目管理软件。它集产品管理、项目管理、 质量管理、文档管理、组织管理和事务管理于一体，是一款功能完备的项目管理 软件，完美地覆盖了项目管理的核心流程。先进的管理思想，合理的软件架构， 简洁实效的操作，优雅的代码实现，灵活的扩展机制，强大而易用的 api 调用机 制，多语言支持，多风格支持，搜索功能，统计功能。
一、 系统概述禅道的功能列表： 1.产品管理：包括产品、需求、计划、发布、路线图等功能。 2. 项目管理：包括项目、任务、团队、build、燃尽图等功能。 3. 质量管理：包括 bug、测试用例、测试任务、测试结果等功能。 4. 文档管理：包括产品文档库、项目文档库、自定义文档库等功能。 5. 事务管理：包括 todo 管理，我的任务、我的 Bug、我的需求、我的项目等 个人事务管理功能。 6. 组织管理：包括部门、用户、分组、权限等功能。 7. 统计功能：丰富的统计表。 8. 搜索功能：强大的搜索，帮助您找到相应的数据。 9. 灵活的扩展机制，几乎可以对禅道的任何地方进行扩展。 10. 强大的 api 机制，方便与其他系统集成。 禅道使用流程图: 二、 最简使用说明禅道的定位不是简单的任务管理软件，而是专业的协同管理软件。研发类 的项目管理本身具有其复杂性， 所以禅道提供的都是必备的功能。但这并不意味 着必须按照禅道的流程来使用， 完全可以按照自己的实际情况来使用禅道。下面 将介绍使用禅道的最简单方式。 2.1 使用禅道来进行项目任务管理 2.1.1 创建项目 1) 进入项目视图，点击右侧的”新增项目“链接。2) 出现项目添加的页面 在这个页面设置项目名称、代号、起止时间、可用工作日、团队名称、项目目标 和项目描述等字段。其中关联产品是可以为空的。2.1.2 设置团队 1) 点击保存按钮，会提示项目创建成功，然后可以选择设置团队。2)或者从项目视图中的团队菜单，也可以进行项目的团队管理。在维护项目团队的时候， 需要选择都是哪些用户可以参与到这个项目中，同时需 要设置这个用户在本项目中的角色（角色可以随便设置，比如风清扬，冬瓜一号 等）。可用工作日和可用工时每天需要仔细设置。通常来讲，一个人不可能每天 8 小时投入，也不可能一星期七天连续投入。 3) 设置完毕之后，系统会自动计算这个项目总得可用工时。2.1.3 分解任务 设置了团队之后，下一步操作就是创建任务。? ? ? ? ?在创建任务的时候，指派给是从项目团队成员中读取。 姓名列表中的首字母可以用来快速筛选用户。 任务的优先级、预计工时（单位小时）都需要进行设置。 如果需要设置任务必须在某一个时间点截止，可以设置截止日期。 可以上传附件。2.1.4 更新任务 任务分解完毕之后，每个人就非常清楚自己做什么事情。所以项目启动之后，对 于项目团队的成员来讲，他要做的事情就是更新任务的状态。1) 任务的列表 在任务的列表页面， 可以看到系统中所有的任务列表，可以通过各种标签方便的 进行筛选。点击某一个任务的链接进入详情页面。2) 任务的详情页面在任务的详情页面可以看到任务的详细信息，包括历次的修改记录等信息。同时 也给出了各种操作的按钮。 3) 开始任务。开始某一个任务的时候， 可以设置已经消耗的时间和预计剩余的时间。单位都是 工时。 4) 完成任务。完成任务的时候，需要设置下已经消耗的时间。 2.1.5 验证关闭任务 任务完成之后， 会自动指派给任务的创建者，这时候任务的创建者可以验证任务 是否完成。如果完成，则可以将其关闭。这件任务就结束了。2.2 只使用禅道来做 bug 管理 测试禅道的测试功能也可以独立出来单独使用。 这种方式很适合于测试团队使用。 禅道里面的 bug 最基本流程是：测试人员提出 bug -& 开发人员解决 bug -& 测 试人员验证关闭。 2.2.1 创建产品 使用 bug 管理功能之前， 需要先创建产品。禅道里面设计的理念是 bug 主要附属 在产品概念下面的，后面我们会详细讲述产品和项目之间的关系。新增产品的时候，需要设置产品的名称、代码，几个负责人信息。2.2.2 提出 bug 有了产品之后，我们就可以来创建 bug 了。? ? ?在创建 bug 的时候，必填的字段是影响版本，bug 标题，重现步骤这些基 本的信息。 所属项目，相关产品，需求可以忽略。 创建 bug 的时候，可以直接指派给某一个人员去处理。如果不清楚的话， 可以保留为空。2.2.3 解决 bug 当一个 bug 指派给某一位研发人员之后，他可以来验证解决这个 bug。 1) 通过各种标签和检索条件找到需要自己处理的 bug 在对 bug 进行出来之前，需要先要找到需要自己处理的 bug。禅道提供了各种各 样的检索方式，比如指派给我，可以列出所有需要我处理的 bug。1) 解决 bug研发人员解决 bug， 选择解决方案， 一般来讲有效的解决 bug 方案是”已解决“。 详细的解决方案，我们在后续的文章中会详细加以讲述。 2.2.4 关闭 bug 当研发人员解决了 bug 之后，bug 会重新指派到 bug 的创建者头上。这时候测试 人员可以来验证这个 bug 是否已经修复。如果验证通过，则可以关闭该 bug。三、 进阶使用说明3.1 使用流程 3.1.1 禅道使用流程图解 在禅道项目管理软件中，核心的角色有产品经理、项目经理、研发团队和测试团 队四种角色。如果您现在的团队是采用敏捷开发的话，那么可以对应到 productowner, scrum master 和 team(dev and tester)。这几种角色之间紧紧围绕产品 的需求展开协作，取得成果。禅道核心的管理流程全图如下所示：3.2 产品经理篇 3.2.1 维护产品 产品管理对于公司来讲，至关重要。只有做出好的产品或者服务出来，才能赢得 市场， 谋求发展和生存。 所以产品经理的这个位子对于公司来讲， 是非常关键的， 相当于公司的大脑，在决定着公司前进的方向。在禅道里面，产品和项目这两个 概念被明确的区分开来。产品是需求方，决定做什么。项目是执行方，解决的是 如何做的问题。而测试则是保障方，解决的是正确的做事情的问题。所以在禅道 中，所有的一切都是围绕产品展开的。产品是整个项目管理活动的核心。 3.2.1.1 创建产品1) 用产品经理的角色登录禅道。 2) 进入产品视图，然后点击页面右侧的“新增产品”链接，即可出现新增产品的页面。3) 如果系统中还没有添加产品，系统也会自动跳转到产品的添加页面。添加产品时需要注意的地方：? ? ? ? ?产品代号相当于大家对这个产品的一个隐喻， 比如禅道项目管理软件的代 码是 zentao。 产品负责人负责整理和解释整个产品的需求，制定相应的发布计划。 测试负责人， 可以指定默认的测试负责人。 这样可以适用于公司人比较多， 提交 bug 不知道该给谁的情况。 发布负责人主要的职责是创建发布。 访问控制， 则可以控制访问该产品的人员列表。比如可以将某一个产品设 为私有，只有产品添加者、产品负责人、测试负责人、发布负责人以及该 产品的项目团队才可以访问。我们产品经理可能都习惯了写需求设计文档，或者规格说明书，通过一个非常完 整的 word 文档将某一个产品的需求都定义出来。但在禅道里面，我们提倡 按照 功能点的方式来写需求。 简单来讲，就是将原来需求设计文档中的每一个功能点 摘出来，录在禅道里面，作为一个个独立的功能点。如果按照 scrum 标准走 的 话，我们可以称之为用户故事(user story)。所谓用户故事，就是来描述一件事情，作为什么用户，希望如何，这样做的目的或者价值何在，这样有用户角色， 有行为，也有目的和价值所在，非常方便与团队成员进行沟通。 3.2.2 创建和评审需求 3.2.2.1 创建需求 1) 使用产品经理角色登录系统。 2) 进入产品视图。 3) 在页面右侧，有“新增需求”菜单，点击菜单，出现新增需求的页面。o o o o o需求的标题是必填项。 所属计划和模块，可以暂时保留为空。 需求审核那块， 我们选上不需要审核，这样新创建的需求状态就是 激活的。只有激活状态的需求才能关联到项目中，进行开发。 需求可以设置抄送给字段， 这样需求的变化都可以通过 email 的形 式抄送给相关人员。 可以设置关键词，这样可以比较方便的通过关键词进行检索。3.2.2.2 评审需求 在创建需求的时候， 有一个&不需要评审&的复选框， 如果选中该复选框的话， 需求的创建是激活中的。但大部分情况下面，需求还是需要评审的。即使产品完 全有一个人负责，也可以将一些不成熟的想法存为草稿，后续再进行处理。新增 需求的评审流程如下：下面我们来看下具体的需求评审页面：?评审结果可以选择确认通过、有待明确、拒绝等操作。如果选择“确认通 过”， 则需求的状态改为“激活中”， 然后就可以关联到项目中进行开发了。?如果选择“有待明确”，会保持需求的草稿状态，并将需求指派回需求的创 建者头上，有其继续进行完善。?如果选择了“拒绝”，则需要给出相应的拒绝原因，拒绝原因可以有：?由谁评审是记录的参与评审的人员名单，可以输入用户名来自动筛选。一 般来讲需求评审可以是一个线下的评审会议， 在禅道里面记录下参与需求 评审的人员即可。3.2.3 变更和评审需求 变更是需求管理必不可少的流程，禅道项目管理软件对需求的变更提供了全 面的支持。其实需求的变更并不可怕，但不清楚影响范围的变更是很可怕的。在 传统项目管理中，由于没有有力工具的支撑，产品经理在变更需求的时候，无法 知晓该需求的影响范围，会有很大的随意性。禅道项目管理软件将需求、任务、 bug 和用例都纳入为一体管理，就可以很清楚的知晓变更的影响范围，从而给产 品经理更好的指导。 禅道里面需求变更的基本流程如下：下面我们来看下具体的操作： 3.2.3.1 变更需求禅道专门提供了需求的变更流程。凡是对需求标题、描述、验证标准和附件的修 改，都应该走变更流程。变更之后的需求状态为变更中。?编辑操作是无法修改需求的标题、描述、验收标准和附件的。?在变更需求的时候， 如果选择了“不需要评审”， 则需求状态自动变成激活， 不需要再走评审流程。?在变更需求的时候，会列出该需求的影响范围：3.2.3.2 评审需求 1) 通过需求的详情页面查看变更前后的变化2) 评审需求，给出评审结果? ? ? ? ?评审结果可以选择确认通过，撤销变更，有待明确或者拒绝。如果选择确 认通过，则需求的状态从“已变更”变为“激活中”。 如果选择撤销变更，则取消当前的变更，并回退到之前的版本。 如果选择有待明确，需求被打回到需求的变更者，继续进行完善。 如果选择拒绝，则需要给出相应的拒绝原因。 同样在评审需求的时候，也会列出相应的影响范围，评审者可以参考。3.2.3.3 确认需求变更 当需求变更被确认之后，研发团队和测试人员需要确认需求的变更。 1) 任务确认需求变动：2)缺陷确认需求变动3) 用例确认需求变动3.2.4 需求的状态和研发阶段 禅道软件设计的需求有两个字段来跟踪它的变化，一个是需求的状态字段， 一个是需求的研发阶段字段，下面来看下这两个字段。 3.2.4.1 需求的状态 需求状态(status)字段，总共有四种状态，分别是草稿(draft)、激活 (active)、已变更(changed)和已关闭(closed)。对应为需求的流程操作共有： 创建、变更、审核、关闭、激活，其状态流转图如下：3.2.4.2 需求的研发阶段 需求还有一个阶段(stage)字段，用来描述激活的需求在研发过程中所处的 阶段。目前总共有等待、已计划、已立项、开发中、开发完毕、测试中、测试完 毕、已验收、已发布。 那么需求的研发阶段是如何变化的呢？一种方案是通过编辑操作，来修改研 发阶段。但我们更提倡另外一种方案，就是在创建任务的时候，仔细设置任务的 类型，比如开发，测试。禅道的程序会自动根据不同类型任务的变化来自动计算 需求的研发阶段，其规则如下： 1) 如果需求没有关联到项目，也没有关联到计划，则需求的研发阶段是&等待&。 2) 如果需求关联到了计划， 还没有关联到项目中， 则需求的研发阶段是&已计划&。 3) 如果需求关联到了项目中， 但还没有分解任务， 则需求的研发阶段是&已立项&。 4) 如果需求关联到了项目中，且进行了任务分解: 如果有一个开发任务进行中，并且所有的测试任务还没有开始，需求的研发阶段 为“研发中”。 如果所有的开发任务已经完成， 并且所有的测试任务还没有开始， 则为“研发完毕”。如果有一个测试任务进行中，则视为“测试中”。 如果所有的测试任务已经结束，但还有一些开发任务没有结束，则视为&测试中&。 如果所有的测试任务已经结束， 并且所有的开发任务已经结束， 则视为&测试完毕&。 5) &验收&阶段是需要产品经理手工来进行确认的。6)如果需求关闭，且关闭原因是“已发布”， 则需求的研发阶段是“已发布”。3.2.5 建立发布计划 古人云，凡事预则立，不预则废。产品需要做规划，才能有轻重缓急，才能正确 的做事。因此对于产品经理而言，计划是必需的。?对于产品经理自己而言， 发布计划可以帮助他规划产品， 制定发布的节奏， 调整需求的优先级。?对于公司其他部门的同事以及外部的客户而言， 发布计划可以让他们知晓 产品的进展情况，以便做好相应的安排。?同时在项目关联需求的时候，计划可以帮助需求的关联。3.2.5.1 创建计划 1) 进入产品视图，选择某一个产品。 2) 点击“计划列表” 3) 出现计划列表页面， 点击页面右侧的“创建计划”， 即可出现计划增加页面。3.2.5.2 关联需求 创建完计划之后，可以为计划关联需求也可以在添加需求的时候指定计划(已经过期的计划不会列出)3.2.5.3 计划和项目之间的关系 禅道软件中并没有对计划和项目并没有非常强的对应关系。如果某一个开发 团队的计划和执行都非常好， 那么一个计划可以对应一个项目。但这是非常理想 的状态。一般情况下面是这样，在项目关联需求的时候，大部分的需求都关联自 一个计划，但同时也关联了其他计划的部分需求。 3.2.6 建立发布 项目结束后产品人员的一个工作就是创建发布，通过创建发布，可以告诉公 司其他相关的部门， 他们可以在新版本产品的基础上开展工作。同时也是鼓舞团 队士气非常好的一个手段。 3.2.6.1 创建发布的前提创建发布有两个前提： 1) 该产品有关联过项目。 2) 该项目有创建过版本。 3.2.6.2 如何创建发布 1) 进入产品视图，选择发布列表。 2) 然后点击“创建发布”，即可出现创建发布的页面。?选择了版本之后， 系统会自动计算这个版本所对应的项目中完成的需求和 解决的 bug，可以进行关联选择。?如果系统自动计算的需求和 bug 不完整，可以在描述字段里面补充。5.2.7 文档管理 禅道软件内置了基本的文档管理功能，这样禅道没有覆盖到的流程就可以通 过文档管理功能来补充。禅道文档库共分为三种类型：产品文档库、项目文档库 和自定义文档库。 其中产品文档库用来存储产品层面产生的文档，项目文档库用来存储项目过程中产生的文档。 自定义文档库则可以用来存储知识库、公司管理 规范等文档。下面让我们来看下具体的操作。 3.2.7.1 维护分类 1) 进入文档视图。 2) 选择产品文档库。 3) 然后选择页面下方的“维护分类”链接，即可出现维护分类的的页面。3.2.7.2 添加文档在产品视图，点击页面右侧的“创建文档”，即可进入文档的创建页面。? ? ? ?文档共有文件、链接和网页三种类型。 文件类型的文档可以上传一个附件。 链接类型的文档可以是一个网页链接。 网页型的文档可以直接使用富文本编辑器撰写。3.2.7.3 浏览文档 文档添加之后，可以在文档库里面查看相应的文档列表。也可以在产品视图的文档库里面查看这个产品下面的所有文档。3.3 项目经理篇 3.3.1 建立项目 3.3.1.1 创建项目 1) 进入项目视图，点击右侧的”新增项目“链接。2) 出现项目添加的页面 在这个页面设置项目名称、代号、起止时间、可用工作日、团队名称、项目目标 和项目描述等字段。其中关联产品是可以为空的。注意事项： 1. 项目代号是一种隐喻，也就是团队内部可以互相了解和知晓，比如禅道项 目曾经使用过“opensesame&来作为项目的代号。 2. 团队名称，可以自己定义，比如叫做“禅道开发团队”等等。 3. 在添加项目的时候，可以选择关联与之相关的产品，以便后续进行需求的 关联。 4. 项目可以控制它的访问权限，分为默认、私有和自定义白名单三种。3.3.2 组建项目团队 项目组建之后要做的事情就是设置团队。很多朋友经常问，为什么我在创建任务 的时候，只能指派给自己呢？其实原因很简单，是因为没有设置团队。 当项目创建成功之后，可以根据提示设置团队。或者从项目视图中的团队菜单，也可以进行项目的团队管理。在维护项目团队的时候， 需要选择都是哪些用户可以参与到这个项目中，同时需 要设置这个用户在本项目中的角色（角色可以随便设置，比如风清扬，冬瓜一号 等）。可用工作日和可用工时每天需要仔细设置。通常来讲，一个人不可能每天 8 小时投入，也不可能一星期七天连续投入。 设置完毕之后，系统会自动计算这个项目总得可用工时。当团队设置完毕之后，整个项目的可用资源就已经确定了：起止时间确定了，参 与的人员也确定了。下面就是来确定项目中要做的事情了。 3.3.3 确定项目要完成的需求列表 项目团队组建完毕之后，接下来要做的一个工作就是确定这期项目要做的需 求。这项任务其实是整个团队，包括产品在内，共同完成的。 3.3.3.1 关联产品 如果在创建项目的时候，已经关联过产品，可以忽略这个步骤。 1) 以项目经理身份登录。 2) 进入项目视图。 3) 点击“关联产品”按钮。然后点选该项目相关的产品即可。3.3.3.2 关联需求1) 在关联需求的时候，可以按照优先级进行排序。 2) 关联的需求状态必须是激活的（评审通过，不能是草稿） 3.3.4 组织进行任务分解 需求确定之后，项目中几个关键的因素都有了：周期确定、资源确定、需求 确定。 下面我们要做的事情就是为每一个需求做 wbs 任务分解，生成完成这个需 求的所有的任务。 3.3.4.1 访问项目的需求列表页面：? ?在项目的需求列表页面，可以很方便地对某一个需求进行任务分解。 同时还可以查看这个需求已经分解的任务数。3.3.4.2 分解任务? ? ?这时候创建任务的时候，就可以选择需求了。 我们同时提供了需求查看的链接。 如果需求和任务的标题是一样的，可以通过”同需求“按钮快捷的复制需求 的标题。3.3.4.3 任务分解的几个注意事项 1) 需要将所有的任务都分解出来。这里面包括设计，开发，测试，美工，甚 至包括购买机器，部署测试环境等等。 2) 任务分解的粒度越小越好，比如几个小时就可以完成。 3) 如果一个任务需要多个人负责，继续考虑将其拆分。 4) 事务型的事务可以批量指派， 比如需要让团队里面的每一个人都写个项目 总结，可以选择类型是事务，然后批量指派给团队里面的所有人员。5) 任务的类型请仔细设置，这个会涉及到需求研发阶段的自动计算。后面我 们会有讲解。 6) 任务的分配最好是自由领取，这样可以最大程度上调动大家的积极性。 7) 任务的分解最好是由团队共同完成，不要由项目经理一人包办。 3.4 开发团队篇 3.4.1 领取任务，并每天更新任务 当项目的任务分解完毕之后，项目团队成员需要领取自己喜欢做的任务，开 始每天的开发。 除了日常的编码工作之外，还应当每天花点时间在禅道里面更新 下任务的状态以及消耗情况。 3.4.1.1 领取任务 领取任务可以通过两种方式， 一种是通过“指派”操作，一种是通过“编辑”操 作。3.4.1.2 更新任务状态 项目开始之后， 每个人每天应当及时更新自己所负责的任务的状态。禅道提供了 几个快捷的操作按钮：开始、完成、关闭、取消和激活。开始、完成和取消没有 什么歧义。解释下关闭和激活。禅道有一个可选流程，就是当任务完成之后，会自动指派回任务的创建者头上， 这时候任务的创建者可以验证任务是否完成。如 果完成，则将任务关闭。如果任务没有完成，则激活任务。这个流程是可选的， 不是必须的流程。适用于传统的命令-控制式的管理。如果对于敏捷开发团队来 讲，忽略这个流程即可。 3.4.1.3 更新任务的消耗 除了更新自己负责任务的状态之外，还应该及时更新任务的工时消耗情况：最初预计，即创建任务的时候的最初预计。该字段在任务开始之后，不应该再进 行修改。这个字段当任务结束之后，可以和已经消耗字段进行对比，以纠正自己 的估计。 已经消耗，则是你在这个任务上所有花费的工时数。 预计剩余，则是你预计这个任务完成大约还需要多少时间。如果预计剩余为 0， 则表示任务完成。这里面需要特别强调的是，最初预计 ≠ 已经消耗 + 预计剩余。 一定要每天更新自己所负责的任务，因为燃尽图的绘制，就是通过预计剩余这 个字段来计算的。 3.4.2 创建版本 当完成若干功能之后， 就可以创建版本了。 版本的概念在英文里面是 build， 可以对应到软件配置管理的范畴。这是一个可选流程，但还是建议团队能够实施 版本管理。 这个版本主要的作用在于明确测试的范畴，方便测试人员和开发人员 的互动，以及解决不同版本的发布和 bug 修复等问题。 流程如下： 1) 首先是团队经过开发，完成了若干需求，或者解决了一些 bug。 2) 这时候某一位发布负责人在 subversion 中创建了一个 tag(标签)，比如 禅道的 tag 目录如下：3) 创建了 tag 之后，这位发布负责人就可以在禅道里面创建一个版本了。说明： 1) 名称编号，团队应该有自己的配置管理规范。比如可以是产品名_版本号_ 状态(stble, beta 之类)_日期 2) 不同开发语言其版本的存在形式也不同，有的需要编译，有的只需要源代 码。请根据公司的实际情况来填写源代码地址，或者是存储地址。 3) 在创建版本的时候，可选择这次版本完成的功能和解决的 bug。这样提交 给测试人员进行测试的时候，就可以明确这次测试的范畴，测试可以更加 有针对性。4) 描述字段可以填写一些测试的注意事项、重点内容等。 3.4.3 申请测试 当版本创建完毕之后，就可以提交给测试人员进行测试了，提交测试会生成 一个测试任务。 在这儿需要和大家解释下这个测试任务的概念。其实英文里面里 面比较合适的单位是 testrun，但翻译到中文里面没有太贴切的词语，我们暂时 用了测试任务的概念。 但这个测试任务和项目里面创建的类型为“测试”的任务 没有直接关联。请大家在使用的时候，注意这个细节。 一般来讲，我们在分解任务的时候，可以创建若干测试类型的任务，比如测 试某某，测试某某，大概估计下测试需要的时间。然后具体的测试工作通过测试 视图的测试任务来跟踪。 申请测试的步骤： 1) 进入项目视图，点击“测试申请”。 2) 然后选择“提交测试”，即可出现提交测试的页面。说明： 1) 负责人为本次测试的负责人。 2) 可以指定这次测试预计起止的时间。 3) 任务描述里面，可以注明此次测试需要注意的地方。 4) 还需要说明的一点是，目前测试任务还没有指派的功能，所以需要大家线 下通知测试团队的负责人，由他来负责组织相应人员来进行测试。 3.4.4 解决 bug提交测试之后，测试人员展开测试，便会有 bug 产生。这时候研发团队的一 个重要职责便是解决 bug。禅道里面 bug 的处理流程比较简单： 测试人员提交 bug =& 开发人员解决 bug =& 测试人员验证关闭，这是比较 正常的流程。还有一个流程是激活流程： 测试人员提交 bug =& 开发人员解决 bug =& 测试人员验证未通过 =& 激活 bug =& 重新解决 =&验证关闭。 开发人员所需要做的事情便是处理自己负责 bug， 并在禅道中登记解决方案： 1) 项目视图中的 bug 列表2) bug 的详情页面也可以找到“解决”操作的按钮。3) 解决 bug 的时候，需要填写 bug 的解决方案。附：bug 的解决方案禅道软件总共提供了其中解决方案： bydesign =& 设计如此，无需改动。 duplicate =& 重复 Bug，以前已经有同样的 bug。 external =& 外部原因，非本系统原因。 fixed =& 已解决; notrepro =& 无法重现，无非重现 bug。 postponed =& 延期处理，确实是 bug，但现在不解，放在以后。 willnotfix =& 不予解决 这其中“已解决”和“延期”的 bug 视为有效 bug。 3.4.5 文档管理 敏捷开发不提倡面面俱到的文档，但必要的文档还是很有必要的，比如数据 库的设计文档、接口文档、测试总结报告等等。具体文档库的使用，请参考：产 品经理篇中的文档管理。 3.4.6 确认 bug 当测试人员提交了 bug 之后，如果开发人员来不及解决这个 bug，这时候可 选的一个操作是确认这个 bug，给测试人员一个反馈。 bug 列表页面会显示是否已经确认过。bug 详情页面有确认操作按钮。需要说明的是，如果一个 bug 被解决之后，也会自动变成已确认。 3.5 测试团队篇 3.5.1 维护 bug 视图模块 在禅道软件中，bug 也同样需要维护模块，以便更好的组织管理 bug。这个 地方需要特别说明下，bug 模块、用例模块和产品模块是独立的，每个视图都有 自己的模块。 为什么这样做呢？主要是考虑到使用的角色不同。 在产品视图里面， 主要是用来组织需求。而在 bug 模块，则主要偏重 bug 管理，那么可能会有和产 品视图不同的模块划分。至于测试用例视图，则更不同了。模块划分里面会有很 多和测试用例直接相关的划分，比如兼容性测试，压力测试等等。所以禅道将这 三个模块分开，需要单独进行维护。 1) 进入测试视图，然后选择缺陷管理。 2) 在页面的左侧，会出现该产品的缺陷模块列表。 3) 模块列表的下部，有模块维护的连接，点击此链接，即可维护模块，详情 的维护界面， ?维护模块的时候是一级级进行维护的。比如可以选择&我的地盘&，然后维 护它的子模块。?左侧的数字是用来排序的， 可以将通过调整模块的排序字段来调整它在模 块树里面的位置。?可以选择某一个模块编辑，编辑的时候可以修改它所属的上级模块，以及 这个模块的默认负责人(当创建 bug 的时候，会自动将这个用户作为默认 的负责人)?可以选择产品视图的某一个模块， 将其下级模块复制到当前的测试视图的 模块中。3.5.2 提交 bug 1) 进入测试视图的“缺陷管理” 2) 点击页面右侧的&创建 bug&，即可进入 bug 创建页面。说明： 1) 项目和任务，以及相关需求，应该认真填写，这样可以将 bug 和项目，任 务，需求关联起来，以便以后的统计分析。 2) 影响版本是必填的。而这里面的列表来源，则是项目中的 build。如果这 个地方没有 build 的话，则需要到项目中创建一个 build。 3) 重现步骤应该翔实准确，确保开发人员可以重现改 bug。 3.5.3 验证 bug，关闭 当开发人员解决 bug 之后，就需要来验证 bug，如果没有问题，则将其关闭。3.5.4 激活 bug 如果开发人员解决 bug 之后，验证无法通过，则可以将 bug 重新激活，交由 最后的解决者去重新解决。 还有一种情况就是 bug 关闭之后， 过了一段时间， bug 又重现了，也需要重新激活。激活 bug 的时候，指派给会自动设置成为最后的解决者头上。3.5.5 找到自己需要的 bug 测试人员一个非常重要的工作就是筛选 bug，禅道对此提供了各种方便的功 能来进行筛选。 3.5.5.1 我的地盘中的 bug 列表。 我的地盘中的 bug 列表， 是所有当前指派给你进行处理的 bug。 如果该列表为空， 则表示没有你需要处理的 bug。3.5.5.2 项目视图中的 bug 列表 项目视图中的 bug 列表，是所有在这期项目中产生的 bug，所以项目团队可以很 方便的在这个页面查看到相应的 bug。3.5.5.3 分类浏览 在 QA 视图的”缺陷列表“页面，可以按照各种条件，非常方便的进行浏览。3.5.5.4 搜索功能 禅道提供了强大的搜索功能，可以组合出非常复杂的条件。3.5.6 维护测试用例视图 同 bug 视图，测试用例视图也是需要单独维护的。方法与之相同，不再赘述。 3.5.7 创建测试用例禅道中的测试用例，彻底的将测试用例步骤分开，每一个测试用例都有若干 个步骤组成， 每一个步骤都可以设置自己的预期值。这样可以非常方便进行测试 结果的管理和 bug 的创建。 直接来看创建用例的页面：说明： 1) 用例的适用阶段，指在哪些个测试阶段，可以用上这个用例。可以进行多 选。 2) 用例步骤可以非常方面在之后插入，之前插入，或者删除当前的步骤。 3) 不要把若干个测试用例作为步骤写到一个测试用例里面， 因为这样不利于 测试的管理和统计。 3.5.8 管理测试任务当开发人员申请测试之后，会生成相应的测试任务给测试人员。这时候测试 人员要做的就是为这个测试任务关联相应的测试用例。 如果这个测试任务需要多 人来配合完成， 则需要将相应的用例指派给相应的人员来进行完成，或者自己领 取相应的测试用例。 3.5.8.1 关联测试用例 1) 进入测试视图， 2) 选择“测试任务”，然后进入测试任务列表。 3) 选择某一个测试任务，点击“关联”菜单，即可出现关联测试用例的页面。几点说明： 1) 测试用例可以通过上面的搜索表单进行搜索。 2) 用例默认是关联最新的版本，也可以点击下载框，选择之前的版本 3) 可以按照需求或者 bug 来进行检索。3.5.8.2 指派或领取用例 在测试任务的用例列表页面，可以点选用例，将其指派给某一个人来执行。3.5.9 执行用例，并提交 bug 在测试任务的用例列表页面，用户可以按照模块来进行点选，或者选择所有 指派给自己的用例，来查到需要自己执行的用例列表。 在用例列表页面，选择某一个用例，然后选择右侧的“执行”菜单，即可执 行该用例。 3.5.9.1 用例列表页面，点击执行3.5.9.2 执行用例3.5.9.3 创建 bug 如果一个用例执行失败，那么可以直接由这个测试用例创建一个 bug，而且 其重新步骤会自动拼装。3.5.10 查看报表统计 测试管理的还有一个重要工作就是统计报表，直接来看步骤： 在 bug 列表页面，点击页面上部的统计报表，即可出现统计报表页面。说明：bug 的统计报表是和当前的列表集合相关的。因此，你可以通过不同的搜 索条件来查找自己要进行统计的 bug 列表，然后再按照不同的统计项进行统计。