API測試提供了許多可維護的自動化功能，可以擴展到性能和安全測試中，但是您的普通測試人員無法訪問。了解如何顯著減少與創建有意義的測試方案相關的時間。

轉向微服務和API驅動的架構正在推動整個行業的重大創新，但也使企業面臨隱患。人機界面（Web和移動UI）不再是主要業務風險所在。相反，最大的漏洞隱藏在API的非人機界面中。

因此，API測試已成為越來越多的關注點，但是我們始終都在聽到“API測試又是什么，為什么我需要它？”

快速總結是，應用程序編程接口（API）是應用程序使用由定義的合同管理的公共接口彼此通信的方式。采用API測試的背后推動力是能夠以獨立于UI的穩定方式測試應用程序的業務邏輯。與僅在前端進行測試相比，API測試可以進行更全面的測試，例如，可以進行性能和安全性測試。行業分析家和敏捷專家（例如Martin Fowler和Mike Cohn）都認為API測試是必經之路。那是什么使我們退縮呢？

測試無效的影響

 軟件團隊希望花費理想的時間，而不僅僅是測試和調試，以最大化成功項目的潛力。但是，傳統上，很難減少在測試和調試上花費的時間，因為在軟件生命周期的后期（包括發行后）發現了許多嚴重的錯誤和安全漏洞。

下圖說明了何時將缺陷引入到應用程序中，以及時間安排對每個階段修復缺陷的成本的影響。您可以清楚地看到，后期缺陷的成本是巨大的——成本的增加來自多種因素（例如，診斷問題和確定根本原因所需的時間，參與該過程的人員數量，以及與缺陷修復相關的日益增加的復雜性（以及由此帶來的風險）。

如果您想自己，“我以前見過”……您可能已經知道了！1996年，Capers Jones發布了此圖表背后的研究報告，即使過去20年中軟件開發實踐發生了變化，但最新的研究報告仍然與今天相關。

我們想成就的地方：測試金字塔

那么我們是在哪里錯了？我們采用的質量方法是錯誤的——我們需要查看上表，并尋找左移缺陷檢測并盡早發現，更容易診斷和修復的缺陷的方法。深入的代碼分析之類的技術可以在編寫代碼后立即發現嵌入在代碼庫中的安全性和可靠性問題，但是為了能夠驗證運行時或功能行為，我們需要花時間在創建和維護自動化測試上，并且，在敏捷的世界中，我們需要這些測試一旦創建便要連續執行，以使它們能夠在實現新功能后“左移”檢測并捕獲回歸。

花費時間和組織測試組合的理想方法通常表示為“測試金字塔”，如下所示，這是通過在開發時間軸上盡力推動盡可能多的測試工作來實現的。您從單元測試的基礎開始，在那里發現的錯誤很容易修復，然后API，集成，組件測試以及系統和UI測試完善了金字塔的層次。

但是，盡管諸如測試驅動開發（TDD），早期單元測試以及軟件測試中的更多自動化之類的做法已成為主流，但軟件團隊仍在后期UI和系統測試上花費過多時間。我們經常將當前的情況描述為倒金字塔形（冰激凌）。但是，仔細研究一下數據，我們發現該行業嚴重缺乏API測試，因此馬提尼杯更合適：

不幸的是，測試金字塔的中間層通常沒有使用，因為投資API測試具有明顯的優勢。例如，可以在軟件開發生命周期的較早階段進行測試（只要有API合同/定義可用），就可以更輕松地實現自動化，并且從根本上來說，它們對于應用程序UI/UX中傳入的更改不那么脆弱。 

通過將API測試組織到常見的用例中，可以創建場景級別的測試，并且API測試的自動化為早期和場景驅動的性能和安全性測試鋪平了道路。最終，對API測試的投資使團隊能夠更好地管理變更并獲得現代開發方法所承諾的敏捷性。經常進行早期測試，不喜歡什么？不幸的是，由于各種原因，團隊正在努力實現API測試。

什么是約束API測試？

