本文綱要

• 【引言】
• 【技術(shù)教練團隊】
• 【持續(xù)集成】
• 【哪些實踐更加優(yōu)先】
• 【復(fù)雜的自動化測試】
• • L0自動化測試
  • L1自動化測試
  • L2自動化測試
  • L3自動化測試
• 【組織級工程實踐氛圍建設(shè)】
• 【小結(jié)】

【引言】

工程實踐，也有稱為技術(shù)實踐，其推進在敏捷轉(zhuǎn)型當中具有重要位置，有推算認為效能提升里面的至少一半來自于工程實踐。由于不能嚴格的區(qū)分提升來自于哪里，以上推算難以證實，但也可以體會到工程實踐的重要性。

當一位教練輔導(dǎo)10人團隊時，可以與團隊成員逐個結(jié)對，手把手傳遞，而在敏捷轉(zhuǎn)型在超過100人的情況下，工程實踐的推進就會遭遇規(guī)模化問題。而隨著敏捷DevOps的深入，當前1000人級別的推進已經(jīng)有很多了，到了千人級規(guī)模，顯然逐個結(jié)對顯然推進速度不夠快，原先在10人團隊的推進手段很難復(fù)制到千人級。本文試圖來看看千人級工程實踐推進。以下來探討下工程實踐規(guī)模化的要點。

【技術(shù)教練團隊】

首先跟著上面例子，既然光靠1個技術(shù)教練逐個結(jié)對去推進顯然不夠，那么很自然的有個方案是建設(shè)技術(shù)教練團隊和外圍熱情者，比如工程實踐主題的CoP，比如TDD CoP，持續(xù)集成CoP。但是這個方案在業(yè)界采納的比例不高，成建制的管理教練團隊比較多見，成建制的技術(shù)教練團隊相對很少，就算有，人數(shù)也有限。在規(guī)模化下工程實踐氛圍也許比有限的技術(shù)教練團隊更加重要，而千人級工程實踐氛圍的帶動得要有賴于組織刻意的推動，首選是持續(xù)集成。

【持續(xù)集成】

規(guī)模化工程實踐首選的推進點是持續(xù)集成。通過持續(xù)集成工具，天然可以方便地以組織級視角來觀察，也就是可以得到規(guī)模化展現(xiàn)和度量。比如可以看到哪些團隊或者系統(tǒng)已經(jīng)啟用了CI（持續(xù)集成），具體樣例指標有：

• 每個月進行多少次，
• CI成功率如何，
• CI里面的自動化測試用例數(shù)量，趨勢是否增長
• 測試覆蓋率趨勢如何。

另外持續(xù)集成是組合實踐，不同組織有不同側(cè)重點，而且在理論上與持續(xù)部署存在交叉。從規(guī)模化推進角度，試圖來識別持續(xù)集成里哪些實踐更加優(yōu)先。

【哪些實踐更加優(yōu)先】

招行去年2019年公布了其DevOps建設(shè)情況，里面給出了招行成熟度模型，成熟度分三級：一級包含了自動化編譯、靜態(tài)代碼掃描、發(fā)布制品庫三個工程實踐。二級是在一級的基礎(chǔ)上，增加了自動化部署。三級是在二級的基礎(chǔ)上增加了單元測試和自動化測試。（引用自招行滕樂英老師分享的演講實錄丨招商銀行DevOps實踐及DevOps標準認證評估分享）
筆者的歸納與招行此模型大體一致，按優(yōu)先順序從高到低如下：

自動化編譯

靜態(tài)代碼掃描

發(fā)布制品庫

自動化部署

自動化測試
自動化測試這里與招行不一樣，下文會說明。

自動化編譯是理所當然的高優(yōu)先，沒有這個余下一切免談。
靜態(tài)代碼掃描是組織級容易推進的工程實踐，最典型的例子是安裝SonarQube服務(wù)，提供給各一線團隊使用。開始時可以降低門檻來切入，切實讓廣大一線團隊感受到好處，然后可以迅速鋪開，切實規(guī)模化的觀測到組織整體代碼質(zhì)量情況。與此實踐對照的是人工code review，code review需要一線團隊主動的人工付出，其規(guī)模化推進就有較大困難，需要專項建設(shè)。
發(fā)布制品庫為發(fā)布管理要點，確保投產(chǎn)版本準確并且可以回溯。
自動化部署在海量服務(wù)部署情況下顯然也是高優(yōu)先。

