阿里妹导读：好的开始是成功的一半！工作中，目标的设置是最不能马虎的事情。今天，我们请来孙阳（阿里巴巴测试开发专家），他从11年入职至今已有8年。在测试技术目标的KPI设置上，他有一些想法要与你分享。

常见误区

误区一：我能做什么，就做什么？

我们在讲测试能力建设的时候，往往会说我们有什么样的问题，所以要建什么样的测试能力，要做到什么样之类。这里经常能看到大家在设置目标的时候，思考路径往往是“我能做什么，我要怎么做”。

比如，海外没有真机环境，所以我们需要建设海外真机环境。接下去就会想到我们在海外有办公室，所以上半年的目标就是在海外办公室部署真机环境，技术方案上可以采用某个方案。

看上去没有什么问题，但是如果你仔细想一想，就会发现这个目标其实禁不起推敲。上半年建了海外环境，那下半年要建什么？这当中对国家选择的标准是什么？对真机环境建设的成本、稳定性、速度、可移植性等要怎么衡量？如果只是觉得业务上需要海外环境，我也能做海外环境，就去做了，那在方案选择上可能就会存在局限性，比如当前的方案就很依赖办公网的建设，其实不利于在世界范围内复制。

这种定目标的方式，很容易变成：今年没有能力，我建了某个能力，明年我发现这个能力不完善，然后我又做了优化一二三。这样做规划，没有体系，缺乏前瞻性，也看不到终局。

误区二：拿手段当目标

有的同学说，我要做自动化调度中心，整合各种自动化平台，解决自动化调度问题，统一所有自动化测试件的执行。上半年的目标就是把平台重构，接入测试件类型一二三四。

这就是典型的拿手段当目标了，我们做自动化调度中心，这是一个手段，而不是目标。

目标是要结合业务测试的痛点问题来的，比如，目前自动化能力分散，在持续集成能力落地时，自动化能力集成成本高。那这时候我建立调动中心的目的就变成了降低持续集成自动化集成成本，然后就可以对这个成本进行度量，以描述我达到的阶段。同时，对平台集成能力也可以进行度量，建立你的子目标：比如可扩展性、稳定性等等。

技术目标设置的思考路径

在说思考路径之前，我想先分析一下，一般的技术目标有哪几种类型。

在质量团队来说，一般我们的技术目标会有两种，一种是做原子能力，解决某一类问题，比如UI自动化、接口自动化、doom等等；二是建一个整合平台，做原子能力的调度，打整体效果。

那么接下来我就以活动质量中心的目标设置来谈一下我的思考路径。

平台整合型

我们在说到平台整合的时候，往往给自己找的价值点都是：降低工具使用成本、沉淀保障策略之类，要降低工具使用成本，其实一个门户网站做个导航可能就能解决问题；而沉淀保障策略，一个文档也能解决问题。所以如果你把价值定位在这两个方面，最多就是量变，很难做出质变。其核心问题是：没有对业务的测试工作产生改变，也就是目标和价值没有想清楚。

| 定义目标

我认为，做平台能力整合，想要做出质变，一定是要对工作模式发生一些变化的。你把一堆能力整合到一起，肯定是希望这些能力能够在某一件事情上产生合力，而这个合力所产生的效果，我认为就是能够对这件事情的模式，产生一些变化。

比如，aone（研发工具平台）整合了一堆能力，改变了研发的工作模式。

那么要怎么去思考这样的变化呢？我觉得有以下几个步骤：

1）先从问题出发，聚焦到一个域，定义出当前工作模式的一个状态，即：当下的阶段。

2）把目光放长远，从三年后往回看，你期望的工作模式是什么？即：愿景的阶段。

3）一年内我期望给工作带来的变化是什么？即：短期目标。

按照这个三个步骤去拆解问题，把终局和阶段想清楚，就能把平台的工作的价值整明白了。

| 能力建设

在定义清楚当前阶段、愿景和目标之后，我们就需要来看Action是什么了，也即是说，为了实现我的目标和愿景，我需要做的事情有哪些。

