关于工作量评估的方法

日常工作中，我们总是需要对未来的任务，进行工作量的评估，这也是项目启动最重要的先决条件，目前这部分主要是基于WBS估算法来进行的，今天跟大家分享一下自己的相关思路以及具体的流程。

第一步：确定测试方案

评估工作量，首选需要确定做哪些工作，因此确定测试方案是评估工作量的前提条件。测试方案中常见的工作内容如下：新功能测试、老功能回归测试、适配测试（兼容性测试）、二轮测试、冒烟测试

第二步：根据测试方案分别评估工作量

在确定测试方案之后，再根据具体工作内容评估对应的工作量。

新功能测试

1、首先。对需求进行功能模块的拆分。

基本思路：

• 可依据产品或交互文档中的模块进行拆分（此时还为进入开发阶段，因此还无法参考开发实现）。
• 进行功能模块拆分时，粒度尽量拆的细一些，从模块到子功能，甚至可以拆到小的功能点。粒度越细，预估工作量的精度越高。

2、其次，根据拆分结果，逐一评估工作量。

基本思路：

• 根据以往的测试经历，类似的功能点，之前的工作量可以直接复用。 例如：以前测试过登录的功能，本次需求中的登录功能与之前测试过的大体相同，那么可以直接沿用之间测试时的实际工作量。 又如：测试过文本编辑的相关内容，本次需求中有类似的需求，那么可以直接沿用之前测试时的实际工作量。
• 根据细化后的功能，通过产品针对该功能的描述或交互中的内容，预估case的量级，然后根据case数量与工作量的对比经验值，预估工作量。比如1小时产出50条case。
• 根据产品或交互文档中描述的内容多少，评估工作量。理论上需求描述的内容越多，case量越多。
• 需要充分考虑隐性需求（即产品在需求文档中没有直接体现的内容），视情况增加预估的工作量。 比如：登录功能，产品需求中针对登录成功、账户名密码错误、网络失败的情况，均给出了相应的提示，但针对隐藏的各种登录错误类型的提示，并没有明确的需求描述。

3、然后，需要从用例设计和用例执行两个方面进行评估。一般情况下：

• 用例设计的时间与用例执行的时间，接近1:1。
• 偏界面功能的用例设计时间，可能略大于执行时间。因为偏界面的case执行操作比较快。
• 操作复杂的功能，用例设计时间会小于执行时间。 例如：执行case时涉及到：配置环境、操作数据库、设置前置条件等等

4、最后，预估可能影响工作量的风险，视实际情况调整工作量的预估。包含但不限于以下内容：

• 相关需求的测试，是否需要配置环境，比如搭建测试服务器。
• 相关需求的测试，是否涉及特定的测试工具或操作方法，是否存在学习的成本。
• 相关需求中，是否存在大量不确定的预期结果（需要视开发实现情况而定），这种情况较多的话，后期需要大量的沟通和确认的工作，因此需要增加相关的工作量。
• 需求的稳定性，如果需求的稳定性较差（后续存在需变的风险），可以提前评估风险，预留出相关的工作量。

老功能回归测试

1、首先，确定需要回归的老功能模块都有哪些。

2、然后，确定每个功能需要回归的粒度：

• 执行全部用例
• 执行checklist
• 执行冒烟case。

3、最后根据以往执行对应任务的工作量，对应预估本次的工作量。

注意：有的时候在开发介入前，很难给出相应的影响范围，那么也没办法准确评估老功能回归测试的范围，因此这种情况下，这部分的预估工作量，可以作为风险与产品沟通备忘。

适配（兼容性）测试

1、首先，确定需要关注适配（兼容性）的功能点有哪些。比如主流程、UI层面等。

2、然后，评估这部分内容的大致工作量，预估单个环境下执行的工作量。

• 具体的评估方法：可参考新功能测试时，通过预估测试用例数量来评估工作量的思路。

3、最后，再根据确定的适配（兼容性）范围列表中的数量，乘以单个环境下执行的工作量，计算出总的工作量。

• 如果适配（兼容性）范围列表的数量较多，考虑到实际操作中熟练程度的提升，可以一定程度的缩减工作量。

二轮测试

1、确定每个模块的回归粒度：checklist或冒烟case。

2、这部分一般都有固定的工作量，根据以往的经验值，来计算二轮测试的预估时间。

注意：有的时候在开发介入前，很难给出响应的影响范围，那么也没办法准确评估老功能回归测试的范围，因此这种情况下，这部分的预估工作量，可以作为风险与产品沟通备忘。

冒烟测试

思路同“二轮测试”

此外，关于工作量评估结果的审核

注意事项：

1、工作量评估结果的审核，需要由经验更为丰富的工作人员来进行，具体的审核方式，与评估工作量的过程类似。

2、工作量评估结果的审核，应当采用团队内部人员的平均值作为衡量标准。

3、工作量评估结果的审核，可以借鉴开发同学评估的工作量，测试的预估工作量不会大于开发的预估工作量，如果超过开发工作量，那肯定存在问题。