2019年我們打了幾場硬仗

simple發表於2020-04-23

前言

這段時間在OKR的驅使下，我們團隊在業務測試和目標達成的路上專注的奔跑，戰線拉的越來越長，擔心積壓的內容太多，走得太遠而忽略了前進路上遇到的經驗教訓的歸納和沉澱。恰逢團隊再次調整，藉此機會來回顧一下從2018年團隊下半年到2019年底，第一次調整後我們團隊總共做了哪些事情，取得了什麼樣的進展，遇到了哪些坑。

專欄文章，寫的比較隨意。

導讀

業務線梳理
目標設定
任務拆解
最有效果的任務1：程式碼覆蓋率體系
- 增量程式碼覆蓋率方案
- 程式碼偽實時染色系統
最有效果的任務2：模型演算法監控體系
團隊取得的落地效果
未來的規劃

業務線梳理

2018年下半年，團隊從6個人增加到21個人，支援的業務型別也從單一的移動端方向，擴充套件了模型演算法、Web端、服務端產品線，業務線方向跨度很大。盤點下來，我們團隊的業務主要分四個方向：

移動廣告SDK
移動廣告DSP引擎
CRM系統
效能研發平臺

三條不同的業務線，面臨的情況各不相同，基本上涵蓋了測試行業各種業務的通病。（效能平臺本文先不做介紹）

SDK業務的特點：

並行版本多，對接了多個媒體端
提測週期短，經常會有定製化需求緊急發版上線
專案是模組化結構
需要定製測試Demo APP，本身無介面
迴歸測試周期短，小改動頻繁，整體迴歸測試代價高昂
廣告打點的特殊性，包括時序、計數、觸發時機等，直接影響計費

移動廣告DSP引擎

收入線，風險高，壓力大
測試難度大，模型演算法相關
底層C++，測試走讀程式碼成本高
關聯上下游較多，排查困難
廣告型別多，資料量巨大

CRM業務線

業務邏輯極其複雜，十幾個系統關聯
業務鏈路長
財務、法務、合同類多測試多，風險高
多個系統並行提測，相互耦合，測試邏輯和構造資料複雜
流程管理比較亂，人員流動大
測試效率化難

設定目標

托爾斯泰說：“幸福的家庭都是相似的，不幸的家庭各有各的不幸”。看了上面的問題，是不是多少能找到自己專案的影子？團隊整合後，面臨的問題形形色色，沒辦法挨個細說，我們團隊對現有問題進行了拆解和討論，並形成了三個大的目標來達成。

目標1: 整體規範專案流程規範，所有業務線自有Jenkins全部遷移到統一的流水線上，打造CI、CT、CD一體化，集中治理
目標2: 建立精準測試體系，完成C++、Java、PHP三個語言的程式碼覆蓋率建設，輔助業務測試、自動化測試、流量回放等手段提升效果
目標3: 推進測試深入化，從廣告投放平臺深入到引擎的模型演算法層面，對廣告的模型和詞典進行全方位監控及行為分析，降低人為失誤造成的事故損失

團隊推行OKR後有很多好處，具體參看團隊之前寫的文章：https://testerhome.com/articles/17888

圍繞著上面提到的目標，我們拆解為四個季度要完成的OKR，可以給大家看一下部分的OKR系統的截圖：

補充一下：這個okr系統是奇效平臺花一週時間做出來的，之前都是管理在Excel中

拆解任務

圍繞著總體的三個目標，我們對專案流程進行了分解，分而治之，每個階段要完成的事情都羅列了出來，大致如下：

從專案立項到釋出上線，總共可以劃分為五個階段：

需求階段
研發階段（程式碼准入）
測試階段
釋出階段
監控階段

我們推動開展測試的左移和右移工作，除了技術方案外，我們與研發團隊一起協商了許多規範和檢查機制，其中讓我們受益頗多的有幾個值得提一下（大廠同學可能覺得很詫異，不是本來就該這樣麼？）：

建立提測單機制，區分優先順序，配置了提測看板，讓一週的工作一目瞭然
設定研發自測演示環節，研發會在測試環境進行主要功能演示，被測試同學圍觀後，提測質量逐漸高了起來
統一Jenkins流水線後，通過Docker解決編譯環境一致性問題，減少了提測後環境問題導致排查耗時
配置檔案規範。以前遇到很多次問題是因為研發本地自測的配置環境跟測試環境不一致造成的

在掃平了專案前期的人為障礙後，我們強化了測試能力建設，其中收效最大的主要是兩件事：

程式碼覆蓋率檢查
模型演算法監控

可能有人要問了，程式碼覆蓋率檢查已經是很多年前提到的概念了，並且在2018年已經很多公司已經建立了這樣的測試手段，這裡我想重點介紹一下我們是怎麼用的。

程式碼覆蓋率檢查

