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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

通過上面的內(nèi)容，我們知道GUI測試是不能替代API測試的。那么，有人又說了：“既然這樣，等測試人員測試完GUI，再讓他們測試API好了。”這樣也是不行的，我們需要將負(fù)責(zé)這兩個(gè)測試的人員分開。因?yàn)槿撕苋菀资艿綉T性影響,從而導(dǎo)致發(fā)現(xiàn)不了問題，也就是所謂的當(dāng)局者迷。

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

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

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

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

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

因?yàn)樯婕暗蕉鄠€(gè)從屬系統(tǒng)，想要構(gòu)造一個(gè)完整真實(shí)的測試環(huán)境幾乎是不可能的。因此，開發(fā)人員和測試人員可能面臨：

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

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

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

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

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

有些測試團(tuán)隊(duì)為了控制風(fēng)險(xiǎn)，會重復(fù)執(zhí)行測試方案。這里有一些更好的建議：

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

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