【落叶162】《测试路上你问我答》（27）如何做好项目的测试工作量评估？

文/秋之川

【目录】

这是《落叶》文集里第 162 片落叶，希望你能喜欢，不为别的，只为这份坚持。

【背景】

同学 A 问：作为测试小组的组长，项目下来之后，我们怎么评估测试所需要的时间呢？评估点包括哪一些？是否有一个行业标准可供参考？

同学 B 问：前两天去面试，面试官问，当你拿到一个产品需求后，怎么去把它拆分成你想要的测试点。

我之所以把这两个问题放到一起回答，是因为我认为第一个问题的解答涵盖了第二个问题的解答。

【你问】

如何做好项目的测试工作量评估？

【我答】

估算方法常用的有几种：

1. 功能点估算，这种是在项目管理里中相对估算较准的，但耗时较长，一般也需要经过相应的培训和练习；

2. 经验法，也叫类比估算法，常用于同类型项目，或复杂度也相差不大的项目，参考历史项目数据估算；

3. 三点估算，给出最可能、最乐观和最悲观的三个值，用加权平均公式可以算出一个相对合理的估算值；

我们常用的方法应该是几者的结合：

粗评：

刚拿到项目或任务时，会用经验法和三点估算法得出一个粗略的评估。

这个根据你自己实际的项目环境而定是否需要，我做粗评的目的，是用于跟技术总监讨论项目计划，根据既定的发布时间反推最晚的提测时间或者是结合开发的评估估计最早能发布的日期；。

细评：

细评就是基于确定的需求范围或任务范围，已经研读过一遍需求文档或任务范围说明书，且没有什么大的疑问或不确定范围了。

我们常用 WBS 法，自上而下地将需求或任务分解开来，基本步骤如下：

树状结构的第一层：把需求功能点分解出来，也许子功能点较多，这里也可以分解成两层，第一层是大模块或分类，第二层是子模块或功能点；

第二层：针对每个功能点，从不同维度去分解场景，常见维度有：UI，交互，业务逻辑，数据检查，异常容错等，还有一些维度，比如有些跟服务端有频繁数据请求的页面或增删改的功能点还需要考虑性能维度，安全维度；

第三层：针对每个功能点基于不同的测试维度，分解成具体的测试点。这一层的所有测试点你就可以看作一个一个的工作包了，能够分配给具体的工程师去估算并做用例设计了；

到这一步，其实就已经回答了 B 同学的问题了，接下来我们再看基于这个树状结构图怎么得出测试时间的估算。

有两种方法：

第一种：估算出第三层所有测试点的测试时间，相当于自下而上就得出了总的测试点人日估算；

第二种：我们可以将第三层的每个测试点看作大小相当的工作包，那么每个所需的测试时间应该相差也不会太大。我们估算出一个工作包大概需要0.2个人日，那总的测试点人日估算 = 0.2 * 测试点个数；

到此为止，同学 B 的问题也回答完毕了。

但是，在实际的项目中，测试工作量其实还要加上下列几项内容：

1. 需求讨论；

2. 项目相关会议；

3. Bug的验证和回归测试；

4. 其它临时任务；

你可以给上述每一项都做个人日估算，加到最后的总人日里，也可以不细分上面那些项，而是在总的估算基础上多算20%加入最后的人日里，相当于预留了20%的buffer。

工作量估算建议最好拆分成设计阶段和执行阶段两部分，这样会便于制订测试计划，根据不同阶段的起始和结束时间来计算所需人力资源数量。

比如你设计阶段有5天，你评估量为10人日，而你执行阶段有10天，但评估测试量是100人日。

如果你算总账，那你总人日是110，时间是15天，你就需要7～8名测试人员，但实际上，你在设计阶段只需要3个人，而执行阶段你却需要10个人。

同时，分阶段评估，也便于你在每个阶段做进度跟踪。

《测试路上你问我答》里的 Q&A 27，如果是你要的，甚好！如果不是，你问，我答！

作者简介：14 年测试 + 11 年项目管理 + 11 年团队管理 = 一个测试老兵

【目录】