软件缺陷

好久没有温习软件缺陷的内容了，老师在PPT说过，由于过久没有复习了印象很是模糊，特意翻开老师讲过的课件看了一遍，现在我把内容大致的放在博客上，希望能够对大家有所帮助。

 

 

软件缺陷是什么？

 软件缺陷指的是系统或系统部件中那些导致系统或部件不能实现其功能的缺陷。如果在执行中遇到一个缺陷，可能引起系统的失效。那么准确有效的定义和描述软件缺陷，可以使软件缺陷得以快速修复，节约了软件测试项目的成本和资源，提高产品质量。

软件缺陷的基本描述

 软件缺陷的描述是软件缺陷报告中测试人员对问题的陈述的一部分并且是软件缺陷报告的基础部分。同时，软件缺陷的描述也是测试人员就一个软件问题与开发小组交流且最好的机会。一个好的描述，需要使用简单的、准确的、专业的语言来抓住缺陷的本质。

 以下是软件缺陷的有效的描述规则：

 

 软件缺陷标识和类型

软件缺陷属性包括缺陷标识、缺陷类型、缺陷严重程度、缺陷产生可能行、缺陷优先级、缺陷状态、缺陷起源、缺陷来源、缺陷原因。

缺陷标识：是标记某个缺陷的唯一表示，可以使用数字序号表示。

缺陷类型：是根据缺陷的自然属性划分缺陷种类。

 

常见软件类型列表：

 

软件缺陷缺陷严重程度

缺陷严重程度：是指因缺陷引起的故障对软件产品的影响程度，所有“严重性”我指的是在测试条件下，一个错误系统中的绝对影响。常见软件缺陷严重等级列表：　

　　　

 

 

软件缺陷缺陷产生的可能性和优先级

缺陷产生的可能性：指缺陷在产品中发生的可能性，通常可以用频率表示。

 

缺陷优先级：指缺陷必须被修复的紧急程度。“优先级”的衡量抓住了在严重性中没有考虑的重要程度因素。　　　

软件缺陷缺陷状态

缺陷状态：指陷通过一个跟踪修复过程的进展情况，也就是在软件生命周期中的状态基本定义，如软件缺陷列表所示：

 

简单、优化的软件缺陷生命周期

生命周期的概念是一个物种从诞生到消亡经历了不同的生命阶段，那么软件缺陷生命周期应该指的是一个软件缺陷被发现、报告到这个缺陷被修复、验证直至最后关闭的完整过程。在整个软件缺陷生命周期中，通常是以改变软件缺陷的状态来体现不同的生命周期的状态的变化，来跟踪项目进展的软件质量。

一个简单、优化的软件缺陷生命周期：

 

发现-打开：测试人员找到软件缺陷并将软件缺陷提交给开发人员。

打开-修复：开发人员再现、修复缺陷、 然后提交给测试人员去验证。

修复-关闭：测试人员验证修复过的软件，关闭已不存在的缺陷。

 

 

软件缺陷处理技巧

管理员、测试人员和开发人员需要掌握在软件缺陷生命周期的不同阶段处理软件安缺陷技巧，从而尽快处理软件缺陷，缩短软件缺陷生命周期，

以下列出处理软件缺陷基本技巧：

 

审阅：当测试人员在缺陷跟踪数据库中输入了一个新的缺陷时，测试员应该提交它，以便在它能够起作用之前进行审阅。这种审阅可以由测试管理员、项目管理员或其他人来进行，主要审阅缺陷报告的质量水平；

拒绝：如果审阅者决定需要对一份缺陷报告进行重大修改，例如需要添加更多的信息或者需要改变缺陷的严重等级，应该和测试人员一起讨论，由测试人员纠正缺陷报告，然后再次提交；

完善：如果测试员已经完整地描述了问题的特征并将其分离，那么审阅者就会肯定这个报告。

分配：当开发组接受完整描述特征并被分离的问题时，测试员会将他分配给适当的开发人员，如果不知道具体开发人员，应分配给项目开发组长，由开发组长再分配给对应的开发人员。

 

　　

 

测试：一旦开发人员修复一个缺陷，它就将进入测试阶段。缺陷的修复需要得到测试人员的验证，同时还要进行回归测试，检查这个缺陷的修复是否会引入新的问题；

