一個項目，規定10天投產，預估5天開發5天測試（這裡估計的是手工測試），那麼接下來因為各種環境或者開發技術原因導致開發時間延長至8天，測試時間只剩2天，作為本項目的測試你只有2天的時間進行測試。此項目為緊急項目，必須保證到期投產。請問如何處理？ ...
看到這篇文章的同學們一定在各種地方看到過“介面測試”這個詞，那麼介面測試到底是測什麼?相信每個人可能都有自己的答案。
介面測試對於不少測試新手來說不太容易理解，介面測試關註的是一個函數、類（方法）所提供的介面是否可靠。介面測試也可以是url的形式進行傳遞，例如，我們通過get方式向伺服器發送請求，那麼我們發送的內容作為URL的一部分傳遞到伺服器端。
下麵，我們從實際案例中瞭解一下介面測試效率。
一個項目，規定10天投產，預估5天開發5天測試（這裡估計的是手工測試），那麼接下來因為各種環境或者開發技術原因導致開發時間延長至8天，測試時間只剩2天，作為本項目的測試你只有2天的時間進行測試。此項目為緊急項目，必須保證到期投產。請問如何處理？
手工測試的流程：
手工測試在未提測前的準備：先根據需求編寫用例和數據準備，然後就是等待提測。每天瞭解下開發進度，到第四、五天的時候通知可能要延期，然後真的延期了，第九天提測了，請速度測試。
因為是人力來執行，執行效率有限，原預估五天手工執行速度不會一下縮減到兩天，還有修複缺陷和複測時間（如果真的達到了請在留言區留下聯繫方式讓我瞻仰下手速達人），所以會導致以下幾種結果：
-
砍掉測試用例，保證主流程，測試不夠充分，到期帶bug投產；
-
無限加班、決戰到天亮，到期投產；
-
項目延期。
我相信做測試的人都會遇到以上這種問題，那麼，做自動化介面測試能否改善這種情況呢？
自動化介面測試的運行場景：
測試前置、開發自測：一個新的自動化介面測試案例開發完成後，直接發給介面對應的開發，安排在開發本地環境執行，一旦開發確認完成介面開發，就開始執行介面測試案例，基本上可以實時拿到測試結果，節省時間的同時又方便開發快速做出判斷。
回歸測試：開發本地測試通過後，或整個需求手工測試通過後，把自動化的介面測試案例做分類整理，挑選出需要納入到回歸測試中的案例，在持續集成環境重新準備測試數據，並把案例納入到持續集成的job中來，這些用於回歸的介面測試案例需要配置到持續集成平臺自動運行。例如每日晚上11點執行腳本，執行完成會發給相關人員。
介面測試的優勢體現在下麵的三個方面：
-
介面測試節省了測試成本，根據數據模型推算，底層的一個Bug大概能夠引發上層的八個Bug，而且底層的Bug很容易引起全網的死機。相反介面測試能夠提供在系統複雜度上升情況下的低成本高效率的解決方案。
-
介面測試不同於傳統開發的單元測試，介面測試是站在用戶的角度對系統介面進行全面高效持續的檢測。
-
介面測試是自動化並且持續集成的，這也是為什麼介面測試能夠低成本、提高收益的根源。
舉這個例子是想更直觀的看下自動化執行效率，但並非所有的項目都適合介面自動化，這裡只是提出一種更有效的測試方法，還是需要測試人員根據自己所處的實際情況判斷哪種更高效。
以上就是我想和大家分享的關於自動化測試的想法，最後附上一張我在實踐中總結的介面自動化測試時需要覆蓋的內容給大家作為參考。
——————————————————分割線——————————————————
我是小微，專註微服務技術分享，致力挖掘更多“高、精、全”的微服務知識分享給大家。
我的微信：weiweiweiblack （備註：博客園 ）
微信公號：黑少微服務，“分享技術，熱愛生活”，歡迎關註
