报告所发现的软件缺陷

《报告所发现的软件缺陷》由会员分享，可在线阅读，更多相关《报告所发现的软件缺陷（36页珍藏版）》请在金锄头文库上搜索。

1、软件测试方法和技术软件测试方法和技术 报告所发现的软件缺陷报告所发现的软件缺陷 报告所发现的软件缺陷1 软件缺陷的描述 1.1软件缺陷的基本描述1.2 软件缺陷属性 2 软件缺陷相关的信息 2.1 软件缺陷的图片、记录信息 2.2 分离和再现软件缺陷 3 软件缺陷的处理和跟踪 3.1 软件缺陷生命周期 3.2 软件缺陷处理技巧 3.3 软件缺陷跟踪系统 3.4缺陷跟踪的方法和图表 软件缺陷的描述软件缺陷的描述 软件缺陷指的是系统或系统部件中那些导致系统或部件不能实现其功能的缺陷。如果在执行中遇到一个缺陷，可能引起系统的失效。那么准确有效的定义和描述软件缺陷，可以使软件缺陷得以快速修复，节约了软

2、件测试项目的成本和资源，提高产品质量。软件缺陷是什么？软件缺陷的基本描述软件缺陷的基本描述 软件缺陷的描述是软件缺陷报告中测试人员对问题的陈述的一部分并且是软件缺陷报告的基础部分。同时，软件缺陷的描述也是测试人员就一个软件问题与开发小组交流的最初且最好的机会。一个好的描述，需要使用简单的、准确的、专业的语言来抓住缺陷的本质。以下是软件缺陷的有效描述规则：q单一准确q可以再现q完整统一q短小简练q特定条件q补充完善q不做评价软件缺陷软件缺陷标识和类型标识和类型 软件缺陷属性包括缺陷标识、缺陷类型、缺陷严重程度、缺陷产生可能性、缺陷优先级、缺陷状态、缺陷起源、缺陷来源、缺陷原因。q缺陷标识：是标记

3、某个缺陷的唯一的表示，可以使用数字序号表示。q缺陷类型：是根据缺陷的自然属性划分缺陷种类。见软件缺陷类型列表： 缺陷类型缺陷类型 描述描述 功能 影响了各种系统功能、逻辑的缺陷 用户界面 影响了用户界面、人机交互特性，包括屏幕格式、用户输入灵活性、结果输出格式等方面的缺陷 文档 影响发布和维护，包括注释，用户手册，设计文档 软件包 由于软件配置库、变更管理或版本控制引起的错误 性能 不满足系统可测量的属性值，如执行时间，事务处理速率等。 系统/模块接口 与其他组件、模块或设备驱动程序、调用参数、控制块或参数列表等不匹配、冲突。 软件缺陷软件缺陷缺陷严重程度缺陷严重程度q缺陷严重程度：是指因缺陷

4、引起的故障对软件产品的影响程度，所谓“严重性”我指的是在测试条件下，一个错误在系统中的绝对影响。见软件缺陷严重等级列表： 缺陷严重等级缺陷严重等级 描述描述 致命 (Fatal) 系统任何一个主要功能完全丧失、用户数据受到破坏、系统崩溃、悬挂、死机，或者危及人身安全 严重 (Critical) 系统的主要功能部分丧失、数据不能保存，系统所提供的功能或服务受到明显的影响 一般 (Major) 系统的部分功能没有完全实现，但不影响用户的正常使用，例如：提示信息不太准确；或用户界面差、操作时间长等一些问题。 较小 (Minor) 使操作者不方便或遇到麻烦，但它不影响功能的操作和执行，如个别的不影响产

5、品理解的错别字、文字排列不整齐等一些小问题。 软件缺陷软件缺陷缺陷产生的可能性和优先级缺陷产生的可能性和优先级q缺陷产生的可能性：指缺陷在产品中发生的可能性，通常可以用频率来表示。q缺陷优先级：指缺陷必须被修复的紧急程度。“优先级”的衡量抓住了在严重性中没有考虑的重要程度因素。 缺陷缺陷产生可能性产生可能性 描述描述 总是 (Always) 总是产生这个软件缺陷，其产生的频率是100% 通常 (Often) 按照测试用例，通常情况下会产生这个软件缺陷，其产生的频率大概是80-90% 有时 (Occasionally) 按照测试用例，有的时候产生这个软件缺陷，其产生的频率大概是30-50% 很少

