提交缺陷报告

一、软件缺陷的判定

1. 什么是缺陷

• 软件存在着不符合质量需求或违背软件用户、客户、企业意愿的问题，这就是软件缺陷 （Defect），又叫“Bug（臭虫）”。

2. 软件缺陷的判定准则

• 软件未达到产品说明书标明的功能；
  • 产品说明书简称为说明（spec）或产品说明（product spec），是软件开发小组 的一个协定。它对开发的产品进行定义，给出产品的细节、如何做、做什么、 不能做什么。这种协定从简单的口头说明到正式的书面文档有多种形式。
• 软件出现了产品说明书指明不会出现的错误；
  • 如金融软件 7*24 工作不能宕机
• 软件功能超出产品说明书指明范围；
• 软件未达到产品说明书虽未指出但应达到的目标；
  • 如软件在断电时的意外处理
• 软件测试员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好。
  • 主要体现在易用性方面。

3. 软件缺陷的表现形式

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

4. 分离和再现软件缺陷

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

5. 避免提交缺陷的缺陷和重复缺陷

• 缺陷的缺陷
  • 是测试人员提交的不是缺陷的缺陷；
  • 是一种无效缺陷；
  • 此类缺陷常使测试人员遭受指责。
  • 怎么办
    • 正确理解需求；
    • 做好复现。
• 重复缺陷
  • 同一个缺陷 A 测试工程师提交后，B 测试工程师又提交或者自己提交的缺陷 与之前提交的缺陷相同或类似；
  • 是一种无效缺陷；
  • 怎么办
    • 尽量避免两个人同时测试同一模块；
    • 自己提交的缺陷与自己的重复，提交前查找一下，增强开发知识。

6. 处理无法再现的缺陷

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

7. 处理有争议的缺陷

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

二、提交缺陷报告

1. 什么是缺陷报告

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

2. 缺陷报告的读者对象

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

3. 缺陷报告的写作准则（5C）

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

4. 缺陷报告的组织结构

• 缺陷的标题/缺陷摘要/缺陷概述/缺陷基本信息
• 预处理
• 复现步骤
• 期望结果
• 实际结果
• 缺陷的严重程度
• 缺陷的优先级
• 测试的软件和硬件环境
• 测试的软件版本
• 缺陷的类型
• 注释文字和缺陷截图

5. 缺陷报告的写作要求

5.1 缺陷标题

• 尽量按缺陷发生的原因与结果的方式书写；
  • 执行完 A 后，发生 B；
  • 在什么地方，做了什么事情，出了什么结果；
    • 使用“在…以后”，“在…时候”或“在…期间”等连结词有助于描 述缺陷的原因和结果。
• 避免使用模糊不清的词语；
• 为了方便搜索和查询，尽量使用关键字；
• 为了便于他人理解，避免使术语、俚语或过分具体的测试细节。

5.2 复现步骤

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

5.3 预期结果

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

5.4 实际结果

• 实际结果的描述要列出具体的表现行为，而不是简单的指出“不正确”或“不起作 用”。
• 如果一个动作产生彼此不同的多个缺陷结果，或者一个动作将产生一个结果，而这 个结果又产生另一个结果。为了易于阅读，这些结果应该使用数字列表分隔开来。 如实际结果：
  • 1.显示“命令代码行…错误”；
  • 2.显示“并且终止…服务”。

5.5 注释/截图

• 可以包含以下各方面的内容：
  • 截取缺陷特征图像文件；
  • 测试过程所使用的测试文件；
  • 测试附加的打印机驱动程序；
  • 再次描述重点，避免开发人员将缺陷退回给测试人员补充更多信息；
  • 再次指明该缺陷是否在前一版本已经存在；
  • 多个平台之间是否具有不同表现；
  • 注释包含缺陷的隔离信息，指出缺陷的具体影响范围。
