51Testing软件测试论坛
标题:
软件测试系列--软件缺陷管理
[打印本页]
作者:
恭喜发财dife
时间:
2018-4-27 17:26
标题:
软件测试系列--软件缺陷管理
软件测试系列---缺陷管理
一、软件缺陷的基本概念
1、软件缺陷的基本概念主要分为:缺陷、故障、失效这三种。
(1)缺陷(defect):存在于软件之中的偏差,可被激活,以静态的形式存在于软件内部,相当于bug;
(2)故障(Fault):软件运行中出现的状态,可引起意外情况,若不加处理,可产生失效,是一个动态行为;
(3)失效(Failure):软件运行时产生的外部异常行为结果,表现与用户需求不一致,功能能力终止,用户无
法完成所需要的应用。
二、软件缺陷的三个基本概念的相互关系
1、bug一定会被激活吗?激活后一定表现为故障吗?
答案是不一定,任何一个软件即便测试的非常严格,在发布后也会存在遗漏的bug,但是这些bug在用户使用的
时候不一定会被激活,因为有些bug隐藏的比较深,用户在使用的过程中不可能触发这些bug,所以这些bug一
直隐藏在软件内部,没有被激活,也就是说即使软件内部有bug,软件也可以正常运行,但也有可能,在某些情
况下,这些bug会被激活,表现为故障*。
2、故障一定会导致失效吗?
答案也是不一定,开发人员在做设计的时候,更多的考虑了在软件使用期间可能出现的故障,然后针对这些故
障采取的一些预防的措施,比如:数据库会出现的数据丢失的问题,为了避免这种失效的出现,产品开发人员
在做设计的时候,也许会采取数据库时时备份的方式,也就是在本地有一个数据库,在异地也有一个数据库,
这个地方的数据库会实现时时的备份,当其中一个数据库出现了异常,那另外一个数据库还可以启动工作,所
以说,缺陷不一定会导致故障,故障不一定会导致失效。
三、软件缺陷报告单
缺陷报告单是任何缺陷修改的一个起始,也就是我们测试人员在进行测试执行的时候,发现了一个缺陷,发现
缺陷后,我们不要口头和开发人员交流,因为口头的交流不仅没有任何的约束力,而且有可能表达不清楚,所
以我们要把缺陷落实在纸面上,也就是要测试人员填写缺陷报告单。
缺陷报告单的作用:
1、测试执行过程中,发现缺陷失效后(不一定是失效,也许是故障,一般来说这个缺陷在测试阶段被发现往
往表现为产品失效),提出书面的报告,提供给开发人员作为定位缺陷的依据,也作为日后缺陷度量的数据
依据,开发人员接到缺陷报告单后,他会根据缺陷报告单上描述的缺陷外在表现来重现这个问题,然后找出
这个问题,也就是缺陷产生的根源。
2、缺陷报告还可以作为我们日后缺陷度量的数据依据,度量是对整个产品进行考核,比如说,我们的软件在
什么时候可以发布,什么时候可以交付给客户等等问题,这个时候我们往往从缺陷度量的数据来看,比如我
们子啊最后一轮进行测试的过程中,每千行代码只有0.1个缺陷,说明我们产品的质量已经非常高了,而且遗
留的缺陷也就非常少了,这个时候就可以发布产品了,所以这个缺陷的统计数据时非常重要的,它可以作为缺
陷度量的依据。
四、软件缺陷管理的目的
缺陷管理的目的是:对各个阶段测试发现的缺陷进行跟踪管理,以保证各级缺陷的修复率达到标准,主要实现
以下目标:
(1)保证信息的一致性;
(2)保证缺陷得到有效的跟踪,缩短沟通时间,解决问题更高效;
(3)收集缺陷数据并进行数据分析,作为缺陷度量的依据。
五、软件缺陷管理工具
软件缺陷管理的流程一定要有相关的软件进行支撑,否则软件缺陷管理的流程是无法正常运行的,就类似于我
们在做开发的过程中,开发JAVA相关的程序我们就需要JBOSS这样的工具,,如果我们开发C++就需要Visua
l C++工具,在软件缺陷跟踪中我们也需要一些工具,比如商用工具Mercury Quality Center是目前非常强大的
软件测试管理工具,它的功能包括业务管理、测试用例的管理、缺陷的分析及测试脚本的管理,所有缺陷仅
仅是其一个点;Rational ClearQuest它主要用于变更控制和缺陷管理这一块,此外还有Bugzilla,Mantis,Jira三个
开源工具。
使用商用的软件缺陷管理工具或软件测试工具,好处是由商家提供一系列支持、工具的相关制定以及后期的升
级服务,所以商用软件缺陷管理工具从整体的易用性和可用性来看,要比开源工具好得多,开源工具最大的好
处就是便宜,不用去花钱购买,但是易用性和可用性相对来说就弱一些。
六、软件缺陷管理的相关角色
软件开发和软件测试的任何一个流程,都应该有流程的入口,流程的出口,还有流程的具体过程以及参与到这
些过程中的相关角色。
在软件跟踪的流程当中,有以下几类角色:
(1)软件开发人员;
(2)软件测试人员;
(3)软件测试项目经理;
(4)软件开发项目经理;
(5)CCB(Change Control Board):变更控制委员会。所谓的变更控制委员会,他是在开发人员和测试人
员对缺陷出现争议的时候,做出最后的裁判;
(6)配置管理员:就是测试人员提交BUG,开发人员修改,修改完check in ,那么在check in这个过程中需
要配置管理员参与进来,只有经过配置管理员授权,开发人员才有资格把代码从本地Check in到服务器中去,
所以配置管理员在软件缺陷管理中也很重要。
软件缺陷报告的内容以及缺陷的相关属性
一、软件缺陷报告的内容
1、Bug Title/Summary:缺陷标题/简单描述
对测试执行过程中实际出现的问题的描述,尽量要简单概要。
2、Repro Step:重现步骤
(1)描述问题的基本环境,包括操作系统、硬件环境、网络环境、被测试软件的运行环境;
(2)简单概括的描述清楚软件出现异常时,测试人员的操作步骤和使用数据;
(3)缺陷原因的分析;比如说:因为不支持字符集,而导致的乱码...等等。
(4)要写清楚,重复操作了多少次,这个bug依然出现。(不能操作一次就提交bug,因为有可能是自己操
作失误。)
(5)相关附件:为了让开发人员更好的了解Bug。 (如果从GUI界面上可以反映出软件的异常,可以截取
界面,粘贴在问题单上 或者 日志、数据包);
(6)属性(在下面详细说明):缺陷报告中除了对缺陷的基本描述外,我们还要对其属性进行说明。
二、软件缺陷的相关属性
测试人员在提交缺陷的时候,需要把缺陷,发现缺陷的过程以及缺陷的一些表现都要描述出来,除此之外这
些缺陷还有一定的相关属性,也要填写出来。
下面我们列举六个比较重要的缺陷属性。
属性1、缺陷发现人
在提交缺陷的时候测试人员一般是缺陷的发现人,这个字段也很重要,比如到QC里面统计一下本季度哪一个
测试人员发现的BUG比较多。
属性2、缺陷发现时间
缺陷发现时间也是一个统计的计数点,或者数据点,缺陷趋势图就是按照时间轴来排列的,如果缺少了缺陷发
现时间,这个图是做不出来的,没有缺陷趋势图,我们就不能进行产品的度量,就不知道产品在什么时候发布
是比较合适的。
属性3、缺陷状态
软件缺陷状态这个属性是非常重要的,在任何的软件报告中,这一个属性是一定要有的。
下面我们主要列出了在QC中常用的几种状态:
New:缺陷的初始状态;
Open:开发人员开始修改缺陷;
Fixed:开发人员修改缺陷完毕;
Closed:回归测试通过;
Reopen:回归测试失败;
Postpone:推迟修改;
Rejected:开发人员认为不是程序问题,不用修改;
Duplicate:与已提交的Defect重复;
作者:
恭喜发财dife
时间:
2018-4-27 17:26
Abandon:被Reject和Duplicate的Defect,测试人员确认后的确不是问题,将Defect置为此状态。
New是缺陷的初始状态,所谓初始状态就是发现问题,发现问题,提交问题后,这个缺陷就处于New状态;
提交给开发人员后,开发人员接受这个问题,那么就把这个缺陷的状态就更改为Open;
开发人员修改缺陷之后,就会把这个缺陷的状态改为Fixed;
然后提交给测试人员,测试人员进行回归测试,回归测试通过,就把状态改为Closed;
我们可以看到New--Open--fixed--closed这个状态是一个比较理想的缺陷流程,也就是测试人员提交问题,开发人
员接受并修改问题,然后测试人员进行回归测试通过。
但是我们一般在缺陷跟踪流程当中也会遇到一些问题:
1、比如说回归测试失败,这个状态就是Reopen,也就是说测试人员在进行回归测试的时候失败了,就要把这个
缺陷的状态改为Reopen,然后再提交给开发人员进行修改,开发人员修改完之后,把这个缺陷的状态改为Fixed,
然后又提交给测试人员,测试人员再一次进行回归测试,直到回归测试成功,把这个缺陷的状态改为Closed。
2、Postpone:推迟修改,比如当我们把问题提交给开发人员的时候,开发人员觉得也接受这个问题,但是暂时
无法修改,那就可以把这个问题置为推迟状态,此时这个缺陷的状态就是Postpone。
3、当我们提交的Defect与别热提交的相同时,缺陷就被置为Duplicate状态。
4、比如说开发人员觉得测试人员提交的不是问题,不用修改,可以将这个BUG置为Reject状态。
5、被Reject和Duplicate的Defect,我们最终要把它置为Abandon状态。
属性4、缺陷严重程度(Severity)
缺陷的严重程度就是:站在用户的交付,bug出现之后对软件质量的破坏程度,也就是说这个软件缺陷的存在
将对这个软件的功能和性能产生怎么样的影响。
一般来说,软件的严重程度分为五个等级:
第一个等级:致命的软件缺陷(Fatal)
造成系统或应用程序崩溃、死机、系统挂起,或造成数据丢失,主要功能完全丧失,导致本模块以及相关模
块异常等问题。如代码错误,死循环,数据库发生死锁、与数据库连接错误或数据通讯错误,未考虑异常操
作,功能错误等。
第二个等级:严重错误的软件缺陷(critical)
严重错误的软件缺陷(critical):系统的主要功能部分丧失、数据不能保存,系统的次要功能完全丧失。问题
局限在本模块,导致模块功能失效或异常退出。如致命的错误声明,程序接口错误,数据库的表、业务规则、
缺省值未加完整性等约束条件。
第三个等级:一般错误的软件缺陷(major)
一般错误的软件缺陷(major):次要功能没有完全实现但不影响使用。如:提示信息不太准确,或用户界面
差,操作时间长,模块功能部分失效等,打印内容、格式错误,删除操作未给出提示,数据库表中有过多的
空字段等。
第四个等级:较小错误的软件缺陷(Minor)
较小错误的软件缺陷(Minor),使操作者不方便或遇到麻烦,但它不影响功能性的操作和执行,如错别字、
界面不规范(字体大小不统一,文字排列不整齐,可输入区域和只读区域没有明显的区分标志),辅助说明描
述不清楚。
第五个等级:建议问题的软件缺陷(Enhancemental)
建议问题的软件缺陷(Enhancemental):由问题提出人对测试对象的改进意见或测试人员提出的建议、质疑。
属性5、缺陷的优先级(Priority)
站在 开发/项目 的角度,综合权衡修改bug的时间、成本、技术和风险,决定bug修改的先后顺序。
优先级每个公司都有自己的标准,例如某公司的标准为:
P0:必须当天修改,8小时内修改;(优先级最高的)
P1:1~2内修改;
P2:2~4天内;
P3:一周内;
P4:发布周期内或者不修改。
属性6、缺陷的类型
1、质量特性的角度
(1)功能;(2)性能;(3)安全性;(4)易用性;(5)可靠性。
2、功能性角度
(1)错误(Error);(2)遗漏(Missing);(3)多余的(Extra);(4)可优化(Improvement /Enhanc
ement /suggestion)
3、缺陷产生的原因:
(1)需求不清晰,导致设计目标偏离客户端需求,从而引起功能或产品特征上的缺陷;
(2)对程序逻辑路径或数据范围的边界考虑不够周全,漏掉某些边界条件,造成容量或边界错误;
(3)新技术的应用,可能涉及技术或系统兼容的问题,事先没有考虑到;
(4)可能由于不支持字符集,而导致的乱码。
等等的一些原因。
属性7、缺陷所属版本
在软件开发测试的过程中,版本的管理是非常重要的,也就属于配置管理的范畴,测试人员开始测试的时候肯
定从配置库里面提取最新的版本;
比如说1.0版本,那么测试完成之后,把问题提交给开发人员,开发人员对1.0版本的源代码进行修改,那么这
个修改完之后的版本肯定是1.0的下一个版本,也就是1.1版本,修改完之后测试人员要进行回归测试,这个时
候测试人员进行回归测试的版本一定是最新版本,即1.1版本。
细分的话,缺陷所属版本还应该有三个属性:(1)发现缺陷的版本;(2)修改bug的版本;(3)回归测试的
版本。
所以说,只有缺陷所属版本在开发过程中规定明确落实下来,我们的产品质量才能有保证,不会造成开发和测
试的混乱。
属性8、缺陷修改日期
最后一个缺陷的属性是缺陷修改日期,是主要对开发人员进行考核的参数,比如测试人员在3月份提交了一个
测试报告单,开发人员在12月份才修改这个问题,由此可见,开发人员修改这个问题的响应时间太长。所以缺
陷修改日期往往可以作为绩效考核或者其他的一些数据统计的基础。
三、范例:优秀的缺陷跟踪单
对WPS或者OFFICE进行测试时,发现错误。
简单描述:
--Arial 、Wingdings 和 Symbol字体会破坏新文体。
详细描述:
--软件测试环境为Windows 2000 sp4
--启动WordEdit编辑器,然后创建新文件;
--输入四行文本,重复输入”welcome to shanghai university“
--选中这四行文本,然后选择下拉菜单,并选择Arial字体;
--所有文本被转换成控制字符、数字、和其他明显的随机二进制数据;
--重复三次,结果都一样。
相关附件
--附件1:变换格式之前的文档;
--附件2:变换格式之后的文档;
软件缺陷初步分析:
--可能是格式问题,保存文件,关闭WordEdit并重新打开文件,但是数据依然被破坏;
--在改变字体前保存文件防止错误;(建议性的)
--对现存文件进行上述错误,错误不再发生;
--只在Windows 2000下发生,而不出现在Solaris、Mac和其他Windows系统。
欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)
Powered by Discuz! X3.2