度量之殇

没有度量

“我们公司的软件测试活动比较随机，测试产出的缺陷也没有统一管理起来。” “那如何来度量软件质量呢？” “凭主观印象拍脑袋吧……近期线上问题少，就觉得质量好。之前刚上线一个大版本，线上问题多，就觉得质量差一点。”

有度量，但无效

“我们每个季度都会评选质量之星，提Bug最多的测试有奖励哟~” “那我们是用缺陷数来度量软件质量的吗？效果咋样？” “基本上是用Bug数来度量。效果不好说，开发和测试经常为一个问题是不是Bug吵的不可开交。”

有效度量，但无积极影响

“我们每个迭代都会进行全面的缺陷分析，可以有效度量交付的质量。” “分析之后呢，有哪些后续活动？” “给全员发一个缺陷分析报告，别的没了。”

有效度量，积极影响，但一量到底

“我们每个迭代都会做缺陷分析，报告透明可视化，根据分析要点制定改进项并跟进。” “看上去还比较理想，关于度量还有什么问题呢？” “目前的缺陷分析持续了一段时间，该改进的都改的差不多了，再分析也分析不出更多的内容，感觉陷入了瓶颈，后面也不知道该怎么做了。”

质量度量建模

没有度量软件质量是极个别的情况，大部分软件还是有的。但度量的时机和选择的方式是否合理有效，就需要打个问号了。

理想的情况是：根据软件所处的不同阶段确定不同的度量目标，选取合适的度量方式，并根据所处阶段的变化适时调整，周期性的度量软件质量；每次度量的产出是形成有效的改进项，行动并观察效果，持续的对软件质量产生积极影响。

度量目标的确定直接影响度量方式的选择和度量效果的评估。 在确定度量目标时，需要综合考虑多种因素，如：软件所处的不同阶段，团队整体对度量成本和收益的预期，度量实施的复杂度，度量效果评估的重要干系人偏好等。在综合考虑多种因素后，确定适合软件现阶段的度量目标。

举个例子，当软件处于0-1阶段时，没有历史的度量数据参考，这时就不宜设置量化的度量目标，如减少前端缺陷、提升自动化测试覆盖率。此时应设置定性的度量目标，如目标用户访谈，团队内反馈收集等。再比如，大量日活的移动端社交软件，老板要求每个迭代提供详细的缺陷报告和前端性能报表，此时就需要设置具体的量化指标来作为度量目标了。

度量方式分为两类，定量分析和定性分析。定量分析是从数量和频率的角度解释因果关系，强调的是数据频率对结果的影响。而定性分析是从意义和影响的角度解释因果关系，强调的是复杂影响和价值判断。两者各有所长，且无法互相取代。

在质量度量方面，定量分析更多的是数据分析，通过数据采集和分析来挖掘背后的意义。如缺陷数量和分布统计，不同服务的测试覆盖率，持续集成各环节的构建效率等。而定性分析更多的是可以引发深度思考的活动，如真实用户访谈，重大事故的根因分析，质量成熟度评估等。针对不同的度量目标，可以选取的度量方式组合也是不同的。

度量关注趋势，而非数值

常见度量方式是用测试环境产生缺陷的数量来评估测试效率和软件质量，这属于定量分析。这种方式的优势是简单易操作，实施成本低。但劣势也较为突出：首先是度量不准，我们认为缺陷之间是不具备可比性的，由于缺陷的严重程度和紧急程度不同，我们不能说一个重大缺陷等于若干个普通缺陷，因此缺陷数量的绝对值累计是不具备统计意义的；然后是容易引起争议，针对开发和测试这两种不同的角色来说，这个度量标准的意义是完全相反的。

在这种度量背景下，测试的目标是破坏软件，缺陷越多越能体现测试的价值，因此测试会绞尽脑汁多提Bug。而开发的目标是实现功能，Bug越多说明实现效率越低。这种度量方式很容易引发团队的割裂、针对重大线上问题的追责、质量工作重点的偏离等现象，这是我们不愿意看到的。

