一、引入
最近学习测试也有一段时间了,是不是总感觉只学了九牛一毛的样子,可是学就得一直坚持不是,有句话说的好,你选择的路,跪着都要走完,所以,接着跟我来学习下测试中关于缺陷管理的知识吧,加油。
二、基本概念
Bug:程序缺陷,电脑系统或者程序中存在的一种破坏正常运转能力的问题或者缺陷,都可以叫做“Bug”,有时也被泛指因软件产品内部的缺陷引起的软件产品最终运行时和预期属性的偏离。
缺陷(Defect):既指静态存在于软件工作产品中的错误,也指软件运行时由于这些错误被激发引起的和软件产品预期属性的偏离现象。
错误(Error):指编写错误的代码,一种是语法错误,另一种是逻辑错误
故障(Fault):软件运行中出现的状态,可引起意外情况,若不加处理,可产生失效,是一个动态行为
失效(Failure):软件运行时产生的外部异常行为结果,表现与用户需求不一致,功能能力终止,用户无法完成所需要的应用
缺陷报告单:测试执行过程中,发现软件失效后,提出书面的报告,提供给开发人员或者其他负责人员作为定位缺陷的依据,也作为日后缺陷度量的数据依据
三、了解
Defect(缺陷):通常指被测试软件的功能与需求规格说明书中的描述不一致,负责人一般为开发人员;
Enhancement(改进):通常指用户需求与需求规格说明书中的描述不一致,负责人员一般为需求人员;
四、缺陷管理的目的
。保证信息的一致性
。保证缺陷得到有效的跟踪,解决
。获取正确的Bug信息,用作缺陷分析和产品质量
五、Bug跟踪流程图
六、缺陷的相关属性
- 缺陷发现人
- 缺陷发现时间
- 缺陷状态
- 缺陷严重程度
- 缺陷所属版本
- 缺陷修改日期
七、缺陷的严重程度
严重性:顾名思义就是软件缺陷对软件质量的破坏程度,即此软件缺陷的存在将对软件的功能和性能产生怎样的影响。
。致命:比如软件的意外退出甚至操作系统崩溃,造成数据丢失
。严重:比如由于单功能失效导致多个相关功能均失败
。一般:比如软件界面的细微缺陷
八、缺陷跟踪单的写作准则
。Correct(准确)
每个组成部分的描述准确,不会引起误解
。Clear(清晰)
每个组成部分的描述清晰,易于理解
。Concise(简洁)
只包含必不可少的信息,不包括任何多余的内容
。Complete(完整)
包含复现该缺陷的完整步骤和其他本质信息
。Consistent(一致)
按照一致的格式书写全部缺陷报告
九、缺陷报告的写作要点
再现:一般是尽量三次再现故障,如果问题是间断的,那要报告问题发生频率。
初步定位:可能影响再现的变量,例如配置变化、工作流、数据库,这些都可能改变错误的特征。
推广:确定系统其他部分是否可能出现这种错误,以及使用不同的数据时是否存在着这种问题等等,特别是那些可能存在更加严重特征的部分。
压缩:精简任何不必要的信息,特别是冗余的测试步骤。
去除歧义:使用清晰的语言,尤其是避免使用那些有多个不同或相反含义的词汇。
中立:公正的表达自己的意思,对错误及其特征的事实进行陈述,避免夸张、幽默或讽刺。
评审:至少有一个同行,最好是一个有经验的测试工程师或测试经理,在递交错误报告之前自己先阅读一遍。