重新打开：如果这个修复没有通过确认测试，那么测试人员将重新打开这个缺陷报告。重新打开一个缺陷报告，需要加注释说明，否则会引起“打开-修复”多个来回，造成测试人员和开发人员不必要的矛盾

 关闭：如果修复通过验证测试，那么测试人员将关闭这个缺陷。只有测试人员有关闭缺陷的权限，开发人员没有这个权限。

暂缓：如果每个人都同意将确定存在的缺陷移到以后处理，应该指定下一个版本号或修改的日期。一旦心的版本开始时，这些暂缓的缺陷应该重新被打开。

测试人员、开发人员和管理者只有紧密的合作，掌握软件缺陷处理技巧，在项目不同阶段，及时的审查、处理和跟踪每个软件缺陷，加速软件缺陷状态的变换，提高软件质量，促进项目的发展。

 

软件缺陷跟踪系统

 

到目前为止所讲述的一切表面上看起来很好，但是运用到实践中还需要软件缺陷跟踪系统，以便描述报告所发现的缺陷，处理软件缺陷属性，跟踪软件缺陷的整个生命周期和生成软件缺陷跟踪图表等。为什么需要建立一套软件缺陷跟踪系统呢？因为它会让我们受益无穷，概括起来有：

一、软件缺陷跟踪系统拥有软件缺陷跟踪数据库，它不仅有利于软件缺陷的清楚描述，还提供统一的、标准化报告，使所有人的理解一致；

二、缺陷跟踪数据库允许自动连续的软件缺陷编号，还提供了大量供分析和统计的选项，这是手工方法无法实现的；

三、基于缺陷跟踪数据库，可快速生成满足各种查询条件、所必要的缺陷报表、曲线图等，开发小组乃至公司的每一个人都可以随时掌握软件产品质量的整体情况、或测试/开发的进度；

四、缺陷跟踪数据库提供了软件缺陷属性并允许开发小组根据对项目的相对和绝对重要性来修复缺陷；

五、可以在软件缺陷的生命期中管理缺陷，从最初的报告到最后的解决。确保了每一个缺陷不会被忽略，同时，它还可以使注意力保持在那些必须尽快修复的重要缺陷上；

六、当缺陷在它的生命周期中变化时，开发人员，测试人员以及管理人员将熟悉新的软件缺陷信息。一个设计良好的软件缺陷跟踪系统可以获取历史记录，并在检查缺陷的状态时参考历史记录；

七、在软件缺陷跟踪数据库中关闭每一份缺陷报告，它都可以被记录下来。当产品送出去时，没一份未关闭的缺陷报告都提供了预先警告的有效技术支持，并且证明测试人员找到特殊领域突然出现的事件中的软件缺陷。

 

软件缺陷报告

任何一个缺陷跟踪系统的核心都是“软件缺陷报告”,一份软件缺陷报告详细信息如表：

 

软件缺陷的详细描述

软件缺陷的详细描述，如上所述，由三部分组成：操作/重现步骤、期望结果、实际结果，有必要再做进一步的讨论:

 

“步骤”提供了如何重复当前缺陷的准确描述，应简明而完备、清楚而准确。这些信息对开发人员是关键的，视为修复缺陷的向导，开发人员有时抱怨槽糕的缺陷报告，往往集中在这里；

“期望结果”与测试用例标准或设计规格说明书或用户需求等一致，达到软件预期的功能。测试人员站在用户的角度要对它进行描述，它提供了验证缺陷的依据；

“实际结果” 测试人员收集的结果和信息，以确认缺陷确实是一个问题，并标识那些影响到缺陷表现的要素。

 

 

缺陷报告的示例

一份优秀的缺陷报告记录下最少的重复步骤，不仅包括了期望结果，实际结果和必要的附件，还提供必要数据、测试环境或条件，以及简单的分析。

 

 

而一份含糊而不完整的缺陷报告，缺少重建步骤，并且没有期望结果，实际结果和必要的图片，如下描述。

 

 

一份散漫的缺陷报告（无关的重要步骤，以及对开发人员理解这个错误毫无帮助的结果信息）如下描述

 

 

缺陷报告数据库信息

项目中使用Microsoft Excel 电子表格或Word 文档来记录和跟踪软件缺陷，但一般只限于最后的分析报告、文档的打印。为了灵活地存储、操作、搜索、分析以及报告大量数据，我们需要建一个数据库。

 

