软件缺陷
软件缺陷:又称之为“Bug”。即计算机软件或程序中存在的某种破坏正常运行能力的问题、错误,或者隐藏的功能缺陷。
表现形式A
软件没有实现产品规格说明书所要求的功能模块。
表现形式B
软件中出现了产品规格说明指明不应该出现的错误。
表现形式C
软件实现了产品规格说明中没有提到的功能需求。
表现形式D
软件没有实现虽然产品规格说明没有明确提及但应该实现的目标。
表现形式E
软件难以理解、不易使用、运行缓慢、用户体验不友好。
缺陷的定义
1、软件在使用过程中存在的任何问题都叫软件的缺陷。
2、缺陷不等同于bug。
3、缺陷的存在会导致软件产品在某种程度上不能满足用户的需求
4、只要你的软件让用户觉得不爽
缺陷的判定标准
软件未实现需求(规格)说明书中明确要求的功能 –少功能
软件出现了需求(规格)说明书中指明不应该出现的错误 -功能错误
软件实现的功能超出需求(规格)说明书指明的范围 -多功能
软件未实现需求(规格)说明书中虽未明确指明但应该实现的要求 –隐性功能错误
软件难以理解,不易使用,运行缓慢,用户体验不好 -不易使用
缺陷产生的原因
需求阶段: 需求描述不易理解,有歧义、错误等
设计阶段: 设计文档存在错误或者缺陷
编码阶段 :代码出现错误
运行阶段 :软硬件系统本身故障导致软件缺陷
软件缺陷的类型
1、功能错误:软件没有达到需求文档的功能要求,或者功能异常
2、 界面错误:软件功能正常,但是界面不好看或者未达到规格说明中的要求
3、兼容性错误:软件和系统中的其他的程序冲突,导致软件无法运行
4、易用性错误:软件用起来不好用
5、 改进建议:改了更好,不改也没事
缺陷属性(在禅道中学习)
1.缺陷标识(ID): 缺陷标识是标记某个缺陷的一组符号。每个缺陷必须有一个唯一的标识。
2.缺陷类型 : 缺陷类型是根据缺陷的自然属性划分的缺陷种类。功能 接口 需求 易用性..
3.缺陷严重程度 :缺陷严重程度是指因缺陷引起的故障对软件产品的影响程度。致命/严重/一般/建议
4.缺陷优先级: 缺陷的优先级指缺陷必须被修复的紧急程度。紧急/一般/不紧急
5.指派人:指这个bug交给谁来修复
6.缺陷状态 :缺陷状态指缺陷通过一个跟踪修复过程的进展情况。
新建(打开):测试人员或其他人员发现并确认提交的bug,如新提交的bug。
被否决:经过确认,提交的bug确认为不是bug.
待修复:开发确认bug的有效性,进行处理
处理中:开发确认bug的有效性,进行处理
已修复:已被开发人员找到原因并修复的缺陷。
关闭 (最终态):测试人员在修复的版本中验证该问题确实已修复。
重新打开:测试人员在修复的版本中验证,确认仍存在该缺陷。
待跟踪:bug无法重现,开发不能定位到问题的原因
缺陷报告的重要组成
(1) 编号
提交缺陷的顺序
(2) 标题
简明扼要的描述缺陷
(3) 发现者
谁发现的缺陷,比如工号、用户名、姓名等
(4) 发现日期
提交缺陷的系统日期,一般是当天
(5) 所属模块
哪个功能模块发现的缺陷(方便开发经理根据模块定位该缺陷的负责人)
(6) 所属版本
在软件哪个版本发现的缺陷,如XX系统vYYYY-MM-DD;或XX系统version X.X.X
(7) 指派给谁
测试人员将缺陷指派给开发经理,开发经理会根据该缺陷所在模块再次指派给具体开发人员
(8) 缺陷状态
创建之后默认为激活状态(打开)
(9) 严重程度
准确评估bug的严重程度,评判标准参考公司的定义规范。
(10) 优先级别
准确评估bug的优先级程度。具体参照公司丢与优先级的定义。一般阻塞测试流程的问题为紧急,其它是情况而定
(11) 缺陷描述
把发现缺陷的过程、步骤、使用的数据等记录下来,使开发人员通过该描述再现该Bug
需注意问题:
① 单独记录每一个缺陷,不要把两个或者多个缺陷记录在一起
② 缺陷描述要清晰准确易读,使用必要、量少的步骤保证缺陷复现
③ 对缺陷的严重程度和优先级别的划分要准确、客观
④ 提交缺陷报告前要认真审核,确保提交的缺陷为有效缺陷
⑤ 不要为了引起开发人员的重视而夸大缺陷
⑥ 小的缺陷也需要记录缺陷报告
⑦ 及时报告缺陷(给开发人员留一些充足的修复时间)
⑧ 对发现的缺陷不做任何评价(随意评价缺陷,很容易伤开发人员的心哦)
⑨ 随机缺陷也要报告(随机缺陷不易重现,按照固定步骤时有时无,所以需要表明它是随机缺陷,尽量详细描述其出现的步骤,以及出现的频率等)
最后感谢每一个认真阅读我文章的人,礼尚往来总是要有的,虽然不是什么很值钱的东西,如果你用得到的话可以直接拿走:
这些资料,对于【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴上万个测试工程师们走过最艰难的路程,希望也能帮助到你!