一、禅道（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），级别高的必须修复，低级别的需要产品进行确认。