缺陷报告

缺陷报告

前言

1. 不做文字的搬运工，多做灵感性记录
2. 这是平时学习总结的地方，用做知识库
3. 平时看到其他文章的相关知识，也会增加到这里
4. 随着学习深入，会进行知识拆分和汇总，所以文章会随时更新
5. 参考的文章过多，所以参考会写不全，见谅

1.软件缺陷

1.含义

• 软件缺陷（Defect）,又叫bug(臭虫)
• 软件存在不符合质量需求或违背软件用户、客户、企业意愿的问题

2.判定标准

• 软件未能达到产品说明书标明的功能
• 软件出现产品说明书指明不会出现的错误
• 软件出现产品说明书指明不会出现的错误
• 软件功能超出产品说明书指明范围
• 软件未达到产品说明书未指出但应达到的目标
  • 说明书也没必要什么都写，有些相当于公认的，是必须要有的（断电保存数据）
• 人软件测试人员认为软件难以理解、不易使用、运行速度缓慢、或者最终用户认为不好

3.分类

1.分类标准

分类标准	英文	含义
缺陷类型	Type	根据缺陷的自然属性划分的缺陷种类
缺陷严重程度	severity	是因缺陷引起的故障对软件产品影响程度
缺陷优先级	priority	缺陷必须修复的紧急程度
缺陷状态	status	缺陷通过一个跟踪修复过程的进展请情况

2.分局缺陷类型分类

• 功能缺陷
• 界面缺陷
• 文档缺陷
• 代码缺陷
• 算法错误
• 性能缺陷

3.根据缺陷等级

• A 类——致命缺陷

1. 由于程序所引起的死机、非法推出
2. 死循环
3. 数据库锁死
4. 因错误操作导致的程序中断
5. 功能错误
6. 与数据库链接错
7. 数据通讯错误

• B 类——严重缺陷
  1. 程序错误
  2. 程序接口错误
  3. 数据库的表、业务规则、缺省值未加完整性等约束条件
• C 类错误——一般错误
  1. 操作界面错误（包括数据窗口内列名、含义是否一致）
  2. 打印内容、格式错误
  3. 简单输入限制未放在前台进行控制
  4. 删除操作未给出提示
  5. 数据库表中有过多的空字段
• D 类——较小缺陷
  • 界面不规范
  • 辅助说明描述不清楚
  • 输入输出不规范
  • 长操作未给用户提示
  • 提示窗口文字未采用行业术语
  • 可输入区域和制度区域没有明显的区分标志
• E 类——意见或建议

4.缺陷处理优先级

缺陷优先级	描述
1	必须立即解决
2	需要正常排队等到修复
3	可以在方便的时候被纠正
4	下一个版本修复
5	不修复或列入软件发布清单

5.缺陷状态

缺陷状态	中文	描述
submitted	已提交	已经提交的缺陷（有些叫新建缺陷）
open	打开	确认’提交缺陷‘，等待处理
rejected	已拒绝	拒绝提交的缺陷，不需要修复或者不是缺陷
resolved	已解决	却选被修复
verified	已验证	确认缺陷缺失被修正
closed	已关闭	确认被修复的缺陷，将其关闭

3.表现形式

• 用户要求的功能、特性没有实现或者部分实现
• 运行出错，包括运行中断、系统崩溃、界面混乱等
• 数据结果不正确、精度不够、不完整或者格式不统一
• 文字显示内容不正确或拼写错误
• 系统性能低下、资源浪费

4.分离和再现

• 发现缺陷后，应该做好分离和再现，排查发现的“缺陷”是不是软件本身的问题，然后再提交
• 重现3次
  • 重现
  • 复现

5.应避免的缺陷

此类缺陷让测试人员遭受职责

1.缺陷的缺陷

• 含义

  • 测试人员提交的不是缺陷的缺陷

  • 是一种无效的缺陷

• 处理

  • 正确理解需求
  • 做好复现

2.重复缺陷

• 含义
  • 同一个缺陷 A测试工程师提交后，B 工程师又提交或者自己提交的缺陷与之前的缺陷相同或类似
  • 是一种无效缺陷
• 处理
  • 尽量避免两个人同时测同一模块
  • 自己提交的缺陷与自己的重复，提交前查找一下，增强开发知识

3.有争议的缺陷

• 有关人员进行沟通、讨论
• 搁置

4.无法再现的缺陷

• 首先，对于这样的缺陷进行详细的记录，使用不同的方法去重现
• 其次，要合理安排时间，要考虑测试项目的进度，对一时难以再现的缺陷可以暂时搁置，以保证项目正常进度，并尽快提交给开发人员
• 最后，在测试过程对未再现缺陷予以关注

2.缺陷报告

1.含义

是对缺陷进行记录、分类和跟踪的文档

2.读者对象

• 软件开发人员
  • 报告缺陷是为了缺陷得到修复
  • 希望获得缺陷的本质特质和复现步骤
• 质量管理人员
• 市场人员
• 计输支持人员
  • 希望得到缺陷的严重程度和分布情况，以及市场和用户的影响程度

3.写作准则（5C）

• Correct(准确)
  • 每个组成部分的描述准确，不会引起误解
• Clear(清晰)
  • 每个组成部分的描述清晰，易于理解
• Concise(简洁)
  • 只包含必不可少的信息，不包含任何多余的内容
• Complete(完整)
  • 包含复现该缺陷的完整步骤和其他本质信息
