软件测试--缺陷报告

一、缺陷报告的基础知识

1、什么是缺陷报告

1)测试人员通过缺陷报告来记录缺陷

2)测试方通过缺陷报告,将缺陷告知给开发方

3)通过缺陷报告实现对缺陷的跟踪管理(设计科学的缺陷管理流程)

总结:缺陷报告是测试人员和开发人员之间重要的沟通方式

2、缺陷报告常用的工具

在企业中都是通过缺陷管理工具来管理缺陷,常用的有:mantis(螳螂)、禅道(zentao国产)、QC(惠普公司、付费)、jira(谐音鸡爪)、bugfree、bugzilla等,还有一部分企业会自制bug管理工具。

提示:不同的工具缺陷报告的模板会有差异,但是毕竟都是对bug进行记录管理,所以核心的内容还是大同小异的

二、如何编写缺陷报告

1、缺陷报告核心组成

1. 缺陷编号(defect/bugID)

说明:记录发现bug顺序流水号

缺陷编号能唯一标识每个bug(不重复)

通常在缺陷管理工具中,缺陷编号是自动生成的

2.缺陷标题(summary)

简明扼要地将缺陷进行描述(概括)

3.缺陷的发现者/创建者(detected by)

此处通常会填写测试人员的账号/姓名

例:测试人员chengxiaoming_QA

4.提交缺陷的日期(detected on date)

注意:缺陷应及时提交

1)缺陷应及时提交,不应人为拖延,影响项目进度

2)在发现bug后,测试方要进行bug审核,确认bug是否有效,尽量避免无效bug(假bug/无效bug等)被提交。

5.缺陷的指派(assigned to)

就是缺陷处理流程中的工作任务安排

1)常规

测试人员→开发主管→具体的开发人员→

2)非常规

(1)例:小公司

测试人员→具体的开发人员

(2)例:大公司

测试人员→测试主管→

6.功能模块(subject)

说明:在哪个功能模块中发现的该bug

便于定位bug,也使开发主管更容易明确将bug指派给哪位具体的开发人员

7.版本(detected in releace)

版本说明:

(1)在专业的测试人员的理解中,版本不仅是指最终发布的版本,也包括在软件研发过程中,出现的若干临时版本

(2)测试方不负责生成版本信息,版本信息通常由项目团队提供

8.缺陷的状态(status)

说明:表明缺陷处于怎样的处理情况

常用的缺陷状态:

新的-new  激活的--open  

已解决--fixed  已关闭--closed

不太常用的缺陷状态:

重新激活的--reopen  被拒绝--rejected

9. 缺陷的严重程度(severity)

说明:表明bug有多糟糕,对程序的破坏有多大

通常bug的严重级别:

1--致命--urgent

2--严重--high

3--中等--medium

4--建议性的小问题--low

说明:

1)不同的bug管理工具级别划分不同,有的工具bug的严重级别划分超过4级

2)缺陷的严重级别定义比较笼统,在实际应用中容易造成争议,所以企业通常会提供详细的bug严重级别说明,测试人员定义严重级别时注意参考,提示:不同公司,甚至同一公司不同项目组,bug严重级别的说明都可能不同,注意区别参考。

3)在项目测试过程中,中等级别bug最多,建议性的小问题主要集中在项目前期

4)经验:

通常功能没有实现属于严重级别(high)

通常UI(界面)错误属于建议性的小问题(low)

10. 缺陷的优先级(priority)

说明:建议该缺陷在什么版本或什么时候被解决--测试人员在优先级的定义上没有决策权,可以给建议,但是开发方结合实际考虑多方因素,可以修改优先级。通常缺陷的优先级别:

1--立即解决--urgent

2--下个版本解决--high

3--在软件发布之前解决--medium

4--尽量在软件发布之前解决--low

说明:

1)不同的缺陷管理工具的优先级定义可能不同,有可能超过4个级别

2)通常越严重的bug,优先级越高,但是一些UI缺陷,虽然严重级别低(4级),可是优先级却高(一般优先级1/2级)

3)优先级4级的定义,一般需要讨论确定,而且该级别bug数量极少并且不严重(通常中等以下严重程度),软件发布后,可以通过省级或者打补丁的方式给与解决。

4)不同公司优先级的详细说明会有不同,大家工作时要注意参考。

11. 缺陷描述/重现步骤(description)

