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