《软件测试策略》——测试相关技术（度量与测量）（四）

京东购买链接：https://item.jd.com/10205955087769.html

 

6.5 度量与测量

在撰写本书时，我们始终在两种极端之间寻求平衡：一边是盲目乐观地认为简单的数字足以量化一切；另一边则是对软件度量标准抱有明显的反感态度，认为它们无法准确反映软件开发的复杂性。而正如常理所示，或许中庸之道才是最佳选择。

在我们的讨论中，度量指标是一个带有标签的数值。单独的数字“3”并无太多含义，但如果说有 3 位程序员正在开发某个功能，这就构成了一个度量指标。我们在日常交流中经常使用度量指标，例如，“我们计划周五下午 3 点发布，还有 5 天时间”，这里就提到了两个不同的度量指标。根据《牛津英语词典》的定义，我们所使用的度量指标就是一套测量体系。我们无时无刻不在进行各种测量，因此，我们不应拒绝度量指标这一概念。

然而，“度量”这个词还有一层更微妙的含义，就好像“如果你不能将其（转换成数字）衡量，你就无法管理它。”我们并不完全认同这一点。我们认识的大多数人都是通过照镜子决定是否理发，少数人可能会在日历上安排时间，但我们还没听说过有人会用尺子量头发的长度来决定是否该剪发。在软件领域，将事物简化为数字确实有其优势。你可以衡量事物，设定目标，然后定期回顾更新。如果一切按计划进行，那就很好，你可以自我祝贺并享受一些休闲时光。如果情况不妙，那么就督促你的团队成员加快工作。如果情况严重，那就需要他们给出解释并定期更新进展。

仪表板（Dashboards）作为一种工具，帮助人们即使在不了解过程细节的情况下，也能概览并掌握全局。但如果度量失衡，就无法达到应有的效果。

度量失衡

最简单的度量方案就是统计 bug 数量。当发现大量 bug 时，测试人员和测试分析师会受到奖励；相反，当 bug 数量较少时，则表示开发人员编写了质量较高的代码，因而也会受到奖励。项目经理则希望看到 bug 数量为零或在一个较低水平，以便他们能够做出产品发布的决策。

不幸的是，最简单的方法并不总是最好的，因为它不可避免地会导致失衡的行为。

每次见到这种度量体系（包括在咨询项目中），我们都会发现它会导致测试人员对每个拼写错误，甚至是每个有争议的拼写错误都提交一个 bug。与此同时，开发人员则会花费精力去争论此 bug“不是 bug”或“不是我的责任”。管理层可能会施加压力以降低 bug 数量，于是人们不再将 bug 录入系统。转而使用便利贴传递，或者在远程工作时，通过聊天工具传递信息。

对量化的渴望有时会无意中将有用的信息排除在系统之外。

这种过度量化的问题不仅发生在测试环节，还存在于交付流程的各个环节中，比如团队的速度、网站用户数量、每周完成的功能数量等。Matthew 曾经与一家公司合作时发现，该公司每天都统计自动化检查的运行次数。即使程序员在不断添加自动化检查脚本，经理还是会每个月调整一次测试运行的间隔，确保每天统计的执行次数是增长的。

Matthew 的研究生导师罗杰 · 弗格森（Roger Ferguson）博士曾说过：“有数字总比没有数字好”，一个数字至少给人一个起点。话虽如此，但让我们考虑这样一个场景：昨天系统中有 5 个拼写错误的 bug，而今天登录功能完全崩溃了，根本没有人可以使用测试环境。我们能因为 bug 数量从 5 个减少到 1 个就说质量有所提升吗？当然不能，这个想法荒谬至极。但是，对于那些远离实际过程、只盯着仪表板的人来说，表面上看起来似乎就是这样的情形。

