软件测试之缺陷管理

一、软件缺陷的基本概念

1、软件缺陷的基本概念主要分为：缺陷、故障、失效这三种。

（1）缺陷（defect）：存在于软件之中的偏差，可被激活，以静态的形式存在于软件内部，相当于bug;

（2）故障（Fault）：软件运行中出现的状态，可引起意外情况，若不加处理，可产生失效，是一个动态行为；

（3）失效（Failure）：软件运行时产生的外部异常行为结果，表现与用户需求不一致，功能能力终止，用户无法完成所需要的应用。

二、软件缺陷的三个基本概念的相互关系

1、bug一定会被激活吗？激活后一定表现为故障吗？

答案是不一定，任何一个软件即便测试的非常严格，在发布后也会存在遗漏的bug，但是这些bug在用户使用的时候不一定会被激活，因为有些bug隐藏的比较深，用户在使用的过程中不可能触发这些bug，所以这些bug一直隐藏在软件内部，没有被激活，也就是说即使软件内部有bug，软件也可以正常运行，但也有可能，在某些情况下，这些bug会被激活，表现为故障*。

2、故障一定会导致失效吗？

答案也是不一定，开发人员在做设计的时候，更多的考虑了在软件使用期间可能出现的故障，然后针对这些故障采取的一些预防的措施，比如：数据库会出现的数据丢失的问题，为了避免这种失效的出现，产品开发人员在做设计的时候，也许会采取数据库时时备份的方式，也就是在本地有一个数据库，在异地也有一个数据库，这个地方的数据库会实现时时的备份，当其中一个数据库出现了异常，那另外一个数据库还可以启动工作，所以说，缺陷不一定会导致故障，故障不一定会导致失效。

三、软件缺陷报告单

缺陷报告单是任何缺陷修改的一个起始，也就是我们测试人员在进行测试执行的时候，发现了一个缺陷，发现缺陷后，我们不要口头和开发人员交流，因为口头的交流不仅没有任何的约束力，而且有可能表达不清楚，所以我们要把缺陷落实在纸面上，也就是要测试人员填写缺陷报告单。

缺陷报告单的作用：

1、测试执行过程中，发现缺陷失效后（不一定是失效，也许是故障，一般来说这个缺陷在测试阶段被发现往往表现为产品失效），提出书面的报告，提供给开发人员作为定位缺陷的依据，也作为日后缺陷度量的数据依据，开发人员接到缺陷报告单后，他会根据缺陷报告单上描述的缺陷外在表现来重现这个问题，然后找出这个问题，也就是缺陷产生的根源。

2、缺陷报告还可以作为我们日后缺陷度量的数据依据，度量是对整个产品进行考核，比如说，我们的软件在什么时候可以发布，什么时候可以交付给客户等等问题，这个时候我们往往从缺陷度量的数据来看，比如我们子啊最后一轮进行测试的过程中，每千行代码只有0.1个缺陷，说明我们产品的质量已经非常高了，而且遗留的缺陷也就非常少了，这个时候就可以发布产品了，所以这个缺陷的统计数据时非常重要的，它可以作为缺陷度量的依据。

四、软件缺陷管理的目的

缺陷管理的目的是：对各个阶段测试发现的缺陷进行跟踪管理，以保证各级缺陷的修复率达到标准，主要实现以下目标：

（1）保证信息的一致性；

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

（3）收集缺陷数据并进行数据分析，作为缺陷度量的依据。

五、软件缺陷管理工具

软件缺陷管理的流程一定要有相关的软件进行支撑，否则软件缺陷管理的流程是无法正常运行的，就类似于我们在做开发的过程中，开发JAVA相关的程序我们就需要JBOSS这样的工具，，如果我们开发C++就需要Visual C++工具，在软件缺陷跟踪中我们也需要一些工具，比如商用工具Mercury Quality Center是目前非常强大的软件测试管理工具，它的功能包括业务管理、测试用例的管理、缺陷的分析及测试脚本的管理，所有缺陷仅仅是其一个点；Rational ClearQuest它主要用于变更控制和缺陷管理这一块，此外还有Bugzilla,Mantis,Jira三个开源工具。

使用商用的软件缺陷管理工具或软件测试工具，好处是由商家提供一系列支持、工具的相关制定以及后期的升级服务，所以商用软件缺陷管理工具从整体的易用性和可用性来看，要比开源工具好得多，开源工具最大的好处就是便宜，不用去花钱购买，但是易用性和可用性相对来说就弱一些。

