用例管理工具 禅道

发布时间 2023-05-04 16:50:13作者: 是程序喵哇
一、禅道(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),级别高的必须修复,低级别的需要产品进行确认。