河北工业大学软件测试Ch15-报告所发现的缺陷-2014讲解

《河北工业大学软件测试Ch15-报告所发现的缺陷-2014讲解》由会员分享，可在线阅读，更多相关《河北工业大学软件测试Ch15-报告所发现的缺陷-2014讲解（57页珍藏版）》请在金锄头文库上搜索。

1、软件测试方法和技术 第2版 第15章 测试用例的设计 软件测试流程 参见教材P39 G.J.Myers 软件测试的艺术 软件测试：程序测试是为了发现错误而执行程序的过程 缺陷跟踪系统驱动的研发管理 缺陷跟踪系统（DTS）驱动的研发管理 DTS 软件测试人员 软件开发人员 软件代码管 理 编译Build Build发布 项目管理人员 Build编译人员 Exchange Microsoft公司缺陷跟踪系统驱动的研发管理 第15章 报告所发现的缺陷 15.l 软软件缺陷的描述 15.2 软软件缺陷相关的信息 15.3 软软件缺陷跟踪和分析 15.4 软软件缺陷跟踪系统统 15.l 软件缺陷的描述

2、15.1.1 软软件缺陷的生命周期 15.1.2 严严重性和优优先级级 15.1.3 缺陷的其它属性 15.1.4 完整的缺陷信息 15.1.5 缺陷描述的基本要求 15.1.6 缺陷报报告的示例 软件缺陷 IEEE (1983) 729 软件缺陷一个标准的定义： p 从产品内部看，软件缺陷是软件产品开发或维护过程中所存在的错 误、毛病等各种问题； p 从外部看，软件缺陷是系统所需要实现的某种功能的失效或违背。 软件缺陷的主要类型/现象： p 功能、特性没有实现或部分实现 p 设计不合理，存在缺陷 p 实际结果和预期结果不一致 p 运行出错，包括运行中断、系统崩溃、界面混乱 p 数据结果不正确

3、、精度不够 p 用户不能接受的其他问题，如存取时间过长、界面不美观 n软件缺陷生命周期指的是一个软件缺陷被发现、报告 到这个缺陷被修复、验证直至最后关闭的完整过程 n缺陷生命周期是各类开发人员一起参与、协同测试的 过程。 n软件缺陷一旦发现，便进入严密监控之中，直至软件 缺陷生命周期终结，这样即可保证在较短的时间内高 效率地关闭所有的缺陷，缩短软件测试的进程，提高 软件质量，同时减少开发、测试和维护成本。 15.1.1 软软件缺陷的生命周期 基本的缺陷生命周期 q发现-打开：测试人员找到软件缺陷 并将软件缺陷提交给开发人员。 q打开-修复：开发人员再现、修复缺 陷，然后提交给测试人员去验证。

4、q修复-关闭：测试人员验证修复过的 软件，关闭已不存在的缺陷。 发现 打开 修复 关闭 常见的软件缺陷生命周期 Bugzilla操作流程 Bug的处理流程 n测试人员或开发人员发现bug后，判断属于哪个模块的问题，填写 bug报告后，通过Email通知项目组长或直接通知开发者。 n项目组长根据具体情况，重新reassigned分配给bug所属的开发者 。 n开发者收到E-Mail信息后，判断是否为自己的修改范围。 A. 若不是，重新reassigned分配给项目组长或应该分配的开发者； B. 若是，进行处理，resolved并给出解决方法。 n测试人员查询开发者已修改的bug，进行重新测试。

5、A. 经验证无误后，修改状态为VERIFIED。待整个产品发布后，修改为 CLOSED。 B. 还有问题，REOPENED，状态重新变为“New“，并发邮件通知。 n如果这个BUG一周内一直没被处理过。Bugzilla就会一直用E-Mail 骚扰它的属主，直到采取行动为止。 Mantis典型的缺陷周期 参见：杨根兴 等，软件质量保证：测试与评价，清华大学出版社2007，page355 软件缺陷属性 缺陷产生的可能性：缺陷在产品中发生的可能性，通常用频率 来表示 软件缺陷缺陷严重程度 缺陷严重程度：是指因缺陷引起的故障对软件产品的影响程度，所 谓“严重性”指的是在测试条件下，一个错误在系统中的绝

