測試分層策略實踐模型
作者 | 安輝，王瑞鵬
在當今企業推動數字化轉型的背景下，如何在提升研發效率的同時守住質量底線，成為了技術團隊尤為關注的話題。軟件測試是確保軟件質量的重要實踐之一，而其中的測試分層策略更是關鍵。盡管“測試分層策略”這一概念對許多團隊來說還比較陌生，它實際上是軟件測試中的一個重要組成部分，決定了團隊如何根據代碼架構的不同，制定相應的測試方法。
然而，很多團隊在面對測試分層策略時存在認知缺乏、設計不完整、以及與實際工作脫節等問題，這直接影響了測試實踐的效率。本文旨在通過提出一個模型，幫助團隊建立統一的測試分層策略認知，提升測試實踐的效果。
什么是測試分層策略?
提到的測試分層策略，大家感覺可能是既熟悉又陌生。其實測試分層策略是測試策略的一部分，對于測試策略，目前業界的普遍說法是測試策略主要包含的兩個方面內容：
- 測什么？- 指測試的目標，是功能、是性能、還是安全？
- 怎么測？- 指測試的手段，由誰，在什么時候，是手動還是自動？
所以依照上述的特征，為了溝通時更聚焦，我更喜歡將測試策略分為流程策略和分層策略：
- 流程策略 - 即以時間為主線確定測試方法。明確產品需求研發過程中的測試活動、角色職責、門禁標準等。
- 分層策略 - 即以軟件的代碼層次為主線確定測試方法。從技術的角度，針對被測單元不同的顆粒度，規劃測試相應的測試方法。
在過往的咨詢經歷中，我們發現多數開發團隊對測試流程策略相對更了解，因為它和人員的日常工作密切相關，每個人都需要知道在什么時候應該和誰協作來做什么事。但往往詢問起團隊某個系統的測試分層策略，卻極少有人能夠說清。
分層策略常見的問題
每當我們調研團隊有關分層策略的問題時，一般會有下面三類典型現象：
- 缺乏統一認識 - “什么是測試分層？我不知道啊！” 一般團隊中極少有人能夠將團隊的測試分層說得清楚，即使是團隊的技術或測試負責人也只能從團隊實操層面說明團隊都做了什么，甚至部分人連測試分層的概念都搞不清，不同角色之間更多是關心自己的一畝三分地，把自己職責上要做的測試做了就行了。
- 缺少頂層設計- “單元測試是開發團隊做的，和測試團隊沒什么關系。” 有部分團隊的技術或測試負責人可以說清楚對某個系統都做了哪些測試，比如有單元，接口，UI等，但是各類測試之間是割裂的，缺乏整體設計與層次間的配合規劃。這樣最容易出現的問題就是將原本應該是金字塔的策略做成了水桶型，不同層次的測試間做了大量重復的工作。
- 與實際工作脫節 - “測試金字塔？在墻上貼著呢。沒啥用，還是該咋做咋做！” 部分有策略意識的團隊有時會短期突擊梳理系統的測試分層策略，梳理過后大家對實踐高質量信心百倍。進入到了具體工作時大家發現這東西不知道怎么和實際的工作結合起來，慢慢的也就忘記了它的存在，回歸最初的工作方式了。
這三種情況的存在會使團隊的測試實踐效率低下，團隊即使投入了大量的資源來增強某些測試實踐也很難達到好的質量保障效果。
分層策略實踐模型
為了嘗試解決這些問題，我們的構想是希望能夠給團隊建立一個對測試分層策略的統一認知與目標，可視化的管理各個層次的測試實踐，并且讓團隊能夠用這個統一的目標來指導自己的工作，所以就產生了本文要給大家介紹的測試分層策略模型。
1.維度設計
首先模型定義了縱向與橫向兩個維度，形成一個四象限的模型框架。其目的是希望對目標被測系統進行分類，不同類別的被測系統會有不同的測試策略推薦：
- 縱向維度考量被測系統的“可測試性”：直觀的理解可測試性就是一個計算機程序在各個層次上能夠被測試的容易程度。我們期望通過可測性維度來體現團隊為該系統添加各層自動化測試的成本，測試成本的高低肯定會影響團隊對測試策略的選擇，畢竟無論哪個團隊的資源都是有限的，需要考慮最合適的投入產出比。
- 橫向維度考量被測系統的“質量風險”：我們期望通過“質量風險”維度來體現被測系統對質量風險的承受能力與團隊現階段的質量保障能力，一個銀行結算系統的測試覆蓋率肯定要比一個公司的門戶網站的要求更高一些，同樣一個各層次自動化測試防護完善的系統肯定也不需要團隊再花太多的精力去做更多的回歸測試。
實際的使用中這兩個維度都可以進一步拆分成若干個評分因子，比如下圖例子中藍色因子代表系統可測性，綠色因子代表系統質量風險。不同的系統可以根據自身情況決定需要采用的因子或者給因子添加權重。
2.策略推薦
接下來團隊可以根據自己系統在兩個維度因子的得分，綜合評定系統在象限中所處的位置，不同的象限會根據系統不同的特點有相應的分層策略原則推薦。
- 理想系統 - 1號象限（可測性高，風險低）：這個象限是一個比較理想的區間，首先處于這個維度的系統可測性好，實施各層測試的成本較低。同時質量風險低意味著系統對缺陷的容忍度高，測試實踐的基礎較好。這種系統是很多團隊的期望與目標，所以業界較為推崇的金字塔分層策略適合這樣的系統。
- 遺留系統 - 2號象限（可測性低，風險低）：相比1號象限，2號象限的系統的質量風險低，但可測性也很低。這樣的情況往往出現在企業中的一些遺留系統，這種系統往往因為技術棧的老舊使其添加更細粒度自動化測試成本很高，甚至有些層次無法測試。所以對于這類系統與其固執的繼續高成本的添加細粒度的自動化測試，不如先從成本較低的粗粒度（比如UI）層測試加起形成質量防護網，以待后續系統可測性提高之后再將測試點逐步下移，所以倒三角型的測試策略會更適合2號象限系統的現狀。
- 核心系統 - 3號象限（可測性高，風險高）：同樣相比1號象限，這個維度的系統雖然也有著很高的可測性，但是他們也有更高的質量風險，系統對質量的要求更加苛刻。比如一些企業的核心業務系統或者銀行中涉賬業務比重較高的系統，業務的重要性使他們承擔不起金字塔策略中下移測試點帶來的質量妥協，在各層中都要追求更高的測試覆蓋率以保障系統功能的安全。例如我們見到的銀行系統中對于UI端核心交易流程的測試投入明顯要比其他行業高出許多，所以這類系統在各個層次上的測試覆蓋率都需要比金字塔要更高些，梯形的測試策略就更適合當前象限。
- 遺留核心 - 4號象限（可測性低，風險高）：這個象限的系統基本上綜合了各種不利因素，各層次測試成本高的同時，對質量要求又苛刻。團隊的目標只能是不顧成本的在各層都竭盡可能的增加測試資源，畢竟高質量風險之下的質量要求是不可妥協的。這時候團隊最應該關注的是需要盡早提升系統的可測性，盡可能的降低測試成本。
2.策略演進
使用本模型，一般系統的分層策略的演進會分為兩個階段：
- 第一階段：在明確系統所處的象限之后，對比現狀與該象限的推薦策略，改善系統的測試實踐使它盡可能符合對應象限推薦的原則。
- 第二階段：通過提升系統的可測性與系統的測試基礎降低質量風險，實現維度躍遷。讓系統可以具備更科學，性價比更高的分層策略。
因此最后從演進的整體趨勢來看，策略應當是“從左向右，從下向上”的，一旦你發現團隊的策略在上面的模型中呈現相反的趨勢，那就需要小心了。配合下一段的實際案例大家對策略的演進應該能有一個更直觀的理解。
實踐落地過程及案例
模型實際的落地過程中通常要經歷模型定制，評估打分，制定改進計劃與落地實施4個環節，在具體落地實施的過程中也會對計劃進行迭代調整。
1.模型定制
在模型定制的過程中，模型的維度（可測性與質量風險）是固定的，但對應拆分出的因子可以根據實際的業務類型，系統與團隊狀況進行適當的定制調整。最好能夠與團隊的關鍵干系人以共創工作坊的形式來定制因子，一方面可以讓關鍵的干系人更深的了解模型的運作原理。同時也增加他們的參與感，后續有更強的實施動力。
2.調研 & 評估階段
調研評估這一步的目的是收集被測系統的信息得出因子評分，同時另一個重要的目的就是需要了解系統的測試基礎現狀。一般建議采用關鍵角色訪談加實地調研的方式來收集信息。僅訪談得到的信息往往容易受其他因素干擾，必須現地現物的看到具體的產出。
3.制定改進計劃
改進計劃的制定基本對標策略演進的兩階段：
第一階段，對標系統所在象限的策略原則建議進行改進。
圖中的被測系統通過因子打分定位到了第2個象限，目前系統只有部分自動化接口測試。根據當前象限的策略推薦，系統應該采用倒三角形策略，又因為當前是一個純后端系統，沒有UI層測試，所以主要改進兩個方面：完善現有接口測試與增加單元級別自動化測試，使當前的分層策略更符合推薦的策略。
第二階段，提升可測性，提升測試基礎實現維度躍遷，進一步優化分層策略。
通過對架構的改造，編碼與持續集成實踐的提升，系統實現維度的遷移，但受制于當前系統的實際情況與技術棧，無法將可測性提升到最高，目前階段只能采用半紡錘形策略。
改進舉措可以和團隊的技術負責人以協作的方式共創得出，外部教練往往只能從原則方向的角度去引導團隊，技術負責人則更清楚實際的系統狀況，只有與他們協作才能產出切實可行的改進舉措。
4.策略改進實施
實施過的團隊中改進的具體舉措大都會直接形成技術債卡片，在日常的迭代中把技術債逐步消化掉。這樣就需要團隊的技術負責人統籌、管理這些具體的改進舉措，把他與技術債融合統一排定優先級。為了更科學的管理改進舉措，我們還會通過類似精益價值樹的方式將粗顆粒度的改進舉措逐層進行拆解并制定相應的成功度量指標（MoS）。
總結
在實際輔導客戶團隊的過程中，我們發現：
- 首先，測試分層策略模型能夠幫助團隊建立一個可視化的頂層設計，實現統一規劃，并明確各層次的測試職責，從而實現測試點在各層的合理分布，達到層次間的有效互補與配合。
- 其次，通過分層策略的演進，團隊可以分析并識別當前測試分層的優化點，規劃改進措施。同時，通過可視化現狀問題，推動架構改造等具體措施，以提升系統的可測試性。
- 最后，將策略模型與技術債務償還的實際操作結合，能夠確保測試策略改進與實際工作緊密對接，使測試實踐與最初設計一致，從而實現測試活動的高性價比。
