day03_缺陷及管理流程

缺陷概述

• 软件或程序中存在的各种问题及错误。软件缺陷的存在会导致软件产品在某种程度上不能满足用户的需求。产品实现不满足用户需求。测试执行时，实际结果和预期结果不一致就是缺陷。

软件缺陷的判定标准

• 软件未达到需求规格说明书中标明的功能
• 软件出现了需求规格说明书指明不会出现错误的地方
• 软件的功能超出了需求规格说明书指明的范围
• 软件未达到需求规格说明书虽未指明但应该达到的目标
• 软件测试人员认为软件难以理解，不易使用，运行速度慢，或者最终用户体验不好

软件缺陷产生是不可避免的，造成软件缺陷产生的原因主要归纳如下：

• 需求解释、记录或者定义错误
• 设计文档说明存在错误或者拼写错误
• 编码说明、程序代码有误
• 硬件或者软件系统上存在错误

编写缺陷报告基本要素

• ID编号：唯一
• 模块：根据产品进行具体的划分，如登录、注册
• 缺陷状态：表明缺陷处理进度，常见的状态有
  • new：新建，表示缺陷刚创建
  • open：打开，表示已经指派或者开发认领了bug
  • inprogress：进行中，表示开发正在修改中
  • fixed：已修复，表示测试可以验证了
  • closed：已关闭，表示测试验证通过
  • rejected：已拒绝，表示开发拒绝了当前bug
  • postpone/delay：已延迟，表示开发延迟修复该bug 
• 缺陷所属模块：缺陷属于哪个被测的模块
• 严重程度：从技术维度来衡量，bug的破坏力

• 优先级：从业务的角度，决定bug修改的先后顺序​

​

• 缺陷类别：用于分类整理缺陷常见的有丶功能错误丶UI界面错误丶兼容性丶易用性丶改进建议

​缺陷报告可以有很多信息组成，如下图所示：

​

​

编写缺陷报告核心内容

• 标题：描述缺陷的基本信息，如（输入密码长度为5时，注册成功。）应保持简短、准确，提供缺陷的本质信息。尽量按缺陷发生的原因与结果的方式书写； 避免使用模糊不清的词语，例如：“功能中断，功能不正确，行为不起作用”等。应该使用具体文字说明缺陷的症状；
• 前置条件：描述缺陷出现依赖的相关基础条件，如（未注册手机号）:
• 复现步骤：测试用例里面的执行步骤。应包含如何使别人能够很容易的复现该缺陷的完整步骤。
  • 简单地一步步引导复现该缺陷，一个步骤包含的操作不要多；
  • 每个步骤前使用数字对步骤编号；
  • 尽量使用短语或短句，避免复杂句型句式；
  • 根据实际需要，提供测试的环境信息；
  • 避免包含多余的步骤，避免丢失必要的步骤。

• 实际结果：执行被测试软件过程中，系统给出的结果。实际结果的描述应向标题信息那样，要列出具体的缺陷症状，而不是简单地指出“不正确”或“不起作用”。
• 预期结果：参照需求说明书，在测试用例中设计的预期结果。描述应与实际结果的描述方式相同。通常需要列出期望的结果是什么。
• 附件：方便开发定位bug的关键信息，包含缺陷症状的截图、日志log丶测试使用的数据文件;

缺陷报告示例

​

缺陷处理流程 

​

缺陷跟踪

1. 新提交的缺陷为新建状态，确认有效后为打开状态，经开发人员修改后，缺陷变为已修复（待验证）状态。
2. 此时就需要测试人员对缺陷进行回归测试，验证问题是否修复。
3. 如果问题已经修复，则测试人员将该缺陷的状态置为关闭状态（验证通过），同时添加回测说明如“该缺陷已 解决”。
4. 如果已经关闭的问题再次出现，则测试人员将该缺陷的状态修改为重新打开；

缺陷跟踪流程

场景1：确认BUG解决

• 测试【new】==》开发【open】==》开发【fix】==》测试【close】

场景2：验证未通过，缺陷仍存在

• 测试【new】==》开发【open】==》开发【fix】==》测试【reopen】

场景3：开发延期处理

• 测试【new】==》开发【open】==》开发【postpone】

场景4：拒绝处理

• 测试【new】==》开发【open】==》开发【reject】