资源预览内容
第1页 / 共31页
第2页 / 共31页
第3页 / 共31页
第4页 / 共31页
第5页 / 共31页
第6页 / 共31页
第7页 / 共31页
第8页 / 共31页
第9页 / 共31页
第10页 / 共31页
亲,该文档总共31页,到这儿已超出免费预览范围,如果喜欢就下载吧!
资源描述
,软件测试方法和技术 第2版 第15章报告所发现的缺陷,zhang_shu_yan163.com,张淑艳,第15章 报告所发现的缺陷,15.l 软件缺陷的描述 15.2 软件缺陷相关的信息 15.3 软件缺陷跟踪和分析 15.4 软件缺陷跟踪系统,15.l 软件缺陷的描述,15.1.1 软件缺陷的生命周期 15.1.2 严重性和优先级 15.1.3 缺陷的其它属性 15.1.4 完整的缺陷信息 15.1.5 缺陷描述的基本要求 15.1.6 缺陷报告的示例,软件缺陷生命周期指的是一个软件缺陷被发现、报告到这个缺陷被修复、验证直至最后关闭的完整过程 缺陷生命周期是各类开发人员一起参与、协同测试的过程。 软件缺陷一旦发现,便进入严密监控之中,直至软件缺陷生命周期终结,这样即可保证在较短的时间内高效率地关闭所有的缺陷,缩短软件测试的进程,提高软件质量,同时减少开发、测试和维护成本。,15.1.1 软件缺陷的生命周期,基本的缺陷生命周期,发现-打开:测试人员找到软件缺陷并将软件缺陷提交给开发人员。 打开-修复:开发人员再现、修复缺陷,然后提交给测试人员去验证。 修复-关闭:测试人员验证修复过的软件,关闭已不存在的缺陷。,常见的软件缺陷生命周期,15.1.2 严重性和优先级,严重性(severity)衡量缺陷对客户满意度的影响程度 致命的(fatal)、严重的(critical)、一般的(major)、微小的(minor) 优先级(Priority):指缺陷被修复的紧急程度。,15.1.3 缺陷的其它属性,缺陷标识(ID) 缺陷类型(type) 缺陷产生可能性(frequency) 缺陷来源(source) 缺陷原因(root cause),见 P.327328 诸表,15.1.4 完整的缺陷信息,前提 操作步骤 期望结果 实际结果 上述的各种缺陷属性,见 P.328 表15-7,软件缺陷的详细描述,“步骤”提供了如何重复当前缺陷的准确描述,应简明而完备、清楚而准确。这些信息对开发人员是关键的,视为修复缺陷的向导 “期望结果”与测试用例标准或设计规格说明书或用户需求等一致,达到软件预期的功能。是验证缺陷的依据。 “实际结果”实际执行测试的结果,不同于期望结果,从而确认缺陷的存在,15.1.5 缺陷描述的基本要求,单一准确 可以再现 完整统一 短小简练 特定条件 补充完善 不做评价,15.2 软件缺陷的相关信息,15.2.1 软件缺陷的图片信息 15.2.2 使用WinDBG记录软件缺陷信息 15.2.3 使用Soft-ICE记录软件缺陷信息 15.2.4 分离和再现软件缺陷,15.2.1 软件缺陷的图片信息,软件缺陷相关的信息包括软件缺陷的图片、记录信息和如何再现和分离软件缺陷,使开发人员和其他的测试人员更容易分离和重现它。 一些涉及用户界面(User Interface)的软件缺陷可能很难用文字清楚地描述,因此软件测试人员通过附上图片比较直观地表示缺陷发生在产品界面什么位置、有什么问题等。,15.2.4 分离和再现软件缺陷,确保所有的步骤都被记录。 特定条件和时间。 压力和负荷、内存和数据溢出相关的边界条件。 考虑资源依赖性包括内存、网络和硬件共享的相互作用等。 不能忽视硬件。与软件不同,硬件不按预定方式工作。 和开发人员紧密合作,理解分离和调试软件缺陷之间的区别,分离和调试软件缺陷之间的区别,再现缺陷现象所需的最少步骤有哪些?这些步骤成功再现的可能性多大? 缺陷是否成立存在?测试结果是否可能起源于测试因素或者测试人员自身的错误,还是影响顾客需求的、系统真正的故障? 哪些外部因素产生软件缺陷? 哪些内部因素,是代码、网络、还是环境引起的软件缺陷? 怎样在不产生新的缺陷的条件下使这个软件缺陷得到修复? 这种修复是否经过调试,单元是否经过测试? 问题解决了吗?它是否通过了确认和回归测试,确定系统的其余部分仍工作正常?,15.3 软件缺陷跟踪和分析,15.3.1 软件缺陷处理技巧 15.3.2 缺陷趋势分析 15.3.3 缺陷分布分析 15.3.4 缺陷跟踪方法,软件缺陷的处理和跟踪,确保每个被发现的缺陷都能够被解决,“解决”的意思不一定是被修正,也可能是其他处理方式(例如,延迟到下一个版本中修正或者由于技术原因不能被修正),总之,对每个被发现的BUG的处理方式必须能够在开发组织中达到一致; 收集缺陷数据并根据缺陷趋势曲线识别测试处于测试过程中的哪个阶段; 决定测试过程是否结束,通过缺陷趋势曲线来确定测试过程是否结束是常用并且较为有效的一种方式。 收集缺陷数据并在其上进行数据分析,作为组织过程改进的财富。,15.3.1 软件缺陷处理技巧,审阅。可以由测试管理员、项目管理员或其他人来进行,审阅缺陷报告的质量水平; 拒绝。如果审阅者决定需要对一份缺陷报告进行重大修改,应该和测试人员一起讨论,由测试人员纠正缺陷报告,然后再次提交; 完善。完整地描述了问题的特征并将其分离,那么审查者就会肯定这个报告; 分配。分配给适当的开发人员,如果不知道具体开发人员,应分配给项目开发组长,由开发组长再分配给对应的开发人员;,软件缺陷处理技巧 (2),验证。缺陷的修复需要得到测试人员的验证,同时还要进行回归测试,检查这个缺陷的修复是否会引入新的问题; 重新打开。重新打开一个缺陷,需要加注释说明、电话沟通等,否则会引起“打开-修复”多个来回,造成测试人员和开发人员不必要的矛盾 关闭。只有测试人员有关闭缺陷的权限,开发人员没有这个权限。 暂缓。如果每个人都同意将确实存在的缺陷移到以后处理,应该指定下一个版本号或修改的日期。一旦新的版本开始时,这些暂缓的缺陷应该重新被打开。,15.3.2 缺陷趋势分析,监控(打开/关闭/已修正的)缺陷随时间的变化 产品开发质量情况取决于累积打开/关闭曲线的趋势。 项目进度取决于累积关闭/打开曲线起点的时间差。 开发人员、测试人员的工作进度、效率也能得到反映,示例,理想趋势图,示例:,微软公司基于缺陷趋势图的里程碑定义,15.3.3 缺陷分布分析,缺陷分布报告,缺陷数量与缺陷属性的函数。如测试需求和缺陷状态、严重性的分布情况等。,示例:根本原因图表,缺陷报告,缺陷分布报告,允许将缺陷计数作为一个或多个缺陷参数的函数来显示,生成缺陷数量与缺陷属性的函数。如测试需求和缺陷状态、严重性的分布情况等。 缺陷趋势报告,按各种状态将缺陷计数作为时间的函数显示。趋势报告可以是累计的,也可以是非累计的; 缺陷年龄报告,显示缺陷处于活动状态的时间,展示一个缺陷处于某种状态的时间长短,从而了解处理这些缺陷的进度情况。 测试结果进度报告,展示测试过程在被测应用的几个版本中的执行结果以及测试周期,15.3.3 缺陷跟踪方法,当前缺陷状态 Bug Dashboard 项目发展趋势: 每天的变化、差异,重点进行趋势分析,软件缺陷报告,任何一个缺陷跟踪系统的核心都是“软件缺陷报告”,一份软件缺陷报告详细信息如表: 软件缺陷项目列表,软件缺陷报告,15.4 软件缺陷跟踪系统,在 11.7 节我们已讨论,小结,本章讲解了应该遵循正规过程正确地描述、分离、分类、记录和跟踪软件缺陷,以保证它们有效地、快速地被修复、最终得到解决。 需要建立软件缺陷跟踪数据库存储、搜索和分析软件缺陷,从而生成一系列的图表,分析项目的发展趋势,控制项目进度,并找到薄弱的领域,预防缺陷。,
网站客服QQ:2055934822
金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号