提綱
分層測試的好處
為什么要做分層測試
從軟件工程的角度，結合軟件開發的V模型、MVC架構、測試金字塔，綜合起來便於理解
1.借鑒與軟件開發的V模型
從V模型的底部往右上方向，先做單元測試，再做集成測試一直到最后的驗收測試。
2.來源於MVC架構
MVC全名是Model View Controller，是模型(model)－視圖(view)－控制器(controller)的縮寫。
我們可以簡單理解為V是用戶看到的界面，C是中間邏輯，M是數據。對於現在流行的微服務SOA來說，V就是前端WEB或者APP, C就是中間密密麻麻的各種接口，M就是最下層的數據：
3.來源於測試金子塔
testing pyramid，類似於V模型，把測試行為從下往上分為單元測試、組件測試、集成測試、系統測試、手工測試。對於測試金字塔，越往下靠越容易自動化，越靠下成本越低，越靠下效率越高。
分層測試的好處
1.定位快：測出哪一層問題，很明確。此方法在處理線上問題則比較常用。
2.針對性強：在用例設計和測試執行時，更具有針對性，思維更清晰。
3.加強對代碼實現邏輯的理解，拓展測試技能。
4.節約時間成本：1）分層測試是一個迭代的過程，測試可以提前介入，不用等到最后面才介入，縮短整體項目時長。2）提前暴露問題，縮短BUG查找時間和修復BUG的時間。
怎么做分層測試
分層測試的測試方法還是原來的測試方法，但對測試人員的代碼能力還有自動化測試水平有較高要求，同時要求測試人員和開發團隊真正的理解敏捷開發和敏捷測試，甚至要求開發團隊達到開發即測試、測試即開發的能力。
手工測試：需要測試界面、微服務的接口和數據庫。
測試開發：還需要關注分層的自動化測試、單元測試、持續集成和持續發布。
在測試的時候，不僅要關注需求文檔中的需求，還要考慮一些隱藏的需求，以及開發的實現，開發采用不同的實現方式，會產生不一樣的測試點
要更多的站在用戶的角度去考慮用戶的使用場景，流程設計是否合理，交互是否順暢，文字是否有歧義，提示是否明確而友好
開發采用了什么技術，什么框架，設計是否合理，是否高效，是否有擴展性，流程是否可控，是否考慮了異常情況，數據處理是否合理，是否存在性能問題，安全性有沒有考慮等等
針對上面的分層結構，我們在設計測試用例的時候，需要考慮以下圖所示的情況（粗略，還需要拓展）：
通常測試人員和開發打交道較多，那么分層測試可以是下圖這種模式：
實施方法
- 單元測試由開發人員在代碼實現完成后進行，QA主要進行接口和UI層的測試。
- 接口層測試：
- 項目啟動時，相關人員評估是否需要QA介入接口測試；交付節奏快、代碼量很小的項目，可以直接從UI層驗證，不需要QA人員進行接口測試；其他項目根據需要進行接口測試。
- 根據開發計划，確定執行接口測試的時間。
- 參與到接口評審，根據接口文檔，確定被測接口。
- 設計case、准備數據、執行測試。
- 跟蹤Bug。
- UI層測試：前后端聯調完畢后，進入接口層測試。UI層測試除了關注UI交互的問題，更重要的是站在用戶的角度，從UI層完成端到端業務流程驗證，易用性、穩定性等因素也是這個層面測試需要考慮的事情。
- 分層測試自動化：
- 從接口層、UI層選擇回歸頻率高的業務流程做自動化回歸，降低回歸測試成本。
- 不是所有業務流程都適合做自動化測試，自動化用例維護也有成本，選擇自動化目標時，應考慮選擇不頻繁變動的流程。
- UI層的變動大，維護成本高，從自動化用例的比例來看，也應該遵循金字塔的結構，UI層應該是占比最少的，把更多的自動化回歸放到接口層、單元測試層。