6、 (rarely) 按照测试用例，很少产生这个软件缺陷，其产生的频率大概是1-5% 缺陷优先级缺陷优先级描述描述立即解决(P1级)缺陷导致系统几乎不能使用或测试不能继续，需立即修复高优先级(P2级）缺陷严重，影响测试，需要优先考虑正常排队(P3级）缺陷需要正常排队等待修复低优先级(P4级）缺陷可以在开发人员有时间的时候被纠正。软件缺陷软件缺陷缺陷缺陷状态状态 q缺陷状态：指缺陷通过一个跟踪修复过程的进展情况，也就是在软件生命周期中的状态基本定义，如软件缺陷状态列表所示: 缺陷状态缺陷状态 描述描述 激活或打开（Active or Open） 问题还没有解决，存在源代码中，确认“提交的缺陷”，等

7、待处理，如新报的缺陷。 已修正或修复(Fixed or Resolved) 已被开发人员检查、修复过的缺陷，通过单元测试，认为已解决但还没有被测试人员验证 关闭或非激活(Closed or Inactive) 测试人员验证后，确认缺陷不存在之后的状态。 重新打开(Reopen) 测试人员验证后，还依然存在的缺陷，等待开发人员进一步修复 推迟(Deferred) 这个软件缺陷可以在下一个版本中解决 保留(on hold) 由于技术原因或第三者软件的缺陷，开发人员不能修复的缺陷 不能重现(Cannotduplicate) 开发不能复现这个软件缺陷，需要测试人员检查缺陷复现的步骤。 需要更多信息(N

8、eedmoreinfor) 开发能复现这个软件缺陷，但开发人员需要一些信息，例如：缺陷的日志文件，图片等。 重复（Duplicate） 这个软件缺陷已经被其他的软件测试人员发现。 不是缺陷（Notabug） 这个问题不是软件缺陷 需要修改软件规格说明书（Spec modified） 由于软件规格说明书对软件设计的要求，软件开发人员无法修复这个软件缺陷，必须要修改软件规格说明书。 软件缺陷缺陷起源和来源软件缺陷缺陷起源和来源q缺陷起源：缺陷引起的故障或事件第一次被检测到的阶段，如软件缺陷起源列表所示。 q缺陷来源：指缺陷所在的地方，如文档、代码等，如软件缺陷来源列表所示。 缺陷来源缺陷来源 描述

9、描述 需求说明书 需求说明书的错误、或不清楚引起的问题 设计文档 设计文档描述不准确、和需求说明书不一致的问题 系统集成接口 系统各模块参数不匹配、开发组之间缺乏协调引起的缺陷 数据流(库) 由于数据字典、数据库中的错误引起的缺陷 程序代码 纯粹在编码中的问题所引起的缺陷 缺陷起源缺陷起源 描述描述 需求 在需求阶段发现的缺陷 构架 在系统构架设计阶段发现的缺陷 设计在程序设计阶段发现的缺陷编码在编码阶段发现的缺陷测试在测试阶段发现的缺陷用户在用户使用阶段发现的缺陷软件缺陷缺陷根源软件缺陷缺陷根源q缺陷根源：指造成上述错误的根本因素，以寻求软件开发流程的改进、管理水平的提高，如软件缺陷软件缺陷

10、根根源源列表列表所示。缺陷根源缺陷根源 描述描述 测试策略 错误的测试范围，误解了测试目标，超越测试能力等 过程，工具和方法 无效的需求收集过程，过时的风险管理过程，不适用的项目管理方法，没有估算规程，无效的变更控制过程等 团队/人 项目团队职责交叉，缺乏培训,没有经验的项目团队，缺乏士气和动机不纯等 缺乏组织和通讯 缺乏用户参与，职责不明确，管理失败等 硬件 硬件配置不对、缺乏，或处理器缺陷导致算术精度丢失，内存溢出等 软件 软件设置不对、缺乏，或操作系统错误导致无法释放资源，工具软件的错误，编译器的错误，2000 千年虫问题等。 工作环境 组织机构调整，预算改变，工作环境恶劣，如噪音过大。

11、 软件缺陷相关的信息软件缺陷相关的信息 软件缺陷相关的信息包括软件缺陷的图片、记录信息和如何再现和分离软件缺陷；对于某一个软件缺陷报告，测试人员应该给予相关的信息，例如捕捉到软件缺陷日志文件和图片，保证开发人员和其他的测试人员可以分离和重现它。q软件缺陷的图片、记录信息 q记录软件缺陷的相关图片 一些涉及用户界面(User Interface)的软件缺陷可能很难用文字清楚地描述，因此软件测试人员通过附上图片比较直观地表示缺陷发生在产品界面什么位置、有什么问题等。 q使用Soft-ICE记录软件缺陷信息 Soft-ICE是 Compuware公司的产品NuMega DriverStudio中一个

12、代表性的工具，用于跟踪软件运行时的变量、内存等状态，而且可以捕捉系统崩溃时的状态。使用它可以记录产品发生缺陷的地方，同时生成日志文件。 如何使用如何使用Soft-ICE Soft-ICE 当出现软件系统崩溃的缺陷时，测试人员需要在软件缺陷报告上附上日志文件，便于开发人员即时修复软件缺陷。q 当遭遇软件崩溃时候，如何使用Soft-ICE？在开始测试之前，已经安装了Soft-ICE并启动了“faults on”的命令。当软件发生崩溃现象时，可以使用下面命令去捕捉必要的信息：qstackstack qu eip-80u eip-80 如果数据窗口是开启的状态，可以输入”wdwd”来关闭该窗口，然后再

13、输入 “dd dd esp-20esp-20”命令。stackstack 、dd dd esp-20esp-20是为了标注跟踪信息。q通过输入x，退出 Soft-ICE的窗口；如果还是无法退出Soft-ICE，需要输入faults off，然后输入x。 q打开Soft-ICE应用程序，立即保存日志文件。一旦再次打开Soft-ICE，请输入faults on 分离和再现软件缺陷分离和再现软件缺陷 为了有效地再现软件缺陷，除了按照软件缺陷的有效描述规则来描述软件缺陷，还要遵循软件缺陷分离和再现的方法和具有较高的技巧性，虽然有时少数几个缺陷很难再现、或者根本无法再现。以下就介绍如何分离和再现缺陷的一

14、些常用方法和技巧。q 确保所有的步骤都被记录。q 特定条件和时间。q 压力和负荷、内存和数据溢出相关的边界条件。q考虑资源依赖性包括内存、网络和硬件共享的相互作用等。 q不能忽视硬件。与软件不同，硬件不按预定方式工作。 开发人员有时可以根据相对简单的错误信息就能找出问题所在。因为开发人员熟悉代码，因此看到症状、测试用例步骤和分离问题的过程时，可能得到查找软件缺陷的线索。一个软件缺陷的分离和再现问题有时需要小组的共同努力。如果软件测试人员尽最大努力分离软件缺陷，也无法表达准确的再现步骤，那么仍然需要记录和报告软件缺陷。 分离和调试软件缺陷之间的区别分离和调试软件缺陷之间的区别 讨论分离和调试软件

15、缺陷之间的区别，是为了划清测试人员与开发人员的责任，增加界限的清晰度与测试资源的控制能力。面对一个软件缺陷时，开发人员或测试人员为了修复它，会提出一系列分步骤地、处理缺陷的疑问：q再现软件缺陷现象所需的最少步骤有哪些？这些步骤成功再现的可能性多大？ q软件缺陷是否成立存在？换句话说，测试结果是否可能起源于测试因素或者测试人员自身的错误，还是影响顾客需求的、系统真正的故障？q哪些外部因素产生软件缺陷？ q哪些内部因素，是代码、网络、还是环境引起的软件缺陷？ q怎样才能在不产生新的缺陷的条件下使这个软件缺陷得到修复？ q这种修复是否经过调试，单元是否经过测试？ q问题解决了吗？它是否通过了确认和回

16、归测试，确定系统的其余部分仍工作正常？ 软件缺陷的处理和跟踪软件缺陷的处理和跟踪 软件缺陷跟踪管理是测试工作的一个重要部分，测试的目的是为了尽早发现软件系统中的缺陷，而对软件缺陷进行跟踪管理的目的是确保每个被发现的缺陷都能够及时得到处理。软件测试过程简单说就是围绕缺陷进行的，对缺陷的跟踪管理，一般而言需要达到以下目标：q 确保每个被发现的缺陷都能够被解决，“解决”的意思不一定是被修正，也可能是其他处理方式（例如，延迟到下一个版本中修正或者由于技术原因不能被修正），总之，对每个被发现的BUG的处理方式必须能够在开发组织中达到一致；q 收集缺陷数据并根据缺陷趋势曲线识别测试处于测试过程中的哪个阶段

17、； q 决定测试过程是否结束，通过缺陷趋势曲线来确定测试过程是否结束是常用并且较为有效的一种方式。q 收集缺陷数据并在其上进行数据分析，作为组织过程改进的财富。 简单、优化的简单、优化的软件缺陷生命周期软件缺陷生命周期 生命周期的概念是一个物种从诞生到消亡经历了不同的生命阶段，那么软件缺陷生命周期应该指的是一个软件缺陷被发现、报告到这个缺陷被修复、验证直至最后关闭的完整过程。在整个软件缺陷生命周期中，通常是以改变软件缺陷的状态来体现不同的生命阶段。因此，对于一个软件测试人员来讲，需要关注软件缺陷在生命周期中的状态的变化，来跟踪项目进度和软件质量。一个简单、优化的软件缺陷生命周期：q发现-打开：

18、测试人员找到软件缺陷并将软件缺陷提交给开发人员。 q打开-修复：开发人员再现、修复缺陷，然后提交给测试人员去验证。 q修复-关闭：测试人员验证修复过的软件，关闭已不存在的缺陷。 发现打开修复关闭复杂的复杂的软件缺陷生命周期软件缺陷生命周期在实际工作中，软件缺陷的生命周期不可能像如上那么简单，需要考虑其它各种情况，给出了一个复杂的软件缺陷生命周期的例子，如图所示： 综上所述，软件缺陷在生命周期中经历了数次的审阅和状态变化，最终测试人员关闭软件缺陷来结束软件缺陷的生命周期。软件缺陷生命周期中的不同阶段是测试人员、开发人员和管理人员一起参与、协同测试的过程。软件缺陷一旦发现，便进入测试人员、开发人员

19、、管理人员的严密监控之中，直至软件缺陷生命周期终结，这样即可保证在较短的时间内高效率地关闭所有的缺陷，缩短软件测试的进程，提高软件质量，同时减少开发、测试和维护成本。软件缺陷生命周期综述软件缺陷生命周期综述软件缺陷处理技巧软件缺陷处理技巧 管理员、测试人员和开发人员需要掌握在软件缺陷生命周期的不同阶段处理软件缺陷技巧，从而尽快处理软件缺陷，缩短软件缺陷生命周期。以下列出处理软件缺陷基本技巧： q审阅。当测试人员在缺陷跟踪数据库中输入了一个新的缺陷时，测试员应该提交它，以便在它能够起作用之前进行审阅。这种审阅可以由测试管理员、项目管理员或其他人来进行，主要审阅缺陷报告的质量水平；q拒绝。如果审阅

20、者决定需要对一份缺陷报告进行重大修改，例如需要添加更多的信息或者需要改变缺陷的严重等级，应该和测试人员一起讨论，由测试人员纠正缺陷报告，然后再次提交； q完善。如果测试员已经完整地描述了问题的特征并将其分离，那么审查者就会肯定这个报告； q分配。当开发组接受完整描述特征并被分离的问题时，测试员会将它分配给适当的开发人员，如果不知道具体开发人员，应分配给项目开发组长，由开发组长再分配给对应的开发人员； 软件缺陷处理技巧软件缺陷处理技巧q测试。一旦开发人员修复一个缺陷，它就将进入测试阶段。缺陷的修复需要得到测试人员的验证，同时还要进行回归测试，检查这个缺陷的修复是否会引入新的问题； q重新打开。如

21、果这个修复没有通过确认测试，那么测试人员将重新打开这个缺陷报告。重新打开一个缺陷，需要加注释说明，否则会引起“打开-修复”多个来回，造成测试人员和开发人员不必要的矛盾 q关闭。如果修复通过验证测试，那么测试人员将关闭这个缺陷。只有测试人员有关闭缺陷的权限，开发人员没有这个权限。 q暂缓。如果每个人都同意将确实存在的缺陷移到以后处理，应该指定下一个版本号或修改的日期。一旦新的版本开始时，这些暂缓的缺陷应该重新被打开。测试人员、开发人员和管理者只有紧密的合作，掌握软件缺陷处理技巧，在项目不同阶段，及时的审查、处理和跟踪每个软件缺陷，加速软件缺陷状态的变换，提高软件质量，促进项目的发展。软件缺陷跟踪

22、系统软件缺陷跟踪系统 到目前为止所讲述的一切表面上看起来很好，但是运用到实践中还需要软件缺陷跟踪系统，以便描述报告所发现的缺陷，处理软件缺陷属性，跟踪软件缺陷的整个生命周期和生成软件缺陷跟踪图表等。为什么需要建立一套软件缺陷跟踪系统呢？因为它会让我们受益无穷，概括起来有：q软件缺陷跟踪系统拥有软件缺陷跟踪数据库，它不仅有利于软件缺陷的清楚描述，还提供统一的、标准化报告，使所有人的理解一致；q缺陷跟踪数据库允许自动连续的软件缺陷编号，还提供了大量供分析和统计的选项，这是手工方法无法实现的；q基于缺陷跟踪数据库，可快速生成满足各种查询条件的、所必要的缺陷报表、曲线图等，开发小组乃至公司的每一个人都

23、可以随时掌握软件产品质量的整体状况、或测试/开发的进度；q缺陷跟踪数据库提供了软件缺陷属性并允许开发小组根据对项目的相对和绝对重要性来修复缺陷；软件缺陷跟踪系统软件缺陷跟踪系统q可以在软件缺陷的生命期中管理缺陷，从最初的报告到最后的解决。确保了每一个缺陷不会被忽略，同时，它还可以使注意力保持在那些必须尽快修复的重要缺陷上；q当缺陷在它的生命周期中变化时，开发人员，测试人员以及管理人员将熟悉新的软件缺陷信息。一个设计良好的软件缺陷跟踪系统可以获取历史记录，并在检查缺陷的状态时参考历史记录； q在软件缺陷跟踪数据库中关闭每一份缺陷报告，它都可以被记录下来。当产品送出去时，每一份未关闭的缺陷报告都提

24、供了预先警告的有效技术支持，并且证明测试人员找到特殊领域突然出现的事件中的软件缺陷。接下来就介绍一下软件缺陷跟踪系统(它遵守IEEE829-1983标准)。 软件缺陷报告软件缺陷报告 任何一个缺陷跟踪系统的核心都是“软件缺陷报告”，一份软件缺陷报告详细信息如表：软件缺陷项目列表软件缺陷项目列表分类分类 项目项目 描述描述 可跟踪信息 缺陷ID 唯一的、自动产生的缺陷ID，用于识别、跟踪、查询 软件缺陷基本信息 缺陷状态 可分为“打开或激活的”、“已修正”、“关闭”等 缺陷标题 描述缺陷的最主要信息 缺陷的严重程度 一般分为“致命”、“严重”、“一般”、“较小”等四种程度 缺陷的优先级 描述处理

25、缺陷的紧急程度， 1是优先级最高的等级，2是正常的，3是优先级最低的 缺陷的产生频率 描述缺陷发生的可能性1%-100% 缺陷提交人 缺陷提交人的名字（会和邮件地址联系起来），一般就是发现缺陷的测试人员或其他人员 缺陷提交时间 缺陷提交的时间 软件缺陷报告软件缺陷报告 软件缺陷基本信息 缺陷所属项目/模块 缺陷所属的项目和模块，最好能较精确的定位至模块 缺陷指定解决人 估计修复这个缺陷的开发人员，在缺陷状态下由开发组长指定相关的开发人员；也会自动和该开发人员的邮件地址联系起来，并自动发出邮件 缺陷指定解决时间 开发管理员指定的开发人员修改此缺陷的时间 缺陷验证人 验证缺陷是否真正被修复的测试人

26、员；也会和邮件地址联系起来 缺陷验证结果描述 对验证结果的描述（通过、不通过） 缺陷验证时间 对缺陷验证的时间 缺陷的详细描述 步骤 对缺陷的操作过程，按照步骤，一步一步地描述 期望的结果 按照设计规格说明书或用户需求，在上述步骤之后，所期望的结果，即正确的结果 实际发生的结果 程序或系统实际发生的结果，即错误的结果 测试环境说明测试环境 对测试环境描述，包括操作系统、浏览器、网络带宽、通讯协议等 必要的附件图片、Log文件 对于某些文字很难表达清楚的缺陷，使用图片等附件是必要的；对于软件崩溃现象，需要使用Soft_ICE工具去捕捉日志文件作为附件提供给开发人员。 软件缺陷的详细描述软件缺陷的

27、详细描述 软件缺陷的详细描述，如上所述，由三部分组成：操作/重现步骤、期望结果、实际结果，有必要再做进一步的讨论：q“步骤”提供了如何重复当前缺陷的准确描述，应简明而完备、清楚而准确。这些信息对开发人员是关键的，视为修复缺陷的向导，开发人员有时抱怨糟糕的缺陷报告，往往集中在这里； q“期望结果”与测试用例标准或设计规格说明书或用户需求等一致，达到软件预期的功能。测试人员站在用户的角度要对它进行描述，它提供了验证缺陷的依据。 q“实际结果”测试人员收集的结果和信息，以确认缺陷确实是一个问题，并标识那些影响到缺陷表现的要素。 缺陷报告的示例缺陷报告的示例 一份优秀的缺陷报告记录下最少的重复步骤，不

28、仅包括了期望结果，实际结果和必要的附件，还提供必要的数据、测试环境或条件，以及简单的分析。优秀的缺陷报告重现步骤 :a)打开一个编辑文字的软件并且创建一个新的文档（这个文件可以录入文字）b)在这个文件里随意录入一两行文字 c)选中一两行文字，通过选择Font 菜单然后选择Arial字体格式 d)一两行文字变成了无意义的乱字符 期望结果：当用户选择已录入的文字并改变文字格式的时候，文本应该显示正确的文字格式不会出现乱字符显示。实际结果:它是字体格式的问题，如果改变文字格式成Arial之前，你保存文件，缺陷不会出现。缺陷仅仅发生在Windows98并且改变文字格式成其它的字体格式，文字是显示正常的

