软件测试方法和技术 - Ch15报告所发现的软件缺陷

《软件测试方法和技术 - Ch15报告所发现的软件缺陷》由会员分享，可在线阅读，更多相关《软件测试方法和技术 - Ch15报告所发现的软件缺陷（33页珍藏版）》请在金锄头文库上搜索。

1、报告所发现的软件缺陷1.软件缺陷的描述 软件缺陷的基本描述软件缺陷属性 2.软件缺陷相关的信息 软件缺陷的图片、记录信息 分离和再现软件缺陷 3.软件缺陷的处理和跟踪 软件缺陷生命周期 软件缺陷处理技巧 软件缺陷跟踪系统 缺陷跟踪的方法和图表1软件缺陷的描述软件缺陷指的是系统或系统部件中那些导致系 统或部件不能实现其功能的缺陷。如果在执行中遇到 一个缺陷，可能引起系统的失效。那么准确有效的定 义和描述软件缺陷，可以使软件缺陷得以快速修复， 节约了软件测试项目的成本和资源，提高产品质量。软件缺陷是什么？2软件缺陷的基本描述 软件缺陷的描述是软件缺陷报告中测试人员对问题的陈述 的一部分并且是软件缺

2、陷报告的基础部分。同时，软件缺陷的 描述也是测试人员就一个软件问题与开发小组交流的最初且最 好的机会。一个好的描述，需要使用简单的、准确的、专业的 语言来抓住缺陷的本质。以下是软件缺陷的有效描述规则： q 单一准确 q 可以再现 q 完整统一 q 短小简练 q 特定条件 q 补充完善 q 不做评价 3软件缺陷标识和类型软件缺陷属性包括缺陷标识、缺陷类型、缺陷严重程度、缺 陷产生可能性、缺陷优先级、缺陷状态、缺陷起源、缺陷来源 、缺陷原因。 q 缺陷标识：是标记某个缺陷的唯一的表示，可以使用数字序号 表示。 q 缺陷类型：是根据缺陷的自然属性划分缺陷种类。见软件缺陷 类型列表：缺陷类类型 描述

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

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

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

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

7、态列表所示:缺陷状态态 描述 激活或打开（Active or Open） 问题还问题还 没有解决，存在源代码码中，确认认“提交 的缺陷”，等待处处理，如新报报的缺陷。 已修正或修复(Fixed or Resolved) 已被开发发人员检查员检查 、修复过过的缺陷，通过单过单 元测试测试，认为认为已解决但还还没有被测试测试人员验员验 证证 关闭闭或非激活(Closed or Inactive) 测试测试人员验证员验证 后，确认认缺陷不存在之后的状 态态。 重新打开(Reopen) 测试测试人员验证员验证 后，还还依然存在的缺陷，等待 开发发人员进员进一步修复 推迟迟(Deferred) 这这个软

8、软件缺陷可以在下一个版本中解决 保留(on hold) 由于技术术原因或第三者软软件的缺陷，开发发人员员 不能修复的缺陷 不能重现现(Cannotduplicate) 开发发不能复现这现这个软软件缺陷，需要测试测试人员员 检查检查缺陷复现现的步骤骤。 需要更多信息(Needmoreinfor) 开发发能复现这现这个软软件缺陷，但开发发人员员需要 一些信息，例如：缺陷的日志文件，图图片等。 重复（Duplicate） 这这个软软件缺陷已经经被其他的软软件测试测试人员发员发 现现。 不是缺陷（Notabug） 这这个问题问题不是软软件缺陷 需要修改软软件规规格说说明书书（Spec modified

9、 ） 由于软软件规规格说说明书对软书对软 件设计设计的要求，软软 件开发发人员员无法修复这这个软软件缺陷，必须须要修 改软软件规规格说说明书书。 7软件缺陷缺陷起源和来源q 缺陷起源：缺陷引起的故障或事件第一次被检测检测 到的阶阶段，如 软件缺陷起源列表所示。 q 缺陷来源：指缺陷所在的地方，如文档、代码等，如软件缺陷 来源列表所示。 缺陷来源 描述 需求说说明书书 需求说说明书书的错误错误、或不清楚引起的 问题问题 设计设计文档 设计设计文档描述不准确、和需求说说明书书 不一致的问题问题 系统统集成接口 系统统各模块块参数不匹配、开发组发组之间间 缺乏协调协调引起的缺陷 数据流(库库) 由于

10、数据字典、数据库库中的错误错误引起 的缺陷 程序代码码 纯纯粹在编码编码中的问题问题所引起的缺陷 缺陷起源 描述 需求 在需求阶阶段发现发现的缺陷 构架 在系统统构架设计阶设计阶 段发现发现的缺陷 设计设计 在程序设计阶设计阶 段发现发现的缺陷 编码编码 在编码阶编码阶 段发现发现的缺陷 测试测试 在测试阶测试阶 段发现发现的缺陷 用户户 在用户户使用阶阶段发现发现的缺陷 8软件缺陷缺陷根源q 缺陷根源：指造成上述错误的根本因素，以寻求软件开 发流程的改进、管理水平的提高，如软件缺陷根源列表 所示。缺陷根源 描述 测试测试策略 错误错误的测试测试范围围，误误解了测试测试目标标，超越 测试测试能

