前两天的文章分享了我对于团队目标管理和绩效考核的一些想法，公众号后台有同学留言问道：测试团队在制定目标和绩效考核时，有没有一些明确的可参考的指标。
团队目标制定和绩效考核，其实会受很多因素影响，比如团队规模，资源预算，行业特性，管理理念，以及当前团队所处的阶段。但整体来说，还是有一些比较通用的指标可以参考的。这篇文章，结合我带团队的经验，聊聊我对于目标管理和绩效考核的一些经验和想法，仅供参考。
对测试团队来说，最核心的目标就是保障质量和提升效率。保障质量简单理解就是少出问题，更稳定的支撑业务运营，辅助业务目标达成；提升效率更好理解，提升单位时间产出，相当于变相的降低了成本，也可以支撑业务更快的迭代。
不过保障质量和提升效率这两个核心目标不够具体，在制定团队目标和绩效考核时，需要注意的是，目标一定要具体、可落地执行、结果可量化，否则绩效考核就会成为一个玩笑。
从软件产品的迭代生命周期来说，一个软件产品大致要经过需求-研发(开发-测试-交付)-运营三个阶段。接下来就以这五个阶段为例，介绍一些比较通用的关键指标。
需求质量
为了保障质量，降低上线后的风险以及带来的影响，测试需要从需求阶段就介入，因此提升需求质量可以看作是测试团队的一个绩效考核目标。当然需求的产出者主要是产品和业务团队，测试团队主要是参与评审，评估是否存在风险，以及相关需求的可测性等。更具体一点，为了提升需求质量，需要通过一系列手段去发现存在的不足并且制定目标去改进，这才是制定绩效考核目标的核心。通用的考核指标，可以参考如下几项：
- 需求评审通过率（是否有遗漏、描述不清、存在逻辑漏洞等）；
- 设计评审通过率（设计是否满足需求要求、是否合理美观友好）；
测试活动的开展应该是为了降低风险，倒逼需求产出方提升需求质量，而不是一味追求高通过率。比如有紧急需求，安全整改或者某些技术组件漏洞打补丁，就要实际从权，而不是一定要卡指标。
研发质量
研发阶段细分的话可以分为开发、测试、交付三个阶段。在每个细分阶段，比较通用的指标，可以参考如下几点：
- 方案评审通过率（方案实现难易程度、可测性、是否需要更多资源）；
- 用例评审通过率（场景是否尽可能覆盖、和技术方案实现是否吻合）；
- 提测准时率（便于评估进度、资源投入和风险）；
- 构建成功率（构建成功率很大程度能反映出研发提测质量。如果经常编译构建失败或自动化测试通过率较低，因为这意味着最基本的需求实现出了问题）；
- 缺陷收敛率（反映缺陷在研发过程阶段的变化趋势和缺陷修复的时效性问题。一般在测试阶段的中前期即单测&集成测试阶段会暴露大量缺陷，到系统测试和回归阶段缺陷就应该有明显下降和收敛，降低产品验收和交付风险）；
- 缺陷reopen率（问题修复可能会带来新的问题，reopen指标可以从一定程度上评估缺陷修复的质量。如果reopen率比较高，那么很可能研发侧出现了问题，需要引起重视和寻找原因，尽快解决）；
注意，这里我提到的都是评审，为什么要做大量的评审工作呢？因为如果源头存在问题，那么编码和测试执行过程的正确性就无从谈起。方向错了就全错了。
测试的本质是验证研发交付的产出物是否达到需求设计及预期的标准，并不能直接带来质量的提升，只能通过种种手段多维度的去验证是否达标，并通过流程规范、度量标准等去保障最终的交付物达标。我们常说的各种测试技术，都是验证和保障质量、提升效率的手段。
线上质量
软件产品线上发布后的质量，其实才是最重要的。只有被用户认可，能支撑企业业务目标达成的软件系统，才符合所谓高质量的定义。因此线上质量的考核指标，可以从用户体验和业务目标达成的角度出发。
- 线上缺陷逃逸率（线上发现的缺陷）；
- 线上问题留存率（线上发现的缺陷留存时长，用来评估修复时效和对线上质量的重视程度）；
- 用户反馈建议量（这里仅针对的是用户针对功能的反馈或者客诉，不包含业务活动的范围）；
- 线上系统稳定性（即我们熟知的SLA，比如系统可用率达到99.9999%）；
- 业务目标达成率（业务目标是否达成，是否存在技术所导致的影响业务目标达成的因素）；
上面提到的这些通用指标，在实际落地中可以更加细化和具体，将目标拆解为更合理的可执行的方法，并且针对这些执行过程制定更详细的指标和数值，这其实就是这几年大家经常听到的质量度量所提倡的。
制定绩效考核目标和指标的目的不是为了考核，而是便于评估为了提升质量和效率，大家所开展的一系列测试活动是否达到了预期效果。