29、。 见所附的图片 缺陷报告的示例缺陷报告的示例 而一份含糊而不完整的缺陷报告，缺少重建步骤，并且没有期望结果、实际结果和必要的图片，如下描述。 含糊而不完整的缺陷报告 重现步骤：打开一个编辑文字的软件. 录入一些文字 选择Arial字体格式 文字变成了乱字符 期望结果： 实际结果： 一份散漫的缺陷报告（无关的重建步骤，以及对开发人员理解这个错误毫无帮助的结果信息）如下描述：缺陷报告的示例缺陷报告的示例散漫的缺陷报告重现步骤：在Window98上打开一个编辑文字的软件并且编辑存在文件 文件字体显示正常 我添加了图片，这些图片显示正常 在此之后，我创建了一个新的文档 在这个文档中我随意录入了大量的

30、文字 在我录入这些文字之后，选择几行文字.并且通过选择Font 菜单然后选择Arial字体格式改变文字的字体。 有三次我重现了这个缺陷 我在Solaris操作系统运行这些步骤，没有任何问题。 我在Mac操作系统运行这些步骤，没有任何问题。期望结果：当用户选择已录入的文字并改变文字格式的时候，文本应该显示正确的文字格式不会出现乱字符显示。 实际结果：我试着选择少量的不同的字体格式，但是只有Arial字体格式有软件缺陷，不论如何，它可能会出现在我没有测试的其它的字体格式 缺陷跟踪数据库信息缺陷跟踪数据库信息 项目中使用Microsoft Excel 电子表格或Word 文档来记录和跟踪软件缺陷，但

