测试相关文档编写要点(需求计划).pptVIP

* * * 2测试参考文档 2.2测试提交文档 * * 测试计划的内容 1.简介 1.1目的 1.2背景 1.3范围 2.测试参考文档和提交文档 2.1测试参考文档 2.2测试提交文档 3.术语和定义 4.测试策略 4.1测试策略 4.2测试工具 * * 5.确定测试内容 6.资源 6.1人力资源 6.2系统资源 7.测试进度 8.测试人员的任务分配 9.风险和问题 测试计划的内容 3术语定义（可选） 定义了开发产品或测试过程中常用术语的含义，开发和测试人员常常因为对一个术语的理解不同产生争议 4.1测试策略（How） 测试策略描述测试小组用于测试整体和每个阶段的方法。 确定测试策略要从模块、功能、整体、系统、版本、压力、性能、配置和安装等各个方面来考虑 * * 4测试策略—测试工具 4.2测试工具 此项目将使用以下工具： 测试计划的内容 1.简介 1.1目的 1.2背景 1.3范围 2.测试参考文档和提交文档 2.1测试参考文档 2.2测试提交文档 3.术语和定义 4.测试策略 4.1测试策略 4.2测试工具 * * 5.确定测试内容 6.资源 6.1人力资源 6.2系统资源 7.测试进度 8.测试人员的任务分配 9.风险和问题 测试计划的内容 5确定测试内容(What) 功能的测试 理论上测试要覆盖所有的功能项 整体考虑 要考虑到数据流从软件中的一个模块流到另一个模块的过程中的正确性 * * 确定测试内容 5确定测试内容 如何确定被测功能的优先级？ * * 资源 人力资源 这里的人力资源包括测试人员，开发人员，项目负责人，客户代表所有与项目有关的人员，即项目接口人 * * 测试工作需要多少人？ 都有那些角色？ 这些角色的责任是什么？ 哪些人负责哪些工作？ 出了什么样的问题应该找谁？ 人员之间用什么交流？ 资源 系统资源(Where) 需要使用的软件在哪里可以下载，测试工具放在哪里？ 需要的硬件怎么解决？ 文档在哪里？ * * 测试计划的内容 7.测试进度（When） 各测试阶段资源要求及时间安排 项目里程碑 可以参考一下项目经理的项目开发进度 可以使用相对日期：比如XXX工作开始于XXX部门XXXX工作的结束并提交XXXX 也可以加注总的测试工作量预期，用“人/月”、“人/日”等描述。 * * 测试进度 * * 测试计划的内容 8.测试人员的任务分配 9.风险和问题 * * 项目开发的计划，大体项目计划-需求-修改详细计划。 * * * * 计划是尺不是鞭子 * * A 需求正确性、真实性：客户问题，需求人员问题！ 是否真的可以正确的描述自己的需求？理所当然、及其平常的问题，已有系统存在的功能。 我们的需求人员是否真的可以正确的理解用户的需求？ 既要熟悉需求人员的工作，又要熟悉软件所涉及的行业的业务。但笔者还是固执的认为，作为测试人员，还是需要对软件产品所涉及的行业的业务有一个全面的、深入的了解——当然，这不是对一个刚刚入门的测试者的要求，但是如果想称为一个优秀的测试者，是难免要付出这部分努力的。 B “可测试性”，每个需求都有个可预知的结果，并且可以通过设计一个可以重复的过程来对这个明确的结果进行验证。如果对于某条需求或某个特性，无法通过一个明确的方法来进行验证，或者无法预知它的结果，那么就意味着这条需求的描述存在缺陷，应该请需求人员对需求文档进行修改或补充——我们有理由相信，如果作为测试人员对需求无法产生准确的理解，那么开发人员也同样无法对同一条需求产生准确的理解。对于一条确定的软件需求理解的二义性，是在不规范的开发过程中导致返工的一个主要原因。如果认为有必要，那应该在“需求评审会议”上确认所有涉众对需求的理解是一致的。 * * 如果要成功的做一个测试项目，首先必须了解测试规模、复杂程度与可能存在的风险，这些都需要通过详细的测试需求来了解。所谓知己知彼，百战不殆。测试需求不明确，只会造成获取的信息不正确，无法对所测软件有一个清晰全面的认识，测试计划就毫无根据可言。活在自己世界里的人是可悲的，只凭感觉不做详细了解就下定论的项目是失败的。 测试需求越详细精准，表明对所测软件的了解越深，对所要进行的任务内容就越清晰，就更有把握保证测试的质量与进度。 如果把测试活动比作软件生命周期，测试需求就相当于软件的需求规格，测试策略相当于软件的架构设计，测试用例相当于软件的详细设计，测试执行相当于软件的编码过程。只是在测试过程中，我们把”软件”两个字全部替换成了”测试”。这样，我们就明白了整个测试活动的依据来源于测试需求。 * * 测试需求通常是以待测对象的软件需求为原型进行分析而转变过来的。但测试需求并不等同于软件需求，它是以测试的观点根据软件需求整理