在度量这件事上，坐而论道可能是相对容易的然而度量实施起来却未必容易，尤其是针对定制化要求的度量实施起来会是一个复杂的工程问题，甚至可以说度量的实施在很大程度决定了度量能为组织在某个领域改进发挥的效果。
这么说一点也不夸张，比如目前常见的代码度量指标如有效代码行、测试覆盖率、圈复杂度等都是借助工具完成采集和统计，为何它们在实施的时候不考虑手工计算呢？答案不言而喻——太麻烦了！并且可以预见到的如果上面这些指标只能手工计算那么它们很快就会被弃之不用连发挥它们作用的机会都没有了。
因此度量的实施不只是一个大胆而又新潮的概念指标而是要解决围绕这个指标产生的问题，其中我认为最关键的是下面三个：
- 从哪里来？指标依赖的数据从哪里提取，采用何种搜集方式较为方便，是直接提取还是间接提取，提取的过程是否存在其他依赖条件；
- 长什么样？指标依赖的数据是怎样组织的，是否存在多维度，其中哪些是关键数据，与之关联的数据有哪些；
- 怎样使用？搜集到的数据怎么样转化成指标，怎么去分析指标表现出来的特征，如果获得的结果与预期的不一致可能是什么原因导致的；
不久前我就与上面三个问题进行了一次激烈的碰撞，我要实施的度量是观测自动化测试防护的有效性，其目的是想了解项目输出的自动化测试用例的质量，即是否能够起到拦截作用，同时还希望研究导致测试用例失败的高频次问题有哪些是否存在改进的可能。
度量的目的已经十分清晰但对于度量的对象还需要进一步地细化。首先是如何理解有效性。通常我们认为建立测试防护后，当交付品的功能发生了可观测的变化并被测试防护捕获则认为这样的防护就是有效；然而还有另一种“有效”也时常发生，当交付品进入外部测试或商用时发生了问题或故障，于是为了检测这些外部的问题和故障又在测试用例中补充了特定的用例，这样针对性的防护也一定是有效的。虽然两者都是有效，但需要考察的数据是不一样的。前者要采集自动化测试失败用例的次数，更确切地说是采集自动化测试由于功能变更导致失败的次数；而后者则要采集泄漏到外部的故障关联的测试用例数量。显然前者是我们此次工作的关注点，也就是说我们的目标至少是获取由于功能变更导致自动化测试失败的次数，注意它是我们的目标却不一定是我们要的数据，数据如何选择和构造是实施问题，接下来就要逐一回答实施过程中的三个问题。
数据从哪里获取？由于我们要获取自动化测试失败的数据，因此从自动化测试运行结果中搜集是首选方案，即从CI中获取自动化测试运行结果。数据源的问题是否解决了呢？别急，还需回答几个细节问题。
- 如何从数据源搜集数据呢？Jenkins的RF插件能汇总自动化测试运行结果，可以采用两种采集方式。一种是手工采集，一般失败用例的数量并不多所以手工采集是可行的；另一种是工具采集，xml格式的运行结果只要在自动化测试运行的流水线中增加相应的处理就能完成采集；
jenkins上的RF插件
-
数据采集的频率是怎么样的？全量的RF每天执行一次，因此运行结果也要按照每天的频度进行采集；
-
数据采集需要持续多久？数据的分析通常要考虑历史趋势变化，加之度量目的中还提到研究改进的可能性，即对改进效果也应进行监测与评估，所以要进行较长时间的采集；
初步分析的结果是需要借助工具从CI上的自动化测试运行结果中搜集失败用例数据，不过开发工具需要时间且采集的数据量其实并不大，因此先用手工采集建立度量，同时开发工具为后续自动化做准备。
数据长什么样？对照RF运行结果中的失败用例，原始数据可以形成下面这样一张表格。
原始数据
有了原始数据后，还要考虑衍生数据，通过衍生数据还能产生更多分析的样本。在这里我们的衍生数据是对失败用例原因的分析，包含下表所示数据。
衍生数据
有了上面两张表格（真的是两张表格，纯手工统计），对自动化测试防护的有效性的度量所需的数据基本上就齐全了，接下来就是如何使用这些数据。
数据如何使用？要分析自动化测试防护的有效性显然是要对失败原因进行分类，区分出实现拦截（原因分类为代码功能故障或用例未调整）的情况。实际上该数据还能细分，比如按照版本统计、按照代码模块（用例编号对应到代码模块）统计；再进一步可以分析哪些用例比较容易发现问题（即失败频率高且为有效防护），分析高频问题是哪些，分析版本交付质量情况（如发现某个版本用例失败频率较高且为有效防护就说明该版本质量需要进行关注），分析失败用例定位周期等。
在实际运用过程中，数据就告诉了我们一个十分有意思的现象，RF用例可通过标签来标注在该用例归属哪个版本并且需要在该版本自动化测试中被执行，而在失败的原因中出现了较多忘记给RF标注标签的说明并且RF标注的标签为norun（不执行），这就说明交付自动化测试用例实际发挥的防护作用很有限（仅发挥了验收作用），因为有大量的不执行用例。再进一步深究不执行用例的原因发现由于这些用例运行需要特定的硬件设备而CI环境中缺乏这样的设备，发现这一问题后项目立即着手进行了改进。因此一旦有了可度量的数据，项目的改进就有了定量分析的参照，这要比依靠少数管理者的感觉要来的靠谱和准确。
网友评论