缺陷管理

• 基本概念和相关术语
  • 缺陷：存在于软件之中的偏差，可被激活，以静态形式存在于软件内部，相当于 Bug
  • 故障：软件运行中出现的状态，可引起意外情况，若不加处理，可产生失效，是一个动态行为
  • 失效：软件运行时产生的外部异常行为结果，表现与用户需求不一致，功能能力终止，用户无法完成所需要的应用
  • 缺陷不一定转化为故障，即使转化为故障，故障也不一定转化为失效
  • 缺陷报告单：测试执行过程中，发现缺陷失效后（当然不一定是失效，也许是故障，一般来说这个缺陷在测试阶段被发现往往表现为产品的失效），提出书面的报告，提供给开发人员作为定位缺陷的依据，也作为日后缺陷度量的数据依据。
• 软件缺陷管理基本流程
  • 测试人员拿到新的版本
  • 测试人员记录 bug
  • 开发人员拿到新的 bug
  • 开发人员解决 bug
  • 开发人员检入代码
  • 每日构建技术人员（builder）拿到最新源代码
  • 编译
  • 发布到服务器
  • 测试人员获取新的版本并验证缺陷是否修复
• 缺陷管理的目的
  • 保证缺陷得到有效的跟踪和解决
  • 获取正确的 bug 信息，用作缺陷分析和产品度量
• 软件缺陷管理工具
  • 商用工具
    • Mercury Quality Center
    • Rational ClearQuest
  • 开源工具
    • Bugzilla
    • Mantis
    • Jira
• 软件缺陷的相关属性
  • 缺陷发现人
  • 缺陷发现时间
  • 缺陷所属版本
  • 缺陷修改日期
  • 软件缺陷的状态
    • New：缺陷的初始状态
    • Open：开发人员开始修改缺陷
    • Fixed：开发人员修改缺陷完毕
    • Closed：回归测试通过
    • Reopen：回归测试失败
    • Postpone：推迟修改
    • Rejected：开发人员认为不是程序问题，拒绝缺陷
    • Duplicate：与已提交的缺陷重复
    • Abandon：被 Reject 和 Duplicate 的缺陷，测试人员确认后的确不是问题，置为此状态。
  • 缺陷的严重程度
    • 致命
    • 一般
    • 提示
• 填写高质量的缺陷报告
  • 简单描述
    • 用一句话简单的、提纲挈领的描述清楚问题
  • 详细描述
    • 描述问题的基本环境，包括操作系统、硬件环境、网络环境、被测软件测运行环境
    • 用简明扼要的语言描述清楚软件出现异常时测试人员的操作步骤和使用数据
    • 如果从 GUI 界面可以反应软件的异常，采用拷屏的方法截取界面，粘贴到缺陷单中
    • 被测试软件运行时候的相关日志文件
    • 测试人员根据上述信息可以给出对问题的简单分析
    • 被测试软件的版本
    • 状态、严重级别、优先级别
    • 提交日期、提交人
  • 相关附件
    • GUI 的拷屏图片
    • 被测试软件运行时的相关日志文件
  • 缺陷报告的写作要点
    • 再现：一般是尽量三次再现故障，如果问题是间断的，那要报告问题发生频率
    • 初步定位：可能影响再现的变量，例如配置变化、工作流、数据库、这些都可能改变错误的特征
    • 推广：确认系统其他部分是否可能出现这种错误，以及使用不同的数据时是否存在着这种问题等，特别是那些可能存在更加严重特征的部分
    • 压缩：精简不必要的信息，特别是冗余的测试步骤
    • 去除歧义：使用清晰的语言，尤其是避免使用那些有多个不同或相反含义的词汇
    • 中立：公正的表达自己的意思，对错误及其特征的事实进行陈述，避免夸张、幽默或讽刺
    • 评审：至少有一个同行，最好是一个有经验的测试工程师或测试经理，在递交错误报告前先阅读一遍
    • 缺陷报告描述完之后，最后可以加上“请XXX（开发人员的名字）及时处理，谢谢”。这样对方感觉比较好。

欢迎扫码关注微信公众号「一朵儿的软件测试之旅」一起学习交流