google測試分享-分層測試

作為網際網路產品來說，我們可以認為產品一直都在beta階段，為什麼這麼說。兩個原因一個是是我們需要使用者的真實體驗來告訴專案團隊這個產品的質量到底怎麼樣，另外一個就是我們一旦發現影響較大的bug，我們可以很快的fix bug，讓產品體驗得到迅速的提升。

      在網際網路產品的新專案啟動過程中，google為了讓SET和TE都能在專案中發揮更大的價值，同時為了讓開發人員具有很高的測試意識和質量意識，特意將專案的測試階段分成三個階段：

小型測試：主要包括單元測試、模組測試，使用mock、fake 等技術來完成，這個階段SET通常會參與進來，但是開發人員仍然是測試的主力，TE卻很少參與。測試執行都是自動化測試執行。

中型測試：主要包括元件測試、特殊區域的整合測試、功能互動的整合測試，這個階段部分是自動化測試執行，部分是手工測試執行。

大型測試：主要包括長鏈路的整合測試、系統測試。從真實使用者的角度，使用真實的資料進行使用者體驗性的測試。這個階段的測試耗時較長，大部分是手工測試，考慮整體產品的服務質量。

      在專案測試計劃過程中，會對小型、中型、大型測試做一個比較詳細的區分，也就是測試範圍的確定，這三個型別的測試的比例很關鍵，不同專案也是不一樣的，一個判斷是否健康的標準是看程式碼覆蓋率。總體上，70/20/10原則：70%是小型測試、20%是中型測試、10%是大型測試。面向使用者的、基礎平臺的會不一樣。下面詳細的說明在不同型別的測試活動上，開發、SET、TE是如何緊密的合作的。

     小型測試階段，開發人員主導測試程式碼的編寫和測試執行。SET和開發人員一起進行單元測試的測試設計，部分功能的測試程式碼編寫，幫助做可測試性上的分析。開發寫程式碼是建立、考慮使用者、使用場景和資料流程上，而測試是破壞、擾亂分離使用者及其資料，所有寫功能程式碼和測試程式碼的思維是不一樣的。CI起來後的小型測試的測試執行也是由開發人員主導的，小型測試在每次code commit後的執行情況都需要開發人員主動去了解並保證所有小型測試的結果都是PASS。其實這裡面還包括code review，每個checkin的程式碼都需要經過SET和開發人員的code review。所以Change list裡面顯示的不僅僅是功能程式碼，還包括測試程式碼。

      中型測試階段，SET主導測試程式碼的編寫和測試執行。對於一個產品的CI來說，小型測試和中型測試的測試程式碼持續執行和迴歸由開發人員、SET、TE共同負責，並不是說由某一個角色來負責。其實也就是說TE也會參與中型測試的測試程式碼的維護和執行工作。對於複雜系統來說，中型測試的測試覆蓋率可能會更高，SET參與的力度會更大。這個階段，和我們國內通常做的介面測試有很多相似之處，介面測試其實包含單個重要介面的介面測試和多個介面之間的整合介面測試。對於阿里來說，上層業務基本上就做單個重要介面的介面測試，而針對中心級別的底層系統，更多的是多個介面之間的整合介面測試。

     大型測試階段，主要是TE主導系統級別的自動化測試和手工測試。大型測試的優點就是能夠真正的站在使用者的角度去使用產品，體驗產品，總體上把控產品的功能和效能等其他特性（這個正好是TE很擅長的能力）。當然缺點就是發現bug後，精準的找到失敗的原因比較困難；另外一個就是測試資料準備工作比較耗時，很難走到特定的程式碼路徑區域（較多的異常else語句）。需要強調的是這些手工執行的case並不僅僅是TE來執行，專案組的其他成員包括PM、PD、開發人員、SET都會得到手工執行case的執行任務，總體策略和結果分析由TE全程把控。

     產品總體質量的dashboard需要展示每次build測試結果、測試進度、自動化測試機構、程式碼覆蓋率。開發人員甚至比SET更加關注CI的結果，而國內的開發人員很少主動關心CI結果，很多時候都是被測試人員通知到，然後還看心情。針對於複雜的系統，我們都需要建立構建依賴規則（記得之前淘寶測試開發了一個dependence系統，將系統之間的依賴關係全部對映出來，跟進code change來實時通知迴歸機制，挺好的事情，不知道後面為啥沒了），通過程式碼變更的地方，來找到本次修改需要run的測試集；比如通用庫上程式碼變更、一個依賴專案上程式碼變更等，使持續整合和錯誤定位更加精準。

     這裡面可以發現google的測試階段的劃分和分層和大部分網際網路公司是一致的，但是google會更加強調小型測試階段的投入產出比，使用自動化測試手段來使用程式碼去測試程式碼，增加確定性和持續性，相比於手工測試而言。另外一個不同點就是google的開發對CI後的結果的重視程度也遠超與國內開發人員，最近幾年自動化測試的發展很快，國內很多測試團隊都寫了很多自動化測試程式碼並CI起來了，但是CI結果的利用以及完善和維護沒有跟上來，很多大公司也存在這樣的問題，他們更多的是關心編寫了測試程式碼，關心自己有能力編寫程式碼，而不去關心維護測試程式碼，不去關心測試程式碼有沒有發揮它應有的價值。

     個人認為真正的測試架構師可以輕鬆的把任何一個SUT分層測試策略規劃出來，甚至在架構和功能細節上進行細分，讓分層測試更加的有效和合理，從而體現整個產品的質量控制計劃的完美性，當然也會參與需要用到的測試工具的架構技術和思路上的指導。在SET和TE做的都比較不錯的才可以把這個任務做的那麼完美，否則只會寫程式碼的人、只會黑盒系統測試的人都無法對SUT進行徹底的理解，並快速的給出最佳的分層測試方案。