缺陷管理

 

缺陷管理

通常在测试执行阶段产生

一、缺陷的基本概念

 

关于 BUG

• Bug的由来
• Debug（调试bug的过程）
• Bug和Defect
• Bug：电脑系统或者程序中存在的任何一种破坏正常运转能力的问题或者缺陷，都可以叫做“Bug”；有时也被泛指因软件产品内部的缺陷引起的软件产品最终运行时和预期属性的偏离。
• Defect（缺陷）：既指静态存在于软件工作产品（文档、代码）中的错误，也指软件运行时由于这些错误被激发引起的和软件产品预期属性的偏离现象。

 

容易混淆的几个概念

常见术语

• 失误（Mistake）：导致软件包含故障的人的行为；
• 缺陷（Defect）：软件的异常情况；（在实际工作中bug和缺陷可能存为缺陷）
• 故障（Fault）：引起一个功能组件不能完成所要求的功能的一种意外情况；
• 失效（Failure）：功能组件执行其规定功能的能力丧失；

 

 

 

缺陷定义

 

 

 

缺陷（Defect），常常又叫做Bug。

计算机软件或程序中存在的某种破坏正常运行能力的问题、错误，或者隐藏的功能缺陷。

从产品内部看，缺陷是软件产品开发或维护过程中存在的错误、毛病等各种问题；

从产品外部看，缺陷是系统所需要实现的某种功能的失效或违背。

 

缺陷示例--导弹误炸事件

 

 

 

 

缺陷来源：

 

缺陷来源于软件生命周期各个阶段。

 

 

 

产生原因：

1.产品说明书不全，不完整和不准确，修改频繁，沟通不畅和理解不同；

2. 软件设计过程中考虑不周到，片面，多变，理解和沟通不足；

3. 文档不足，压时间，赶进度，设计和编码错误都会引入缺陷；

4. 测试和实施过程中安装环境配置错误等。

 

缺陷的评价标准：

• 软件未实现需求规格说明书（SRS）要求的功能
• 软件未实现需求规格说明书（SRS）虽未明确提及但应该实现的目标
• 软件出现了需求规格说明书（SRS）指明不应出现的错误
• 软件实现了需求规格说明书（SRS）未提到的功能
• 软件难以理解、不易使用、运行缓慢，或者从测试工程师的角度来看——最终用户会认为不好

 

二、缺陷的属性

 

缺陷报告的相关属性：

 

• 缺陷ID
• 标题
• 产生的步骤
• 所属模块
• 发现人
• 发现的时间
• 严重程度
• 优先级
• 类型
• 状态
• 可再现性
• 发现阶段
• 责任人
• 所属版本
• 修改日期
• 引入原因
• 备注信息
• 相关附件

 

 

缺陷类型

 

• 遗漏（Missing）
• 错误（Error）
• 额外的实现（Extra）
• 改进（Enhancement）

 

 

优先级的划分

 

表示处理和修正软件缺陷的先后顺序的指标，即哪些缺陷需要优先修正，哪些缺陷可以稍后修正。

 

 

 

严重程度的划分

 

指因缺陷引起的故障对软件产品的影响程度

 

 

 

 

 

缺陷跟踪的交付物

 

 缺陷报告单（Bug Report）：也叫缺陷跟踪单。测试执行过程中，发现软件失效后，提出书面的报告，提供给开发人员或者其他负责人员作为定位缺陷的依据，也作为日后缺陷度量的数据依据。（只有提交了报告单才能被记录，方便以后提交报告给上级）

 

缺陷管理工具中的BUG Report

 

 

 

 

 

三 缺陷的生命周期

 

• 缺陷的生命周期
• 缺陷的生命周期就是指缺陷从开始提出到最后完全解决，并通过验证和确认的过程。在这个过程中缺陷报告的状态不断发生着变化，记录着缺陷被处理的过程。
• 缺陷的生命周期通过缺陷流程图得以展现

 

bug的流程

 

 

 

 

状态说明：

 

