一.什么是缺陷报告
1. 测试人员发现bug,将bug记录在缺陷报告中
2. 通过缺陷报告将bug告知给开发人员
3. 通过缺陷报告实现对bug的跟踪管理
4. 缺陷报告是测试人员和开发人员之间重要的沟通方式
二.编写缺陷报告的常用工具:
在企业中通常使用缺陷管理工具来管理bug,例如:禅道(中文、国产、免费)、jira(鸡爪)、mantis(螳螂)、QC(惠普公司.收费.英文)、bugfree.、bugzilla等,还有一些企业使用自制的bug工具
说明:不同公司使用的bug管理工具不同,但是都是管理bug的,所以模板大同小异
三、如何编写缺陷报告(组成)
案例:两数加减乘除,除法功能没有实现
1、缺陷编号(defect/bug ID)
就是发现bug的顺序号(流水号),能唯一标识每一个bug,通常的bug管理工具会自动生成编号
注意:项目中的bug编号是统一排序管理的
2、缺陷标题(summary)
简明扼要的描述该bug(概括描述)
3、发现者/创建者(detected by)
通常填写发现bug的测试人员的姓名或账号
账号通常在企业由管理人员创建,例如:
测试人员账号:
Zhoujl_qa、cuihui_qa
4、提交缺陷的日期(detected on date)
注意:应“及时”提交bug
发现bug应“审核”,尽量避免“假bug”被提交(例如:操作错误、配置错误、需求理解错误等造成的假bug),保证提交bug的质量
5、缺陷的指派(缺陷指派给谁处理):(assigned to)
常见指派:测试人员-->开发主管-->具体的开发人员
其他情况:
例如:小公司
测试人员-->具体开发人员
例如:大公司
测试人员-->测试主管-->开发主管-->具体开发人员
6、功能模块(subject)
在哪个功能模块中发现该bug
作用:定位bug,并且通常开发主管可以通过功能模块明确,该由谁来负责解决该bug(一般是谁开发的谁负责解决)
7、所属的版本
说明:对于专业的测试人员来说,版本不仅仅指最终发布的版本,也包括在研发过程中曾经出现过的若干临时版本。
扩展:回归测试(回测),就是在当前版本中,对于上个版本测试过的功能,再重新测试一遍。
回归测试的必要性:1.如果有新增功能,新功能可能会对原有功能造成影响,引发bug;2.开发人员修改bug,很可能在解决bug的同时带来新的问题;
回归测试存在重复性测试,所以如果条件允许,自动化进行回归测试是比较高效的
8、状态(status)
表明缺陷处于怎样的处理情况
(1)常见的状态
新的--new 激活的--open
已解决--fixed 已关闭--closed
(2)不是很常见的状态
被拒绝的--rejected 重新激活--reopen
面试题:
Q1:软件bug的生命周期?/缺陷报告的跟踪管理过程(流程步骤)
缺陷报告/缺陷的处理过程(流程、步骤、生命周期)
步骤1:测试人员提交新的缺陷给开发经理
步骤2:开发经理对缺陷进行审核,
情况1:如果确认是有效bug,会将缺陷激活,并指派给相应的开发人员
情况2:如果确认不是bug,将拒绝该bug,由测试方对被拒绝的bug进行相应处理
步骤3:开发人员对指派的bug进行调试和修改,解决后bug将设置为“已解决”状态
步骤4:测试人员对已解决的bug进行返测,
情况1:返测通过,测试人员 将bug关闭
情况2:返测失败,测试人员将bug重新激活,指派回开发人员继续解决bug,直到bug返测通过关闭为止
返测:就是对开发人员已解决状态的bug进行测试验证该bug是否被修复
Q2、如果提交的bug(提bug)被开发方拒绝了,测试人员要怎么做?(经验型题目,以下为答题思路)
首先:明确bug被拒绝的原因,然后自检自查,确认是否由于测试人员操作失误或对于需求理解错误等造成“无效bug”被提交
接下来:找相应的人员(开发人员、产品经理等)进行沟通讨论,确认是否是bug
如果在沟通解决问题的过程中遇到了自己无法解决的问题,应问自己的直属领导汇报,由领导出面协调解决
最终:如果经过沟通讨论确认不是bug,由测试人员或测试主管负责关闭该bug,如果最终确认是bug,那么谁拒绝谁负责将bug激活,再次回到缺陷处理流程中,继续跟踪处理
9、缺陷的严重程度(severity)
严重程度:表明缺陷有多糟糕,对程序破坏有多大。
1--致命--urgent
2-严重--high
3-中等/一般--medium
4-建议性小问题--low
说明:1)不同的bug管理工具,严重级别的划分可能不同,有分5级甚至5级以上的。
在实际测试中:“中等”级别的bug 相对较多,“建议性小问题”在项目前期会比较集中(提示:项目面试中经常会被问印象深刻的bug,各个严重级别的bug适当留意准备)
(2)bug的的严重级别定义太笼统不详细,容易造成开发人员和测试人员之间的争议,所以企业通常会制定详细的严重级别说明解决该问题。
注意:不同公司,甚至同一公司不同项目组,关于bug严重程度说明都可能不同,要注意区别参考
3)经验:通常如果功能没有实现,属于2--严重
10、缺陷优先级(priority)
说明:就是希望或者建议开发方在什么版本或什么时候解决该bug(决策权在开发主管,测试方只是提供建议)
优先级的级别划分:
1--立即解决--brgent
2-下一个版本解决--urgent
3-在软件发布之前解决--medium
4-尽量在软件发布之前解决--low(数量少、不严重--通常中等及以下级别)
说明:1)不同的bug管理工具,严重级别的划分可能不同,有分5级甚至5级以上的。
(2)测试人员建议下一个版本解决bug比较多
(3)通常严重程度和优先级是正比关系,但是有特殊情况:界面的bug(建议性小问题)严重级别低,但是通常优先级别较高(bug)
(4)测试人员建议缺陷的优先级后,开发方可能会根据实际情况修改优先级,不同公司、项目组对于bug优先级的具体说明还是可能不一样的,大家工作中应注意区别。
Q1:影响缺陷优先级的因素有哪些?
(1)缺陷的严重程度,严重程度越高,通常优先级也越高
(2)开发人员的开发压力,通常开发压力越小,解决bug的优先级越高
(3)缺陷的影响范围越大,优先级越高
(4)解决缺陷的成本(时间)成本越低,优先级越高
Q2:缺陷的严重程度和优先级是正比关系吗?
通常是正比关系,但是有特殊情况,例如:界面拼写错误严重级别低但是优先级高
Q3:缺陷的严重程度和优先级确定后,开发方可以修改吗?
严重程度一旦确定开发方不能修改
优先级开发方根据实际情况可以修改,通常延后
Q4:发布的软件中存在发现但是没有解决的bug吗?
在发布的软件中有可能存在发现但是没有解决的bug
此类bug数量应较少,严重程度应较低,通常中等及以下。
通常经过“bug讨论”,分析解决bug的付出成本,和不解决bug是否会给用户带来严重损失,以及由此是否会引发法律诉讼后,才能决定
该类bug发布后,软件企业通常会通过打补丁或升级版本的方式,在后期解决bug
11、缺陷重现步骤/缺陷描述(description)
就是将发现bug的过程(步骤、数据)记录下来,使开发人员能够重现bug
要求:逻辑清晰、用语专业准确、不要有二义性(歧义)、易读易懂、不要出现评价性的词语,做到如实记录bug
缺陷报告中可以附带“证迹”(通常就是截图或视频)
测试人员应养成随手截取证迹的习惯
提示:很多企业会对缺陷描述有格式要求,常见的格式:
例如:
步骤:(step)
预期:(期待)结果(expect result)
实际: (真实)结果(actual result)
四、缺陷报告总结
1.缺陷报告的作用?
(1)缺陷报告可以记录bug
(2)缺陷报告可以对bug进行跟踪管理
(3)缺陷报告可以实现对bug的分类、统计和总结
2.如何识别bug?
(1)参考需求文档,当与需求不符时就是bug
(2)参考bug的5条定义(总的纲领)
(3)参考测试用例中的预期结果,当实际结果与预期结果不一致就是bug
(4)与测试同事、开发人员、产品经理,用户等沟通、讨论来识别bug
3.编写缺陷报告的注意事项?
补充:随机bug
也叫偶发缺陷或不可重现bug(慎重使用该名称),就是执行相同的测试过程,时有时无的bug
Always sometimes
问题:测试人员如果遇到随机bug如何处理?
(1)遇到随机bug也要报告
(2)随机bug要说明该bug为随机bug
(3)随机bug的描述应尽量详细,尽可能多的提供bug信息,方便开发方进行bug调查,如果能够提供证迹尽量提供
(4)如果开发方需要测试人员配合bug调查,测试人员应积极配合(例如:提供bug出现频次、保留测试环境、提供相关测试数据或日志等)
(5)如果可以进行白盒测试,也可以加入白盒测试辅助