缺陷概述
- 软件或程序中存在的各种问题及错误。软件缺陷的存在会导致软件产品在某种程度上不能满足用户的需求。产品实现不满足用户需求。测试执行时，实际结果和预期结果不一致就是缺陷。
软件缺陷的判定标准
- 软件未达到需求规格说明书中标明的功能
- 软件出现了需求规格说明书指明不会出现错误的地方
- 软件的功能超出了需求规格说明书指明的范围
- 软件未达到需求规格说明书虽未指明但应该达到的目标
- 软件测试人员认为软件难以理解，不易使用，运行速度慢，或者最终用户体验不好
软件缺陷产生是不可避免的，造成软件缺陷产生的原因主要归纳如下：
- 需求解释、记录或者定义错误
- 设计文档说明存在错误或者拼写错误
- 编码说明、程序代码有误
- 硬件或者软件系统上存在错误
编写缺陷报告基本要素
- ID编号：唯一
- 模块：根据产品进行具体的划分，如登录、注册
- 缺陷状态：表明缺陷处理进度，常见的状态有
- new：新建，表示缺陷刚创建
- open：打开，表示已经指派或者开发认领了bug
- inprogress：进行中，表示开发正在修改中
- fixed：已修复，表示测试可以验证了
- closed：已关闭，表示测试验证通过
- rejected：已拒绝，表示开发拒绝了当前bug
- postpone/delay：已延迟，表示开发延迟修复该bug
- 缺陷所属模块：缺陷属于哪个被测的模块
- 严重程度：从技术维度来衡量，bug的破坏力
优先级：从业务的角度，决定bug修改的先后顺序
缺陷类别：用于分类整理缺陷常见的有丶功能错误丶UI界面错误丶兼容性丶易用性丶改进建议
缺陷报告可以有很多信息组成，如下图所示：
编写缺陷报告核心内容
- 标题：描述缺陷的基本信息，如（输入密码长度为5时，注册成功。）应保持简短、准确，提供缺陷的本质信息。尽量按缺陷发生的原因与结果的方式书写； 避免使用模糊不清的词语，例如：“功能中断，功能不正确，行为不起作用”等。应该使用具体文字说明缺陷的症状；
- 前置条件：描述缺陷出现依赖的相关基础条件，如（未注册手机号）:
- 复现步骤：测试用例里面的执行步骤。应包含如何使别人能够很容易的复现该缺陷的完整步骤。
- 简单地一步步引导复现该缺陷，一个步骤包含的操作不要多；
- 每个步骤前使用数字对步骤编号；
- 尽量使用短语或短句，避免复杂句型句式；
- 根据实际需要，提供测试的环境信息；
- 避免包含多余的步骤，避免丢失必要的步骤。
- 实际结果：执行被测试软件过程中，系统给出的结果。实际结果的描述应向标题信息那样，要列出具体的缺陷症状，而不是简单地指出“不正确”或“不起作用”。
- 预期结果：参照需求说明书，在测试用例中设计的预期结果。描述应与实际结果的描述方式相同。通常需要列出期望的结果是什么。
- 附件：方便开发定位bug的关键信息，包含缺陷症状的截图、日志log丶测试使用的数据文件;
缺陷处理流程
缺陷跟踪
- 新提交的缺陷为新建状态，确认有效后为打开状态，经开发人员修改后，缺陷变为已修复（待验证）状态。
- 此时就需要测试人员对缺陷进行回归测试，验证问题是否修复。
- 如果问题已经修复，则测试人员将该缺陷的状态置为关闭状态（验证通过），同时添加回测说明如“该缺陷已 解决”。
- 如果已经关闭的问题再次出现，则测试人员将该缺陷的状态修改为重新打开；
缺陷跟踪流程
场景1：确认BUG解决
-
测试【new】==》开发【open】==》开发【fix】==》测试【close】
场景2：验证未通过，缺陷仍存在
-
测试【new】==》开发【open】==》开发【fix】==》测试【reopen】
场景3：开发延期处理
-
测试【new】==》开发【open】==》开发【postpone】
场景4：拒绝处理
-
测试【new】==》开发【open】==》开发【reject】