如何评估测试工作量

场景一：合同前的工作量估算
场景描述：
（1）没有实施过CMMI2级
（2）合同未签，需要给客户报价
（3）有客户的概要需求，有类似的项目数据可供参考
（4）需要估计整个项目的总工作量，以便于估算总成本，给客户报价

估算步骤：
（1）寻找类似的历史项目，进行项目的类比分析，根据历史项目的工作量凭经验估计本项目的总工作量；
（2）进行WBS分解，力所能及地将整个项目的任务进行分解；
（3）参考类似项目的数据，采用经验法估计WBS中每类活动的工作量；
（4）汇总得到项目的总工作量；
（5）与第（1）步的结果进行印证分析，根据分析结果，确定估计结果。

场景二：基于详细需求的经验估计
场景描述：
（1）只有详细需求，没有历史数据
估算步骤：
（1）WBS分解，将任务分解到一个人或者一个小团队可以执行的颗粒度；WBS分解时要识别出所有的交付物、项目管理活动、工程活动等。
（2）采用经验法估计每个活动的工作量；
（3）汇总得到：每个阶段的工作量、项目的总工作量。
其他说明：
　　在该场景下，只使用了经验法，无法对结果进行印证，难以判断结果的合理性。

场景三：由编码估算整体
场景描述：
（1）有类似项目的历史数据
（2）有编码活动的生产率数据
（3）有详细需求
（4）实施了CMMI2级，但是没有积累历史项目的工作量分布数据
估算步骤：
（1）产品分解，将系统分为子系统，子系统分解为模块；
（2）WBS分解，将任务分解到一个人或者一个小团队可以执行的颗粒度；WBS分解时要识别出所有的交付物、项目管理活动、工程活动等。
（3）建立WBS分解中的活动与产品元素的映射关系，识别出WBS中哪些活动可以采用模型法估算；
（4）估计产品元素的规模，可以采用代码行法或功能点法，并估计每个产品元素的复杂度、复用率等；
（5）根据历史的编码阶段的生产率数据和产品元素的规模估计、复杂度、复用率等采用模型法计算每个产品元素的编码工作量；
（6）根据历史的类似项目的数据及估算人的经验估计其他活动的工作量，可以采用经验法。
（7）汇总得到：每个阶段的工作量、项目的总工作量。
其他说明：
在该场景下，混合使用了经验法与模型法，这2种方法互相补充，而不是互相印证。

场景四：由总体印证基于WBS的估计
场景描述：
（1）有类似项目的历史数据
(2) 有类似项目的全生命周期的生产率数据（含管理工作量）
（3）有详细需求
（4）实施了CMMI2级，但是没有积累历史项目的工作量分布数据
估算步骤：
（1）产品分解，将系统分为子系统，子系统分解为模块；
（2）估计产品元素的规模，可以采用代码行法或功能点法；
（3）累计出整个产品的总规模，并估计产品总体的复杂度、复用率等；
（4）根据类似项目的全生命周期的生产率数据和产品的总规模、复杂度、复用率等采用模型法计算总的开发工作量；
（5）WBS分解，将任务分解到一个人或者一个小团队可以执行的颗粒度；WBS分解时要识别出所有的交付物、项目管理活动、工程活动等。
（6）根据历史的类似项目的数据及估算人的经验估计所有活动的工作量，可以采用经验法。
（7）汇总得到：每个阶段的工作量、项目的总工作量。
（8）与第（4）步得出的工作量进行比较印证，如果偏差不大，则以第（7）步的结果为准，如果偏差比较大，要仔细分析原因，可能的原因举例如下：
　　类似项目的生产率数据不适合本项目；
　　WBS分解的颗粒度不够详细；
　　估算专家的经验不适合本项目；
　　具体任务的估计不合理；
　　针对原因，对估算的结果进行调整，使其趋向合理。
其他说明：
　　在该场景下，对于项目的总工作量有2个结果或者多个结果，这些结果可以互相印证，以发现估算过程中的不合理之处，是估计更加合理。

场景五：三维印证基于WBS的估计
场景描述：
（1）有类似项目的历史数据
(2) 有类似项目的全生命周期的生产率数据（含管理工作量）
（3）有详细需求
（4）实施了CMMI3级，有历史项目的工作量分布数据（阶段分布、工种分布）
估算步骤：
（1）产品分解，将系统分为子系统，子系统分解为模块；
（2）估计产品元素的规模，可以采用代码行法或功能点法；
（3）累计出整个产品的总规模，并估计产品总体的复杂度、复用率等；
（4）根据类似项目的全生命周期的生产率数据和产品的总规模、复杂度、复用率等采用模型法计算总的开发工作量；
（5）根据历史项目的工作量分布数据及第（4）步估算的项目总工作量，计算：
 每个阶段的工作量
 每个工种的工作量
（6）WBS分解，将任务分解到一个人或者一个小团队可以执行的颗粒度；WBS分解时要识别出所有的交付物、项目管理活动、工程活动等。
（7）根据历史的类似项目的数据及估算人的经验估计所有活动的工作量，可以采用经验法。
（8）汇总得到：每个阶段的工作量、每个工种的工作量、项目的总工作量。
（9）与第（4）、（5）步得出的工作量进行比较印证，如果偏差不大，则以第（7）步的结果为准，如果偏差比较大，要仔细分析原因，可能的原因举例如下：
　　类似项目的生产率数据不适合本项目；
　　WBS分解的颗粒度不够详细；
　　估算专家的经验不适合本项目；
　　具体任务的估计不合理；
　　针对原因，对估算的结果进行调整，使其趋向合理。
其他说明：
　　在该场景下，对于项目的总工作量有2个结果或者多个结果，并且采用2种方法都得到了每个阶段、每个工种的工作量、项目的总工作量，可以从上述的3个维度对这些结果进行互相印证，以发现估算过程中的不合理之处，是估计更加合理。

----------------------------------------------------------------------------------

WBS是项目范围管理中的技术，它是确定项目范围的一种主要技术，也是进行成本、资源的估算的基础。

 

 

测试工作规划

　　测试工作的规划，至少包含两项要点：测试目标的订定与测试资源的配置。

　　测试目标的订定，最重要的在于软件通过的准则，亦即测试何时方可结束。

　　对于测试的要求可简单区分为二：一种是通过目标所订之软件品质；一种是在既定资源内达到最佳成效。前者要求山头一定要攻下，不达目的绝不停止。譬如目标为单位测试时间的错误发现率须低于某数字，若超过了就得延长测试。此种方式适用于品质要求较高的软件。至于后者则是上市时间已宣布，无法更改者，其目标着重于铲除最严重的错误。此种测试较着重测试的准备、经常对测试执行与除错设定时限与数量要求，其中最容易遵循的准则即为：重要功能永远先测。这两类测试的需求不同，足以影响到测试的计划、测试的顺序与关心的重点。

　　至于测试资源配置适当性，则是评估测试目标能否达成的重要参考指标。测试人员需要合理的测试资源，譬如要求总研发人力的20%以上。总时程的1/3以上。人力不足，测试流于形式，时程过短，找到错误也来不及除错，均不可取。除了测试在研发的比重，也需注意测试工作本身在规画管理、规格个案订定、测试执行、回归测试、训练准备工作的人力分配。人员的训练与设备的安排尤其容易轻忽，需加以注意。不同阶段测试的资源配置，也必须加以考量，如此可避免测试集中于功能测试，忽略系统测试。这些工作的适切安排，有助于协助测试工作时时都执行最重要，也最有效的测试。

 

生活需要一点点童心，工作也一样，于是选择了这个名为童话仙境的空间，似乎不错！