1、报告缺陷的重要性

软件缺陷的描述是软件缺陷报告的基础部分，需要使用简单、准确、专业的术语来描述缺陷。否则，它就会含糊不清，可能会误导开发人员，影响开发人员的效率，也会影响测试人员自身的声誉，准确报告缺陷是非常重要的。

  1. 清晰准确的软件缺陷描述可以减少开发人员退回来的缺陷数量，可以节省开发人员和测试人员的时间。
  2. 提高软件缺陷修复的速度，使项目组能够有效地工作。
  3. 提高测试人员的可信任程度，可以得到开发人员对有效缺陷的及时响应。
  4. 加强开发人员、测试人员和管理人员的协同工作，让他们更好的工作。

2、报告缺陷注意事项

  • 尽量确保缺陷可以重现。

    • 如果提交的缺陷无法重现，会影响开发人员的工作效率。

  • 简洁、准确、完整

    • 测试人员在提交缺陷报告时，要站在开发人员的角度上思考问题，要确保开发人员能迅速定位问题，而不会产生理解上的歧义。

  • 一个缺陷一个报告（重点）

    • 有的测试人员喜欢在一个缺陷报告里提交多个缺陷，这种习惯不提倡，原因有以下两点：
    • 不便于分配。
    • 比如缺陷报告有2个缺陷，分别属于不同的开发人员，到底该分配给谁呢？
    • 不便于验证。
    • 比如一个缺陷报告里面有2个缺陷，缺陷1已经解决，缺陷2还没有解决，那么这个缺陷报告该不该关闭呢？

      3、缺陷书写规范

  • 标题：应保持简短、准确，提供缺陷的本质信息

    • 尽量按缺陷发生的原因与结果的方式书写；
    • 避免使用模糊不清的词语，例如：“功能中断，功能不正确，行为不起作用”等。应该使用具体文字说明缺陷的症状；
    • 为了便于他人理解，避免使用俚语或过分具体的测试细节。
  • 复现步骤：应包含如何使别人能够很容易的复现该缺陷的完整步骤。
    • 为了达到这个要求，复现步骤的信息必须是完整的、准确的、简明的、可复现的。常见问题：
    • 包含了过多的多余步骤，且句子结构混乱，可读性差，难以理解；
    • 包含的信息过少，丢失了操作的必要步骤；
  • 复现步骤的正确书写方式：
    • 提供测试的环境信息；
    • 简单地一步步引导复现该缺陷，一个步骤包含的操作不要多；
    • 每个步骤前使用数字对步骤编号；
    • 尽量使用短语或短句，避免复杂句型句式；
    • 复现的步骤要完整、准确、简短；
    • 将常见步骤合并为较少步骤；
    • 按实际需要决定是否包含步骤执行后的结果。
  • 实际结果：是执行复现步骤后软件的现象和产生的行为。
    • 实际结果的描述应向标题信息那样，要列出具体的缺陷症状，而不是简单地指出“不正确”或“不起作用”。
  • 期望结果：描述应与实际结果的描述方式相同。通常需要列出期望的结果是什么。
  • 附件：对缺陷描述的补充说明，可以是以下一些类型：
    • 缺陷症状的截图；
    • 测试使用的数据文件；166 199 188
  • 其它：
    • 选择合适的缺陷严重性属性；
    • 按相应的规定，填写相应的字段信息
  • 避免常见的错误：
    • 避免使用我、你等人称代词，可以直接使用动词或必要时使用“用户”代替
    • 避免使用情绪化的语言和强调符号；
    • 避免使用诸如“似乎”、“看上去可能”等含义模糊的词汇，而需要报告确定的缺陷结果；
    • 避免使用自认为比较幽默的语句，只需客观地描述缺陷的信息；
    • 避免提交不确定的测试问题，自己至少需要重现一次再提交。

  • 反面的示例：

    • 上海人：哪能查询到的结果和查询条件不搭噶的。
    • 北京人：哥们好不容易输入一堆个人详细信息后，点击保存后全瞎了。

      4、缺陷报告模板

      | 缺陷ID： | 625143 | 测试日期： | 2010/7/28 | | —- | —- | —- | —- | | 测试人员： | lion | BUG类型： | 界面错误 | | 功能模块： | 侧导航 | 环境（浏览器）： | 谷歌浏览器 | | 严重程度： | 3 | 优先级： | 3 | | 概要描述： | 侧导航文字变多，导致换行 | | | | 1、打开网站首页，查看左侧导航
      2、找到食品行，添加多个文字
      3、出现换行效果
      结果：导致用户无法点击
      预期结果：文字应该不换行显示 | | | | | 解决者： | 小A | 解决日期： | 2010/7/29

    | | 解决方案： | 可以添加 title属性 把所有的文字写进去 | | |

5、缺陷处理流程

                        ![图片.png](https://cdn.nlark.com/yuque/0/2020/png/1029078/1593335416988-de8ad27f-e5f9-44f3-a431-490a0a729fe1.png#align=left&display=inline&height=287&margin=%5Bobject%20Object%5D&name=%E5%9B%BE%E7%89%87.png&originHeight=397&originWidth=701&size=33543&status=done&style=none&width=506)

6、缺陷密度

基本的缺陷测量是以每千行代码的缺陷数(个/KLOC)来测量的。称为缺陷密度，其测量单位是defects／KLOC。可按照以下步骤来计算一个程序的缺陷密度：
累计开发过程中每个阶段发现的缺陷总数。
统计程序中新开发的和修改的代码行数。
计算每千行的缺陷数=1000缺陷总数/代码行数。
例如：
一个29.6万行的源程序总共有145个缺陷，则缺陷密度为：
缺陷密度＝1000145/296000=0.49 个／KLOC。