测试管理工具---禅道培训文档

1.产品经理创建产品

2.产品经理创建需求

3.项目经理创建项目

4.项目经理确定项目要做的需求

5.项目经理分解任务，指派到人

6.开发人员实现需求

7.测试人员测试，提交bug

禅道地址：http://192.168.0.196/zentao/user-login-L3plbnRhby8=.html?tid=jm9z8q2a

禅道的设计是围绕产品展开的，所以需要先添加一个产品。

	产品视图-->添加产品

产品名称和产品代号是必填项. 其中产品代号可以理解为团队内部约定俗称的一个称呼， 
比如禅道的代号是zentao，可以是英文字母和数字的组合。
产品线：该产品属于那一个产品线。比如禅道这个产品线，下面包含禅道专业版，禅道开源版，禅道企业版 。  
产品负责人：负责整理需求，对需求进行解释负责，制定发布计划，验收需求。
测试负责人：可以为某一个产品指定测试负责人，这样当创建bug，而不知道由谁进行处理的时候，该产品的测试负责人会成为默认的负责人。
发布负责人：由这个角色负责创建发布。  
产品类型：默认是正常的类型， 还可以选择多分支（适用于客户定制场景）和 多平台（适用于跨平台应用开发，比如iOS，安卓，pc端等）的产品。 
访问控制：可以设置产品的访问权限，其中默认设置只要有产品视图的访问权限就可以访问。 如果这个产品是私有产品，可以将其设置为私有项目，那么就只有项目团队成员才可以访问。或者还可以设置白名单，指定某些分组里面的用户可以访问该产品。

产品-->点击新建产品-->设置-->模块

维护模块的时候是一级级进行维护的。
也可以在产品->点击新建产品-->所有模块下的维护模块进行维护

产品-->点击新建产品-->研发需求-->提研发需求

需求的标题和所属模块是必填项。 

所属计划可以暂时保留为空。 需求审核那块，选择不需要审核，这样新创建的需求状态就是激活的。

只有激活状态的需求才能关联到项目中，进行开发。
 
 需求可以设置抄送给字段，这样需求的变化都可以通过email的形式抄送给相关人员。 
 
 可以设置关键词，这样可以比较方便的通过关键词进行检索。

产品-->点击新建产品-->计划-->创建计划

计划的名称是必填项

开始时间和结束时间都可以手动输入日期，也可以在日历小控件中选择 

可以通过选择时间段来确定结束日期，如“一个月”

创建完计划之后，可以为计划关联需求

产品-->点击新建产品-->计划-->关联研发需求

也可以在新建计划然后在添加需求的时候指定计划(已经过期的计划不会列出)

在创建需求的时候，有一个"不需要评审"的复选框，如果选中该复选框的话，需求的创建是【激活】中的；

但大部分情况下面，需求还是需要评审的；

即使产品完全由一个人负责，也可以将一些不成熟的想法存为草稿，后续再进行处理。新增需求的评审流程 如下：

如果创建需求时，不选择不需要评审，那么创建的需求为【草稿】状

评审结果可以选择确认通过、有待明确、拒绝等操作。如果选择“确认通过”， 

则需求的状态改为“激活”，然后就可以关联到项目中进行开发了； 

如果选择“有待明确”，会保持需求的草稿状态，并将需求指派回需求的创建者头上，由其继续进行完善；

如果选择了“拒绝”，则需要给出相应的拒绝原因，拒绝原因可以有：

由谁评审是记录的参与评审的人员名单，可以输入用户名来自动筛选。 一般来讲需求评审可以 

是一个线下的评审会议，在禅道里面记录下参与需求评审的人员即可。 然后指定一个参与了评审 

的用户在线上修改需求的状态即可，如产品经理。

凡是对需求标题、描述、验证标准和附件的修改，都应该走变更流程。变更之后的需求状态为变更中。 

变更之后的需求应该走变更流程

