在制定系统测试计划的时候如何通过......（2010-5-31）（获奖名单已公布）

默默巫

       论坛上有不少关于测试计划的帖子，讨论都相对宽泛，这里希望就测试计划中如何确定测试范围一项进行具体的讨论。
       测试范围是测试计划中所有要素的先行者，后续的进度、任务、风险、度量等内容都要依靠其进行估计，马虎不得。其相关的理论、方法、工具都有不少，为了更有针对性，这里规定一下讨论的前提，既：系统测试计划中实现WBS的方法（因为该方法相对直观，使用和相关工具（如：Project）也比较成熟）。
       希望能够从树形结构如何规划、分解的粒度、工作包的定义、工作中的度量指标、对后续工作的指导意义等相关方面进行说明。

      注：创建工作分解结构（WBS）是把项目可交付成果和项目工作分解成较小的、更易于管理的组成部分的过程。工作分解结构是以可交付成果为导向的工作层级分解，其分解的对象是项目团队为实现项目目标、提交所需可交付成果而实施的工作。工作分解结构每下降一个层次就意味着对项目工作更详尽的定义。工作分解结构组织并定义项目的总范围，代表着现行项目范围说明书所规定的工作。

如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！

获奖名单
奖项	获奖名单	奖励	答案链接
三等奖	Jackc	100论坛积分	9#

yoosa035

各种敬仰啊，学习中...

wjlMydream

看晕了都。。。需要学习的太多了，加油！

zoufeifei_88

我也有点晕了、

806114786

谢谢，正是我所要找的东西，学习了……

cececece

看的有点晕

puchonghui

这题目纯粹在误导
分解结构和确定范围有啥关系。。。。难道分解之前还不知道到底要分解些啥么。。。

namisang

关注 学习

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完成初稿后，切换到时间视图，检查的是每个员工每天的工作量。将工作量过重与过轻员工酌情重新分配。



[ 本帖最后由 Jackc 于 2010-6-11 16:26 编辑 ]

havards

正需要呢，期待回答
BTW，默默你的头像都挺好玩啊，嘿嘿

zdlzx

1、树形结构如何规划：

先确定要提交哪些可交付物，并根据交付物确定要进行测试的类型。如要提交一个可运行的产品至少需要做功能测试。如果该产品对于性能有要求，要求提交性能测试报告，则相应的要做性能测试。如果对于产品支持的环境有要求则要求进行兼容性测试。

然后对每种类型的测试细分任务，并为每个任务设定相应的开始和结束时间，约束其制约关系。如，测试需求收集和测试环境的搭建可能并无必须的先后次序，而测试环境的搭建一定是测试数据准备的前置任务。当测试通过WBS进行明确的细分到一定程度后，对项目有一定了解程度的人就能看出你其实不准备做某种类型的测试了。

最后，把相关的资源分配到每个任务上（一般人力资源占大多数，也包含一些环境资源等）。

2、分解的粒度：

分解的粒度因项目而异，因交付成果的不同而异。一般分解到WBS下层的组成部分对于上层而言，是完成上层对应的可交付成果不仅是必要的而且是充分的即可。具体操作时一般最小的任务不会少于1天，但当然有些任务是在1天内并行。

3、工作包的定义：
根据PMBok的定义：属于工作分解结构底层组成部分的计划工作叫工作包，可以安排在进度表中，估算费用，进行监控。它能够可靠地估算工作费用和持续时间。

4、工作中的度量指标：
目前没有用到过WBS的度量指标。

5、对后续工作的指导意义：
一般来说，从WBS上可以看出一个项目的时间、内容、资源情况。WBS能够为后续范围核实和范围控制，以及后续资源的分配奠定一个基础。实际执行时的偏差能够帮我们及时发现并控制项目风险，并为今后更合理地控制范围、分配资源等提供借鉴。

qiuteng258

先对项目的目标和范围进行拆分，得到系统设计的目标和范围，然后再次拆分得到一个总的测试目标和范围。
然后对系统功能进行功能拆分，再进行工作包拆分，对于每个工作包再进行测试对象与测试范围的拆分，这样就得到了每个工作包的测试范围了。
测试范围=系统测试范围+每个工作包的测试范围。

XZTest

WBS在CMMI二级项目计划和PMBOK中都有涉及，确实是项目管理中常用到的，而且从开发的角度去看应该较成熟的。但是无论项目计划、开发计划、还是测试计划等等各式各样的计划，从内容上看都有很大的相似度，而且往往项目计划中对于测试工作的安排还是不够具体，必须制定测试自己的计划，因此针对测试工作可以借鉴这些内容。
    个人感觉WBS应该是测试过程中所有工作任务的树形结构罗列，从大到小，从粗到细。从顶层结构看，可以参考所选的测试测试模型和周期模型，如双V模型，将系统测试分为“测试计划”、“测试设计”、“测试实现”和“测试执行”四个阶段，每个阶段代表一个里程碑，然后进行细分，如“测试实现”继续分为“预测试项制定”、“测试用例写作”和“测试规程制定”，想分还可以继续分下去，如“测试用例写作”可以再次分为“A模块用例写作”、“B模块用例写作”、“用例评审”等等，依次类推。
    具体分解的粒度，最底层称之为“工作包”，即可以进行任务分配的“包”（将任务打包），看项目大小，这个包可以是以1人日为单位，也可以是1人周为单位，那么这样的任务分配形式比直接张三负责A模块，李四负责B模块的分工更加公平。
    这个树形结构一旦分解完成，可以估计每一级的工作量（人日）（上级工作量往往等于下级之和）。也就是说，测试计划中的工作量估计可以用WBS做为基础。
    另外测试进度安排也可以以WBS做为参考了，因为一定程度上上述WBS的分解是依据模型周期来制定的，加上开始和终止时间就是一份进度表，当然这里需要进行必要的调整，有些任务是并行的，如果用Project类似的工具绘制甘特图会更加直观。
    总之借鉴项目管理中的WBS可以做为测试计划的一个基础，和测试需求分析、跟踪关系、度量、任务进度等息息相关。

hotivy

貌似比较专业，等高人~但愿不是copy党的

msnshow

先占位，晚些再回复