提到程式碼覆蓋率，社群裡面大大小小可以找到幾十篇類似的原理、搭建、使用等介紹的帖子，在這裡我重點說一下我們團隊的技術歷程和思考。
前面提到的，我們團隊三個業務線，用的語言分別是Java、C++、PHP。也就是說從一開始我們就不能集中技術力量去解決某個語言的覆蓋率方案。好在現在網際網路資訊的便利，有TesterHome社群和MTSC大會這樣的平臺，讓我們可以獲取到很多優秀團隊和公司的做法，這裡簡單羅列一下我們參考到的方案：

2018年MTSC大會：
- 《雙精準測試實踐-陸金所》
- 《汽車之家新車電商精準測試解決方案-聞小龍》
- 《有贊測試增量程式碼覆蓋率工具》
- 《基於codediff 的差異程式碼覆蓋率統計實現-轉轉》
2019年MTSC大會：
- 《進化的覆蓋率--實時程式碼染色 - 螞蟻金服》
- 《恰如其分的自動化測試 - 淘寶》

我們的業務並沒有比其他公司的業務獨特到哪裡去，只不過我們團隊要同時解決三個語言的程式碼覆蓋率設計，僅此特殊而已。

程式碼覆蓋率的原則

在投入去做程式碼覆蓋率的時候，我們明確了一個原則和幾個期望：

原則：程式碼覆蓋率只是一種度量工具，輔助測試的手段，而非評判標準。

為什麼這麼說呢？我這裡簡單舉幾個例子：

function test(int a, int b){
    return a/b;
}

輸入：a=3，b=6；
// 行覆蓋率：100%
// 漏測b=0

function test(int a, int b){
    if(a < 5 || b < 10) {
        return a/b
    } else {
        return 0 
    }
}

//輸入1：a=3，b=6；
//覆蓋率：50%
//輸入2：a=10，b=11；
//覆蓋率：50%
// 漏測b=0

這裡不論是行覆蓋率還是branch覆蓋率為100%都說明不了任何問題，這個我們內部進行過認真的討論，實際上我們在做程式碼覆蓋率的時候，希望能把目光鎖定到那些本次新增的程式碼、方法、類，但是覆蓋率為0的情況，是什麼情況導致我們覆蓋為0？冗餘程式碼？預埋邏輯？覆蓋不到？還是漏測了？

期望：
- 在專案快速迭代節奏下從容評估迴歸測試範圍
- 在海量回歸case中快速提取測試case
- 在複雜業務場景中針對性設計用例
- 對存量case進行梳理和刪減
- 對現有的自動手段進行效果跟蹤和改進
- 降低漏測場景的復現成本
- 通過視覺化度量的方式，促進測試質量的提升
- 在專案流程中，形成質量卡點，強化質量意識

增量程式碼覆蓋率

幾種語言的程式碼覆蓋率方案沒辦法寫在一篇文章中，如果感興趣的話在社群裡都可以找到。這裡簡單介紹一下我們的方案設計：
PHP程式碼覆蓋率方案

php-code-caverage並不支援增量報告的展示，如果需要展示的話也比較簡單，只需要做如下事情：

加入增量diff資料（通過解析git diff資料得到）；
在結構化覆蓋率資料統計的時候增加增量覆蓋率資料的相關欄位；
覆蓋率報告渲染程式中相容新增的增量覆蓋率資料欄位；
修改對應的報告模板支援增量覆蓋率資訊；

PHP增量程式碼覆蓋率

C++程式碼覆蓋率方案

C++程式碼覆蓋率是我們另外一個組來實現的，其中的一些細節可以去搜一下Qtest測試之道里面的兩篇文章《gcov C++程式碼覆蓋率測試工具》原理篇和實踐篇：
原理篇
 實踐篇

Java程式碼覆蓋率方案

Java程式碼覆蓋率的文章，社群裡不勝列舉，這裡就不再介紹了。

程式碼偽實時染色方案

在完成程式碼覆蓋率統計並整合到Jenkins後，我們每週的週會都會追蹤一下程式碼覆蓋率對業務測試的幫助，一開始大家對覆蓋率還是比較贊同，覺得可以輔助測試，假如發現覆蓋率資料偏低會主動去檢查是否是設計的用例沒有執行到。後來有一些同學反饋說，他們通過覆蓋率結果反推case非常的困難，流程太長。通過了解，我們發現業務測試在補充用例到時候需要做幾件事：

清空之前到測試覆蓋率資料
編譯打包、部署環境
執行一個“可能會”提升覆蓋率的測試場景
執行完了後，回收覆蓋率資料到流水線
檢視資料結果，是否有提升

在除錯一條case的時候，整個反饋的鏈路太長，響應不及時，業務測試同學需要逐條的嘗試case是否有效，耗費大量的時間。怎麼解決這個問題？螞蟻金服的議題啟發了我們！
在跟螞蟻的講師溝通後，我們發現要做到他們那樣的程度對我們這樣的小團隊來說不太可能，因為我們不具備這樣的技術力量來修改編譯器，而且我們還有多語言的需求。於是我們開始嘗試了自己的野路子方式，偽實時程式碼染色系統。