这时候我就可以根据目标进行拆解，明确哪些是平台架构需要完成的，哪些是原子能力需要提升的，然后看当前的短板在哪里，重点投入兵力建设。

| 举个例子

以活动质量中心为例，我们先来灵魂拷问：

当下我们对会场的质量保障模式是：S级（重大项目）大促半自动化、日常活动全裸奔；

如果往后做三年，我希望给这件带来的变化是：以场景化的方式、针对不同活动，提供个性化的全自动化保障策略；

一年内我能达到的台阶：所有营销类活动全自动化保障。

在定义清楚目标之后，就要来看达成目标我需要建设的能力了。

比如，我要在今年实现所有营销类活动全自动化保障，我就需要做这几件事情：

1）建立活动质量中心，和研发活动一体化系统对接，实现关键节点（选品、搭建）环境的自动化检测和流程卡口。

2）针对会场特色，把核心原子能力做厚。

而往三年目标走的话，我还需要：沉淀保障能力模板，针对不同类型活动提供场景化解决方案（比如3C和大工业）；活动覆盖面拓展，系统对接导购系统等。那这些的优先级在本财年就会被降低。

平台能力整合型的，我认为大概就是这个思路了，下面再来看看原子能力型的。

原子能力型

所谓原子能力，一定是解决某一类型问题的，比如会场UI自动化，解决的就是会场UI层质量问题。

针对原子能力的KPI，我认为其思考路径应该是这样的：先定义问题，再定义目标，然后思考需要能力项，再根据指标思考方案和实施路径。

| 定义问题

明确当前的问题是什么，这里对问题的分析需要更加全面，要有抽象能力。比如当你遇到了一个单点的问题，可以思考这个问题是否具备通用性，可能一个个例问题背后，是一个普遍的现象。而越是抽象的问题，解决的难度越大，而价值也越大。

以活动会场UI自动化为例，开始我想解决的是S级（重大项目）大促会场质量保障的问题，后来想想这东西一年用两次，不划算，而日常几百次的营销活动会场都是裸奔，为什么我不能把S级（重大项目）大促保障的思路复用到日常会场呢？然后再往外延展，导购活动的页面质量，能不能用同样的思路解决呢？最终，我定义的会场UI自动化能力要解决的问题就是：所有活动类型的会场UI质量保障。

| 定义目标和能力项

所谓的价值，就是要把问题解决到什么程度。问题解决得越彻底，价值越大，所以我们在解决问题的时候，姿势一定帅，不能是一个临时方案，而要有长效机制。

在明确了目标之后，就可以分析要实现这个目标，我们所需要的能力项有哪些了。

还是以活动会场UI自动化为例，作为测试能力，我认为必须能够替代手工测试。比如破图、死链、样式错乱、空楼层、空白品、重复品、无价格品等等影响用户体验的问题。所以，对于问题的覆盖面肯定有要求。

然后，运行速度要快，要给运营及时的反馈，否则做为发布卡点，体验很差。
再者，对稳定性和误报率肯定有要求，假摔会导致排查成本增加，也会给运营发布的体验造成负面影响。

这样分析下来，我相信，能力项也就出来了：覆盖率、执行速度、稳定性。

| 定义指标

定义了目标和能力项，之后就需要对每一个能力项做到什么程度进行定义，这就是我们说的指标了。

比如覆盖率上，我希望脚本能发现所有问题，而所有问题又很难定义，所以，我至少希望脚本能替代手工，那我的KPI就可以定义为：脚本覆盖所有手工测试的case，实现会场内容全自动化检查。

在执行速度上，我们希望做到2分钟内执行完成。

在稳定性上，我们希望成功率达到三个9，误报率小于1‰。

当然，有时候由于缺乏历史数据积累，很多数字只能靠拍，但是拍也不是乱拍。我们可以从业务上的效果来思考，比如执行速度，我们如果希望一次S级大促所有会场在15分钟之内完成测试，那么根据会场数量、执行机的数量，就可以反推出单个case的运行时长，而这个就是我们能力项的指标了。