那么问题来了，如果不是为了统计缺陷数量，我们收集缺陷数据的意义何在？首先，相比于数量绝对值，我们更应该关注的是数量或分布的变化趋势，比如：在某一时间段内缺陷提交量激增，我们则需要分析出缺陷激增的原因以避免潜在的风险；在大规模重构后，某后端服务的缺陷占比持续增长，我们则需要重点关注该服务，是否在重构时引入了不必要的改动，是否缺乏足够的测试保证原有功能不被破坏。

其次，我们在统计了不同缺陷维度后，形成缺陷分析报告，可以对团队提出有意义的改进项，跟进执行效果。再次，我们可以针对识别出的严重问题进行根因分析，找到某个痛点的有效解决方法，使度量真正的对质量产生积极的影响。举个根因分析的例子：

在上面的讨论中，度量方式既可以引入定量分析，也可以引入定性分析，或者干脆组合两者一起分析，都是可行的。只要我们选择了适合当下的的方式就好。

周期性度量 & 适时调整

度量周期的选择也很重要。除了第一次度量，后续的度量都是建立在上一次度量的基础之上的，那么我们期望达到的效果是，上一次度量产生的行动项已经被执行，并产生了稳定的积极影响，那么就可以进行下一次的度量了。一方面检验上次行动项的执行效果，另一方面产生新的行动项。度量周期的设置不宜过短，太短的话可能还来不及产生效果，或者团队还处在适应变化的震荡期中，无法度量成效；度量周期设置也不宜过长，过长的话可能已经引入了额外的变量，导致度量成果不准确。一般来说，我们以改进后两个迭代左右为周期来度量，是比较适宜的。

在持续度量一段时间后，度量陷入瓶颈，更多的度量并没有带来更大的积极效益。这种情况下，我们就需要思考如何重新确定度量目标，选择不同的度量方式，引入更多的变量来刺激变化产生。我们认为质量度量应该发生在产品生命周期的任何阶段，哪怕当下没有调整度量方式的需要。在什么时机调整才算“适时”呢？这需要结合全生命周期的质量度量建模和产品所处阶段的度量目标来综合判断了。

全生命周期的度量

迭代内度量

在迭代内的多个阶段，可以针对不同阶段关心的要素选择度量方式和指标。在一个迭代内或者软件的一个稳定阶段内，应采取相同的度量策略，聚焦于主要的观察点，不宜引入过多变化。

• 需求阶段：更关心需求质量，迭代划分是否合理；
• 实现阶段：更关心实现方案的有效性和复杂度，对需求的工作量预估是否准确等；
• 测试阶段：更关心缺陷趋势、缺陷分布和引入时机；
• 上线和运维：更关心系统稳定性，重大缺陷的响应力。

跨迭代度量

在跨迭代的全生命周期中，可以针对不同阶段的首要交付目标去做度量的建模。由于时间跨度较大，需要持续评估度量效果，适时调整度量策略，及时把控度量方向。

• 0-1阶段：没有已知的度量参考，偏重定性分析，可关注需求质量和工作量预估，收集团队内部反馈；
• 迭代阶段：需确保新增功能可用，已有功能不受影响；可做定性和定量分析；
• 变更阶段：有重大系统变更，需要全方位的度量，确保风险控制有据可循；
• 维护阶段：持续已有度量，提升效率减少浪费。
  

度量过程可视化

可以采用仪表盘来可视化整个度量过程，如下图：

• 横坐标是度量维度，纵坐标是迭代；
• 红绿灯代表健康度，文字表示该度量点上的关键事件；
• 每一行代表一次迭代内的所有度量及效果；
• 多行结合看，可以观察多个迭代的度量变化，以及团队关键事件如何影响度量。

总结

软件质量的有效度量，需要在确定度量目标后，选择合适的度量方式和度量指标，持续的度量和反馈，并适时调整度量策略。做到软件全生命周期的有效度量，才能真正为软件研发过程降本增效，事半功倍。

yxn125

公众号：圆小豆的美梦工场