度量数据到底度量了谁，谁又该去度量

前些日子听同事说，XXX部门做了个工具平台，可以度量每个开发人员所负责模块的UT情况，很感兴趣这个平台是如何度量的，于是要了工具的网址，准备上去一探究竟。

登上平台胡乱看了两眼，我已经对这个所谓的开发测试能力度量系统失去了信心：我所熟悉的一个模块，由于系统比较特殊当前实际上并没有在代码提交环节做UT测试，然而，平台上显示的UT测试充分度评估竟然是100%！这个平台并没有起到应有的度量作用！

喊来之前的同事了解了下这个平台上显示的数据背后的统计规则，真是让我笑掉大牙：平台的统计思路是：要求开发人员自己反馈所负责模块的所有特性和需求内容，将这些数据放入后台作为功能的全集，而后，要求开发在UT用例中标识用例具体测试的是哪一个特性或需求，然后将其对应起来，而这个所谓的充分度度量，实际上是用已经有用例对应的特性数作为分子，开发人员之前反馈的所有特性数作为分母，通过这个比值算出来的。

稍微想一下都会意识到：分母的数据是开发人员自己反馈的，分母中的用例对应关系也是开发人员自己标识的，既然都需要开发人员自己反馈，让开发人员给个测试充分度的反馈值就可以了，何必还要计算呢？

所谓度量，最基本的就应该是可信，上文中说的这个平台，度量数据全部要求被度量者自行反馈，数据的可信程度完全取决于被度量者的诚实程度，而如果这个度量数据再和被度量者的利益有所关联（比如测试充分度达到xx的奖金多发10%，或者充分度不达标影响晋升、考核等），恐怕这个诚实程度就要打个问号了。看似度量了开发人员的能力，实际上度量的是道德。这里要说明下，上文提到的我所熟悉的模块，我也私底下找对应的开发人员了解了下，之所以数据是100%，是因为开发人员根本就没有反馈分母数据---这就更可笑了，平台的设计人员显然是考虑到分母为0时的容错的，但是却没有结合实际的业务情况作出应有的判断，在我看来，给0%都比给100%更能说明问题

当然，光是吐槽改变不了任何事情的，鉴于上述问题，我认为要做到数据可信，其实并不难，只要做到数据的客观反馈即可。最简单的办法可以通过转移反馈人为利益无关者的方式收集数据：分母可以通过项目SE反馈，分子数据可以通过测试人员评审后反馈，这样反馈的数据才能更接近真实；当然，既然做的是度量平台，更多的应该考虑自动化手段，毕竟，所谓的利益无关者也不是总有时间去做反馈工作：分母可以通过构建特性基线数据库或需求数据库，从中获取数据（事实上，公司其实是有这样的平台并且运作成熟），分子数据可以通过构建UT用例基线库进行实时统计。其实自动化仅仅是工具，还需要一些流程上的优化，使工具可以落实在日常工作中才行。

总之，无论是自动化度量还是非自动化度量，千万不要让能力度量变成道德度量。