6、对影响。 缺陷严重等级 描述 致命 Fatal 系统任何一个主要功能完全丧失、用户数据受到破 坏、系统崩溃、悬挂、死机，或者危及人身安全 严重 Critical 系统的主要功能部分丧失、数据不能保存，系统所 提供的功能或服务受到明显的影响 一般 Major 系统的部分功能没有完全实现，但不影响用户的正 常使用，例如：提示信息不太准确；或用户界面差 、操作时间长等一些问题。 较小 Minor 使操作者不方便或遇到麻烦，但它不影响功能的操 作和执行，如个别的不影响产品理解的错别字、文 字排列不整齐等一些小问题。 软件缺陷缺陷产生的优先级 q缺陷优先级：指缺陷必须被修复的紧急程度。 “优先级”的衡量

7、抓住了在严重性中没有考虑的 重要程度因素。 缺陷优先级 描述 立即解决 (P1级) 缺陷导致系统几乎不能使用或测试不 能继续，需立即修复 高优先级 (P2级） 缺陷严重，影响测试，需要优先考虑 正常排队 (P3级） 缺陷需要正常排队等待修复 低优先级 (P4级） 缺陷可以在开发人员有时间的时候被 纠正。 软件缺陷类型 缺陷类型：是根据缺陷的自然属性划分缺陷种类。 缺陷类型 描述 功能 影响了各种系统功能、逻辑的缺陷 用户界面 影响了用户界面、人机交互特性，包括屏幕格式、 用户输入灵活性、结果输出格式等方面的缺陷 文档 影响发布和维护，包括注释，用户手册，设计文档 软件包 由于软件配置库、变更管

8、理或版本控制引起的错误 性能 不满足系统可测量的属性值，如执行时间，事务处 理速率等。 系统/ 模块接口 与其他组件、模块或设备驱动程序、调用参数、控 制块或参数列表等不匹配、冲突。 软件缺陷缺陷产生的可能性 q缺陷产生的可能性：指缺陷在产品中发生的可 能性，通常可以用频率来表示。 缺陷产生可能 性 描述 总是 (Always) 总是产生这个软件缺陷，其产生的频率是 100% 通常 (Often) 按照测试用例，通常情况下会产生这个软 件缺陷，其产生的频率大概是80-90% 有时 (Occasionally ) 按照测试用例，有的时候产生这个软件缺 陷，其产生的频率大概是30-50% 很少 (

9、rarely) 按照测试用例，很少产生这个软件缺陷， 其产生的频率大概是1-5% 软件缺陷缺陷状态 q缺陷状态：指缺陷通过一个跟踪修复过程的进展情况 ，也就是在软件生命周期中的状态基本定义 缺陷状态 描述 激活或打开 （Active or Open） 问题还没有解决，存在源代码中，确认“提交的缺陷”，等 待处理，如新报的缺陷。 已修正或修复 (Fixed or Resolved) 已被开发人员检查、修复过的缺陷，通过单元测试，认为 已解决但还没有被测试人员验证 关闭或非激活 (Closed or Inactive) 测试人员验证后，确认缺陷不存在之后的状态。 重新打开 (Reopen) 测试人

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

11、fied） 由于软件规格说明书对软件设计的要求，软件开发人员无 法修复这个软件缺陷，必须要修改软件规格说明书。 软件缺陷起源 q缺陷起源：缺陷引起的故障或事件第一 次被检测到的阶段 软件开发的基本过程 RAD - V Model (改进) 软件缺陷起源 缺陷起源 描述 需求 在需求阶段发现的缺陷 构架 在系统构架设计阶段发现的缺陷 设计 在程序设计阶段发现的缺陷 编码 在编码阶段发现的缺陷 测试 在测试阶段发现的缺陷 用户 在用户使用阶段发现的缺陷 软件缺陷来源 缺陷来源：指缺陷所在的地方，如文档、代码等 缺陷来源 描述 需求说明书 需求说明书的错误、或不清楚引起 的问题 设计文档 设计文档描

12、述不准确、和需求说明 书不一致的问题 系统集成接口 系统各模块参数不匹配、开发组之 间缺乏协调引起的缺陷 数据流(库) 由于数据字典、数据库中的错误引 起的缺陷 程序代码 纯粹在编码中的问题所引起的缺陷 软件缺陷缺陷根源 q缺陷根源：指造成上述错误的根本因素，以寻 求软件开发流程的改进、管理水平的提高。 缺陷根源 描述 测试策略 错误的测试范围，误解了测试目标，超越测试 能力等 过程，工具 和方法 无效的需求收集过程，过时的风险管理过程， 不适用的项目管理方法，没有估算规程，无效 的变更控制过程等 团队/人 项目团队职责交叉，缺乏培训,没有经验的项 目团队，缺乏士气和动机不纯等 缺乏组织 和通

13、讯 缺乏用户参与，职责不明确，管理失败等 硬件 硬件配置不对、缺乏，或处理器缺陷导致算术 精度丢失，内存溢出等 软件 软件设置不对、缺乏，或操作系统错误导致无 法释放资源，工具软件的错误，编译器的错误 ，2000 千年虫问题等。 工作环境 组织机构调整，预算改变，工作环境恶劣，如 噪音过大。 15.1.4 完整的缺陷信息 n前提 n操作步骤 n期望结果 n实际结果 n上述的各种缺陷属性 见 P.328 表15-7 软件缺陷的详细描述 q“步骤”提供了如何重复当前缺陷的准确描述，应简明 而完备、清楚而准确。这些信息对开发人员是关键的 ，视为修复缺陷的向导 q“期望结果”与测试用例标准或设计规格说

14、明书或用户 需求等一致，达到软件预期的功能。是验证缺陷的依 据。 q“实际结果”实际执行测试的结果，不同于期望结果， 从而确认缺陷的存在 15.1.5 缺陷描述的基本要求 q单一准确 q可以再现 q完整统一 q短小简练 q特定条件 q补充完善 q不做评价 软件缺陷的有效描述规则 q单一准确 ：每个报告只针对一个软件缺陷，在一个 报告中报告多个软件缺陷的弊端常常是只有其中一 个软件缺陷得到注意和修复 例1 联机帮助文档中下述不同的15页中的单词拼写错 误： 例2 登录对话框不接受大写字母输入的口令或者登录 ID号 q可以再现 q完整统一：提供完整、前后统一的软件缺陷的修复 步骤和信息 q短小简练

15、：只解释事实和演示、描述软件缺陷必需 的细节。 软件缺陷的有效描述规则 q特定条件 例：搜索功能在没有找到结果返回时跳转页面不对 q补充完善=对软件缺陷跟踪到底 从发现软件缺陷的那一刻起，测试员的责任就是保 证它被正确的报告，并且得到应有的重视，继续监 视其修复的全过程。 q不做评价 软件缺陷报告是针对产品的，软件缺陷描述不要带 有个人观点，不要对开发人员进行评价 q尽快报告软件缺陷 15.1.6 示例 见 P.330 优秀的缺陷报告 重现步骤 : a)打开一个编辑文字的软件并且创建一个新的文档（这个文件可 以录入文字） b)在这个文件里随意录入一两行文字 c)选中一两行文字，通过选择Font

16、 菜单然后选择Arial字体格式 d)一两行文字变成了无意义的乱字符 期望结果：当用户选择已录入的文字并改变文字格式的时候，文本 应该显示正确的文字格式不会出现乱字符显示。 实际结果:它是字体格式的问题，如果改变文字格式成Arial之前， 你保存文件，缺陷不会出现。缺陷仅仅发生在Windows98并且 改变文字格式成其它的字体格式，文字是显示正常的。 见所附的图片 散漫的缺陷报告的示例 重现步骤： 在Window98上打开一个编辑文字的软件并且编辑存在文件 文件字体显示正常 我添加了图片，这些图片显示正常 在此之后，我创建了一个新的文档 在这个文档中我随意录入了大量的文字 在我录入这些文字之后，选择几行文字.并且通过选择Font 菜单然后选择 Arial字体格式改变文字的字体。 有三次我重现了这个缺陷 我在Solaris操作系统运行这些步骤，没有任何问题。 我在Mac操作系统运行这些步骤，没有任何问题。 期望结果：当用户选择已录入的文字并改变文字格式的时候，文本应该显示正确 的文字格式不会出现乱字符显示。 实际结果：我试着选择少量的不