度量是将一个数字赋给一个对象或事件的特征，可以与其他对象或事件进行比较。度量是一种很好的手段来检验我们离目标到底有多远。
如果项目不进行度量，我们则不知道当时的状态和目标相比到底是落后了还是超前了，是偏差了还是符合目标要求。
因此我们常常把度量当作一种路标，来衡量团队是否在偏离轨道还是朝着正确的轨道在前进。
但是，在使用度量的时候，我们应该警惕以下两点误区：
度量个人绩效而不是度量团队目标
如果把度量用在对个人的绩效评价上面，将会是一件非常危险的事情。因为个人为了达到绩效指标的要求，势必会想方设法来满足指标考核要求。
比如如果我们对开发人员每天开发的代码量（行数）做考核的话，就很有可能使得开发人员为了达到指标要求而开发出大量的冗余代码或者使得代码逻辑不够简洁清晰，久而久之代码的可维护性将会变得很差。
这种没有正确使用度量造成的后果不是我们希望看到的。一旦把度量应用在个人考核方面，则很有可能会出现各种各样的副作用。
因此我们应当把度量放在关注团队的目标上面，比如我们关注自动化测试的通过率，是为了检验到底我们当前版本离我们希望达到的质量目标有多远，而不是为了证明开发人员写的代码有多差。
另外需要记住的是，我们应当把度量当作一种正向的激励手段而不是负面的惩罚别人的证据，否则我们一定不会得到客观的结果。
只看单独的指标而不是全局性的指标组合
我们如果只对单个指标进行割裂的分析是没有任何意义的。比如说测试人员在测试过程中发现了很多缺陷，这说明什么？
有可能说明测试人员的能力强；也可能说明不是测试人员厉害而是开发人员太差，写的代码出现很多问题；还有可能不是因为开发人员差而是因为此模块本身就很复杂难度高，所以出现的缺陷当然比开发一个简单功能的模块多。
因此如果你不是全局性对多个指标进行综合性分析，而只是看单独的指标是很难知道真正的根源是什么。我们只有结合其他指标一起，通过全局性思维去分析，才能透过这些指标发现项目的真实情况，才有助于我们接下来采取正确的行动。
那么与敏捷测试相关的度量指标有哪些呢？下面是部分参考的指标：
代码覆盖率
指由开发人员在单元测试过程中运行单元测试用例时所执行的代码量占该模块总代码量的百分比。目前有很多工具可以帮助自动化的统计这个度量值，比如Jacoco就是一个用于Java语言的代码覆盖率统计工具。
另外需要注意一点的是，代码覆盖率指标并不要一味追求100%。包括Martin Fowler在内的众多专家都认为追求100%代码覆盖率是没有意义的，因为它并不代表代码质量就真的那么高。
代码覆盖率真正的意义是帮助发现你的代码还有哪些部分没有被测试，因此一般代码覆盖率达到80%以上就已经很好了。
验收测试通过率
指某版本（一个Sprint或Release）中通过验收测试的用户故事数占总用户故事数的百分比。该指标主要是用来衡量当前版本的需求总体完成情况以及是否达到发布的条件。因为只有通过验收测试的用户故事才可以算“完成”，所以我们可以很容易统计出本次版本的需求完成情况。
另外对于是否可发布，除了验收测试通过率外我们还需要关注最小可发布特性集MRF（指在一个版本内最少必须要实现的需求集，否则无法满足本次版本目标）里的需求必须全部完成，并且这是必要条件而不是充分条件。
每用户故事点数缺陷率
指某版本（一个Sprint或Release）中发布后发现的缺陷数（可以定义发布后一段时间内发现的缺陷，比如两周内）除以本次版本用户故事点数的总数。
这个指标主要是用来度量版本的总体质量，以帮助我们进行分析版本质量是否随着迭代的增加而逐渐提升的趋势。
验收自动化率
指能够通过自动化测试来验收的用户故事数占总用户故事数的百分比。该指标主要是考核自动化实施的情况。
我们应该鼓励尽量把能进行自动化的验收测试都要自动化，只有自动化的程度越高，我们进行回归测试的效率也会越高。
源自公众号 晨小菜