API測(cè)試提供了許多可維護(hù)的自動(dòng)化功能，可以擴(kuò)展到性能和安全測(cè)試中，但是您的普通測(cè)試人員無法訪問。了解如何顯著減少與創(chuàng)建有意義的測(cè)試方案相關(guān)的時(shí)間。

轉(zhuǎn)向微服務(wù)和API驅(qū)動(dòng)的架構(gòu)正在推動(dòng)整個(gè)行業(yè)的重大創(chuàng)新，但也使企業(yè)面臨隱患。人機(jī)界面（Web和移動(dòng)UI）不再是主要業(yè)務(wù)風(fēng)險(xiǎn)所在。相反，最大的漏洞隱藏在API的非人機(jī)界面中。

因此，API測(cè)試已成為越來越多的關(guān)注點(diǎn)，但是我們始終都在聽到“API測(cè)試又是什么，為什么我需要它？”

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

測(cè)試無效的影響

 軟件團(tuán)隊(duì)希望花費(fèi)理想的時(shí)間，而不僅僅是測(cè)試和調(diào)試，以最大化成功項(xiàng)目的潛力。但是，傳統(tǒng)上，很難減少在測(cè)試和調(diào)試上花費(fèi)的時(shí)間，因?yàn)樵谲浖芷诘暮笃冢òòl(fā)行后）發(fā)現(xiàn)了許多嚴(yán)重的錯(cuò)誤和安全漏洞。

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

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

我們想成就的地方：測(cè)試金字塔

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

花費(fèi)時(shí)間和組織測(cè)試組合的理想方法通常表示為“測(cè)試金字塔”，如下所示，這是通過在開發(fā)時(shí)間軸上盡力推動(dòng)盡可能多的測(cè)試工作來實(shí)現(xiàn)的。您從單元測(cè)試的基礎(chǔ)開始，在那里發(fā)現(xiàn)的錯(cuò)誤很容易修復(fù)，然后API，集成，組件測(cè)試以及系統(tǒng)和UI測(cè)試完善了金字塔的層次。

但是，盡管諸如測(cè)試驅(qū)動(dòng)開發(fā)（TDD），早期單元測(cè)試以及軟件測(cè)試中的更多自動(dòng)化之類的做法已成為主流，但軟件團(tuán)隊(duì)仍在后期UI和系統(tǒng)測(cè)試上花費(fèi)過多時(shí)間。我們經(jīng)常將當(dāng)前的情況描述為倒金字塔形（冰激凌）。但是，仔細(xì)研究一下數(shù)據(jù)，我們發(fā)現(xiàn)該行業(yè)嚴(yán)重缺乏API測(cè)試，因此馬提尼杯更合適：

不幸的是，測(cè)試金字塔的中間層通常沒有使用，因?yàn)橥顿YAPI測(cè)試具有明顯的優(yōu)勢(shì)。例如，可以在軟件開發(fā)生命周期的較早階段進(jìn)行測(cè)試（只要有API合同/定義可用），就可以更輕松地實(shí)現(xiàn)自動(dòng)化，并且從根本上來說，它們對(duì)于應(yīng)用程序UI/UX中傳入的更改不那么脆弱。 

通過將API測(cè)試組織到常見的用例中，可以創(chuàng)建場(chǎng)景級(jí)別的測(cè)試，并且API測(cè)試的自動(dòng)化為早期和場(chǎng)景驅(qū)動(dòng)的性能和安全性測(cè)試鋪平了道路。最終，對(duì)API測(cè)試的投資使團(tuán)隊(duì)能夠更好地管理變更并獲得現(xiàn)代開發(fā)方法所承諾的敏捷性。經(jīng)常進(jìn)行早期測(cè)試，不喜歡什么？不幸的是，由于各種原因，團(tuán)隊(duì)正在努力實(shí)現(xiàn)API測(cè)試。

什么是約束API測(cè)試？

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

開發(fā)人員從金字塔的底部開始工作，并且對(duì)單位級(jí)別的工作很滿意。這是他們的代碼（至少是他們的職責(zé)范圍），單元測(cè)試似乎很自然地適合他們的工作流程。自動(dòng)創(chuàng)建單元測(cè)試在此級(jí)別上提高了效率，并且軟件行業(yè)了解需要在這里進(jìn)行全面測(cè)試。

