[[279063]]

好的開始是成功的一半!工作中，目標的設置是最不能馬虎的事情。今天，我們請來孫陽(阿里巴巴測試開發專家)，他從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的運行時長，而這個就是我們能力項的指標了。

★ 方案和實施路徑選擇

好了，根據以上的分析，我們已經得到了能力建設的目標和指標，那在方案的選擇和實施路徑上也就會相對清晰了，這里本文就不再贅述了。

小結

在很多時候，能力整合和原子能力往往是相輔相成的，能力整合打應用場景，原子能力打解決問題的深度，只有結合起來很才能最大化價值。但是在定義KPI的時候，兩者其實可以分開考慮，這樣在團隊資源投入上也更容易分工和形成合力。

另外，思考價值、目標的過程是很折磨人的，但是我認為這是一個鍛煉“思考力”的方式，一旦習慣了以后，就會按照這個思考路徑來想問題了。