11、力等 过过程，工具和方法 无效的需求收集过过程，过时过时的风险风险管理过过程 ，不适用的项项目管理方法，没有估算规规程， 无效的变变更控制过过程等 团队团队/人 项项目团队职责团队职责 交叉，缺乏培训训,没有经验经验的 项项目团队团队，缺乏士气和动动机不纯纯等 缺乏组织组织和通讯讯 缺乏用户户参与，职责职责不明确，管理失败败等 硬件 硬件配置不对对、缺乏，或处处理器缺陷导导致算 术术精度丢丢失，内存溢出等 软软件 软软件设设置不对对、缺乏，或操作系统错误导统错误导 致 无法释释放资资源，工具软软件的错误错误，编译编译器的 错误错误，2000 千年虫问题问题等。 工作环环境 组织组织机构调调整，

12、预预算改变变，工作环环境恶恶劣， 如噪音过过大。 9软件缺陷相关的信息 软件缺陷相关的信息包括软件缺陷的图片、记录 信息和如何再现和分离软件缺陷；对于某一个软件缺 陷报告，测试人员应该给予相关的信息，例如捕捉到 软件缺陷日志文件和图片，保证开发人员和其他的测 试人员可以分离和重现它。 q 软件缺陷的图片、记录信息 q 记录软件缺陷的相关图片 一些涉及用户界面(User Interface)的软件缺陷可能 很难用文字清楚地描述，因此软件测试人员通过附上图片比 较直观地表示缺陷发生在产品界面什么位置、有什么问题等 。 10分离和再现软件缺陷 为了有效地再现软件缺陷，除了按照软件缺陷的有效描述规 则

13、来描述软件缺陷，还要遵循软件缺陷分离和再现的方法和具 有较高的技巧性，虽然有时少数几个缺陷很难再现、或者根本 无法再现。以下就介绍如何分离和再现缺陷的一些常用方法和 技巧。 q 确保所有的步骤都被记录。 q 特定条件和时间。 q 压力和负荷、内存和数据溢出相关的边界条件。 q 考虑资源依赖性包括内存、网络和硬件共享的相互作用等。 q 不能忽视硬件。与软件不同，硬件不按预定方式工作。 开发人员有时可以根据相对简单的错误信息就能找出问题所 在。因为开发人员熟悉代码，因此看到症状、测试用例步骤和 分离问题的过程时，可能得到查找软件缺陷的线索。一个软件 缺陷的分离和再现问题有时需要小组的共同努力。如果

14、软件测 试人员尽最大努力分离软件缺陷，也无法表达准确的再现步骤 ，那么仍然需要记录和报告软件缺陷。 11分离和调试软件缺陷之间的区别 讨论分离和调试软件缺陷之间的区别，是为了划清测试人 员与开发人员的责任，增加界限的清晰度与测试资源的控制能 力。面对一个软件缺陷时，开发人员或测试人员为了修复它， 会提出一系列分步骤地、处理缺陷的疑问： q 再现软件缺陷现象所需的最少步骤有哪些？这些步骤成功再现 的可能性多大？ q 软件缺陷是否成立存在？换句话说，测试结果是否可能起源于 测试因素或者测试人员自身的错误，还是影响顾客需求的、系 统真正的故障？ q 哪些外部因素产生软件缺陷？ q 哪些内部因素，是代

15、码、网络、还是环境引起的软件缺陷？ q 怎样才能在不产生新的缺陷的条件下使这个软件缺陷得到修复 ？ q 这种修复是否经过调试，单元是否经过测试？ q 问题解决了吗？它是否通过了确认和回归测试，确定系统的其 余部分仍工作正常？ 12软件缺陷的处理和跟踪 软件缺陷跟踪管理是测试工作的一个重要部分，测试的目的是 为了尽早发现软件系统中的缺陷，而对软件缺陷进行跟踪管理 的目的是确保每个被发现的缺陷都能够及时得到处理。软件测 试过程简单说就是围绕缺陷进行的，对缺陷的跟踪管理，一般 而言需要达到以下目标： q 确保每个被发现的缺陷都能够被解决，“解决”的意思不一定 是被修正，也可能是其他处理方式（例如，延

16、迟到下一个版本 中修正或者由于技术原因不能被修正），总之，对每个被发现 的BUG的处理方式必须能够在开发组织中达到一致； q 收集缺陷数据并根据缺陷趋势曲线识别测试处于测试过程中的 哪个阶段； q 决定测试过程是否结束，通过缺陷趋势曲线来确定测试过程是 否结束是常用并且较为有效的一种方式。 q 收集缺陷数据并在其上进行数据分析，作为组织过程改进的财 富。 13简单、优化的软件缺陷生命周期 生命周期的概念是一个物种从诞生到消亡经历了不同的生命阶 段，那么软件缺陷生命周期应该指的是一个软件缺陷被发现、报告 到这个缺陷被修复、验证直至最后关闭的完整过程。在整个软件缺 陷生命周期中，通常是以改变软件缺陷的状态来体现不同的生命阶 段。因此，对于一个软件测试人员来讲，需要关注软件缺陷在生命 周期中的状态的变化，来跟踪项目进度和软件质量。一个简单、优 化的软件缺陷生命周期：q 发现-打开：测试人员找到软件缺陷并将软件缺陷提交给开发人员。 q 打开-修复：开发人员再现、修复缺