第1个回答 2022-06-26
缺陷的定义
软件未实现产品说明书要求的功能
软件出现了产品说明书指明不应该出现的功能
软件实现了产品说明书未提到的功能
软件未实现产品说明书虽未明确提及但应该实现的目标
软件难以理解、不易使用、运行缓慢或者（从测试的角度看）最终用户会认为不好
缺陷的属性(重要)
属 性 名 称 描 述
缺陷类型（type） 缺陷类型是根据缺陷的自然属性划分的缺陷种类
缺陷严重程度（Severity） 缺陷严重程度是指因缺陷引起的故障对软件产品的影响程度
缺陷优先级（Priority） 缺陷的优先级指缺陷必须被修复的紧急程度
缺陷状态（Status） 缺陷状态指缺陷通过一个跟踪修复过程的进展情况
缺陷起源（Origin） 缺陷起源指缺陷引起的故障或事件第一次被检测到的阶段
缺陷来源（Source） 缺陷来源指缺陷的起因
缺陷根源（Root Cause） 缺陷根源指发生错误的根本因素
缺陷的严重程度:
如闪退和页面有错别字,那么闪退更严重
缺陷优先级:
比如:帮助文档中有错别字和启动页有错别字,那么启动页有错别字优先级更高
正向需求的优先级比反向需求的优先级高
缺陷状态:提交的缺陷需要认可,认可的缺陷才会进行修复
缺陷起源,来源,根源一般情况和我们测试没什么关系
1.缺陷类型:功能,用户界面,文档,软件包,性能,系统/模块接口
注意:需求分析,设计阶段,文档类型的缺陷多;集成测试阶段,一般接口类型的缺陷多一些;
系统测试阶段,一般界面,功能类型的缺陷多点;验收测试阶段更多的关注性能;实施过程可能会遇到一些软件包的缺陷
2.缺陷严重程度:致命（Fatal）,严重（Critical）,一般（Major）,较小（Minor）
注意:每个公司都有不同的命名方法,但大体差不多
3.缺陷优先级:立即解决（P1级）(4个小时内修改),高优先级（P2级）(24小时),正常排队（P3级）(新版本发布前),低优先级（P4级）(改也行,不改也行)
解释:怎么来衡量一个缺陷的优先级,一般是软件的基本功能缺陷,是优先级高的
4.缺陷状态:(表示缺陷的处理进度)
发现缺陷是缺陷处理的前提,但是还没有进入缺陷处理流程
激活或打开(新建):测试人员操作
确认:测试主管或产品经理去确认,然后指派给某人去处理
已修正或修复:开发人员去操作
关闭或非激活:测试人员验证后,再填写
重新打开:测试人员验证不通过,再填写
推迟:缺陷现阶段不去修复,测试人员和测试管理人员及开发等相关人员确定后,填写
保留:缺陷修复不了,开发人员填写,但要和测试人员确认同意
不能重现:开发人员填写,开发人员通过缺陷报告中的步骤操作,发现不能重现,他就填写"不能重现",这种现象是测试人员的职业污点
需要更多信息:开发人员填写,开发人员重现这个缺陷,缺少资料.
重复:别的测试人员也发现了这个bug
不是缺陷:开发人员填写,测试人员人生污点
需要修改软件规格说明书:缺陷不是技术人员的问题,是需求有问题
5.缺陷的三源(起源,来源,根源)
在测试总结中会关注来源(直接造成bug的)
缺陷生命周期(重点)
发现缺陷->提交缺陷->确认缺陷->分配缺陷->修复缺陷->验证缺陷->关闭缺陷
如果验证缺陷不通过,回到提交缺陷流程
发现缺陷:测试人员发现的
提交缺陷:测试人员
确认缺陷:测试主管或产品经理
分配缺陷:一般是谁确认缺陷谁分配给相关人员,开发,产品经理,ui
修复缺陷:主要是开发人员,还有产品经理,ui
验证缺陷:测试人员
关闭缺陷:测试人员
缺陷的识别
通过测试用例中的预期结果进行识别
通过需求规格说明书进行识别
通过用户手册及其他文档进行识别
通过同行业相类似成熟的商业软件来识别
通过和开发人员的沟通进行识别
通过和有经验的测试人员沟通进行识别
参照同行业隐式需求进行识别
识别缺陷的依据:
需求文档,设计文档,产品原型,测试用例
其他识别方法:
同行的成熟软件,和开发沟通,有经验的测试人员,同行业的隐性需求
缺陷报告编写(重点)
1.缺陷报告本身要保证没有任何表述性的错误
一:缺陷报告的内容:
1.缺陷编号:Bug_项目名称_模块名称_功能名称_001
2.所属模块:一级模块,二级模块,三级模块
3.优先级:p1-p4(p1最优先)
4.严重程度:s1-s4(s1最严重)
5.缺陷概述:一句来描述缺陷的基本情况
6.缺陷的描述:复现步骤,预期结果,实际结果
7.提交人:
8.备注:一般写缺陷产生的特殊情况或贴缺陷的图片
二:缺陷报告的编写目的:
1.展现缺陷的详细信息
2.展现缺陷的影响程度和方式
注意:很多高层人员会去阅读缺陷报告,大部分相关人员也会去阅读
三.报告编写准则:准确,清晰,一致,简洁,完整
四.缺陷描述的准则:
1.可以重现
2.不要做评价