互聯網“土地革命”的下一個階段也許是關于API的戰爭。Web時代著力于為用戶提供更快、高效地產品和服務，而API則可以拓展B2B之間的業務品牌聯系。這意味著，無論是商家還是客戶都需要一個服務級別協議（SLA），來促進業務整合。然而對于服務消費來說，面向服務的架構（SOA）需要信任，公眾和私人服務需要API的完整性。

隨著API經濟的出現，不可否認的一點是越來越多的業務將會影響API風險。確保您API的安全性、可靠性和預期性能水平顯得比以往任何時候都要重要。

誤區一：在有SLA的情況下，不需要進行API測試

如果應用程序API出錯了，很容易讓用戶感覺你的應用程序隨處充滿漏洞。無論故障是出現在組件中還是API中。應用程序對我們來說很重要，包括開源軟件和將要采用的API。我們使用第三方功能的同時，也會將我們暴露于風險中。

當你將API整合到你的業務處理中，API的完整與否將會與業務風險息息相關。幾乎不考慮客戶滿意度和品牌忠誠度的做法是很危險的。一般情況下，我們認為其他組織公開的API是安全和可靠的。但如果不是，它可能會給我們帶來很多問題，例如品牌侵蝕、顧客丟失、收益減少。

對于每個API測試的嚴格程度，取決于它在業務過程中的重要程度。比如，一家航空公司的在線辦理登機手續過程中，有一個負責在線打印天氣預報的API，它的測試并不需要投入太多的精力。

誤區2：它已經包含在GUI測試中

很多次，當問客戶是怎樣進行API測試的時候，他們都是回答：“這是屬于GUI的測試內容呀。”進行GUI測試是無可否認的，它是任何終端到終端的測試過程中不可缺少的一部分。但是，GUI測試本身并不能有效的行使API。

比如，一個公開的API，并且可以直接訪問。它是否可以扛得住大范圍的誤用和惡意攻擊呢？

在應用程序的UI層面進行操作是很難獲得大面積的API測試覆蓋率的。它只能測出一些顯而易見的，很容易表現出來的錯誤。然而，更多的問題是掩蓋在行為、數據、性能和安全方案下的。這些都是很難從UI中看出來的。所以，僅僅是CUI測試而沒有API測試，我們很難保證API的安全性和可靠性。

此外，我們還需要關注事件過程。當UI報告顯示“交易成功”，你確定它是否真的各個方面都達到了預期效果呢？例如：

• 數據庫是否更新？
• 消息是否被傳送到ESB？
• 如果測試失敗，你能找出時間、位置和原因么？

最后還是要強調，GUI的測試結果真的不堪一擊。會為如今快速更新換代的應用程序帶來難以預計的風險。應用程序即使只有微小的變化也會導致測試套件的不同步。比如：

• 即使沒有出現錯誤也會報告測試失敗——這將大大降低團隊的工作效率。
• 測試失敗時，無法找出問題的真正原因。

誤區3：GUI測試人員可以直接執行API測試

通過上面的內容，我們知道GUI測試是不能替代API測試的。那么，有人又說了：“既然這樣，等測試人員測試完GUI，再讓他們測試API好了。”這樣也是不行的，我們需要將負責這兩個測試的人員分開。因為人很容易受到慣性影響,從而導致發現不了問題，也就是所謂的當局者迷。

一個簡單的API測試的主要步驟包括多樣的正負輸入和大量的測試案例。這些不需要大量專業知識和工具就可以完成。這些方法可以很好地測試API的功能。

但如果你想真正了解API在關鍵業務過程中的出錯風險，必須在真實場景中使用API。它是否可以記錄多種事務狀態（是否登陸，不同的偏好設置等）？進入到下一個步驟的消息響應是否合適？它是否觸發了正確的行為？例如，JMS消息是否恰當的出現在ESB中。

為了使我們設計的測試案例可以真實的反應API在真實場景的行為，需要關注：

• 安全訪問控制認證機制
• JMS和MQ隊列
• 主機方位
• SAP或其他ERP訪問
• ESB訪問
• 數據庫訪問
• 數據交換中將測試數據設為最優先級
• 真實數據可能會與其他數據產生合并、混淆
• 復雜的驗證可能覆蓋和關聯多個不同的場景步驟和技術

誤區4：無法執行終端到終端的測試

因為涉及到多個從屬系統，想要構造一個完整真實的測試環境幾乎是不可能的。因此，開發人員和測試人員可能面臨：

• 復雜的測試環境
• 區分和控制邊界，限制資源訪問
• 不可訪問的第三方/合作伙伴的系統和服務
• 限制測試時間窗口
• 缺少/不穩定成分
• 不斷變化的開發環境

使用服務器虛擬化，團隊可以快速創建模擬測試環境，獲得必要的系統行為。無需訪問實際的生產環境即可進行測試。服務器虛擬化解決方案捕獲實時系統行為，讓你無需為制約因素、等待時間和訪問費用的問題煩惱。

誤區5：不僅僅是測試，還需要監控

隨著敏捷開發與持續交付的采用率上升，變化的發生無處不在。甚至一些微不足道的變化都可能引起上游組件與API的交互和下游組件對API的處理。

了解到細微的變化如何對業務流程造成影響，我們知道測試的每一步都是至關重要的。它能保證程序可以達到預期的功能、性能、安全性和可靠性。通過對這些變化對程序的影響，我們可以很容易的設置測試周期。

有些測試團隊為了控制風險，會重復執行測試方案。這里有一些更好的建議：

• 使用連續的回歸測試，以確保進程達到預期目標。
• 定期分析被測試的API，以及它們的依賴關系。

即使你經常監視您的應用程序與APM解決方案，大多數只是臨場表現的變化。功能更改通常沒有監測，檢測或報告。如果要確保API驅動的流程總是符合預期，你需要一個有一個強大的回歸測試套件。它可以幫助你完成預期的監控力度。并且當出現問題時，會立刻通知你。使你更容易查明故障的根本原因，幫助你快速解決問題，大大減少了故障對業務的影響。