第二章软件测试计划实例.pptVIP

第二章 软件测试计划 测试计划 测试范围 测试环境需求 测试进度安排 测试风险 使用Rational TestManager 进行测试计划　 2.1 测试计划 软件测试应该考虑到的问题 软件测试的内容 测试计划模板 如何确定测试计划 软件测试计划 测试中应考虑到的问题 所有的出错可能性 性能(Performance)问题 软件的兼容性(Compatibility) 测试计划模板 测试背景 产品 项目涉及人员（如软硬件项目负责人）介绍以及相应联系方式等 测试依据 软件需求文档； 软件规格书； 软件设计文档； 其他（参考文档） 测试资源 测试设备需求； 测试人员需求 测试环境需求； 其他 测试策略 采用的测试方法； 搭建哪些测试环境； 采用的测试工具以及测试管理工具 怎样进行人员培训 测试日程 测试需求分析； 测试用例编写 测试实施，根据项目计划，将测试分成哪些测试阶段，每个阶段的工作重点以及投入的资源等 其他 编写的日期，作者等信息 2.2 软件测试的范围 设计阶段 产品设计是否符合客户需求 架构设计是否符合产品设计，是否容易导致缺陷，是否容易导致低劣性和不稳定性，是否有利于测试 测试方案是否对功能覆盖完备，是否采用恰当方法测试每个不同领域，时间人力是否足够，帮助开发人员提高效率的措施是否恰当和足够，是否保证测试工具的质量 实施阶段 - 某次代码更新是否引发严重缺陷以至无法测试 - 某个开发人员是否引入了太多缺陷 稳定阶段 - 缺陷是否值得修复 - 缺陷修复顺序是否合理 - 缺陷修复是否会引发更 多的缺陷 发布阶段 - 缺陷数量是否有扩大化 的趋势 - 待发布版本是否符合发布标准 确定测试范围 测试组审查系统需求 测试组审查设计文档系统 测试工程师评审任务说明，确定关键系统功能和高风险系统功能。 测试工程师对系统清晰定义并理解系统需求或使用的用例，以便确定测试目标、测试目的和测试策略 确定用于项目的自动测试工具。 将测试参数形成文档，其中包括确定测试目标、测试目的和测试策略时所做的所有假设。还需将先决事件、文档及支持各种测试活动的产品罗列出来。 确定系统验收准则，估计测试风险，制订降低风险的计划 2.3 测试环境需求 操作系统类型版本和补丁版本，被测试软件的版本和补丁版本、相关支撑软件 计算机的配置情况，主要包括CPU 、内存和硬盘的相关参数，其它硬件参数 2.5 软件测试的七类风险 设计，编码，相关文档质量不规范，软件质量标准不清晰 用户的需求发生重大变更或测试计划和设计大幅度地调整等因素所导致测试时间延长、经费增加 测试初始阶段的软，硬件设备不到位 测试人员的技术不到位 特定的测试环境不能到位 主要的测试人员因故缺席 测试数据准备不充分 质量需求或产品的特性理解不准确，造成测试范围分析的误差 测试用例设计不到位，执行不完全 2.6 使用Rational TestManager进行测试计划 2.6.1 TestManage介绍 TestManager提供测试管理的核心平台，它是测试人员的工作环境。测试人员与团队成员用它来计划、管理、组织、执行、评估以及报告个别测试用例或整个测试计划。通过与需求管理工具RequisitePro 的集成，TestManager 可以生成关于测试用例的需求覆盖率报告，从而保证测试的完备性。利用它可以控制所有类型的测试活动－从手工回归测试到缺陷跟踪，直到扩展的自动化压力测试。通过集中控制测试流程并轻松共享测试结果，IBM Rational TestManager提高了整个开发生命周期的测试效率。 2.6.2 Testmanage测试流程 利用TestManager实现软件自动化测试流程： 测试计划、测试设计、测试实施、测试执行、测试评估 测试流程 测试流程 每个测试环节的具体阐述如下： 测试计划的目的是确定和描述要实施和执行的测试。这一环节主要生成包含测试需求和测试策略的测试计划。 测试设计的目的是确定、描述和生成测试过程和测试用例。 测试实施的目的是记录、生成或编写在测试设计环节中定义的测试过程。这一环节主要将测试过程转化为计算机可以理解并执行的信息，称为测试脚本。 测试执行的目的是确保整个系统按既定意图运行。对于每一个迭代，都需要增加测试过程和测试用例用以测试新增的功能，同时还需要重复执行以前版本测试过的所有测试用例（回归测试）。 测试评估的目的是生成并交付测试评估摘要。这是通过复审并评估测试结果、确定并记录变更请求（Change Request）以及计算主要评估方法来完成的。测试评估摘要以组织有序的格式提供测试结果和主要评估方法，用于评估测试对象和测试流程的质量。 2.6