分層是復雜軟件系統常見的設計思路。比如
互聯網的七層/五層模型，
Android系統的APP/FWK/JNI/Kernel等，都是通過分層、解耦，達到簡化問題，易于維護，便于擴展的效果。
傳統的
黑盒測試主要關注客戶需求，
白盒測試比較靈活，但實際應用中以驗證編碼實現為主，兩者都忽略了設計這個開發過程中承上啟下的環節。
分層測試的核心思想是：針對有明確分層設計的軟件系統，采用白盒測試的技術，在層與層之間驗證接口的正確性。分層測試以調用接口驅動被測系統，盡量不依賴于打樁（具體原因后面會提到）。去年下半年開始我們在Android測試中嘗試分層測試，取得了很好的效果。
1、精準。我們都知道，離問題產生的地方越近，就越容易觸發問題。如果問題發生在底層，以白盒測試的方法，很難精確打擊，特別是一些復雜場景或異常流程，可能無法構造。而分層測試的切入點就是層與層之間的接口，從機制上更接近出問題的地方，因此也更容易命中目標。
2、低成本。這個優勢源于可測試性。舉例來說：我們要測試Android系統下撥號的性能，黑盒怎么測呢？測試人員需要打開秒表，同時進行撥號的操作，并觀測電話是否撥通。操作麻煩不說，誤差也很大。如果用分層測試的方式，只要提供撥號和檢查是否撥通兩個對外開放的接口，通過用例腳本調用，并記錄兩者的時間，就可以方便準確地得到耗時。更進一步，我們還可以在不同層次的接口調用時均記錄下時間，在腳本中直接對各個環節的耗時進行分析，從而自動分析流程的瓶頸，找到影響性能的關鍵環節。
再回過頭來看前面提到的盡量避免打樁的建議，也是考慮到成本。打樁是白盒測試最困難的部分，特別是涉及到復雜的數據類型或者系統內部狀態。因此很多開發同事不愿意使用UT。分層測試重驅動弱打樁，測試腳本主要還是運行在真實的測試環境中，這樣就避免了打樁上的投入，也更接近開發的調試手段。
3、高效。這里是指用例執行速度快。首先
自動化測試的速度就明顯優于手工測試，基于API調用的自動化又比UI自動化要快，分層測試的高效就建立在API調用高效的基礎上。從我們收集的數據來看，相同的用例，手工執行的耗時平均在5-8分鐘，UI自動化一般也需要1-2分鐘，而分層測試通常10-20秒就完成了，效率提升達10倍。
4、易定位。易定位其實是和精準對應的。在
用例設計的時候就考慮到用例所針對的代碼，一旦出現問題，自然就容易定位了。
5、穩定。客戶需求是易變的，內部實現也是易變的，但是層與層之間的接口是不同開發人員之間的約定，通常會盡量保持穩定。這里也有一組數據：從Android 4.2到Android 4.4，我們設計的JNI層用例變更不到10%，而針對APP界面開發的用例，變更率高達40%。
6、盡早測試。盡早測試是
敏捷所提倡的，目的是把問題攔截在前端，降低問題修復成本。由于分層測試不依賴于完整系統，可以通過直接調用底層接口進行測試，就不需要等到整個系統開發完成。其實分層測試的思想和自底向上的系統開發模式也是不謀而合的。
介紹了這么多分層測試的優勢，那么它是萬能的銀彈嗎？首先，分層測試不是端到端的測試，接口之上的部分無法覆蓋，因此無法替代驗收測試。另外，分層測試依賴于被測系統良好的分層設計，如果被測系統的結構不清晰，耦合嚴重，分層測試就不合適了。