一、禅道（ZenTao）简介
禅道是一款B/S结构的软件，主要功能 ：产品管理、项目管理、测试管理、文档管理、组织管理、后台管理
备注：市面上的用例管理工具很多，每个项目都可能有自己的用例管理工具，禅道是一款免费开源的管理工具，很多自研公司都是用的禅道。这些管理工具功能和用法大同小异。
二、禅道的安装
1）下载禅道项目管理系统，到禅道官网（Windows/Linux/Mac）
2）将禅道软件安装到电脑根目录上（D：\xampp）
3）在“禅道集成运行环境”窗口中，单击“启动禅道”按钮，如出现以下页面说明成功
注意：禅道访问默认使用admin/123456
三、禅道中的常见操作
禅道中常见操作之添加用户
禅道中用户大概可以分以下几种：测试人员、研发人员、产品经理、
项目经理、测试主管 、研发主管、产品主管、运维人员
注意：用户添加前，先要配置分组和所属部门的创建
禅道中常见操作之添加产品
禅道中的需求依附在产品下，新增产品以后才可以新增需求，然后在新增的
产品下提需求和计划，可将产品分解为子模块A、模块B、模块C...
禅道中常见操作之添加项目
1、项目经理进入项目视图，添加项目
2、项目关联产品，即可选择关联该产品对应的某些需求
禅道中常见操作之bug管理
禅道里面设计的理念是bug主要附属在产品概念下面，有对应产品以后才
可以开始提bug。默认Bug的严重程度分为四级，优先级分为五级（管理员
可进行自定义）。
1、禅道里面缺陷处理的基本流程是：
测试提交bug => 开发解决bug => 测试验证bug => 测试关闭bug；
2、如果bug验证没有通过，可以激活：
测试提交bug => 开发解决bug => 测试验证bug => 测试激活bug => 开发解决bug => 测试验证 => 测试关闭。
3、在创建bug的时候，必填的字段是：
影响版本，bug标题，重现步骤，所属模块。
4、创建bug的时候，可以直接指派给某一个研发人员去处理，他可以来验证解
决这个bug。
5、开发解决bug后，可以直接指派给对应测试员去验证，他可以来验证通过后
关闭这个bug
四、如何提出高质量的bug
发现bug是测试人员必须具备的能力，不管在什么公司，测试⼈员在执行测试任务的时候，发现bug和提bug,以及跟踪Bug是必要的工作。如何提出高质量的bug,是体现测试人员水平的重要标志。从功能测试人员，到测试开发，高级测试开发等，都避免不了与bug打交道。可是现在也存在这么⼀种现象：测试人员提的bug质量不高，开发人员看不明白。于是就来找测试人员，来解释这个bug是怎么回事，如此来回折腾浪费工作时间，在跨部门协作的时候，这样的情况尤其严重。
测试人员提bug质量不高，主要表现在如下几个方面：
（1） bug表述不清，只有⼀句话，介绍bug是什么，然后没有其他的说明。
（2）不提bug,发现问题直接告诉开发⼈员，在工作交流平台上不断讨论bug。
(3)发现bug的场景没有保留，重现成本较高。
针对上面的各种情况，我们测试人员要不断地提高相应的能力，提出高质量的bug。
如何提出高质量的bug呢？
⼀，熟悉Bug管理工具
每个公司不管规模大小，都应该有bug管理平台，如jira,禅道，teambition,云龙,或是公司自主研发的项目管理平台；只要我们通过相应的平台来管理项目，bug等，要想更好地提bug必须先全面了管理平台的功能。很难想象，如果你相应的管理平台都不会用，如何更好的辅助测试呢？
⼆，准确地给bug定级
BUG严重程度（针对BUG）、优先级别（针对解决时间）。根据bug的影响，每个公司会定不同的bug分级标准。如p0,p1,p2,p3,或是致命，严重，⼀般，低级与建议,或者A,B,C,D。作为测试人员必须了解相应的分析标准，在发现bug后才能准确地给bug定位，从而影响bug的修改优先级。
三、准确记录bug信息
要想准确地定位bug，从而快速地修复bug,相应的bug信息是必须的，同时发现bug必须通过公司的bug管理平台进行记录和跟踪。有的时候公司会通过bug管理平台来设定bug的模板，有的公司没有，但是不管有没有模板，我们需要记录以下信息：
【环境】
【前置条件】
XXXX
【测试步骤】
1，XXXX
2，XXXX
3，XXXX
【预期结果】
XXX
【实际结果】
XXXX（必须有截图）
同时上传错误日志或是错误界面截图（甚至用录屏工具录屏）。准确设置相应的bug负责人，相关知情人，以及其他的必要信息。如果bug比较复杂，保留bug发现的现场，以供开发人员来进行排查。
四、实时跟踪Bug进展
Bug提交后不是就和测试人员没有关系了，你需要实时跟踪bug的进展情况。根据bug的不同级别，关注开发人员修改的进度，相应的修改情况是否准确记录。同时要做到如下几点：
（1）根据测试安排和轮次，先将发现的bug进行记录，不能反复验证bug.
（2）不要相信开发人员，不管他说的修改的内容如何，影响范围如何，必须按自己先前的测试用例进行验证。
（3）如果上线的时候，原则上必须把bug修复完；如果没有修复完，对bug进行评审（CCB），级别高的必须修复，低级别的需要产品进行确认。
