软件的缺陷

在软件的开发与使用过程中往往会出现与我们预料之外的各种影响软件功能的错误。

在IT行业我们称这些影响软件正常功能的错误叫缺陷。

这篇文章将要和大家介绍软件的缺陷，以及在项目中测试人员如何管理这些缺陷

一、了解缺陷

1. 定义：缺陷又称BUG。计算机软件或程序中存在的某种破坏正常运行能力的问题、错误，或者隐藏的功能缺陷。从产品内部来看，缺陷是软件产品开发或维护过程中存在的错误、毛病等各种问题；从产品外部看，缺陷就是系统所需要实现的某种功能的失效或违背。

 

2. 缺陷的来源：来源于软件生命周期的各个阶段

 

3. 产生原因：

产品说明书不全，不完整和不准确，修改频繁，沟通不畅和理解不同，软件设计过程中的考虑不周到，片面，多变理解和沟通不足

 

4. 缺陷的评价标准

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

 

5. 缺陷的属性

项目中，大多数都是用工具来管理缺陷的，所以像缺陷ID、发现的时间、发现人等都是自动生成的

相关附件中，测试人员可以附上BUG的截图、跟踪日志等

 

6. 缺陷的类型

遗漏、错误、额外的实现、改进

 

7. 缺陷优先级的划分

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

 

 

8. 缺陷严重程度的划分

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

9. 缺陷跟踪的交付物

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

 

缺陷管理工具中的BUG report

 

10. 缺陷的生命周期

就是指缺陷从开始到最后完全解决，并通过验证和确认的过程。

在这个过程中缺陷报告的状态不断发生着变化，记录着缺陷被处理的过程。

 

11. 缺陷的流程及对应的状态

状态说明：

1. 新建（new）：测试人员提交新问题标识的状态
2. 打开（open）：已经确认为是BUG的状态
3. 已修复（fixed）：为开发人员修改问题后所标志的状态，等待测试验证
4. 重新打开（reopen）：测试人员对修改问题进行验证后没有通过所标志的状态或者已经修改正确的问题又重新出现错误，由测试人员改变。
5. 已关闭（closed）：为测试人员对修改问题进行验证后通过所标志的状态。由测试人员改变
6. 拒绝（rejected）：开发人员认为不是BUG、描述不清楚、重复、不能复现、不采纳所提意见建议、或虽然是个错误但还没到非改不可的地步故忽略不急、或者测试人员提错、从而拒绝的问题。由BUG分配人或者开发人员来设置。
7. 重复（duplicated）表示该BUG已经被其它测试人员找出来了，或者开发认为原因是相同的（但从测试来看，认为出现的地方不同、表现有所不同等），后者建议重视，单独提出这个bug，因为如果不提，可能会影响我们后续的跟踪。
8. 延期（postponed）：由于时间、进度、重要程度或者技术/需求等方面的原因认为不能解决、延期解决、或者本版不做保留待到后续版本解决的Bug。
放弃（abandon）：被拒绝或重复的缺陷，测试人员确认后的确不是问题，将缺陷置为此状态，abandon是一种特殊意义的closed（测试人员标记的状态）

 

12. 缺陷的状态迁移矩阵

 

二、缺陷管理

1. 缺陷沟通（沟通是测试人员的主要工作之一）

2. 简单的BUG跟踪流程

 

3. 软件测试缺陷管理流程

 

4. 缺陷管理中常出现的问题和应对方法

问题：

• 提交的缺陷开发人员不认可怎么办？
• 如何处理不能重现的缺陷？
• 如何处理好与开发人员及其他相关人员的关系？
• 缺陷太多怎么办？
• 找不到缺陷怎么办？
• 缺陷得不到及时修复怎么办？
• 如何处理缺陷级别定义之争？
• 如何处理缺陷跟踪中的扯皮现象？

解决方法：

1. 测试人员要对自己有自信，因为我们有依据，确认自己没有问题后，开发若还不认可，可以向领导寻求帮助
2. 养成出现缺陷立马记录下来的习惯（截图）方便后续处理，避免背锅
3. 注意沟通的语气（委婉），工作之余培养好关系
4. 重点关注缺陷多的模块，缺陷太多的模块直接打回给开发
5. 先分析自己，是不是自己设计的用例不全，有没有覆盖需求
6. 及时跟踪缺陷，及时了解开发修复的进度，若迟迟得不到修复的话上报领导
7. 先和开发解释，解释不了可以寻求帮忙（这种情况一般不会出现）
8. 确保自身没有问题，尽量说服开发，若不行上报领导

5. 缺陷报告的书写

书写准则（5C）：

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

 

缺陷报告的写作要点：

• 再现：一般是尽量三次再现故障，如果问题是间断的，那要报告问题发生频率。
• 初步定位：可能影响再现的变量，例如配置变化、工作流、数据库，这些都可能改变错误的特征。
• 推广：确定系统其他部分是否可能出现这种错误，以及使用不同的数据时是否存在着这种问题等等，特别是那些可能存在更加严重特征的部分。
• 压缩：精简任何不必要的信息，特别是冗余的测试步骤。
• 去除歧义：使用清晰的语言，尤其是避免使用那些有多个不同或相反含义的词汇。
• 中立：公正的表达自己的意思，对错误及其特征的事实进行陈述，避免夸张、幽默或讽刺。
• 评审：至少有一个同行，最好是一个有经验的测试工程师或测试经理，在递交错误报告之前自己先阅读一遍。

 

缺陷报告单的基本内容

BUG的摘要要用一句话的形式简明扼要地将BUG藐视出来，要清晰指出BUG所在部位以及其错误类型。

 

三、常用的缺陷管理工具

1. 缺陷管理的目的

• 保证信息的一致性
• 保证缺陷得到有效的跟踪，缩短沟通时间，解决问题更高效
• 利于缺陷分析、产品度量，使项目情况可视化加强

 

2. 常用的缺陷管理工具

1. QC（QC是TD的升级版，QC的升级就是ALM）
2. 禅道(bugfree升级版）
3. Mantis
4. JIRA
5. TestLink
6. Bugzilla
7. Redmine

TD不仅可以管理缺陷，还可以管理测试、需求乃至整个项目过程（收费）
禅道：也是项目管理工具，不仅可以管理缺陷，基于敏捷开发模型，同样适用与其它开发模型（开源）

 

3. 常用工具说明

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是一个自由开放源码软件的解决方案，它提供集成的项目管理功能，问题跟踪，并为多个版本控制的选项的支持。