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

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

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

如果應(yīng)用程序API出錯了，很容易讓用戶感覺你的應(yīng)用程序隨處充滿漏洞。無論故障是出現(xiàn)在組件中還是API中。應(yīng)用程序?qū)ξ覀儊碚f很重要，包括開源軟件和將要采用的API。我們使用第三方功能的同時，也會將我們暴露于風險中。

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

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

誤區(qū)2：它已經(jīng)包含在GUI測試中

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

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

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

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

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

最后還是要強調(diào)，GUI的測試結(jié)果真的不堪一擊。會為如今快速更新?lián)Q代的應(yīng)用程序帶來難以預計的風險。應(yīng)用程序即使只有微小的變化也會導致測試套件的不同步。比如：

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

誤區(qū)3：GUI測試人員可以直接執(zhí)行API測試

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

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

但如果你想真正了解API在關(guān)鍵業(yè)務(wù)過程中的出錯風險，必須在真實場景中使用API。它是否可以記錄多種事務(wù)狀態(tài)（是否登陸，不同的偏好設(shè)置等）？進入到下一個步驟的消息響應(yīng)是否合適？它是否觸發(fā)了正確的行為？例如，JMS消息是否恰當?shù)某霈F(xiàn)在ESB中。

為了使我們設(shè)計的測試案例可以真實的反應(yīng)API在真實場景的行為，需要關(guān)注：

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

誤區(qū)4：無法執(zhí)行終端到終端的測試

因為涉及到多個從屬系統(tǒng)，想要構(gòu)造一個完整真實的測試環(huán)境幾乎是不可能的。因此，開發(fā)人員和測試人員可能面臨：

• 復雜的測試環(huán)境
• 區(qū)分和控制邊界，限制資源訪問
• 不可訪問的第三方/合作伙伴的系統(tǒng)和服務(wù)
• 限制測試時間窗口
• 缺少/不穩(wěn)定成分
• 不斷變化的開發(fā)環(huán)境

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

誤區(qū)5：不僅僅是測試，還需要監(jiān)控

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

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

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

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

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