缺陷管理

 

缺陷管理

一般在测试执行阶段产生

 

1、缺陷的基本概念

 

关于 BUG

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

 

容易混淆的几个概念

常见术语

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

 

 

缺陷定义

 

 

 

缺陷（Defect），经常又叫作Bug。

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

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

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

 

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

 

 

 

 

缺陷来源：

 

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

 

 

产生缘由：

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

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

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

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

 

缺陷的评价标准：

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

 

2、缺陷的属性

 

缺陷报告的相关属性：

 

• 缺陷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字体有问题。

• 详细描述

  • 一、打开WordEdit。

  • 二、输入一些文本。

  • 三、选择Arial。

  • 四、文本被破坏

• 软件缺陷初步分析：

  • N/A

 

 

冗余混淆的缺陷报告

 

• 简要描述

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

  像会破坏一些数据。

 

• 详细描述

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

  一些字体的混合。

  • 二、文件正常打印。

  • 三、建立并打印一张图表，工做正常。可是有些内容不是很清楚。

  • 四、以后，建立了一个新文件。

  • 五、而后，输入了一大堆随机文本。

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

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

  • 八、重复三次，每次结果都同样。

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

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