• 新建（new）：测试人员提交新问题标识的状态
• 打开（open）：已经确认为是BUG的状态
• 已修复（fixed）：为开发人员修改问题后所标志的状态，等待测试验证。
• 重新打开（reopen）：测试人员对修改问题进行验证后没有通过所标志的状态或者已经修改正确的问题又重新出现错误，由测试人员改变。
• 已关闭（closed）：为测试人员对修改问题进行验证后通过所标志的状态。由测试人员改变。
• 拒绝（rejected）：开发人员认为不是BUG、描述不清、重复、不能复现、不采纳所提意见建议、或虽然是个错误但还没到非改不可的地步故可忽略不计、或者测试人员提错，从而拒绝的问题。由BUG分配人或者开发人员来设置。
• 重复（duplicated）：表示该BUG已经被其他测试人员找出来了，或者开发认为原因是相同的（但从测试来看，认为出现的地方有所不同、表现有所不同等）
• 延期（postponed）：由于时间、进度、重要程度或者技术/需求等方面的原因，认为不能解决、须延期解决、或者本版不做留待到后续版本解决的BUG。

 

 

缺陷沟通：

 

 

 

 

 

 

一个简单的bug跟踪流程

 

 

 

 

 

BMS:缺陷管理工具

 

 

缺陷报告的状态：

 

 

 

 

 

缺陷状态迁移矩阵

 

 

 

 

 

rejected、duplicate 开发人员同意就跳转到reopen

不同意就跳转到abandon

 

软件测试缺陷管理流程

 

 

 

缺陷管理中的常见问题

 