【復(fù)雜的自動化測試】

然后來到了復(fù)雜的自動化測試。首先的復(fù)雜來自于自動化測試這個詞本身，自動化測試在不同組織語境下有不同含義，有些地方說的自動化測試是指啟用諸如selinium的自動化測試，招行把單元測試和自動化測試并列，看起來單元測試好像不是自動化測試。

本文采用其字面意思，即是覆蓋全部自動化測試，采用微軟的自動化測試分類方法，按如下劃分：

L0自動化測試

特征是無需部署安裝也不依賴外部資源，這與經(jīng)典單元測試高度重合。為什么不用單元測試這個提法？因為有些地方的單元測試超出了L0范疇，甚至覆蓋到了L2，這與XUnit系列單元測試工具的強大有關(guān)，無論如何，單元測試這個詞目前存在不同理解，啰嗦一些的L0自動化測試更加精準。

L1自動化測試

特征是無需部署安裝但依賴外部資源，也類似于單元測試，一般所用工具就是XUnit系列。

L2自動化測試

特征是無UI界面基于接口/API的測試。仍然可以使用XUnit系列工具，當然也可以使用專門接口測試工具。

L3自動化測試

特征是UI界面自動化測試。常見使用Selinium。

微軟公布的實例里面說明當前微軟目前現(xiàn)有大多數(shù)測試都是L3級，而招行的情況是接口測試占據(jù)多數(shù)，招行精益敏捷類對接口測試覆蓋率要求達到100%，也就是在以上的L2級。

招行將其測試組合形容為測試橄欖球型，這與筆者之前所提出的紡錘形是一回事。

對于微軟實例說L3最多，這也許與微軟產(chǎn)品特征有關(guān)，尤其是其Office系列，這樣的話是冰淇淋形。筆者猜想微軟測試冰淇淋形組合是特例。而招行測試橄欖球形更加代表了規(guī)模化測試推進的樣例。

測試金字塔理論上以L0為基礎(chǔ)，數(shù)量最多。但從性價比上不是最經(jīng)濟的，在規(guī)模化角度上，跨團隊接口聯(lián)通更加優(yōu)先。

因此自動化測試里面優(yōu)先推進建設(shè)以接口/API測試為特征的L2自動化測試，然后L0，L1。而基于界面的L3測試更加排在后面。

【組織級工程實踐氛圍建設(shè)】

個別一線團隊會自動自發(fā)地建設(shè)持續(xù)集成，但如果在千人規(guī)模上考慮這個問題，就不能夠指望自動自發(fā)。因為這里面存在至少2重困難：

1，持續(xù)集成建設(shè)本身存在難度；

2，對如何實踐是否帶來高效率沒有統(tǒng)一認識。

因此要培養(yǎng)工程實踐氛圍，值得利用持續(xù)集成工具特性來開展組織級工程實踐度量，建立標桿，引領(lǐng)更多團隊前進。
對于指標樣例，有如下列推薦

• 測試用例數(shù)量，比如月度新增數(shù)量，起始時，不在于絕對數(shù)量，關(guān)鍵在于持續(xù)增加，如果總運行時間過長，那么分多級運行，比如區(qū)分白天晚上
• 執(zhí)行頻率，比如月度執(zhí)行次數(shù)，執(zhí)行頻率越高越好
• CI成功率，比如自然月成功率，100%成功意味著沒有充分利用CI，甚至為了100%反而耗費了額外的工作量，推薦各組織摸索一個恰當?shù)匠晒β蕝^(qū)間
• 測試覆蓋率，比如月度比例趨勢，這又是一個微妙的指標，不能夠下降，但并不是越高越好，需要各組織摸索一個合適的區(qū)間

【小結(jié)】

持續(xù)集成是工程實踐規(guī)模化的核心實踐。其中的自動化測試推薦優(yōu)先以基于接口/API的L2自動化測試。技術(shù)教練團隊值得考慮，但有難度，更重要的是提升工程實踐氛圍，值得收集并公開各種度量。

總結(jié)

以上是生活随笔為你收集整理的工程实践规模化推进要点分析的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。