31、一般只限于最后的分析报告、文档的打印。为了灵活地存储、操作、搜索、分析以及报告大量数据，我们需要建一个数据库。 基于已经讨论过的内容，就比较容易建立一个软件缺陷跟踪数据库，可以使用Microsoft Access或SQL server，也可以使用Oracle、DB2 等关系数据库管理系统。一个缺陷跟踪数据库的基本表，将要包括多达几十项的数据项，如bug的ID号、标题(Title)、状态、严重程度、优先级、重现步骤、期望结果、实际结果、项目名称、模块、报告作者、日期等等。 所有缺陷的数据不仅要存储在共享数据库中，还要有相关的数据连接，如产品特性数据库、产品配置数据库、测试用例数据库等的集成。因为

32、某个缺陷是和某个产品特性、某个软件版本、某个测试用例等相关联的，有必要建立起这些关联。同时为了提高缺陷处理的效率，还有和邮件服务器集成，通过邮件传递，测试和开发人员随时可以获得由系统自动发出有关缺陷状态变化的邮件。 缺陷跟踪的方法和图表缺陷跟踪的方法和图表 缺陷数据是生成各种各样测试分析、质量控制图表的基础，从这些缺陷分析图表中可以清楚地看到缺陷的修复过程，分析缺陷发生根本原因，跟踪管理缺陷的效率。1.1.软件项目如何发展：软件缺陷打开软件项目如何发展：软件缺陷打开/ /关闭图表关闭图表 打开/关闭图表是最基本的缺陷分析图表，它能提供许多有关软件缺陷状态、项目进度、产品质量、开发人员的工作等信