• 如，缺陷的注释可能包含下面的内容：
  • 能在 Win2000 和 WinXP 文本框中显示文本内容，但不支持 Win98
  • 屏幕刷新后，现象会消失。
  • 使用二进制文件，不存在该错误。
  • 参见附加的使用说明书和测试文件。

6. 怎么提交高质量的缺陷报告

• 尽早提交缺陷报告。
• 清楚地说明此问题对用户价值的危害。
• 提供尽可能多的技术信息（如包含复现该缺陷需要的环境变量或测试所用的数据文 件），方便程序员调试。
• 报告的软件缺陷进行了必要的隔离，报告的缺陷信息具体、准确。
• 易于搜索软件测试报告的缺陷。
• 一个缺陷报告中只报告了一种缺陷。
• 缺陷报告中不要提问题。
• 避免常见的错误  我（I）、你（You）、他/她（He/She）
  • 情绪化的语言和强调符号！！！
  • 似乎（Seems）、看上去可能（Appears to be）
  • 认为比较幽默的内容
  • 不确定的测试问题（Issues）/不确定是否是缺陷

三、缺陷的分类

1. 缺陷的分类标准

2. 根据缺陷类型对缺陷分类

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

3. 根据缺陷的等级对缺陷分类

• A 类—致命缺陷，包括以下各种错误：
  • 由于程序所引起的死机，非法退出；
  • 死循环；
  • 数据库发生死锁；
  • 因错误操作导致的程序中断；
  • 功能错误；
  • 与数据库连接错误；
  • 数据通讯错误
• B 类—严重缺陷，包括以下各种错误：
  • 程序错误；
  • 程序接口错误；
  • 数据库的表、业务规则、缺省值未加完整性等约束条件
• C 类一般缺陷，包括以下各种错误：
  • 操作界面错误（包括数据窗口内列名定义、含义是否一致）；
  • 打印内容、格式错误；
  • 简单的输入限制未放在前台进行控制；
  • 删除操作未给出提示；
  • 数据库表中有过多的空字段
• D 类—较小缺陷，包括以下各种错误：
  • 界面不规范；
  • 辅助说明描述不清楚；
  • 输入输出不规范；
  • 长操作未给用户提示；
  • 提示窗口文字未采用行业术语；
  • 可输入区域和只读区域没有明显的区分标志
• E 类—意见或建议

4. 根据缺陷处理的优先级对缺陷分类

5. 根据缺陷状态对缺陷分类

四、缺陷报告的处理

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

• 软件测试人员提交缺陷报告；
• 测试负责人审核后将缺陷报告分配给相关的开发人员修改；
• 缺陷被修改后由测试人员根据缺陷报告中的修改记录进行返测；
• 返测通过的缺陷报告由负责人关闭，返测未通过的缺陷报告直接返回开发人员重新 修改，缺陷报告直到缺陷被修复以后才关闭；
• 关闭或已解决的缺陷报告可能会被阶段性的复审重新打开，这些报告一旦被再次打 开应该立即处理。

2. 缺陷报告的标准处理流程

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

3. 缺陷跟踪管理系统/缺陷管理工具

3.1 缺陷管理工具的功能

• 缺陷提交
• 缺陷跟踪
• 缺陷分析
  • 有效的缺陷分析不仅可以评价软件质量，同时可以帮助项目组很好地掌握和评 估软件的研发过程，进而改进研发过程，未对缺陷进行分析就无法对研发流程 进行改进。
  • 缺陷分析还能为软件新版本的开发提供宝贵的经验，进而在项目开展之前，指 定准确、有效的项目控制计划，为开发高质量的软件产品提供保障。

3.2 常见缺陷管理工具

• Bugzilla
• Bugfree
• Mantis
• Jira
• ZenTao（禅道）
• Quality Center/Application Lifecycle Management
  • 目前市场占用率最高的项目管理工具。
  • 全球最大的测试工具提供商 Mercury Interactive 公司生产的企业级项目管理工 具。