一、禅道(ZenTao)
(1)介绍
禅道是一个项目管理工具,也是一个bug管理工具,还是一个用例管理工具。
(2)作用
为了解决众多企业在管理中出现混乱,无序的现象,开发出来
(3)来源
禅道属【易软天创公司】
(4)属性
禅道是集产品管理,项目管理,测试管理于一身,同时包含事务管理,组织管理众多功能,是中小企业管理的首先工具
(5)架构
bs架构(是web)
(6)常见项目管理工具
禅道、jira/confluence(鸡爪),tapd(腾讯开发,敏捷开发)
Jira
Tapd
(7)常用的用例管理工具
禅道、testlink、test manage、飞蛾、
(8)常见的bug管理工具
禅道、bugfree、bugzilla
(9)为什么我们要学习禅道?
因为禅道集于用例管理工具,缺陷管理工具,项目工具一身
(10)禅道的特点
a、开源、免费
b、安装简单
c、功能齐全
二、禅道安装
1、新建一个文件夹(不要有中午路径和目录)
2、下载禅道安装包
3、点击安装包
4、安装后有一个文件夹,点击打开
5、点击启动禅道
6、点击启动
7、访问禅道
8、点击开源版
9、输入账号和密码
10、安装成功
三、禅道的使用
1、了解公司成员在禅道中的工作职责
2、添加用户
a、单个添加用户
b、批量添加用户
3、添加产品:
4、提需求
5、维护模块
6、计划
7、需求
==========================
我们的工作就在这里
用例:
8、新建用例(新建单个用例)
9、建用例(批量添加用例)
10、导入到用例
11、导入用例出现问题
(1)用工具上的模板,或者修改自己模板(加上两个必填项)
(一)先导出一条写好的用例
(二)在将写好的用例,增加用例
(三)在导入到用例中
12、执行用例
用例:(有通过,失败,阻塞)
失败的用例就是bug
13、点击bug
14、 bug包含的内容:
1、所属产品
2、所属项目
3、所属模块
4、影响版本
5、当前指派
6、bug类型
7、bug标题
8、bug严重级别
9、bug优先级
10、重现步骤
11、相关联需求
15、bug类型:
(1)代码错误
(2)界面优化
(3)配置相关
(4)安装部署
(5)安全相关
(6)性能问题
(7)标准规范
(8)测试脚本
(9)其他
16、系统
17、浏览器
18、直接添加bug:
19、添加单个bug
20、批量添加bug
21、bug报表
22、导出bug清单
23、bug清单
三、BUG
1、bug的等级
(1)1级bug (致命bug)
(2)2级bug(严重bug)
(3)3级bug(一般bug)
(4)4级bug(简易性bug)
划分:
1级bug (致命bug)
必须优先修改,在测试中较少出现,一旦出现应立即中止当前版本测试;
(1)常规操作引起的崩溃,死机,死循环,内存泄露,无法启动,异常退出,严重花屏
(2)数据泄露,数据安全性问题, 如恶意攻击造成账户密码信息泄露
(3)涉及金钱,如支付类的软件,金钱的计算
(4)导致无法测试的错误:如服务器报500
(5)功能实际与需求严重不符
2级bug (严重bug)
不影响其他功能测试的情况下可以进行版本测试
(1)重要功能不能实现如:微信不能聊天,或发朋友圈
(2)错误的波及面广,影响其他重要功能实现(如系统刷新,数据不更新)
(3)非常规操作告知:崩溃,死机,死循环,比如:一个账号,多区域,多设备登录等
(4)外观难以接受的缺陷(如:页面失真,完全变形)
(5)密码铭文显示(需要脱敏)
(6)轻微的数据计算错误
3级bug (一般bug)
测试工作中存在最多的,解决率关系版本的优化程度
(1)次要功能不能实现:如表情包,添加文字
(2)操作页面错误
(3)查询错误,数据显示错误
(4)兼容性问题
4级bug(建议性bug)
测试初期较多,优先程度低,在测试后期出现较少,
(1)界面不规范 (如:风格,一半中文,一半英文)
(2)辅助说明描述不清
(3)日常描述实用专业术语不规范
(4)界面存在错误文字
(5)用户体验感不好
2、优先级
bug的处理时间
1级 表示立即处理
2级 表示紧急处理
3级 表示正常处理
4级 表示有时间处理
3、重现步骤
(1)重现步骤
(2)实际结果
(3)预期结果
4、关联需求
工作中提交bug,一定要记得关联需求
5、bug生命周期
①基本流程
新建bug(测试)==指派给开发(指派前后端开发,测试指派)==开发验证bug==解决bug(开发)==待验证,(开发转给测试)==验证bug(测试)== 验证通过==关闭bug(测试)
②异常流程(验证不通过情况)
新建bug(测试)==指派给开发(前后端开发,测试指派)==开发验证bug==解决bug(开发)==待验证,(开发转给测试)==验证bug(测试)==验证不通过==再次指派给开发(前后端开发,测试指派)==解决bug(开发)==待验证,直到验证通过===关闭bug(测试)
③异常流程(关闭bug后,激活bug)
新建bug(测试)==指派给开发(前后端开发,测试指派)==解决bug(开发)==待验证,(开发转给测试)==验证bug(测试)== 验证通过==关闭bug(测试)==再次遇到同一个bug==激活bug==指派开发==解决bug(开发)==待验证,(开发转给测试)==验证bug(测试)== 验证通过==关闭bug(测试)
在工作中已经提了bug,需要和对应的开发通知下,自己要跟进
6、bug解决方案:
(1)设计如此
(2)重复bug
(3)外部原因
(4)已解决
(5)无法重复
(6)延期处理
(7)不予解决
7、 你认为是bug,开发认为不是bug,如何处理?
总结:三个方向:
①自我原因
检查自己的测试过程或疏忽的问题,如:页面404,服务未启动,自己配置错了、后天数据库有脏数据等。
②开发原因
a.你把报错的图片截取出来
b.把测试步骤记录下来,重现bug步骤
c. 查看后台的日志,把日志错误查找出来
d、在和开发进行沟通,说明原因;如果电话沟通不了,现场沟通,操作bug说明报错,说明影响程度。
e.如果开发还是不认,需要找开发经理,协调测试,请求其他开发辅助解决;
③产品原因
既不是开发原因,也不是测试原因,是产品原因
与开发沟通,开发是按需求开发,测试是按需求测试,测试的时候发现测试不了,少了某个步骤或环节,测试不了,找到开发,开发不认。找产品确定功能点,是不是产品遗漏了,如果是产品少了需求,就要从产品通过邮件发送整个项目组,补上需求,给开发加上工期,测试在测试。
8、偶现bug?
工作中出现了偶现的bug如何处理?(刚刚有,现在没有了)
偶现bug就是无法重现的bug:
解决方案‘:
1、先记录重现步骤,和报错的现象,查看后天报错
2、在与开发交流,描述bug的现象,确认bug的严重程度;
3、尽量去重现或查看源代码,查看逻辑是否有问题,让开发修改
4、根据bug的严重程度,找测试经理确认:影响小,不影响版本,先记录下,写明原因,下一个版本解决或后期关注;如果影响大,找测试经理和开发经理协调修改
9、bug的状态
1、new (新的)
2、assigned(已指派)
3、open(打开)
4、fixd(修复)
5、pending reset(待再测)
6、close(已关闭)
7、reopen(再次打开)
8、pending reject(拒绝)
9、rejected(被拒绝)