33、息：1)项目目前的质量情况取决于累积打开曲线和累积关闭曲线的趋势。 2)项目目前的进度取决于累积关闭曲线和累积打开曲线起点的时间差。 3)开发人员已经完成修复软件缺陷了吗？累积关闭曲线是否快速的上升。4)测试人员是否积极的去验证软件缺陷也就是说：是否累积关闭曲线紧跟在累积打开曲线后面。 管理者可以知道项目在哪一个时间点出现问题，同时协调开发和测试之间的关系，积极推动项目的发展，从而达到项目里程碑的要求，提高项目发布的质量。以下将通过打开/关闭的累积缺陷图分析项目的进展情况。 缺陷跟踪的方法和图表缺陷跟踪的方法和图表打开/关闭的累积缺陷图n当累积的打开曲线（如图的顶部曲线）在一条渐近线限制下稳定

34、下来，通常就认为该测试完成了。 n修正日期在关闭日期之前，可以看到关闭曲线大约落后了一个星期。这种滞后起源于将修复的软件缺陷引入到产品并将该产品发送到测试小组，以及测试配置和回归测试所引起的延迟。这种延迟集中到测试的最后一天。 n在当前测试阶段找到软件缺陷的能力在减弱。发现软件缺陷的极限在8月23号左右；接下来系统测试第二个周期发现少数几个软件缺陷，在最后的周期中没有发现缺陷。n开发人员完成了修复软件缺陷了吗？在测试和修复的过程中，发现这两条曲线在不断的收敛，当这两条曲线收敛成一个点时，开发人员基本上完成了修复软件缺陷的任务了。并且注意到关闭曲线紧跟在打开曲线的后面，这表明项目小组正在快速地推

