昨晚在某個測試交流羣，聽了一個測試老司機分享接口自動化測試的內容，對接口自動化有了更深的一些認識，也爲接下來公司的接口自動化實施，提供了更多的思路。
這篇博客，就說說功能測試到接口自動化的進階，以及接口自動化的一些事。。。
前言
自動化測試，算是近幾年比較火熱的一個話題，當然，更是軟件測試未來的一個發展趨勢。未來，功能測試等非核心的測試工作，都將被外包。
想要在軟件測試這個行業繼續前行，就必須擁有核心競爭力，掌握自動化測試技術，是必不可少的一個技能。
在《Google軟件測試之道》一書中有介紹到：在Google，70%的自動化測試工作集中於單元測試，20%集中於接口測試，剩下10%纔是UI測試。
誠然，我們沒有Google那麼完善的機制和工程師文化，沒必要一切照搬Google，但Google作爲互聯網2.0時代最耀眼的一個公司，它的技術發展方向，流程管理等可以說是不久的將來，
我們也要到達的方向。選擇適合自己的，落地應用，是當下我們應該做的。
目前國內的互聯網行業，大環境來說，還處在一個快速發展，需要流程化標準化的時期，如何跟上不斷變幻發展的節奏，除了不斷了解接觸新的東西，還需要不斷學習，提升自身，以內在
的驅動力，去緊跟時代浪潮。即使做不了弄潮兒，也不能變成時代淘汰的那一批。說到這裏，推薦2本書：吳軍的著作《浪潮之巔》、《硅谷之謎》，感興趣的童鞋可以去看看。。。
一、接口測試的必要性和意義
接口，即API，應用程序編程接口，關於接口的介紹，之前的博客就有詳細介紹過，感興趣的童鞋可以去看看：接口測試簡介
這裏主要說說接口測試的必要性和意義：
接口測試實施在多系統的平臺架構下，有着極爲高效的成本收益比（當然，單元測試收益更高，但實施單元測試的成本投入更大，技術要求更高，所以應該選擇更適合自身的纔是最好的方案）。
接口測試天生爲高複雜性的平臺帶來高效的缺陷檢測和質量監督能力，平臺複雜，系統越龐大，接口測試的效果越明顯。
總的來說，接口測試是保證高複雜性系統質量的內在要求和低成本的經濟利益驅動作用下的最佳方案，主要體現在如下三個方面：
1、節省了測試成本
根據數據模型推算，底層的一個程序BUG可能引發上層的8個左右BUG，而且底層的BUG更容易引起全網的死機；接口測試能夠提供系統複雜度上升情況下的低成本高效率的解決方案。
2、接口測試不同於單元測試
接口測試是站在用戶的角度對系統接口進行全面高效持續的檢測。
3、效益更高
將接口測試實現爲自動化和持續集成，當系統複雜度和體積越大，接口測試的成本就越低，相對應的，效益產出就越高。
二、做接口測試需要哪些技能
關於這點，在之前的博客也說過，傳送門：做接口測試需要哪些技能
做接口測試，需要的技能，基本就是以下幾點：
業務流：瞭解系統及內部各個組件之間的業務邏輯交互；
數據流：瞭解接口的I/O（input/output：輸入輸出）；
協議：包括http協議，TCP/IP協議族（之前的博客有系統的介紹過協議，傳送門：http協議：菜鳥入門系列）
工具：工具可以輔助我們更好更高效的完成工作，常用的接口測試工具有：jmeter、loadrunner、soapui、postman等；
數據庫知識：無論是從數據庫獲取知識，還是確認數據落地，抑或接口對數據執行了哪些操作，都需要確認，因此數據庫知識（其實就是增刪改查）就很有必要；
補充：接口文檔的幾個必要點：完整性、一致性、容錯性；
三、接口自動化測試
1、如何開展
首先，調試單個接口，保證單個接口的正確和通暢（類似於性能測試中的基準測試）；
其次，明確數據流，業務流；
最後，將N個接口測試腳本串起來，執行即可；
最重要的一點，別想太多太複雜，先把最基礎最簡單的做起來，就成功一大半了，至於擴展性的第三方接口、https、定時任務、自動出測試報告、自動發郵件等等功能，這都是不斷累計和優化的，
行動起來就行，想太多不如行動起來，讓接口自動化測試落地，纔是我們首先需要考慮的！
2、開展之前需要知道的
現在的測試對象包含幾個頁面？
每個頁面涉及幾個接口？
分別在哪一步調用？
每個接口包含哪些字段？
各個字段對應數據庫哪張表？
每個表中各個字段是什麼意思？
各個接口對錶產生了怎樣的操作？
3、自動化框架
什麼是框架？你可以理解爲一個完整的環，也可以理解爲讓接口測試腳本運行的一整套環境，平臺，隨便什麼都可以；一般一個自動化測試框架包含以下幾點：
數據池：即測試數據的存儲管理，一般集成爲一個data包，其中包括：
log（日誌文件）、report（測試報告文件，一般爲xml格式）、
case-data（單個接口的測試數據，一般爲json格式）、server-data（接口業務串聯的數據，可以用excel管理）腳本管理中心：接口測試腳本的統一管理、存儲、調度中心，常用的工具有maven、ant等，或者可以使用編程語言中的單元測試框架提供的功能，選擇自己適用的即可；
運行平臺：一般是藉助工具來運行這些測試腳本，工具可以使用上面提及到的幾種（jemter、loadrunner、soapui等），同樣，選擇合適的很重要；
持續集成工具：最常見的就是Jenkins，它的作用就是監控外部程序的調用執行，定時或者觸發調度任務，測試腳本執行等功能；
通信服務：dubbo、spring_boot、thrift等RPC、REST同步調用服務；
測試結果統計管理中心：比如testlink，目的是爲了測試結果自動更新上傳，更好的統計測試結果，以便後期的優化；
上面說了這麼多，實際上它的意義就是：數據與腳本分離，測試結果自動提交通知，提高測試腳本和測試數據的維護便利等等。。。
我正在使用的框架爲：jemter+maven+Jenkins+dubbo+MySQL......
關於接口自動化測試，基本就是上述的內容，當然，選擇適合自身實際情況的框架，落地實施，纔是重點，行動起來，才能鹹魚翻身。。。