關於自動化測試的定位及一些思考
大家對自動化的理解，首先是想到Web UI自動化，這就為什麼我一說自動化，公司一般就會有很多人反對，因為自動化的成本實在太高了，其實自動化是分為三個層面的（UI層自動化、介面自動化、單元測試），不是每個層面的自動化都是遙不可及的，以下標示一下這三個層面的難易程度（網上叫這個為自動化金字塔）：
基本上可以肯定的是，單元測試是成本最低的，也是最容易推廣，見效最大的，但是很多公司不會投入這塊，原因是因為現在大部分公司都是人才短缺，特別是成手的研發人員。你說投入到專案實際開發工作的人員都嫌不夠，怎麼可能抽出相關人力去做單元測試。而以目前大部分公司的測試團隊人員構成來說，能做單元測試的基本沒有（有也被抽去做開發了），這也是大家一致認為單元測試屬於開發職責的原因（除了他們自己沒人能做了）。
單元測試如果做不了，那麼介面（API或Service）自動化測試能做不？這個只要有一定的技術基礎還是能做的，至少有一部分測試人員是能夠做介面測試的（話說效能測試就屬於一種介面自動化），如果能自主開發或直接引進一套像樣的介面自動化工具或框架（工具上來說，市面上也不少），那麼就可以開展這部分的工作，我相信大部分公司能做好的自動化測試，應該也是基於這一層的（所以我們建議有條件的話，自動化測試可以先在這一層面開層，當然前提是真有那麼多介面或服務需要測試）。介面自動化測試框架應該具有以下功能，根據複雜度和各自需求而定：
1、校驗
這個很好了解，如果沒有校驗，單純的執行介面的話，那就談不上測試了。所以支援對返回值校驗是一個必須的功能。
2、資料隔離
資料隔離就是指具體的請求介面、引數、校驗等資料做到與程式碼相隔離，便於維護，一旦需要調整介面用例、新增介面用例時可很快速的找到位置，隔離的另一個好處就是可複用，框架可以推廣給其他團隊，使用者可以使用相同的程式碼，只需要根據要求填寫各自用例即可測試起來。
3、資料傳遞
做到資料隔離可維護後，資料傳遞是另外一個更重要的需求。
資料傳遞是指介面用例之間可以做到向下傳參，例如我們通過建立訂單介面建立一個訂單，該介面會返回一個訂單號，接下來我們要進行呼叫查詢訂單的介面，從返回的資料中與建立訂單用例中的資料進行校驗，此時第二個介面的請求資料是需要從第一個介面用例中的返回中提取的。這樣的例子比比皆是，所以支援資料傳遞是又一個必不可少的功能。
4、動態函式
實際用例場景中我們可能會有隨機生成一個手機號、字串加密等需求，在資料與程式碼隔離之後，此時我們就需要程式碼可以支援做到識別對應關鍵字時可以執行對應的函式進行填充。例如在資料中填寫nowTime()時，具體執行時會被替換成當前時間，填寫random(5)時，會被替換成一個五位的隨機數等等。
5、可配置
有時，我們的需求是用例不單單隻能在一個環境上執行，可能需要同一份介面用例可以在QA、預發、線上等多個環境都可以執行。所以框架需要做到可配置，便於切換，呼叫不同的配置檔案可以在不同的環境執行。
6、日誌
日誌包含執行的具體執行介面、請求方式、請求引數、返回值、校驗介面、請求時間、耗時等關鍵資訊，日誌的好處一來是可以便於在新增用例有問題時快速定位出哪裡填寫有問題，二來是發現bug時方便向開發反饋提供資料，開發可以從觸發時間以及引數等資訊快速定位到問題所在。
7、視覺化報告
用例執行後，就是到了向團隊展示結果的時候了，一個視覺化的報告可以便於團隊成員瞭解到每次自動化介面用例執行的成功數、失敗數等資料。
8、用例驅動
（1）用例的驅動模式，涉及到怎麼存放測試資料，怎麼描述用例，又如何複用；
（2）考慮到效率的話還要支援併發；
（3）當然測試報告不能光記錄成功和失敗，還有用例執行耗時、介面呼叫耗時、場景的通過率等各項數值的統計。
說完單元測試、介面測試的自動化，我們現在來說說UI層自動化測試，這也是一直很火併且也是自動化概念先入為主的一塊，畢竟市面上有不少成熟的自動化工具，如QTP、Selenium等。這塊自動化一定是會有測試團隊參與的，就算自動化框架是由開發來完成，那麼具體測試工作也是由Tester全程參與的。UI層自動化測試真的不容易推行，無論有多麼完善的自動化框架，在這一塊維護的成本也是非常高的，特別是懂開發的人不懂測試，懂測試的人不懂開發，這一矛盾現象所帶來的內部消耗就不少，再加上專案需求和UI層都在頻繁變動，而且Web UI技術越來越複雜和多元化（UI層自動化需要基於物件識別技術），這些都導致很多公司不願意投入這一塊。即使這樣，做為一個有上進心的測試人員，我們也是需要多想想這一塊，畢竟這是離我們測試最近的一塊“技術沃土”了（之一）。
現在我們來重點來談下Web UI自動化測試（目前的系統大都通過Web UI來展示），一般成熟一點的自動化工具方案大體是這樣：
1、開發語言：Python或Java；
2、開源測試框架：Selenium WebDriver；
3、Web元素定位：Xpath+cssSelector+findElement或findElements方法；
具體實施細節來講重點是針對Web UI自動化測試的特點，將各層包裝，分而治之的思想，各自相互獨立，職責定義清楚，下面簡要說明下：
1、測試用例業務流操作實現及測試資料分離管理；
2、頁面元素定位及頁面元素的操作分離；
3、視覺化的日誌查詢系統；
4、跨瀏覽器支援如：IE,Firefox,Chrome；
5、視覺化的的測試報告，可以具體查詢到日誌/截圖等；
6、實現了通過Excel的資料驅動管理；
7、郵件傳送管理，可以自定義具體時間及接受者等；
以上是一般Web UI自動化測試的一些實踐要求，當然也是相對簡易的，複雜的就是實現平臺化管理，每天測試工程師，只需要選擇具體專案、所測的測試用例集，然後執行，輸出測試報告，郵件自動傳送到相關開發/測試，框架的開發維護上也能夠持續整合。
說完了這三個層面的自動化測試，那麼我們再來分析一下，到底應該優先開展哪個層面的自動化測試，到底是哪個投入產出比最高，以下分享一篇網上文章的部分內容，人家已經給了答案：
眾所周知，軟體測試的邊際成本會隨著缺陷探測率的提高而提高，這就是軟體測試的基本公理之一"測試的不可窮盡性"的經濟學體現。這一規律也適用於自動化測試，也就是說隨著自動化覆蓋率的提升，自動化的成本也呈現指數式上升。按照這個思路進行拓展，可以分析下單元測試，整合測試和UI測試的自動化成本曲線如圖2所示。與通常理解的一致，為了達到相同的自動化率(x0)，UI的成本最高、其次是API，Unit則最低。
經濟學中有另外一個著名的理論叫做邊際效益遞減。當做一項投資，隨著投資量的增加，單位投資增量所帶來的單位收益是越來越少的，甚至在某個臨界點之後，這個收益有可能是負數。而這個零界點，就是投資收益最大的點。在這個點之前的所有投資，都可以擴大總收益，而在超過之後繼續進行投資，就不那麼明智了。
圖2 自動化成本/收益曲線
按照這個思路，在圖2上，針對三種不同型別的自動化測試，可以獲得三個零界點。而總收益最大的點在介面測試上，隨後是單元測試，UI測試則最低。
如果從測試效果上看，介面測試和UI/單元測試相比，有很多優勢。 對於單元測試來說，通常單元測試是針對程式碼進行的測試，而介面測試是在測試一個活的，經過部署的系統。 另外，單個介面測試與單個單元測試用例相比，也可以覆蓋更多的程式碼。更重要的是，介面測試也可以是面向業務的測試，通過介面進行業務層面的測試。
而相比UI自動化用例，介面測試更加的簡單直接，執行效率更高。 除了部分如企業級應用軟體，可能很多業務在前端進行之外，很多情況下，絕大部分通過UI完成的業務操作完全可以通過API端完成。某些情況下，API（介面）的測試條件覆蓋率甚至可以多過UI。
綜合上述的分析，筆者認為在自動化測試的初級階段，適合奔小康的測試團隊的自動化模式應該是中間層的介面最大，兩端的UI和Unit測試適度實施。從圖形上看，就是一個橄欖型（中間的介面測試效益比最高）。如果再加上一部分的手工測試，那就是一個不倒翁了。（題外話：介面測試可以由開發團隊來做，也可交由測試團隊去開展）
按照這個模式，將大部分自動化投資用於介面測試，可以獲得最高的投資回報。再結合持續測試與持續整合等最佳實踐，在團隊之間彼此共享測試用例、測試框架或者平臺，通過介面測試這一承上啟下的測試型別，可以自下而上地逐步翻越過紙杯蛋糕模式中的那堵牆。（備註：紙杯蛋糕模式，是一種反金字塔的自動化模式，開發和測試各自為政，線性的開展測試，無法並行協同測試，相當於有道部門牆，開發的自測環節和測試開展的測試環節，沒有建立關聯和資源共享---重複測試、度量目標不一致、過度自動化）