• Consistent(一致)
  • 按照一致的格式书写全部缺陷报告

4.组织结构

• 缺陷的标题 / 缺陷的摘要 / 缺陷概述 / 缺陷概述 / 缺陷基本信息
  • 其实就是标题
• 预处理
  • 相当于预置条件。可要可不要，看情况
• 复现步骤
  • 就是操作步骤，用例写的好了，可以直接粘贴过来
• 期望结果
  • 用例的预期结果
• 实际结果
• 缺陷的严重程度
• 缺陷的优先级
• 测试的软件和硬件环境
• 测试的软件版本
  • pc、安卓、iso、linux
  • 软件：安装了什么依赖软件
  • 硬件：cpu,内存、（牌子、大小）
• 缺陷的类型
• 注释文字和缺陷截图
  • 截图：一般在陈述不清楚时候使用，还有一些开发不认同的

5.写作要求

前言

• 尽量提前跟开发沟通一下，看他觉得这是不是bug，他确定是了，再提也不晚

1.缺陷标题

• 尽量按照缺陷发生的原因与结果的方式书写
  • 执行完A后，发生B
  • 在什么地方，做了那些事情，除了什么结果
    • 使用链接词语：
      • 在。。。以后
      • 在。。。时候
      • 在。。。期间
• 避免使用模糊不清的词语
• 方便搜索查询，尽量使用关键词
• 方便他人理解，要避免使用术语、俚语或过分具体的测试细节

2.重现步骤

• 提供测试的预备步骤和信息
• 步骤完整、准确、简短，内有缺漏任何操作步骤，没有任何多余的步骤
• 将常见步骤合并未较少步骤
• 简单地一步一步地引导复现该缺陷
• 每一个步骤尽量只记录一个操作
• 每一个步骤前面使用数字对步骤编号
• 尽量使用短语和短句，避免复杂句型和句式
• 只记录各个操作步骤是什么，不要包括每个步骤的执行结果

3.预期结果

• 软件应该具有的结果，或者说正确的结果是什么样子

4.实际结果

• 试剂结果的描述要列出具体的表现行为，而不是简单指出“不正确”或“不起作用”

• 如果一个动作产生彼此不同的多个缺陷结果，或者一个动作将会产生一个结果，而这个结果又产生另一个结果。为了易于阅读，这些结果应该用数字列表分割开来

比如：实际结果：

1.显示“命令代码行。。。错误”

2.显示“并且终止。。。服务”

5.注释/截图

1. 包含的内容

   • 截取缺陷特征图像文件
   • 测试过程所使用的测试文件
   • 测试附加的打印机驱动程序
   • 再次描述重点，避免开发人员将缺陷退回给测试人员补充更多信息
   • 再次指明该缺陷是否在前一版本中已经存在
   • 多个平台之间是都具有不同的表现
   • 注释包含缺陷的隔离信息没指出缺陷的具体影响范围

   如：

   • 能在win2000和winXP文本框中显示恩本内容，但是不支持Win98
   • 屏幕刷新后，现象会消失‘
   • 使用二进制文件，不存在该错误
   • 参见附加的使用说明书和测试文件

6.避免使用的语言

• 我（I）你（you） 他/她（He / She）
• 情绪化的语言和强调符号（！！！）
• 似乎（Seems） 、看上去可能（Appears）
• 认为比较幽默的的内容
• 不确定的测试问题（Issues） / 不确定是否是缺陷

6.提高质量

• 尽早提交缺陷报告
• 清楚说明次问题对用户价值的危害
• 提供尽可能多的技术信息，方便程序员调试
  • 如包含该缺陷需要的环境变量或测试所用的数据文件
• 报告的软件缺陷进行了必要的隔离，报告的缺陷信息具体、准确
  • 一定要提前排查过不是因为人为的原因导致，就是软件本身得原因
• 易于搜索软件测试报告的缺陷
• 一个缺陷报告中只报告了一种缺陷
• 缺陷报告中不要提问问题

7.缺陷报告处理

1.简单处理流程/缺陷生命周期

人员	处理	得/传
软件测试人员	提交
测试负责人	分配	相关人员
相关人员		修改记录
测试人员	返测
负责人	关闭
开发人员	返测未通过	处理步骤

• 关闭或已解决的缺陷报告可能会被阶段性的复审重新打开，应该立即处理

2.缺陷报告的处理流程

• 缺陷报告的处理流程和缺陷的处理流程是一样的

• 正常缺陷
• 重复缺陷
• 无效缺陷
• 推迟修改
• 验证不通过：返测不通过
• 描述不清楚

3.缺陷管理工具

1.管理工具的功能

• 缺陷提交
• 缺陷跟踪
• 缺陷分析

2.有效缺陷分析好处

• 评价软件质量
• 帮助项目组很好掌握和评估软件的研发过程，进而改进研发过程，
• 为软件新版本的开发提供宝贵的经验，进而在项目开展之前，指定有效、准确的项目控制计划

3.常见的缺陷管理工具

• Bugzilla
  • 八个zei了
• Bugfree
• Mantis
• Jira
• Zen Tao(禅道)
• Quality Center / Application Lifecycle Management(ALM)

---

软件说明书

• 简称说明（spec）或产品说明书（product spec）
• 是软件开发小组的一个协定。它对开发的产品进行定义，给出产品的细节、如何做、做什么、不能做什么。这种协定从简单的口头说明到正式的书面文档有多种形式

参考

1. 尚硅谷课件

跳转

知识目录