说明:将发现bug的过程(步骤、数据)记录下来,使程序员可以重现该bug(要让程序员看明白)注意:逻辑清晰、易读易懂、不要有二义性(歧义)、专业准确、缺陷应如实记录,不要有评价性的语言。

补充:缺陷报告中一般会要求附带“证迹”(图片或视频)

(1)缺陷报告的跟踪处理过程(重点)

(流程、步骤、生命周期、bug的一生)?

步骤1:测试人员提交新的缺陷给开发主管(提bug)

步骤2:开发主管确认该bug

情况1:确认是bug,开发主管将缺陷指派给具体的开发人员,缺陷被激活

情况2:确认不是bug,开发主管“拒绝”该bug,测试方经过沟通、确认后作出相应处理。

步骤3:开发人员调试(debug)并解决bug,解决后,bug为“已解决”状态

步骤4:测试人员对“已解决”的bug进行返测

情况1:返测通过,测试人员将bug关闭

情况2:返测未通过,测试人员将bug重新激活,指派回给该名开发人员,再次解决bug,直到返测通过,关闭为止。

(2)什么是返测?(重点)

测试人员对(已解决)的bug进行再次测试,用以验证该bug是否被修复。

面试题2:如果测试人员提bug,被开发方拒绝了?要怎么办?

首先:明确bug被拒绝的原因,然后自检自查,确认是否有bug

接下来:要与相应人员沟通确认bug,如果沟通过程遇到自己无法解决的问题,向自己的直属领导汇报,由领导出门解决问题。

最终:如果沟通讨论后确认不是bug,就由测试方(测试员/测试主管)负责“关闭bug”

如果沟通、讨论后确认是bug,那么谁拒绝的谁负责激活bug,并将bug纳入回常规处理流程。

提示:不同的缺陷管理工具,模板不同,缺陷的状态也有可能不同。

2、回归测试(重点)

(1)回归测试,在当前版本中,对上一版本测试过的所有功能再重新测试一遍,

(2)为什么要做回归测试(必要性):

①解决bug的同时,可能会带来新的问题

②新增加功能,可能对原有功能造成影响,产生新的问题。

③回归测试存在“重复测试”,如果条件允许,可以自动化测试实现回归,这样可以提供测试效率

3、影响bug优先级的因素有哪些?

1)缺陷的严重程度--缺陷越严重优先级越高

2)缺陷的影响范围--影响范围越大,优先级越高

3)开发人员的开发压力--一般开发压力小,bug优先级越高,开发压力越大,优先级越低

4)解决bug的成本(时间)--一般成本越低,优先级越高

4、bug的严重程度和优先级一定是正比关系吗?

不一定,通常情况严重程度和优先级是成正比关系的,但是有特殊情况,例如:UI缺陷,严重程度低,但是优先级却高。

5、bug的严重级别和优先级确定后,开发方可以修改么?

严重级别确定后开发方不能修改缺陷优先级测试方给出建议,开发方可以修改(通常是延后)

6、发布的软件中,是否可能存在发现但是没有解决的bug?

有可能,通常此类bug要求数量极而且不严重,该类bug需要通过“bug讨论”,权衡解决bug的成本,以及不解决是否会给用户带来严重损害,以及是否会产生诉讼,评估讨论后,方能确定该类bug发布后,软件企业通常会通过升级版本或打补丁的方式给与解决。

三、缺陷报告总结

1、缺陷报告的作用?

1)可以记录缺陷

2)可以实现对bug的跟踪管理

3)可以实现对bug的分类、统计和总结

2、如何识别缺陷?

1) 参考需求要求--当实际结果与需求不符就是bug

2) 参考缺陷的定义(总的纲领)

3) 参考测试用例中的预期结果-当实际结果与预期结果不一致就是bug

4) 与测试人员、开发人员、产品经理、用户等沟通讨论来识别bug

3、编写缺陷报告的注意事项?

1)小的缺陷也要报告

2)对于不可重现的缺陷(随机bug)也要报告,但要注明该bug不可重现

3)及时报告缺陷,不作任何评价

4)对缺陷的严重程度、优先级的划分准确、客观,不夸大bug

5)缺陷描述清晰、准确、易读,使用最少、必须得步骤,保证缺陷可以再现

6)在提交缺陷报告之前一定要认真审核,确保提交的缺陷是有效的,而不是因为自己的疏忽或操作不正确造成的“假缺陷”

  • 4
    点赞
  • 54
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

测试日记

你的鼓励将是我最大的创作动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值