软件的缺陷

在软件的开发与使用过程当中每每会出现与咱们预料以外的各类影响软件功能的错误。

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

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

1、了解缺陷

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. 缺陷的状态迁移矩阵

 

2、缺陷管理

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

2. 简单的BUG跟踪流程

 

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

 

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

问题：

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

解决方法：

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

5. 缺陷报告的书写

书写准则（5C）：

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

 

缺陷报告的写做要点：

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

 

缺陷报告单的基本内容

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

 

3、经常使用的缺陷管理工具

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