一、缺陷的基本概述
- 缺陷的定义
- 缺陷的属性
- 缺陷类型:缺陷的类型包括功能(Function)、界面(UI)、文档(Documentation)、软件包(Package)、性能(Performance)、接口(Interface)
[注意]
需求分析、设计阶段,文档类型的缺陷多;
集成测试阶段,一般接口类型的缺陷多一些;
系统测试阶段,功能、界面类型的缺陷多一些;
验收测试阶段,更多的关注性能缺陷;
实施过程,可能会遇到一些软件包的缺陷- 缺陷严重程度:缺陷严重程度是指缺陷对软件的影响程度,一般包括致命(Fatal)、严重(Critial)、一般(Major)、较小(Minor),不同公司有具体的分类
- 缺陷被修复的优先级:优先级取决于缺陷对测试工作的影响程度,例如:电商系统中的用户注册功能无法使用(无法注册,购买,收藏,加入购物车等)就需要立即修复
【面试提问】缺陷的严重程度和优先级有什么关系?
1)没有直接的关系
2)缺陷严重程度是指缺陷对软件的影响程度,缺陷被修复的优先级取决于缺陷对测试工作的影响程度- 缺陷的状态:表示缺陷的处理进度
- 激活/打开(新建):由测试人员进行标注。确认。确认新提交的缺陷是一个真实有效的缺陷。一般由测试主管、或者质量保证(QA)、由产品经理进行确认。经确认后,有效的缺陷会指派给相关人员进行处理。。
- 已修复/修正。在缺陷被修复后,一般由开发人员进行。
- 关闭/非激活。缺陷被修复完成后,经过测试人员的验证后,没有问题。
- 重新打开。经过测试人员的验证后,缺陷没有修复成功,需要重新打开进行再次处理和修复。v
- 推迟。缺陷现在不修复,推迟到下一个版本或者阶段。测试要跟开发或者其他相关的管理人员进行确认。。
- 保留。缺陷暂时修复不了。一般也是由开发人员去设定。也需要测试人员进行确认。
- 不能重现。开发按照却显得复现步骤不能再次发现缺陷。一般闪退、崩溃类型的缺陷具有类似的特征。或者由于操作系统的差异、浏览器的缓存等信息,出现的问题。所以作为测试人员,提交 bug 之前,要再三的确认 bug。需要更多信息。作为测试人员,提交 bug的时候,要尽可能的把所有相关的文件一起提交。(图片、视频)。
- 重复。测试中,一定要避免这种情况的出现。尤其在软件的某一个功能频繁被多个模块(由不同的测试人员测试)调用的情况下。
- 不是缺陷。一定不要在测试工程师的工作生涯中被开发标注缺陷状态为不是 bug。
- 需要修改需求说明书。缺陷不是技术原因造成的,而是由于需求不明确或者设计不明确造成。
- 缺陷的起源、来源、根源:一般关注较多的是缺陷的来源(直接原因);在测试总结的时候,关注缺陷的根源。
二、缺陷的生命周期
- 发现缺陷。由测试人员。开发也能知道自己哪里写错了,但是不会广而告之。
- 提交缺陷。由测试人员。开发更不可能提交 bug。
- 确认缺陷。一般由测试主管、或者质量保证(QA)、由产品经理进行确认。
- 分配缺陷。经确认后,有效的缺陷会指派给相关人员进行处理。一般由谁确认的缺陷,就由谁分配。分配的对象可能是开发、也可能是、也可能是产品经理。
- 修复缺陷。主要由开发修复,也有可能是产品经理修复问题,也有可能是UI修复问题。
- 验证缺陷。测试去验证缺陷有没有修复成功。
- 关闭缺陷。只能是测试人员进行。否则出了问题,测试认识一律不背锅。
【面试问题】针对你工作中发现的一个 bug,说说这个bug 的处理过程?
答:缺陷的生命周期中,每一个环节由谁做什么
三、缺陷的识别
- 通过测试用例中的预期结果进行识别
- 通过需求规格说明书进行识别
- 通过用户手册及其他文档进行识别
- 通过同行业相类似成熟的商业软件来识别
- 通过和开发人员的沟通进行识别
- 通过和有经验的测试人员沟通进行识别
- 参照同行业隐式需求进行识别
四、缺陷报告
- 缺陷编号:Bug_项目名称_模块名称_功能名称_0001。
- 所属模块:一级模块/二级模块/三级模块
- 优先级:缺陷的修复紧急程度。P1>P2>P3>P4,例如基本流可以用P1,P2,备选流可以用P3,P4
- 严重程度:缺陷对软件的影响程度,S1>S2>S3>S4
- 缺陷概述:用一句话描述缺陷的基本情况。
- 缺陷的描述:将缺陷的复现步骤、预期结果和实际结果列出来。
- 提交人:是谁就写谁的名字。
- 备注:一般写产生该缺陷的特殊情况。将 bug的截图作为备注信息。
五、缺陷跟踪系统
- 禅道:国产、项目、产品、测试齐全,对个人和组织开源免费
- QC(ALM):外国软件、英文,功能齐全
- JIRA:国外软件、JAVA环境、主流(商业)
- TAPD