本文綱要

• 【引言】
• 【技術教練團隊】
• 【持續集成】
• 【哪些實踐更加優先】
• 【復雜的自動化測試】
• • L0自動化測試
  • L1自動化測試
  • L2自動化測試
  • L3自動化測試
• 【組織級工程實踐氛圍建設】
• 【小結】

【引言】

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

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

【技術教練團隊】

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

【持續集成】

規?；こ虒嵺`首選的推進點是持續集成。通過持續集成工具，天然可以方便地以組織級視角來觀察，也就是可以得到規?；宫F和度量。比如可以看到哪些團隊或者系統已經啟用了CI（持續集成），具體樣例指標有：

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

另外持續集成是組合實踐，不同組織有不同側重點，而且在理論上與持續部署存在交叉。從規?；七M角度，試圖來識別持續集成里哪些實踐更加優先。

【哪些實踐更加優先】

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

自動化編譯

靜態代碼掃描

發布制品庫

自動化部署

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

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

【復雜的自動化測試】

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

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

L0自動化測試

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

L1自動化測試

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

L2自動化測試

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

L3自動化測試

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

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

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

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

測試金字塔理論上以L0為基礎，數量最多。但從性價比上不是最經濟的，在規?；嵌壬?#xff0c;跨團隊接口聯通更加優先。

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

【組織級工程實踐氛圍建設】

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

1，持續集成建設本身存在難度；

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

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

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

【小結】

持續集成是工程實踐規?；暮诵膶嵺`。其中的自動化測試推薦優先以基于接口/API的L2自動化測試。技術教練團隊值得考慮，但有難度，更重要的是提升工程實踐氛圍，值得收集并公開各種度量。

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。