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進行徹底的了解，并快速的給出最佳的分層測試方案。