Ch15-所发现的缺陷要点讲解.ppt

软件测试方法和技术 - Ch.15报告所发现的软件缺陷 主讲教师：郭晓燕 第十五章 报告所发现的软件缺陷 15.1 软件缺陷的描述 软件缺陷指的是系统或系统部件中那些导致系统或部件不能实现其功能的缺陷。 如果在执行中遇到一个缺陷，可能引起系统的失效。那么准确有效的定义和描述软件缺陷，可以使软件缺陷得以快速修复，节约了软件测试项目的成本和资源，提高产品质量。 软件缺陷的有效描述 开发人员修复缺陷是开发过程中的重要一环，很多工作都是围绕着缺陷展开的。 软件缺陷的描述也是测试人员就一个软件问题与开发小组交流的最初且最好的机会。 一个好的描述，需要使用简单的、准确的、专业的语言来抓住缺陷的本质。 15.1 软件缺陷的描述 有效描述软件缺陷的好处 减少软件缺陷从开发人员返回的数量 提高软件缺陷修复的速度，使得小组可以有效的工作 提高测试人员的信任度 加强开发人员、测试人员和管理人员的协同工作 软件缺陷的生命周期 软件缺陷生命周期应该指的是一个软件缺陷被发现、报告到这个缺陷被修复、验证直至最后关闭的完整过程。 在整个软件缺陷生命周期中，通常是以改变软件缺陷的状态来体现不同的生命阶段。 因此，对于一个软件测试人员来讲，需要关注软件缺陷在生命周期中的状态的变化，来跟踪项目进度和软件质量。 软件缺陷的生命周期 “新打开的”：发现-打开：测试人员找到软件缺陷并将软件缺陷提交给开发人员。 “已修正的”：打开-修复：开发人员再现、修复缺陷，然后提交给测试人员去验证。 “已关闭的”：修复-关闭：测试人员验证修复过的软件，关闭已不存在的缺陷。 软件缺陷的生命周期 在实际工作中，软件缺陷的生命周期那么简单，需要考虑其它各种情况， 给出了一个复杂的软件缺陷生命周期的例子， 软件缺陷的等级 测试员给软件缺陷分类，划分严重性和优先级 严重性表示软件缺陷的恶劣程度，当用户碰到该缺陷时影响的可能性和程度； 优先级表示的是修复缺陷的重要程度和紧迫程度。 严重性分类 致命 ：系统崩溃、数据丢失、数据毁坏、安全性被破坏 严重：功能或特性没有实现，主要功能部分丧失，次要功能部分丧失或致命错误声明。 一般：系统的部分功能没有完全实现，但不影响用户的正常使用，例如：提示信息不太准确；或用户界面差、操作时间长等一些问题。 较小：小问题，对功能几乎没有影响。建议 软件缺陷的等级 优先级分类 立即修复(P1)，阻止了进一步测试，立竿见影 在产品发布前必须修复(P2)：缺陷严重，影响测试，需要优先考虑 如果时间允许应该修复(P3) 可能会修复(P4)，但是即使有此缺陷产品也能发布。 举例 网站登录功能年龄输入项对非数字没有检验，显示异常画面。 一启动就崩溃的软件 某按钮摆放位置应该向页面下方移动 15.1.4 完整的软件缺陷报告 任何一个缺陷跟踪系统的核心都是“软件缺陷报告”，一份软件缺陷报告详细信息如表： 软件缺陷项目列表 软件缺陷报告 手工报告软件缺陷 任何一个缺陷跟踪系统的核心都是“软件缺陷报告” 缺陷编号： 0001 15.1.4 缺陷描述的基本要求 报告软件缺陷的基本原则 单一准确：尽量一个报告只针对一个软件缺陷 可再现：提供精确步骤，可再现并修复缺陷。 完整统一：完整前后统一的软件缺陷 短小简练：只给出事实和演示软件缺陷必需的细节 特定条件：通常情况下软件没有问题，而是在特定条件下出现，所以缺陷描述时不要忽视这些特定条件。 对缺陷跟踪到底：从发现Bug开始，要保证它被正确的报告直至修复的全过程。 不要评价缺陷 缺陷报告的示例 一份优秀的缺陷报告记录下最少的重复步骤，不仅包括了期望结果，实际结果和必要的附件，还提供必要的数据、测试环境或条件，以及简单的分析。 软件缺陷的详细描述 软件缺陷的详细描述，如上所述，由三部分组成：操作/重现步骤、期望结果、实际结果，有必要再做进一步的讨论： “步骤”提供了如何重复当前缺陷的准确描述，应简明而完备、清楚而准确。这些信息对开发人员是关键的，视为修复缺陷的向导，开发人员有时抱怨糟糕的缺陷报告，往往集中在这里； “期望结果”与测试用例标准或设计规格说明书或用户需求等一致，达到软件预期的功能。测试人员站在用户的角度要对它进行描述，它提供了验证缺陷的依据。 “实际结果”测试人员收集的结果和信息，以确认缺陷确实是一个问题，并标识那些影响到缺陷表现的要素。 缺陷报告的示例 而一份含糊而不完整的缺陷报告，缺少重建步骤，并且没有期望结果、实际结果和必要的图片，如下描述。 缺陷报告的示例 一份散漫的缺陷报告（无关的重