在接到项目咨询时，经常会被问到的一个问题是，你用哪些指标衡量质量？或者你的QA团队设置哪些KPI？
首先，metrics和KPI并不相同，metric是对系统、模块或流程所具有的某个特定属性进行测量。Key Performance Indicator KPI顾名思义，关键绩效指标，它在度量的基础上叠加了数字反馈。KPI可以理解为“别人让我做到什么程度”。举个例子，汽车仪表盘上的时速表是一个典型的metric，代表了车辆行驶时的速度变化。每小时的公里数具有可比性、简单明了。仪表盘上的带指示灯的充电表是一个KPI，一旦电量低于阈值会亮黄灯，接近临界值会亮红灯。在电量这个指标的基础上增加量化的反馈，协助司机了解状况和进度，并进行必要的调整。
那么说到如何衡量项目或产品的质量，经过多年的验证和总结，我认为有3个metrics是最实用的。
1. Daily submitted defects vs. daily closed defects
在版本上线前的回归测试或系统测试期间，基本上大家都会去监控bug的数量。但bug数量的多少并不能完全代表该版本质量的高低。由于功能特性的不同，可能存在虽然bug不多，但很难修复的情况。更能给予版本上线信心的，是监控bug变化的趋势。我最推崇的是监控每日bug增加数与每日bug关闭数的对比，并且以蝴蝶图的展现形式最一目了然。
以上图为例，左边是bug的日增变化，右边是bug关闭的每日趋势。走势上能直观感受到问题修复的速度在有序增加，在回归测试中期时已超过新增问题的速度。再搭配遗留bug总数*严重程度，例如此例中总遗留bug数为11，逐个确认问题的严重程度后，就可以比较自信地得出是否达到上线标准的结论了。
2. Number of post-launch defects
版本上线后，回溯版本质量的指标主要由漏测bug数来表示。如何定义漏测bug视具体项目场景而定。以to B产品为例，版本间隔周期较长。如果监控整个周期，将增加许多管理成本。因此推荐监控上线后一周内，生产环境上的bug数量，包括测试人员回归发现或客户投诉后确认的问题。如果是to C项目，例如游戏版本在灰度后即全网发布，测人人员一般不做线上回归，则可以监控版本周期内客户投诉量，包括客服记录和社群记录等。
这里需要注意的是，有些团队会设置把漏测率为质量KPI。
漏测率 = 线上bug / 总bug数
除非版本之间的技术复杂度、功能规模恒定，否则请谨慎使用此比率。因为这个值会受到过多因素干扰而导致抖动过多，比如某个版本的功能点较少，上线后发现1个bug，就可能产生较大的漏侧比率。两个项目的漏测率也不能客观地比较。
3. Testing points per every 100 points of feature delivery
从效能角度考虑，服务单位规模的功能上线需要投入多少测试资源，是从另一个纬度评价质量的指标。项目管理标准化是使用这一指标的前提。以一个基于敏捷的研发团队为例，可以监控每发布100个points的功能点时所需要的测试points是多少。这个数值随版本周期而变化，数值越小代表测试的资源占用越低。这可能是测试策略的优化带来的，也可能是代码效率提升带来的，但总之直观展现了测试效能的趋势。
指标和KPI的作用需要匹配合适的项目场景。以上3个指标非常适用于相对宏观的质量衡量。在具体项目中，也可以搭配必要的KPI。比如在提高测试效能的特定项目中，降低testing pts / 100 pts of feature delivery是最终目的，期间可以加上AT coverage rate作为测试开发团队的KPI。
但总体上，我不提倡设置KPI。能理性看待和处理KPI的团队并不多见。常常key performance indicator变kill people individually..
灵活运用，及时分析才能让指标不浮于“汇报”，从而真正发挥出激励团队、持续优化的作用。
