文/秋之川
这是《落叶》文集里第 330片落叶，希望你能喜欢，不为别的，只为这份坚持。
第十五章 测试工作量估算该怎么做呢？
今天快下班的时候，Luck 把他的测试工作量评估发给了我，我打开一看，居然要 20 个人日，而我心里的估算大致在10个人日，他估的比我估的整整多了一倍。
于是，我就问他测试的主要范围是什么？这20个人日是依据什么估算出来的？
他说他是根据以往类似需求测试量来判断的，大概要20个人日，并没有什么特别的依据。
我跟他说，你用的其实就是经验法，我们常用的估算方法有这么几种：
-
功能点估算，这种是在项目管理里中相对估算较准的，但耗时较长，一般也需要经过相应的培训和练习；
-
经验法，也叫类比估算法，常用于同类型项目，或复杂度也相差不大的项目，参考历史项目数据估算；
-
三点估算，给出最可能、最乐观和最悲观的三个值，用加权平均公式可以算出一个相对合理的估算值；
我跟 Luck 说，在刚拿到需求清单时，我已经用经验法和三点估算法做了一个粗评，主要是用于跟老大讨论项目计划，根据既定的发布时间反推最晚的提测时间或者是结合开发的评估估计最早能发布的日期。
现在让你们做的其实是细评，是基于确定的需求范围，研读过需求文档之后做的工作量评估了，这时候，你就不应该还是采用经验法了，而是应该使用 WBS 估算法（Work Breakdown Structure）。
基本步骤：
-
第一层：把需求功能点分解出来，也许子功能点较多，这里也可以分解成两层，第一层是大模块或分类，第二层是子模块或功能点；
-
第二层：针对每个功能点，从不同维度去分解场景，常见维度有：UI，交互，业务逻辑，数据检查，异常容错等，还有一些维度，比如有些跟服务端有频繁数据请求的页面或增删改的功能点还需要考虑性能维度，安全维度；
-
第三层：针对每个功能点基于不同的测试维度，分解成具体的测试点。这一层的所有测试点你就可以看作一个一个的工作包了，能够分配给具体的工程师去估算并做用例设计了；
-
根据树状结构图估算测试工作量：
-
第一种：估算出第三层所有测试点的测试时间，相当于自下而上就得出了总的测试点人日估算；
-
第二种：我们可以将第三层的每个测试点看作大小相当的工作包，那么每个所需的测试时间应该相差也不会太大。我们估算出一个工作包大概需要0.2个人日，那总的测试点人日估算 = 0.2 * 测试点个数；
- 在实际的项目中，测试工作量还要加上下列几项内容，给每一项都估算大致的人日，再加到最后的总人日里。也可以不细分，而是在总的估算基础上多算20%，再加入最后的人日里，相当于预留了20%的 buffer：
- 需求讨论；
- 项目相关会议；
- Bug的验证；
- 回归测试；
- 其它临时任务；
Luck 听完之后，跟我说：“我明白了，原来还可以这么精确地估算工作量啊，那我现在就去试试，然后再发给你看看，有没有问题，跟你的粗评有多大差距。”
“好，有任何问题随时可以找我。” 我边说边合上了手边的 PMBOK 学习笔记。
《告诉你如何从执行测试到管理测试》带你迈出第（15）步！，点击这里可查看完整地图
作者简介：14 年测试 + 11 年项目管理 + 11 年团队管理 = 一个测试老兵
网友评论