越來越多地采用API測試的最大障礙是測試的實際創建。創建在API級別上起作用的有意義的測試并非易事，更不用說將它們串在一起以創建適當的測試方案了。在防止采用API測試方面，同樣重要的是開發人員和測試人員之間存在的知識鴻溝。API測試需要測試人員通常缺乏的知識和能力，并且經理不想讓開發人員進行集成或API測試。

開發人員從金字塔的底部開始工作，并且對單位級別的工作很滿意。這是他們的代碼（至少是他們的職責范圍），單元測試似乎很自然地適合他們的工作流程。自動創建單元測試在此級別上提高了效率，并且軟件行業了解需要在這里進行全面測試。

另一方面，測試人員是在UI級別的金字塔頂端進行工作的，其中用例和界面直觀且易于映射到原始業務需求。他們對應用程序的看法是從外面看的。

API測試位于這兩個角色之間，既需要有關接口設計的知識，又需要如何使用它們。測試人員通常無法在此級別上工作，將API視為代碼，并且開發人員了解接口和API時，他們通常對接口如何與其他子系統結合使用沒有完整的了解，因此將API測試視為功能測試，而不是其職責范圍。

直到最近，還缺少測試工具自動化來幫助縮小單元和系統測試，開發人員和測試人員之間的差距。為了幫助軟件行業更接近理想的測試金字塔并從我們今天看到的馬提尼杯中發展出來，我們將Smart API Test Generator引入了Parasoft SOAtest，這是我們易于使用和使用的功能測試自動化工具。

放棄馬提尼杯

Smart API Test Generator是Google Chrome網絡瀏覽器的插件，可監視手動測試并使用人工智能創建自動API方案測試，從而降低了采用API測試所需的技術技能，并幫助您構建可擴展的API測試策略團隊和組織。它是這樣的：

智能API測試生成器會在您執行手動測試時監視后臺流量，并將其發送到其人工智能引擎，該引擎可識別API調用，發現模式，分析API調用之間的關系，并自動生成完整的，有意義的API測試方案，不只是一系列API測試步驟。

使API測試更易于訪問

Smart API Test Generator使API測試更易于測試團隊使用，因為這些API測試方案是使用他們已經在做的測試實踐創建的。與手動或什至自動UI測試不同，記錄的API活動可以幫助測試人員與開發人員更好地協作，其單一工件可以被兩個團隊輕松共享和理解，并且比復雜的UI測試更能診斷出缺陷的根本原因這需要組裝整個應用程序。

另一方面，僅進行UI測試時，開發人員和測試人員往往會在通信和調試技術中保持孤立狀態——往往導致漫長的等待時間以及缺陷引入，缺陷檢測和缺陷解決之間的反復。

API測試方案的強大功能

在UI測試期間記錄的API交互需要某種形式的組織成場景或用例。SOAtest Smart API Test Generator的人工智能通過基于不同API調用之間的關系創建方案來提供幫助。

如果沒有Smart API Test Generator的幫助，用戶將不得不花時間研究他們的測試用例，尋找模式，以及手動建立關系以形成每個測試方案。此外，Parasoft SOAtest提供了一種直觀的，由UI驅動的方法來描述斷言，從而使測試人員無需編寫任何代碼即可執行復雜的斷言邏輯。否則，用戶將手工編寫每個斷言的代碼，他們可能會錯過一個斷言或將其置為錯誤。然后，可以使用可視化工具和工具輔助邏輯來擴展這些API測試，從而創建更大范圍的測試套件。

結論

盡管軟件團隊承認希望實現單元，API和UI測試的理想分布，但現實情況是，您的普通團隊正在完成單元測試的平均工作，并且仍然依賴后期UI和系統測試。API測試提供了開發人員和測試人員之間理想的通信機制，并具有高度可維護的自動化水平，可以擴展到性能和安全性測試中。

將這些測試左移并在軟件生命周期的較早時間執行它們意味著及早發現關鍵的安全性和體系結構缺陷，在這些缺陷中，它們更易于診斷且修復風險較小。利用Parasoft SOAtest的Smart API Test Generator提供的自動化功能，API測試更加容易訪問，并且可以大大減少與創建有意義的測試方案相關的時間。