六、软件缺陷管理的相关角色

软件开发和软件测试的任何一个流程，都应该有流程的入口，流程的出口，还有流程的具体过程以及参与到这些过程中的相关角色。

在软件跟踪的流程当中，有以下几类角色：

（1）软件开发人员；

（2）软件测试人员；

（3）软件测试项目经理；

（4）软件开发项目经理；

（5）CCB（Change Control Board）：变更控制委员会。所谓的变更控制委员会，他是在开发人员和测试人员对缺陷出现争议的时候，做出最后的裁判；

（6）配置管理员：就是测试人员提交BUG，开发人员修改，修改完check in ，那么在check in这个过程中需要配置管理员参与进来，只有经过配置管理员授权，开发人员才有资格把代码从本地Check in到服务器中去，所以配置管理员在软件缺陷管理中也很重要。

软件缺陷报告的内容以及缺陷的相关属性

一、软件缺陷报告的内容

1、Bug Title/Summary：缺陷标题/简单描述

对测试执行过程中实际出现的问题的描述，尽量要简单概要。

2、Repro Step：重现步骤

（1）描述问题的基本环境，包括操作系统、硬件环境、网络环境、被测试软件的运行环境；

（2）简单概括的描述清楚软件出现异常时，测试人员的操作步骤和使用数据；

（3）缺陷原因的分析；比如说：因为不支持字符集，而导致的乱码...等等。

（4）要写清楚，重复操作了多少次，这个bug依然出现。（不能操作一次就提交bug,因为有可能是自己操作失误。）

（5）相关附件：为了让开发人员更好的了解Bug。（如果从GUI界面上可以反映出软件的异常，可以截取界面，粘贴在问题单上或者日志、数据包）；

（6）属性（在下面详细说明）：缺陷报告中除了对缺陷的基本描述外，我们还要对其属性进行说明。

二、软件缺陷的相关属性

测试人员在提交缺陷的时候，需要把缺陷，发现缺陷的过程以及缺陷的一些表现都要描述出来，除此之外这些缺陷还有一定的相关属性，也要填写出来。

下面我们列举六个比较重要的缺陷属性。

属性1、缺陷发现人

在提交缺陷的时候测试人员一般是缺陷的发现人，这个字段也很重要，比如到QC里面统计一下本季度哪一个测试人员发现的BUG比较多。

属性2、缺陷发现时间

缺陷发现时间也是一个统计的计数点，或者数据点，缺陷趋势图就是按照时间轴来排列的，如果缺少了缺陷发现时间，这个图是做不出来的，没有缺陷趋势图，我们就不能进行产品的度量，就不知道产品在什么时候发布是比较合适的。

属性3、缺陷状态

软件缺陷状态这个属性是非常重要的，在任何的软件报告中，这一个属性是一定要有的。
下面我们主要列出了在QC中常用的几种状态：

New:缺陷的初始状态；Open：开发人员开始修改缺陷；Fixed：开发人员修改缺陷完毕；Closed：回归测试通过；Reopen：回归测试失败；Postpone：推迟修改；Rejected：开发人员认为不是程序问题，不用修改；Duplicate：与已提交的Defect重复；Abandon：被Reject和Duplicate的Defect，测试人员确认后的确不是问题，将Defect置为此状态。

New是缺陷的初始状态，所谓初始状态就是发现问题，发现问题，提交问题后，这个缺陷就处于New状态；

提交给开发人员后，开发人员接受这个问题，那么就把这个缺陷的状态就更改为Open；

开发人员修改缺陷之后，就会把这个缺陷的状态改为Fixed；

然后提交给测试人员，测试人员进行回归测试，回归测试通过，就把状态改为Closed；

我们可以看到New--Open--fixed--closed这个状态是一个比较理想的缺陷流程，也就是测试人员提交问题，开发人员接受并修改问题，然后测试人员进行回归测试通过。

但是我们一般在缺陷跟踪流程当中也会遇到一些问题：

1、比如说回归测试失败，这个状态就是Reopen，也就是说测试人员在进行回归测试的时候失败了，就要把这个缺陷的状态改为Reopen，然后再提交给开发人员进行修改，开发人员修改完之后，把这个缺陷的状态改为Fixed，然后又提交给测试人员，测试人员再一次进行回归测试，直到回归测试成功，把这个缺陷的状态改为Closed。

2、Postpone：推迟修改，比如当我们把问题提交给开发人员的时候，开发人员觉得也接受这个问题，但是暂时无法修改，那就可以把这个问题置为推迟状态，此时这个缺陷的状态就是Postpone。

