缺陷的属性
- 缺陷的类型:功能(Function)、界面(UI)、文档(documentatio)、软件包(package)、性能(performance)、接口(interface)
注意:需求分析、设计阶段,文档类型的缺陷多,集成测试阶段,一般接口类型的缺陷多一些;系统测试阶段,功能、界面类型的缺陷多一些;验收测试阶段,更多的关注性能缺陷;实施过程,可能会遇到一些软件包的缺陷。
- 缺陷的严重程度。缺陷的故障对软件的影响。一般有分类,每个公司和团队的分类标准会略有不同。
注意:结合缺陷的影响,结合软件的具体功能(业务或者流程)
- 缺陷的修复优先级。很大程度上取决于缺陷对测试工作的影响程度。例如:电商系统的用户注册功能无法使用(无法登录、购买、结算、支付、等功能都无法进行),就必须立即修复;电商系统中关于用户购买流程帮助功能说明的网页链接点击404页面。
注意:优先级的衡量,一般可以根据测试的软件系统的全业务流程划分,软件的基本功能缺陷,优先级高,甚至需要立即解决。软件的备选流、基本功能测试中的反向测试内容,优先级较低,甚至有先可改可不改。
面试提问:缺陷的严重程度和优先级有什么关系?
- 没有任何直接的关系
- 不要认为严重的缺陷,修复优先级就高
- 如果碰到优先级和严重程度都高的缺陷,也只是偶然。
例如,qq的帮助按钮,经常有闪退的现象,严重程度很高,但优先级就很低。企业logo不影响任何功能,但是必须优先修复。
-
缺陷的状态。表示缺陷的处理进度。
发现缺陷是缺陷处理的前提。但还没有进入缺陷的处理流程。
1、激活/打开(新建)。由测试人员进行标注
2、确认。确认新提交的缺陷是一个真实有效的缺陷,一般由测试主管或者质量保证(QA),或产品经理进行确认,经确认后,有效的缺陷指派给相关人员进行处理。
3、已修复/修正。在缺陷被修复后,一般由开发人员进行。
4、关闭/非激活。缺陷被修复完成后,经过测试人员验证后,没有问题。
5、重新打开。经过测试人员的验证后,缺陷没有修复成功,需要重新打开进行再次处理和修复。
6、推迟。缺陷现在不修复,推迟到下一个版本或者阶段。测试要与开发人员或者相关管理人员进行确认。
7、保留。缺陷暂时修复不了,一般也是由开发人员去设定。
8、不能重现。开发按照缺陷的复现步骤不能再次发现缺陷。一般有闪退或者崩溃现象,或者浏览器的差异。所以作为测试人员,提交bug之前要再三确认bug。
9、需要更多信息。作为测试人员,提交bug时,要尽可能把所有相关文件一起提交。(图片、视频)
10、重复。测试中一定要避免这种情况出现。
11、不是缺陷。
缺陷的起源、来源、根源。一般关注较多的是缺陷的来源(直接原因);在测试总结的时候,关注缺陷的根源。
二、缺陷的生命周期
面试提问:针对你工作中发现的一个bug,说说这个bug的处理过程。(缺陷的生命周期中,每一个环节)
三、缺陷的识别
依据:需求文档、设计文档、产品原型、测试用例、都是客观的依据。同行业的类似成熟软件,和开发人员沟通,跟有经验的测试人员沟通。
四、缺陷报告
1.缺陷编号。Bug-项目名称-模块名称-功能名称-0001
2、所属模块。一级模块/二级模块/三级模块
3、优先级。缺陷的修复紧急程度。p1>p2>p3>p4
4、严重程度。s1>s2>s3>s4
5、缺陷概述。用一句话描述缺陷的基本情况
6、缺陷的描述。将缺陷的复现步骤,预期结果和实际结果列出来。
7、提交人
8、备注。一般写产生该缺陷的特殊情况,将bug的截图作为备注信息。