软件度量（一）: 测试执行效率的度量

做项目的数据采集，效率是绕不开的一个数据需求。我们一般都会用生产率来衡量项目的效率，如编码的生产率，测试用例设计的生产率，测试执行的生产率。生产率的标准定义是：生产率是衡量每单位投入的产出量，是用来表示产出与投入比率的术语。但是，在软件项目中，计算生产率会遇到一个问题——产出量的衡量方法。对于开发，代码量是最直观的一个产出衡量度量，可是，我们知道，每行代码的难易度不一样。两个项目，即使它们的生产率都是0.8KLOC/PM，它们的效率也可能大相径庭。用Function Point，Cocomo则能在一定程度上避免这个问题。

在测试项目中，也有同样的问题。一般情况下我们会用单位时间执行的测试用例数量来度量测试执行效率。

测试执行生产率=被执行的测试用例总数÷执行测试用例的总时间

可是，有些测试用例的执行时间只需要几秒钟，有些测试用例的执行时间需要几分钟甚至几十分钟。两个项目，即使第一个项目1小时执行100个测试用例，另一个项目1小时只执行10个测试用例，我们也不能说第二个项目比第一个项目效率低。于是，用标准的生产率来衡量测试执行效率，无法进行项目之间的横向比较和借鉴。历史数据的作用也就大打折扣。

为了解决这个问题，一个方法是测试用例设计工程师在设计测试用例时，就估算并记录每个测试用例所需的执行时间，我们将这个时间值称之为测试用例的消化点数（如一个测试用例需用5分钟执行，则它的消化点数是5）。然后用被执行的测试用例的消化点总和来度量产出的规模。

测试执行生产率=∑被执行的测试用例消化点÷执行测试用例的总时间

它的单位是消化点/人时。

        这样计算得到的生产率就解决了测试用例大小不同的问题，可以用来在不同的业务线，不同的项目之间比较效率和作为估算依据了。

        不过，由于项目背景和要求不一样，在我的公司，大部分项目还是没有在设计时就估算每个测试用例所需的执行时间。考虑到一条产品线的测试用例还是有一定的稳定性（粒度大小），我对上面的计算做了如下改进。在一段时间里，使用被执行的测试用例数和这些测试用例的纯执行时间总和来计算平均的测试用例消化点数。然后用这个平均消化点数乘以测试用例数来计算消化工数总和，从而得到测试执行生产率。

 

我们一般会用该产品线的1～2个项目来计算该产品线的平均消化点数。这里，纯测试执行工数的定义是直接执行测试用例的工数；执行测试用例的总工数则包括测试准备工数，纯测试执行工数，登录和对应Bug的工数，Q&A的工数。

 

下面是某个业务中多个产品线的生产率，第二列是用消化点计算的生产率，第三列是用测试用例数计算的生产率。从归一化后的方差来看，使用消化点计算的生产率明显比用测试用例个数来计算的生产率要更能真实反映不同项目效率的差异。这样的数据也才更有横向比较和参考的价值。

 

项目代号

消化点/PH

Use Case/PH

A

41.4

4.7

B

27.6

1.8

C

43.2

5.1

D

43.8

4.3

E

50.4

6.6

F

53.4

6.5

G

26.4

1.8

H

42

5.1

I

49.2

5.3

平均值

41.9

4.6

归一化后方差

0.05

0.15