3、当我们提交的Defect与别热提交的相同时，缺陷就被置为Duplicate状态。

4、比如说开发人员觉得测试人员提交的不是问题，不用修改，可以将这个BUG置为Reject状态。

5、被Reject和Duplicate的Defect，我们最终要把它置为Abandon状态。

属性4、缺陷严重程度（Severity）

缺陷的严重程度就是：站在用户的交付，bug出现之后对软件质量的破坏程度，也就是说这个软件缺陷的存在将对这个软件的功能和性能产生怎么样的影响。

一般来说，软件的严重程度分为五个等级：

第一个等级：致命的软件缺陷(Fatal)

造成系统或应用程序崩溃、死机、系统挂起，或造成数据丢失，主要功能完全丧失，导致本模块以及相关模块异常等问题。如代码错误，死循环，数据库发生死锁、与数据库连接错误或数据通讯错误，未考虑异常操作，功能错误等。
第二个等级：严重错误的软件缺陷（critical）

严重错误的软件缺陷（critical）：系统的主要功能部分丧失、数据不能保存，系统的次要功能完全丧失。问题局限在本模块，导致模块功能失效或异常退出。如致命的错误声明，程序接口错误，数据库的表、业务规则、缺省值未加完整性等约束条件。
第三个等级：一般错误的软件缺陷（major）

一般错误的软件缺陷（major）：次要功能没有完全实现但不影响使用。如：提示信息不太准确，或用户界面差，操作时间长，模块功能部分失效等，打印内容、格式错误，删除操作未给出提示，数据库表中有过多的空字段等。
第四个等级：较小错误的软件缺陷（Minor）

较小错误的软件缺陷（Minor），使操作者不方便或遇到麻烦，但它不影响功能性的操作和执行，如错别字、界面不规范（字体大小不统一，文字排列不整齐，可输入区域和只读区域没有明显的区分标志），辅助说明描述不清楚。
第五个等级：建议问题的软件缺陷（Enhancemental）

建议问题的软件缺陷（Enhancemental）：由问题提出人对测试对象的改进意见或测试人员提出的建议、质疑。

属性5、缺陷的优先级（Priority）

站在开发/项目的角度，综合权衡修改bug的时间、成本、技术和风险，决定bug修改的先后顺序。

优先级每个公司都有自己的标准，例如某公司的标准为：

P0：必须当天修改，8小时内修改；（优先级最高的）

P1：1~2内修改；

P2：2~4天内；

P3：一周内；

P4：发布周期内或者不修改。

属性6、缺陷的类型

1、质量特性的角度

（1）功能；（2）性能；（3）安全性；（4）易用性；（5）可靠性。

2、功能性角度

（1）错误（Error）；（2）遗漏（Missing）；（3）多余的（Extra）；（4）可优化（Improvement /Enhancement /suggestion）

3、缺陷产生的原因：

（1）需求不清晰，导致设计目标偏离客户端需求，从而引起功能或产品特征上的缺陷；

（2）对程序逻辑路径或数据范围的边界考虑不够周全，漏掉某些边界条件，造成容量或边界错误；

（3）新技术的应用，可能涉及技术或系统兼容的问题，事先没有考虑到；

（4）可能由于不支持字符集，而导致的乱码。

等等的一些原因。

属性7、缺陷所属版本

在软件开发测试的过程中，版本的管理是非常重要的，也就属于配置管理的范畴，测试人员开始测试的时候肯定从配置库里面提取最新的版本；

比如说1.0版本，那么测试完成之后，把问题提交给开发人员，开发人员对1.0版本的源代码进行修改，那么这个修改完之后的版本肯定是1.0的下一个版本，也就是1.1版本，修改完之后测试人员要进行回归测试，这个时候测试人员进行回归测试的版本一定是最新版本，即1.1版本。
细分的话，缺陷所属版本还应该有三个属性：（1）发现缺陷的版本；（2）修改bug的版本；（3）回归测试的版本。

所以说，只有缺陷所属版本在开发过程中规定明确落实下来，我们的产品质量才能有保证，不会造成开发和测试的混乱。

属性8、缺陷修改日期

最后一个缺陷的属性是缺陷修改日期，是主要对开发人员进行考核的参数，比如测试人员在3月份提交了一个测试报告单，开发人员在12月份才修改这个问题，由此可见，开发人员修改这个问题的响应时间太长。所以缺陷修改日期往往可以作为绩效考核或者其他的一些数据统计的基础。