我们的导师 Cem Kaner 博士，将这个问题称为建构效度（Construct Validity），这是一个在科学领域有特定含义的术语。也就是说，简单地计算几件事并不合理。例如，我们可以在桌子上数现金（纸币）的张数，但如果每张纸币的面额不同，单纯的数量并不能告诉我们太多信息。如果我们根据纸币的数量来奖励团队，他们可能会把大额纸币换成小额，营造出生产效率提高的假象。我们在之前的自动化检查数量的例子中就看到了这一情况。Kaner 博士在 SoftwareEngineering Metrics: What Do They Measure and How Do We Know（链接 6-1）一文中可能对此做了描述—读完这篇文章后，人们很容易感到沮丧甚至压抑。在其职业生涯后期，Kaner 博士将软件比作股市投资，对于上市公司有一系列的度量指标，但所有指标都存在问题。这些指标反映了公司在某些方面的真实情况，若投资者能够综合考虑一系列相互制衡的指标并理解它们，将会对公司有一个更全面、更深刻的认识。

筛选数据是了解事情进展的一种方式，另一种则是深入参与工作流程。打个比方：老师不需要通过分数来了解学生的情况—老师本身就清楚学生的状态。之所以产生分数，是为了呈现给家长、校方和招生办等。这是为了让外界人士能便捷地了解和比较。度量标准同样起到了这样的作用。随着抽象层级的提升，从单日细节到团队每两周总结，再到多个团队的每三个月汇报，信息在逐级传递中逐渐流失。我们的挑战在于，以最紧凑的方式提供最不易被误解的信息，最大限度地保留关键内容。

我们要区分查询指标（inquiry metrics）和控制指标（control metrics）。在缺陷大小和影响相似的情况下，你可以进入需求管理系统并报告团队本周发现的20 个 bug。上周也是 20 个，并且修复了 15 个—看起来 bug 数量仍在增加。你甚至可以回溯几个月的数据，把这些数字填入电子表格制成图表。然而，当你每周更新图表，并基于它来决定晋升和涨薪时，就已经从查询指标转移到了控制指标。有了控制指标，人们就有了改变行为的动机。这时，我们开始看到关于何为bug、何为功能请求、严重程度如何界定的争论。人们可能开始自己发现并修复bug，而不经由正式渠道报告。可能会有人争辩说，标记为 WILL_NOT_FIX（不会修复）的 bug 也应该算作已修复，如果计入它们，图表上的数字就会下降。结果，质量也慢慢下滑。

Jerry Nadelman对于bug数量的看法

我们发现 bug 数量会呈现周期性变化。当开发一个新功能时，bug 数量会很高。但随着时间推移，经过几天 / 几周，随着功能逐渐完成，发现的 bug 数量会逐渐减少。如果度量指标很重要，我们就必须查看历史趋势。对我们来说，新功能开发最初几周的 bug 数量应该与之前功能开发最初几周的 bug 数量进行对比，后期的 bug 数量也应是如此对比。如果不这样做，你将看到一个持续的上下波动，那么这个度量指标就会失去意义。我们还需将 bug 数量与故事点估值进行对照。更高的故事点数意味着更大的复杂度，预计也会有更多的 bug 出现。对于一个规模较大的故事来说，发现20 个 bug 可能并不算是大问题，但若是一个估计值点数低、理应在一天内完成的小故事中发现了 20 个 bug，那就是一个巨大的警告信号。

本章的目标是促使你停下来思考一下，什么样的度量计划才能引导你走向正确的方向。我们完全支持查询指标，但不要止步于此—要验证它们。例如，在列出过去两周内发现的所有 bug 后，获取这些 bug 清单。弄清楚是否重要的 bug得到了修复，还是仅仅修复了容易解决的问题。如果重要的 bug 得到了修复但bug 总数仍在上升，我们如何解释这对质量的影响？

本章更多的是引导思考而非展示实例。在第 9 章中，我们将讨论能够经得起检验的测试度量指标实例。

对度量指标的一个常见期望用途是预测未来，有时也被称为预测，这值得一提。