在需求详情页，点击【变更】按钮对需求进行变更操作 编辑操作是无法修改需求的标题、描述、

验收标准和附件的。 在变更需求的时候，如果选择了“不需要评审”，则需求状态自动变成激活，不需要再走评审流程。

评审结果可以选择确认通过，撤销变更，有待明确。如果选择确认通过，则需求的状态从“已变更”变为“激活 中”。 

如果选择撤销变更，则取消当前的变更，并回退到之前的版本。

 如果选择有待明确，需求被打回到需求的变更者，继续进行完善。

线下会议，可以由产品经理主持召开


会议主要内容

1. 产品经理可以事先对需求做一个划分，将本期项目计划要实现的需求做一个规划。 
2. 然后由产品经理给大家做需求的讲解，与会成员可以提出自己的意见。
3. 按照需求分析的结果对项目中要实现的需求做调整：移除不需要的需求，并添加新的需 求。 
4. 然后对需求的工作量进行估计，并确定每一个需求的优先级。 
5. 成立项目并开展工作。

项目-->项目列表-->创建项目

注意事项：

项目代号是一种隐喻，也就是团队内部可以互相了解和知晓；

在添加项目的时候，可以选择关联与之相关的产品，以便后续进行需求的关联； 

项目可以控制它的访问权限，分为默认、私有和自定义白名单三种。

项目-->新建项目-->设置-->团队-->团队管理

也可以点项目-->团队成员

关联产品：项目--->产品--->关联产品

也可以在在创建项目时关联

项目--->新建的项目--->阶段-->建任务

需要将所有的任务都分解出来。这里面包括设计，开发，测试，美工，甚至包括购买机器，部署测试环境等等 

任务分解的粒度越小越好，比如几个小时就可以完成 

如果一个任务需要多个人负责，继续考虑将其拆分

事务型的任务可以批量指派，如要让团队的每一个人都写个项目总结，可以选择类型是事务，然后批量指派 给所有人员 

任务的分配最好自由领取，调动大家积极性

任务的分解最好由团队共同完成，不要由项目经理一人包办

领取任务并更新任务工时

由开发人员账户登录（18926787153		hhgk123）

进入地盘，待处理

开发完成后点击完成按钮，填写消耗工时，指派给测试进行测试

1.创建版本：创建新的待测版本

项目-->新建的项目-->版本-->创建版本

负责人为本次测试的负责人。 

可以指定这次测试预计起止的时间。 

任务描述里面，可以注明此次测试需要注意的地方。

测试人员提交Bug ---> 开发人员解决Bug ---> 测试人员验证关闭

测试人员提交Bug ---> 开发人员解决Bug ---> 测试人员验证未通过 ---> 激活Bug ---> 重新解决 ---> 验证关闭。

当测试人员提交了bug之后，如果开发人员来不及解决这个bug，这时候可以先确认这个bug，给测试人员一 个反馈。

在BUG详情页点击【确认】按钮，确认后的BUG状态为【激活】

测试人员登录（18890325950		hhgk123）

用例的适用阶段，指在哪些个测试阶段，可以用上这个用例。可以进行多选。 

用例步骤可以非常方便在之后插入，之前插入，或者删除当前的步骤。 

不要把若干个测试用例作为步骤写到一个测试用例里面，因为这样不利于测试的管理和统计。

测试-->用例-->导出数据(注意：编码格式选择GBK）

测试-->用例-->导入CSV(注意：编码格式选择GBK）

可以由管理员到后台--自定义--用例--评审流程里开启。 

开启评审流程时，可以设置哪些用户提交的用例不需要评审。

用例的评审流程开启后，新建的用例状态为【待评审】

用例评审是一个线下活动，线下开会评审用例后，由有权限的人员显示修改用例状态。

 测试--->测试单--->关联用例

可以在用例列表，也可以在测试单--测试版本里执行用例

用例失败点击【转BUG】直接提交BUG