基于已经讨论过的内容， 就比较容易建立一个软件缺陷跟踪数据库，可以使用Microsoft Access或SQL server，也可以使用Oracle、DB2等关系数据库管理系统。一个缺陷跟踪数据库的基本表，将要包括多达几十项的数据项，如bug的ID号、标题（Title）、状态、严重程度、优先级、重现步骤、期望结果、实际结果、项目名称、模块、报告作者、日期等

 

所有缺陷的数据库不仅要存储在共享数据库中，还要有相关的数据连接，如产品特性数据库、产品配置数据库、测试用例数据库等的集成。因为某个缺陷是和某个产品特性、某个软件版本、某个测试用例等相关联的，有必要建立起这些关联。同时为了提高缺陷处理的效率，还有和邮件服务器集成，通过邮件传递，测试和开发人员随时可以获得由系统自动发出有关缺陷状态变化的邮件。

 

 

缺陷跟踪的方法和图表

缺陷数据是生成各种各样测试分析、质量控制图表的基础，从这些缺陷分析图表中可以清楚地看到缺陷的修复过程，分析缺陷发生的根本原因，跟踪管理缺陷的效率。

 

1、软件项目如何发展：软件缺陷打开/关闭图表

                              打开/关闭图表是最基本的缺陷分析图表，它能提供许多有关软件缺陷状态、项目进度、产品质量、开发人员的工作等信息： 

 

1）项目目前的质量轻快取决于累计打开曲线和累计关闭曲线的趋势。

 

2）项目目前的进度取决于累积关闭曲线和累积打开曲线起点的时间差。

3）开发人员已经完成修复软件缺陷了吗？累积关闭曲线是否快速的上升。

4）测试人员是否积极的去验证软件缺陷也就是说：是否累积关闭曲线紧跟在累积打开曲线后面。

        管理者可以知道项目在哪一个时间点出现问题，同时协调开发测试之间的关系，积极推动项目的发展，从而达到项目里程碑的要求，提高项目发布的质量。以下将通过打开/关闭的累积缺陷图分析项目的进展情况

 

打开/关闭的累积缺陷图

 

 

 

------当累积的打开曲线（如图的顶部曲线）在一条渐近线限制下稳定下来，通常就认为该测试完成了。

------修正日期在关闭日期之前，可以看到关闭曲线大约落后了一个星期。这种滞后起源于将修复的软件缺陷引入到产品并将该产品发送到测试小组，以及测试配置和回归测试所引起的延迟。这种延迟集中到测试的最后一天。

------在当前测试阶段找到软件缺陷的能力在减弱。发现软件缺陷的极限在8月23号左右；接下来系统测试第二个周期发现少数几个软件缺陷，在最后的周期找你拐没有发现缺陷。

------开发人员完成了修复软件缺陷了吗？在测试和修复过程中，发现这两条曲线在不断的收敛，当这两条曲线收敛成一个点时，开发人员基于完成了修复软件缺陷的任务了。并且注意到关闭曲线紧跟在打开曲线的后面，这标明项目小组正在快速地推进问题的解决。

------当测试人员从一个测试阶段到另一个测试阶段时，发现累积打开曲线有一个突起，这样的凸起是非常可怕的，说明开发人员修复缺陷引入新的缺陷或者有些软件缺陷被遗漏到下一个阶段发现了。项目管理人员需要召开紧急会议分析当前项目情况。找到解决办法。

 

 

 

软件缺陷为何发生：根本原因图表

 

分析软件缺陷根本原因不仅有助于测试人员决定哪些功能领域需要增强测试，而且可以使开发人员的注意力集中到那些引起最严重，最频繁的领域。如下图显示了软件缺陷产生的3个主要来源区域------用户界面显示，逻辑和规格说明书-------占据发现软件缺陷总数的75%。如果从测试风险角度看，这些区域可能隐藏缺陷比较多的地方，需要测试更细、更深些。从开发角度来说，这些是代码质量提高的主要区域，假定某个产品前后发现10000个Bug，代码在这三个区域减少10个百分点，则总Bug数能减少750(7.5%),代码质量改善效果就很显著

 

 

 

 开发人员如何响应：关闭软件缺陷周期图表

关闭软件缺陷周期图标