另一方面，測(cè)試人員是在UI級(jí)別的金字塔頂端進(jìn)行工作的，其中用例和界面直觀且易于映射到原始業(yè)務(wù)需求。他們對(duì)應(yīng)用程序的看法是從外面看的。

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

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

放棄馬提尼杯

Smart API Test Generator是Google Chrome網(wǎng)絡(luò)瀏覽器的插件，可監(jiān)視手動(dòng)測(cè)試并使用人工智能創(chuàng)建自動(dòng)API方案測(cè)試，從而降低了采用API測(cè)試所需的技術(shù)技能，并幫助您構(gòu)建可擴(kuò)展的API測(cè)試策略團(tuán)隊(duì)和組織。它是這樣的：

智能API測(cè)試生成器會(huì)在您執(zhí)行手動(dòng)測(cè)試時(shí)監(jiān)視后臺(tái)流量，并將其發(fā)送到其人工智能引擎，該引擎可識(shí)別API調(diào)用，發(fā)現(xiàn)模式，分析API調(diào)用之間的關(guān)系，并自動(dòng)生成完整的，有意義的API測(cè)試方案，不只是一系列API測(cè)試步驟。

使API測(cè)試更易于訪問

Smart API Test Generator使API測(cè)試更易于測(cè)試團(tuán)隊(duì)使用，因?yàn)檫@些API測(cè)試方案是使用他們已經(jīng)在做的測(cè)試實(shí)踐創(chuàng)建的。與手動(dòng)或什至自動(dòng)UI測(cè)試不同，記錄的API活動(dòng)可以幫助測(cè)試人員與開發(fā)人員更好地協(xié)作，其單一工件可以被兩個(gè)團(tuán)隊(duì)輕松共享和理解，并且比復(fù)雜的UI測(cè)試更能診斷出缺陷的根本原因這需要組裝整個(gè)應(yīng)用程序。

另一方面，僅進(jìn)行UI測(cè)試時(shí)，開發(fā)人員和測(cè)試人員往往會(huì)在通信和調(diào)試技術(shù)中保持孤立狀態(tài)——往往導(dǎo)致漫長(zhǎng)的等待時(shí)間以及缺陷引入，缺陷檢測(cè)和缺陷解決之間的反復(fù)。

API測(cè)試方案的強(qiáng)大功能

在UI測(cè)試期間記錄的API交互需要某種形式的組織成場(chǎng)景或用例。SOAtest Smart API Test Generator的人工智能通過基于不同API調(diào)用之間的關(guān)系創(chuàng)建方案來提供幫助。

如果沒有Smart API Test Generator的幫助，用戶將不得不花時(shí)間研究他們的測(cè)試用例，尋找模式，以及手動(dòng)建立關(guān)系以形成每個(gè)測(cè)試方案。此外，Parasoft SOAtest提供了一種直觀的，由UI驅(qū)動(dòng)的方法來描述斷言，從而使測(cè)試人員無需編寫任何代碼即可執(zhí)行復(fù)雜的斷言邏輯。否則，用戶將手工編寫每個(gè)斷言的代碼，他們可能會(huì)錯(cuò)過一個(gè)斷言或?qū)⑵渲脼殄e(cuò)誤。然后，可以使用可視化工具和工具輔助邏輯來擴(kuò)展這些API測(cè)試，從而創(chuàng)建更大范圍的測(cè)試套件。

結(jié)論

盡管軟件團(tuán)隊(duì)承認(rèn)希望實(shí)現(xiàn)單元，API和UI測(cè)試的理想分布，但現(xiàn)實(shí)情況是，您的普通團(tuán)隊(duì)正在完成單元測(cè)試的平均工作，并且仍然依賴后期UI和系統(tǒng)測(cè)試。API測(cè)試提供了開發(fā)人員和測(cè)試人員之間理想的通信機(jī)制，并具有高度可維護(hù)的自動(dòng)化水平，可以擴(kuò)展到性能和安全性測(cè)試中。

將這些測(cè)試左移并在軟件生命周期的較早時(shí)間執(zhí)行它們意味著及早發(fā)現(xiàn)關(guān)鍵的安全性和體系結(jié)構(gòu)缺陷，在這些缺陷中，它們更易于診斷且修復(fù)風(fēng)險(xiǎn)較小。利用Parasoft SOAtest的Smart API Test Generator提供的自動(dòng)化功能，API測(cè)試更加容易訪問，并且可以大大減少與創(chuàng)建有意義的測(cè)試方案相關(guān)的時(shí)間。