思考自動化測試--分層測試（三）
由于多種原因吧，自動化測試剛開始發展，都想去做手工測試代替，都想做黑盒的覆蓋測試。結果，自動化測試維護成本過高，穩定性也不好，但是執行效率，回歸起來又不錯。越來越多的人在思考如何更好的做自動化測試。尤其是在敏捷開發盛行的年代，自動化測試已經成了軟件開發測試過程中，重要的組成部分，那么到底怎么做自動化測試收效最高呢。目前較為流行的方式--分層測試。
我比較推薦分層測試的金字塔說法：分層測試就是構建高效的測試金字塔，不同層次的測試可以用盡量低的成本防御不同類型的風險。
說法慢抽象的，先來看個實例圖，再做慢慢解釋：
上面我們先看到了金字塔了，然后我以比較常見的web項目做例子來解釋分層測試。誠如上面說的如果我們單純做黑盒的自動化測試，其實就是在UI這個層次上，不斷開發維護腳本，結果可能帶來的風險就是人員的無限投入，卻很難得到比較好的測試效果。而這個金子塔的意思就是將應用，分成不同層次的自動化測試，比方說UI就是通過界面進行端對端測試，一般是黑盒測試；service一般針對接口，服務，比方說如果你用REST方式構建web的話，那么可以對REST接口進行測試，還有比方說直接對HTTP接口進行測試，對webservice接口進行測試；而Unit這個包含的比較多了，簡單的說在web應用的dao，service，controller，model這些可以寫類似junit的單元測試，javascript，css也可以做前段的單元測試。這這個金子塔就說的，根據層次劃分，不同層次的測試量不同， 越是在塔尖的，測試開發維護都比較復雜，那么測試的量就越小，而下層的單元測試則可進行比較高的覆蓋測試。
簡單的說，分層自動化測試，就是把我們單一看著UI的功能自動化測試，將自動化測試擴展到不同的軟件層次上，進行測試。
這種測試方式，相比于傳統的自動化測試，會有幾個改變：
- 將開發拉入測試：其實測試工作也是開發一個很重要的工作內容，傳統的開發測試分的很細的方式，不利于分層測試，像單元測試，還是需要開發多多投入。
- 將測試引入開發：分層的測試，需要對被測系統的開發結構有認識，至少你要知道你覆蓋了多少了吧，甚至開發大致怎么實現的，不然UI前面對那些接口也不知道那很難評估測試結果的。
- 最好跟持續集成配合使用：重復利用自動化測試的執行成本低的效率，在工程集成完畢前后，更加自動地執行測試，及時的反饋測試結果，從而更好地提高測試效率。
- 使用Mock來實現分層測試，因為是分層那么就可能有隔離一些模塊或者外系統，那么就可以用Mock來模擬這些隔離的模塊，進行測試。
- 需要合理的評估測試覆蓋，不同層次的測試程度都需要合理的評估，這個范圍的控制是保證分層測試測試質量的最核心的規劃，這個才是成功關鍵。
綜上所述，分層自動化測試是追求覆蓋的傳統自動化測試的一種修正，充分利用自動化測試的優點，盡量規避自動化測試的缺點。當然分層測試也有些要注意的問題：
- 測試重復：分層可能對測試是重復的，在上層測過了，下層還繼續測。從測試角度上說是重復測試，但是從整個流程看測試的話，不同層次的測試，屬于過程的不同階段，比方說單元測試，可以在編譯后進行測試，在集成前就可以發現問題，而UI的自動化測試則更加滯后一點，功能不同效果不同，測試的重復還是可以忍受的。
- 測試遺漏：這個就很需要對測試覆蓋的規劃能力，而且這里要說明的一點，自動化測試不能或者很難做到全覆蓋測試。手工測試還是不能放下的，而手工做到全覆蓋是有必要的。
- 測試復雜度，分層測試需要工具比較多，人員能力比較強，要控制那么多工具進行測試，還要對業務，甚至開發有了解，還要開發人員參與進來，投入也不小。
不管分層測試有多少難度，他是目前解決自動化測試開發維護的一個比較好的方案。如果要大規模使用自動化測試，我想分層的思想應該是不容忽視的。
