第四讲 软件测试计划.ppt

第二章 测试计划 主要内容 管理学中的计划 指对我们如何能达到目标的描述 IEEE定义的测试计划 测试计划： 一个叙述了预定的测试活动范围、途径、资源及进度安排的文档。 它确定了测试项、被测特征、测试任务、人员安排以及与计划相关的风险。 三要素： 时间 资源 范围 其他方面 策略 风险控制 计划的作用 计划能给管理者和被管理者指明前进的方向 计划可以减少不确定性对组织的影响和冲击 计划可以减少无序和浪费 计划有利于管理和控制 关于测试计划 1. 为什么要编写测试计划？ 领导能够根据测试计划做宏观调控，进行相应资源配置等； 测试人员能够了解整个项目测试情况以及项目测试不同阶段的所要进行的工作等； 便于其他人员了解测试人员的工作内容，进行有关配合工作 2. 什么时间开始编写测试计划？ 需求分析后，在整个测试工作过程中，不断修改 3. 由谁来编写测试计划？ 具有丰富经验的项目测试负责人 测试计划的核心活动 1.确定测试策略 2.确定测试系统（软件和硬件） 3.预估工作量（资源和时间进度计划） 4.评估事件进度风险并准备风险缓解计划 5.准备并复查测试计划文档 测试计划的设计与实现 测试软件需求（1/8） 需求分析过程 收集用户需求 编写需求定义文档 编写软件功能说明 审核软件需求文档 测试软件需求（2/8） 如何确定测试需求 确定测试内容 或是确定测试的具体对象 测试软件需求（3/8） 功能测试需求： 一个明确的功能特性可以生成一条测试需求 性能测试需求 通常包含在“补充需求”中的“非功能性需求” 测试软件需求（4/8） 需求分析中测试人员工作 理解需求，参与审核需求文档 理解项目的目标、限制，了解用户应用背景 编写测试计划 准备资源 测试软件需求（5/8） 测试需求文档： 具有清晰的格式和文档结构 需求的内容正确 需求的内容完整 需求具有可行性 必要性 对不同的需求的优先级进行定义 描述明确、无歧义、上下文一致 可证实和可靠性 可修改性 可追踪 需求文档被及时更新 测试软件需求（6/8） 需求测试的内容： 需求文档是否符合公司的格式要求？ 需求是否正确？ 要保证需求文档中所描述的内容是真实可靠的 这是“真正的”需求吗？描述的产品是否就是要开发的产品？ 需求是否完备？列出的需求是否能减去 一部分？ 需求是否可实现？ 需求是否合理？ 需求是否可测？ 测试软件需求（7/8） 需求测试的方法： 复查 (Review) 复查一般是让工作中合作者检查产品并提出意见。同级互查可以面对面进行，也可以通过E-Mail实现，并没有统一标准。发现文档缺陷同级互查的能力是三种方法中最弱的。 走查 (Walkthrough) 相比较审查走查较为宽松，其事先需要收集数据，也没有输出报告的要求。 审查 (Inspection) 审查是为发现缺陷而进行的。关键组件的审查通过会议进行，会前每个与会者需要进行准备，会议必须按规定的程序进行，缺陷被记录并形成会议报告。审查被证明是非常有效的发现缺陷的方法。 测试软件需求（8/8） 测试计划的设计与实现 测试策略（1/5） 确定测试范围 问题： 测试过度 测试不足 某些阶段的测试或者某些内容的测试可以简化 当对原有系统进行修改升级时，某些测试不需要 某些测试根本不可能进行 测试策略（2/5） 确定测试顺序 先测优先级最高的需求 对新功能和修改功能的代码进行测试 运用等价划分技术和边界值分析技术减少测试工作量 测试那些最有可能出现问题的地方 关注用户最常使用的功能和配置情况等 测试策略（3/5） 确定测试方法 测试策略（4/5） 测试标准 入口标准：描述在开始之前需要做哪些工作 出口标准：描述在怎样的情况下可以结束测试 暂停/继续测试： 描述如果缺陷妨碍测试进行下去，会发生什么事情。如果情况很糟，无法执行计划的测试，则应暂停测试，等完成修复工作后，再完成测试工作。 通过/失败标准 执行每项测试应该有一个明确的预期结果。如果得到了预期的结果，测试就通过。否则表示测试失败。 测试策略（5/5） 自动化测试工具的选择 是否使用自动化测试工具，哪个阶段用什么工具 好处： 能够很好进行性能测试和压力测试 能够改进回归测试 能够缩短测试周期 能够提高测试工作的课重复性 测试软件的编写 测试计划的设计与实现 确定测试系统 确定测试系统 测试系统不仅指用于测试的硬件，也包括测试架构以及测试配置 测试架构：测试用例的组织形式 测试配置：软硬件环境 测试计划的设计与实现 预测工作量（1/2） 预测工作量 确定要完成的任务：测试用例的组织形式 确定每个任务的所需工作量 确定完成每个任务的时间 为测试工作建立详细的时间进度计划和里程表 预测工作量（2/2） 评估进度风险 开始测试时，所需硬件没有到位 开始