(ppt)软件测试计划.ppt

测试计划 IEEE定义的测试计划 测试计划： 一个叙述了预定的测试活动范围、途径、资源及进度安排的文档。 它确定了测试项、被测特征、测试任务、人员安排以及与计划相关的风险。 三要素： 时间 资源 范围 其他方面 策略 风险控制 计划的作用 计划能给管理者和被管理者指明前进的方向 计划可以减少不确定性对组织的影响和冲击 计划可以减少无序和浪费 计划有利于管理和控制 关于测试计划 1. 为什么要编写测试计划？ 领导能够根据测试计划做宏观调控，进行相应资源配置等； 测试人员能够了解整个项目测试情况以及项目测试不同阶段的所要进行的工作等； 便于其他人员了解测试人员的工作内容，进行有关配合工作 2. 什么时间开始编写测试计划？ 需求分析后，在整个测试工作过程中，不断修改 3. 由谁来编写测试计划？ 具有丰富经验的项目测试负责人 测试计划的核心活动 1.确定测试策略 2.确定测试系统（软件和硬件） 3.预估工作量（资源和时间进度计划） 4.评估事件进度风险并准备风险缓解计划 5.准备并复查测试计划文档 测试计划的设计与实现 测试策略（1/5） 确定测试范围 问题： 测试过度 测试不足 某些阶段的测试或者某些内容的测试可以简化 当对原有系统进行修改升级时，某些测试不需要 某些测试根本不可能进行 测试策略（2/5） 确定测试顺序 先测优先级最高的需求 对新功能和修改功能进行测试 运用等价划分技术和边界值分析技术减少测试工作量 测试那些最有可能出现问题的地方 关注用户最常使用的功能和配置情况等 测试策略（3/5） 确定测试方法 测试策略（4/5） 测试标准 入口标准：描述在开始之前需要做哪些工作 出口标准：描述在怎样的情况下可以结束测试 暂停/继续测试： 描述如果缺陷妨碍测试进行下去，会发生什么事情。如果情况很糟，无法执行计划的测试，则应暂停测试，等完成修复工作后，再完成测试工作。 通过/失败标准 执行每项测试应该有一个明确的预期结果。如果得到了预期的结果，测试就通过。否则表示测试失败。 测试策略（5/5） 自动化测试工具的选择 是否使用自动化测试工具，哪个阶段用什么工具 好处： 能够很好进行性能测试和压力测试 能够改进回归测试 能够缩短测试周期 能够提高测试工作的课重复性 测试软件的编写 确定测试系统 确定测试系统 测试系统不仅指用于测试的硬件，也包括测试架构以及测试配置 测试架构：测试用例的组织形式 测试配置：软硬件环境 预测工作量（1/2） 预测工作量 确定要完成的任务：测试用例的组织形式 确定每个任务的所需工作量 确定完成每个任务的时间 为测试工作建立详细的时间进度计划和里程表 预测工作量（2/2） 评估进度风险 开始测试时，所需硬件没有到位 开始测试时，测试的系统还没有布置好 开始测试时，测试用例还没有准备好 测试过程中，需求发生变更 测试过程中，用户界面发生变更 复查测试文档 详细描述工作的范围 估计定义测试用例和实施测试所需工作 确定所需资源（人、硬件、软件和工具） 为各个人物分配资源 制定进度表 确定进度安排或质量风险 制定解决风险的应急计划 追踪项目进展并采取纠正措施 在适当的时候重新定制 向整个项目提供测试状态的可视性 对失败或堵塞测试纠正后重新测试 测试计划的目的 尽早地明确测试工作内容（范围）、测试工作的方法以及测试工作所需要的各种资源。 所有涉及到测试工作的人员，尽快将下一步测试工作需要考虑的问题和准备的条件落实。 测试计划工作的重点在于：对当前工作任务的准备和规划以及信息的交流。 测试计划注意事项 增强测试计划的实用性 坚持“5W1H”规则，明确内容与过程 采用评审和更新机制，保证测试计划满足实际需求 测试计划和测试策略 测试计划编写6要素？（5W1H） 测试类型和目的 测试阶段 可以用表格明确测试的执行情况 不同测试阶段对测试内容和测试方法考虑不同 如：单元测试——考虑代码的覆盖 系统测试——考虑需求的满足情况 测试方法 功能测试（1/2） 测试目标 确保所有的被测对象功能正常 测试方法 至少为每条测试需求设计两个测试用例，一个用来验证是否实现了应有的功能，一个用来检查功能的实现是否存在问题 符合业务规则的操作和数据是否可以得到预期的结果？ 不符合业务规则的操作和数据是否都被拒绝接受，并提供出正确的、容易理解的提示信息。 所有的业务规则的实现是否同需求中的描述相互一致 系统测试阶段所有的测试用例均采用手工方式通过对用户界面的操作来执行。 功能测试（2/2） 完成标准： 对系统测试阶段：必须保证所有准备执行的测试用例全部被执行，并且保证所有提交的缺陷全部被正确地解决。 特殊事项的考虑 如果由于某项原因导致测试时间被缩短，将会考虑按照测试用例的优先级