• 提交的缺陷开发人员不认可怎么办？(给出提交缺陷的依据，如果还是不行，向上级或有经验的人员寻求帮助）
• 如何处理不能重现的缺陷？(出现缺陷必须立马截图记录，以防之后无法找到)
• 如何处理好与开发人员及其他相关人员的关系？(多沟通）
• 缺陷太多怎么办？（先打回让开发自己解决）
• 找不到缺陷怎么办？（分析代码质量真的太高还是用例设计不够全面）
• 缺陷得不到及时修复怎么办？（及时告知上级，与开发协调解决）
• 如何处理缺陷级别定义之争？（根据客观实际情况和项目组划分的范围定义）
• 如何处理缺陷跟踪中的扯皮现象？

 

 

四 缺陷报告的书写

 

缺陷报告单书写准则

 

• Correct（准确）

   每个组成部分的描述准确，不会引起误解

• Clear（清晰）

   每个组成部分的描述清晰，易于理解

• Concise（简洁）

   只包含必不可少的信息，不包括任何多余的内容

• Complete（完整）

   包含复现该缺陷的完整步骤和其他本质信息

• Consistent（一致）

   按照一致的格式书写全部缺陷报告

 

缺陷报告的写作要点

 

• 再现：一般是尽量三次再现故障，如果问题是间断的，那要报告问题发生频率。
• 初步定位：可能影响再现的变量，例如配置变化、工作流、数据库，这些都可能改

        变错误的特征。

• 推广：确定系统其他部分是否可能出现这种错误，以及使用不同的数据时是否存在

       着这种问题等等，特别是那些可能存在更加严重特征的部分。

• 压缩：精简任何不必要的信息，特别是冗余的测试步骤。
• 去除歧义：使用清晰的语言，尤其是避免使用那些有多个不同或相反含义的词汇。
• 中立：公正的表达自己的意思，对错误及其特征的事实进行陈述，避免夸张、幽默或讽刺。
• 评审：至少有一个同行，最好是一个有经验的测试工程师或测试经理，在递交错误报告之前自己先阅读一遍。

 

 

缺陷报告单基本内容

 

 

 

  Bug的摘要是要用一句话的形式简明扼要地将Bug描述出来，要清晰指出Bug所在部位以及其错误类型，不能太笼统。如“页面对非法输入有问题”可以修改为“流量信息查询页面对于非法输入没有进行校验”

 

 

缺陷描述举例

 

• 简单描述

  • Arial、Wingdings和Symbol字体会破坏新文件。

• 详细描述

  • 软件测试环境为windows 2000 sp4

  • 启动WordEdit编辑器，然后创建新文件。

  • 输入四行文本，重复输入”The quick fox jumps over the lazy brown dog”。

  • 选中所有四行文本，然后选择字体下拉菜单，并选择Arial。

  • 所有文本被转换成控制字符、数字和其它明显的随机二进制数据。

  • 重复三次，结果都一样。

• 相关附件

  • 附件1：变换格式之前的文档

  • 附件2：变换格式之后的文档

• 软件缺陷初步分析：

  • 粗略估计是格式问题，保存文件，关闭WordEdit并重新打开文件，但是数据仍

  然被破坏

  • 在改变字体前保存文件防止错误。

  • 对现存文件，错误不再发生。

  • 只在WINDOWS 2000下发生，而不出现在Solaris、Mac和其他Windows系

  统。

 

 

含糊不完整的缺陷描述

 

 

• 简要描述

  • WordEdit处理Arial字体有问题。

• 详细描述

  • 1、打开WordEdit。

  • 2、输入一些文本。

  • 3、选择Arial。

  • 4、文本被破坏

• 软件缺陷初步分析：

  • N/A

 

 

冗余混淆的缺陷报告

 

• 简要描述

  • 我在Solaris、Windows 98和Mac上运行WordEdit，当使用某些字体时，好

  像会破坏一些数据。

 

• 详细描述

  • 1、在Windows 98上打开WordEdit，然后编辑两个现有文件。这些文件包含

  一些字体的混合。

  • 2、文件正常打印。

  • 3、创建并打印一张图表，工作正常。但是有些内容不是很清楚。

  • 4、之后，创建了一个新文件。

  • 5、然后，输入了一大堆随机文本。

  • 6、在输入了文本之后，选中一些行。然后，拉下字体菜单并选择Arial。

  • 7、改变的文本被破坏了。

  • 8、重复三次，每次结果都一样。

  • 9、我在Solaris上重复步骤1-6，没有发现任何问题。

  • 10、我在Mac上重复步骤1-6，没有发现任何问题。

• 缺陷原因分析：

  • 我尝试选择其他字体，但是只有Arial出现这个错误。但是，其他没有测试的字

  体仍然有可能出错。

五 常用管理工具

缺陷管理的目的

 

• 保证信息的一致性

• 保证缺陷得到有效的跟踪，缩短沟通时间，解决问题更高效

• 利于缺陷分析、产品度量，使项目情况可视化加强

 

 

 

 

 

常用的缺陷管理工具

 

1. QC（QC（quality control）是TD的升级版，QC的升级就是ALM）

2. 禅道(bugfree升级版）

3. Mantis

4. JIRA

5. TestLink

6. Bugzilla

7. Redmine（开源，基于敏捷开发模型）

 

常用工具说明

 

1. QC 商业购买 --基于Web的测试管理工具，可以组织和管理应用程序测试流程的所有阶段，包括指定测试需求、计划测试、执行测试和跟踪缺陷。此外，通过Quality Center还可以创建报告和图来监控测试流程。

2. 禅道 国产开源 -- 本地化做的比较好。禅道是为研发类项目/团队量身定制的一款管理软件，覆盖产品开发的整个生命周期，页面简洁、流程清晰。

3. Mantis 开源 -- 是一个基于PHP技术的轻量级的开源缺陷跟踪系统，以Web操作的形式提供项目管理及缺陷跟踪服务。

4. TestLink 开源，可以与Mantis集成；是sourceforge的开放源代码项目之一，作为基于web的测试管理系统。

5. JIRA 开源，可二次开发，是Atlassian公司出品的项目与事务跟踪工具。

6. Bugzilla 是Mozilla公司提供的一款开源的免费Bug（错误或是缺陷）追踪系统，用来帮助你管理软件开发，建立完善的BUG跟踪体系

7. Redmine 是一个开源的、基于web的项目管理和缺陷跟踪工具。它用日历和甘特图辅助项目及进度可视化显示，同时它支持多项目管理。Redmine是一个自由开放源码软件的解决方案，它提供集成的项目管理功能，问题跟踪，并为多个版本控制的选项的支持。

 

六  缺陷分析

 

识别BUG

 

• BUG是由于软件开发者的疏忽和失误造成的。

• BUG是软件生命周期内发现和未被发现的所有问题总和。

• 全面质量管理和全程软件测试：

BUG不单指软件测试阶段发现的软件系统的功能性错误，还应包括软件开发过程中需求、设计、开发等阶段评审过程发现的问题，以及软件发布后客户发现并反馈的问题，同时还包括那些隐藏在软件内部未被发现的问题。（总结经验教训，改进软件开发过程）