項目10天投產，測試僅剩2天，如何處理？

看到這篇文章的同窗們必定在各類地方看到過「接口測試」這個詞，那麼接口測試究竟是測什麼?相信每一個人可能都有本身的答案。

接口測試對於很多測試新手來講不太容易理解，接口測試關注的是一個函數、類（方法）所提供的接口是否可靠。接口測試也能夠是url的形式進行傳遞，例如，咱們經過get方式向服務器發送請求，那麼咱們發送的內容做爲URL的一部分傳遞到服務器端。

下面，咱們從實際案例中瞭解一下接口測試效率。

一個項目，規定10天投產，預估5天開發5天測試（這裏估計的是手工測試），那麼接下來由於各類環境或者開發技術緣由致使開發時間延長至8天，測試時間只剩2天，做爲本項目的測試你只有2天的時間進行測試。此項目爲緊急項目，必須保證到期投產。請問如何處理？

手工測試的流程：

手工測試在未提測前的準備：先根據需求編寫用例和數據準備，而後就是等待提測。天天瞭解下開發進度，到第4、五天的時候通知可能要延期，而後真的延期了，第九天提測了，請速度測試。

由於是人力來執行，執行效率有限，原預估五天手工執行速度不會一下縮減到兩天，還有修復缺陷和複測時間（若是真的達到了請在留言區留下聯繫方式讓我瞻仰下手速達人），因此會致使如下幾種結果：

• 砍掉測試用例，保證主流程，測試不夠充分，到期帶bug投產；

• 無限加班、決戰到天亮，到期投產；

• 項目延期。

我相信作測試的人都會遇到以上這種問題，那麼，作自動化接口測試可否改善這種狀況呢？

自動化接口測試的運行場景：

測試前置、開發自測：一個新的自動化接口測試案例開發完成後，直接發給接口對應的開發，安排在開發本地環境執行，一旦開發確認完成接口開發，就開始執行接口測試案例，基本上能夠實時拿到測試結果，節省時間的同時又方便開發快速作出判斷。

迴歸測試：開發本地測試經過後，或整個需求手工測試經過後，把自動化的接口測試案例作分類整理，挑選出須要歸入到迴歸測試中的案例，在持續集成環境從新準備測試數據，並把案例歸入到持續集成的job中來，這些用於迴歸的接口測試案例須要配置到持續集成平臺自動運行。例如每日晚上11點執行腳本，執行完成會發給相關人員。

接口測試的優點體如今下面的三個方面：

• 接口測試節省了測試成本，根據數據模型推算，底層的一個Bug大概可以引起上層的八個Bug，並且底層的Bug很容易引發全網的死機。相反接口測試可以提供在系統複雜度上升狀況下的低成本高效率的解決方案。

• 接口測試不一樣於傳統開發的單元測試，接口測試是站在用戶的角度對系統接口進行全面高效持續的檢測。

• 接口測試是自動化而且持續集成的，這也是爲何接口測試可以低成本、提升收益的根源。

舉這個例子是想更直觀的看下自動化執行效率，但並不是全部的項目都適合接口自動化，這裏只是提出一種更有效的測試方法，仍是須要測試人員根據本身所處的實際狀況判斷哪一種更高效。

以上就是我想和你們分享的關於自動化測試的想法，最後附上一張我在實踐中總結的接口自動化測試時須要覆蓋的內容給你們做爲參考。

——————————————————分割線——————————————————

我是黑少，直男一枚，微服務硬核玩家，喜歡分享、愛交友人、崇尚「實踐出真知」的理念，以折騰鼓搗代碼爲樂

個人微信：weiweiweiblack （備註：開源中國）

微信公號：黑少微服務，專一微服務技術分享，非技術不八卦！