笔记~【软件测试基础】——缺陷管理

缺陷管理

缺陷定义

  软件或程序中存在的各种问题。

缺陷判定标准

1. 软件没有达到需求说明书标明的功能。
2. 软件出现了需求说明书中指明不会出现错误的地方。
3. 软件超出了需求说明书指明的范围。
4. 软件出现了需求说明虽未指明，但应该达到的目标。
5. 软件难以使用，效率低下。

缺陷分类

  缺陷：存在于软件之中的偏差，可被激活，以静态形式存在于软件内部，相当于BUG。
  错误：没有定义的或者未知的错误信息
  故障：软件运行中出现的状态，可引起意外情况，若不加处理，可产生失效；重新启动调整后，可以恢复用户使用。
  失效：软件运行时产生的外部异常行为结果，表现与用户需求不一致，功能能力终止，用户无法完成所需要的应用。

缺陷报告单

  测试过程中，发现缺陷失败后，提出书面报告，提供给开发人员作为定位缺陷的依据。
  缺陷报告还可以作为缺陷度量的数据依据，度量是对整个产品进行考核。

缺陷管理的目的

缺陷管理的目的是：对各个阶段测试发现的缺陷进行管理，以保证各级缺陷的修复达到标准，主要达到以下目标：
1）保证信息的一致性；
2）保证缺陷得到有效的跟踪，缩短沟通时间，解决问题更高效；
3）收集缺陷数据并进行数据分析，作为缺陷度量的依据

缺陷状态（常用）9个

1）New：缺陷的初始状态
2）Open：开发人员开始修复缺陷
3）Fixed：开发人员修改缺陷完毕
4）Closed：回归测试通过
5）Reopen：回归测试失败
6）Postpone：推迟修改
7）Rejected：开发人员认为不是程序问题，不用修改
8）Duplicate：与已提交Defect重复
9）Abandon：被Reject和Duplicate的Defect，测试人员确认后的确不是问题，将Defect置为此状态。

缺陷书写规范

  标题：应该保持简短、准确，提供缺陷的本质信息；
  复现步骤：应包含如何使别人能够复现缺陷的完整步骤；
  实现结果：执行复现步骤后软件的现象和产生的行为，实际结果的描述，应向标题信息那样，要列出具体的缺陷症状；
  期望结果：描述应与实际的结果的描述方式相同，需要列出期望的结果是什么；
  附件：对缺陷描述的补充说明，可以以下类型：
  - 缺陷症状的截图；
  - 测试使用的数据文件；

软件测试的生命周期

需求分析——测试计划——测试用例设计与开发——测试执行——测试评估

• 需求分析：测试人员对需求文档进行分解，了解需求，得出测试点与测试要求；
• 测试计划：经过需求评审，明确测试需求后，根据需求编写测试计划，包括软件的主要功能、测试范围、测试环境、人员分配、时间进度安排等；
• 测试用例设计与开发：测试人员通过需求分析，了解软件相关功能的测试点，使用在测试计划中确定的测试技术与测试方法，对于已确定的测试条件进行逐步推敲，精炼设计出来的，重点用于说明如何操作，产生何种结果的测试用例。
• 测试执行：是测试人员最为关键的工作阶段，结合测试方法，运用手工或自动化的手段执行测试，暴露出软件各方面的缺陷，最终，使得软件质量过关，满足客户需求；
• 测试评估：测试团队根据软件测试的结果进行评估，包括是否合格，是否满足上述条件，严重的bug是否已经关闭，保证顺利上线，并做出预测报告总结。

Bug的生命周期

  一个bug被发现到这个bug被关闭的过程。
  bug周期：发现bug——提交bug——指派bug——研发确认bug——研发修复bug——回归验证bug——是否通过验证——关闭bug
  生命周期中缺陷的状态：新建——指派——已解决——待验证——关闭
  bug六要素：
   1）编号：唯一
   2）bug名称：言简意赅
   3）优先级：和时间有关（高中低）
   4）严重级别：
   致命的：导致软件崩溃，和钱有关，阻碍了核心业务
   严重的：重要功能出现异常
   一般的：非核心功能出现异常
  轻微的：建议性的问题，UI上的问题
   5）复现步骤：将在测试中出现的BUG的步骤写出来，确保所有的步骤都被记录，记录下所做的每一件事，每一个步骤，每一个停顿。无意间丢失一个步骤或增加一个多余的步骤，可能导致无法再现缺陷。
   6）附件：对BUG的存在的一个佐证（截图、视频、日志）

“继续记录学习生活，坚持更新~”