敏捷开发中有效度量测试绩效的一个指标

软件项目大家通常最关心的就是Quality (质量)、Cost (成本)、 Delivery（交期）。管理者希望以此为结果，进行过程分解，建立一套结果到过程的分解指标，从不同的角度，不同的形式通过数据形式将这些属性展示出来。而同时我们也要关心这些数据将为未来的改进提供什么样的帮助。

针对开发团队通常会系统统计BUG类指标，如：和统计Bug数量，Bug重开率，Bug分布，Bug原因统计等不同，目的是希望找到BUG产生的原因找到集中的因素进行改善从而提高产品质量。我们知道Bug密度降低，浪费在Bug修复时间也会减少，就可以提升项目的交付速度。而且，Bug密度通常也作为衡量研发人员开发质量维度的指标之一。

那么针对测试团队，我应该如何通过确定合适的指标来推动改善促进项目的交付和质量呢？这个也是很多公司感到困扰的地方。通常选用的，测试泄露率，指标为例，设想是较好的，目的是希望测试设计的用例能够覆盖的更全，从而降低泄露到客户端的缺陷。但是，仅仅这一个维度的指标，会导致测试团队成员过于偏向测试用例的完备性，而不考虑测试的效率。一个产品缺陷空间实际是未知的，想完整的验证完理论上是不可行的，而交付是有时间要求的。因此，测试团队除了要保证不泄露外，也需要提升自己的效率，能在有限的时间内完成测试，保证达成交付目标。

我在担任测试总监时，通常会给测试团队设置一个考核指标，对于提升测试效率和质量都有比较好的促进作用：

Bug平均生命周期=Bug被验证解决时间-Bug被发现登记的时间

考核方向为，平均生命周期越短越好。根据排队理论，的利特尔法则，采用敏捷开发模式时可以有如下公式：

平均交付周期=平均在开发管道并行的需求数/平均交付速率

平均交付周期：指需求从进入开发团队到完成交付的时长；

并行需求数：整个开发过程管道中并行的需求数目，处于开发各阶段的需求之和；

平均交付速率：指单位时间交付的需求数

在并行需求不变的情况下，提升平均交付速率，就可以提升交付速度，而交付速度是可以提升团队的市场竞争力的。单位时间交付需求取决于：

1、开发团队基于现有的流程工具实现需求的能力（这一系统通常短期基本很难有所改进）

2、Bug 修复时间，在这个时间中包括：研发确认BUG时间+定位Bug时间+测试回归测试时间+研发转测试的交接准备等待时间

而研发确认Bug时间，通常取决于测试提交的Bug描述和复现过程是否清晰；

定位Bug时间，通常取决于研发能力和记忆的衰减，定位时实际研发人员很大比例时间是浪费在重新回忆实现过程找到修改入口，研发能力无法短期提升情况下，可以通过加快反馈速度来让研发快速找到定位点，降低时间的浪费。从而降低向整体的交付周期。

通过上述分析其实我们可以发现，测试其实对于提升项目的交付周期是有很大的促进作用的。因此，通过驱动测试团队去改善Bug平均生命周期，可以让测试团队积极的改善测试流程和测试工具，也可以提升测试团队工作主动性和专业度，还可以提升团队协同，测试积极推动研发及尽早的清除Bug。