做项目的数据采集,效率是绕不开的一个数据需求。我们一般都会用生产率来衡量项目的效率,如编码的生产率,测试用例设计的生产率,测试执行的生产率。生产率的标准定义是:生产率是衡量每单位投入的产出量,是用来表示产出与投入比率的术语。但是,在软件项目中,计算生产率会遇到一个问题——产出量的衡量方法。对于开发,代码量是最直观的一个产出衡量度量,可是,我们知道,每行代码的难易度不一样。两个项目,即使它们的生产率都是0.8KLOC/PM, 它们的效率也可能大相径庭。用Function Point,Cocomo则能在一定程度上避免这个问题。
在测试项目中,也有同样的问题。一般情况下我们会用单位时间执行的测试用例数量来度量测试执行效率。
测试执行生产率=被执行的测试用例总数÷执行测试用例的总时间
可是,有些测试用例的执行时间只需要几秒钟,有些测试用例的执行时间需要几分钟甚至几十分钟。两个项目,即使第一个项目1小时执行100个测试用例,另一个项目1小时只执行10个测试用例,我们也不能说第二个项目比第一个项目效率低。于是,用标准的生产率来衡量测试执行效率,无法进行项目之间的横向比较和借鉴。历史数据的作用也就大打折扣。
为了解决这个问题,一个方法是测试用例设计工程师在设计测试用例时,就估算并记录每个测试用例所需的执行时间,我们将这个时间值称之为测试用例的消化点数(如一个测试用例需用5分钟执行,则它的消化点数是5)。然后用被执行的测试用例的消化点总和来度量产出的规模。
测试执行生产率=∑被执行的测试用例消化点÷执行测试用例的总时间
它的单位是消化点/人时。
这样计算得到的生产率就解决了测试用例大小不同的问题,可以用来在不同的业务线,不同的项目之间比较效率和作为估算依据了。<