35、进问题的解决。 n当测试人员从一个测试阶段到另一个测试阶段时，发现累积打开曲线有一个突起，这样的凸起是非常可怕的，说明开发人员修复软件缺陷引入了新的缺陷或者有些软件缺陷被遗漏到下一个阶段发现了。项目管理人员需要召开紧急会议分析当前项目情况，找到解决办法。 缺陷跟踪的方法和图表缺陷跟踪的方法和图表软件缺陷为何发生：根本原因图表软件缺陷为何发生：根本原因图表 分析软件缺陷根本原因不仅有助于测试人员决定哪些功能领域需要增强测试，而且可以使开发人员的注意力集中到那些引起最严重，最频繁的领域。如下图显示了软件缺陷产生的3个主要来源区域用户界面显示，逻辑和规格说明书占据发现软件缺陷总数的75%。如果从测试

36、风险角度看，这些区域可能是隐藏缺陷比较多的地方，需要测试更细、更深些。从开发角度来说，这些是代码质量提高的主要区域，假定某个产品前后发现10000个Bug，代码在这三个区域减少10个百分点，则总Bug数能减少750(7.5%)，代码质量改善效果就很显著。 开发人员如何响应：关闭软件缺陷周开发人员如何响应：关闭软件缺陷周期图表期图表 关闭软件缺陷周期图表开发人员如何响应：关闭软件缺陷周开发人员如何响应：关闭软件缺陷周期图表期图表 “关闭周期”有一个简单直观的意义：关闭周期将开发人员对软件缺陷的响应量化到软件缺陷报告中，一个稳定的关闭周期图表是显示了从一天到另一天相对较少的变化，这是一个理想的例子。如果软件缺陷报告推迟了它们打开的日期，这就将日常关闭曲线拉向0，此外，一个可接受的日常关闭曲线是不显示朝向任何边界的明显倾斜。一个稳定而接受的关闭周期图表指出了一个理解良好，运行平稳的缺陷管理过程。理想情况是一个向下或水平趋向的关闭软件周期曲线。如图所示关闭软件缺陷周期图表中的关闭周期是稳定而可接受的。缺陷一般大约一个半星期内得到修正，这是一个良好的速度。Q & A