问题描述：
论坛上有不少关于测试计划的帖子，讨论都相对宽泛，这里希望就测试计划中如何确定测试范围一项进行具体的讨论。
测试范围是测试计划中所有要素的先行者，后续的进度、任务、风险、度量等内容都要依靠其进行估计，马虎不得。其相关的理论、方法、工具都有不少，为了更有针对性，这里规定一下讨论的前提，既：系统测试计划中实现WBS的方法（因为该方法相对直观，使用和相关工具（如：Project）也比较成熟）。
希望能够从树形结构如何规划、分解的粒度、工作包的定义、工作中的度量指标、对后续工作的指导意义等相关方面进行说明。
注：创建工作分解结构（WBS）是把项目可交付成果和项目工作分解成较小的、更易于管理的组成部分的过程。工作分解结构是以可交付成果为导向的工作层级分解，其分解的对象是项目团队为实现项目目标、提交所需可交付成果而实施的工作。工作分解结构每下降一个层次就意味着对项目工作更详尽的定义。工作分解结构组织并定义项目的总范围，代表着现行项目范围说明书所规定的工作。
精彩答案：
会员 Jackc：
首先，刚才查了一些WBS的资料，发现这个题目有点问题。WBS并不能帮助计划确定测试任务的整体范围，它只能在计划提供的整体范围下细化各个具体任务属性。而任务整体范围则是在计划初稿中就已经设计好的，它的来源是市场或客户最终需求。
比如，在计划中规定测试范围是XXX票务系统的黑盒功能测试。而使用WBS则可以将这个功能测试划分为：阿尔法测试和贝塔测试（甚至划分到某个功能测试的粒度）
在国内的大公司，都是使用Project分解计划的，比如HW和ZTE。其实整个分解过程并不复杂。
1、好的WBS来源于一份完整的资源清单。一个好的资源清单相当于完成了70%的WBS
这份清单必须包括：
1）项目任务信息：测试对象简介、可追溯的需求、测试整体范围和限制、测试优先级和重点、测试过程描述以及测试方法（包括自动化部分）
2）项目资源信息：项目相关部门和成员/联系信息/职责（包括测试）、测试环境、缺陷管理/辅助工具、测试项目组之外可用的资源
3）其他关键信息：项目风险分析（假设与依赖）、项目测试度量标准（包括软件入口/出口、暂停/重启标准）、测试整体周期
2、整理出上面的清单后，就可以开始划分系统测试各个阶段。
大体上，标准的测试周期可以划分为：测试准备阶段——测试执行阶段——测试验收阶段三部分。这三大周期的时间段划分严格按照项目总体计划的时间来定。这个道理很简单，比如，项目规定5月11号交互客户，那么验收测试阶段必然要在4月底结束。
3、按第2步中的各个大阶段细分测试任务并部署测试资源。
以准备阶段为例。
1）准备阶段需要完成的任务主要包括：需求分析、用例设计、环境搭建。（可能还包括员工培训、设计测试策略以及各种评审等）
2）核对上一步的任务是否还能细分。比如，需求分析可以细分为各个功能模块的需求，比如，登录功能需求、新建用户功能需求、管理员用户功能需求等等；而环境搭建则可以分为缺陷管理工具的配置、测试服务器的配置、自动化工具的配置等等。
在此阶段选择的最小粒度通常会参考该任务执行人员或执行团队能力和该任务时间限制来决定，但是最终计划的最小粒度是“一个人在某段时间的任务”。
比如，“登录功能设计用例”额定时间是1周，如果预计测试人员A在1周内能完成这个任务，那么“登录功能设计用例”这个任务就可以作为最小的粒度的任务单元，不需要再细分了。
再比如，自动化测试工具配置额定时间为2周，而测试员B需要3周才能完成。则可以将自动化测试工具配置分为两部分，比如B完成设计脚本这部分，C完成安装和调试工具这部分。
同理，可以将上面的A/B/C换成独立的测试小组。
但是这样做需要注意一点：各个测试小组则需要根据自己所分配的任务再做一次WBS，生成的小组测试计划会被添加到系统测试总计划中。
4.、几个需要注意的地方
1）计划要符合SMAT原则。具体的，可量化的，可执行的，有时间限制的计划才是一个好计划。
2）争取尽量多的备用时间，实际测试总比预计的要花更多的时间。备用时间可以分开部署在3大阶段之后或全部部署计划最后。
3）部署专门的部门沟通人员，甚至可以细化到各个小组都进行相同的部署。在跨部门和异地合作中，这项工作会给项目节约不少的时间。
4）通过Project完成初稿后，切换到时间视图，检查的是每个员工每天的工作量。将工作量过重与过轻员工酌情重新分配。
原帖地址：http://bbs.51testing.com/thread-218610-1-2.html
版权声明：本文由会员Jackc首发于51Testing软件测试论坛每周一问活动。
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。
