應用程序編程接口（API）是應用程序的服務層。它們連接數據層和表示層（UI），并驅動用戶與應用程序交互的方式。

如果API無法正確響應用戶活動，則說明該應用程序已損壞。開發人員和測試人員有責任確保所連接的API在其應用程序中正常工作。

API測試對于識別應用程序多層中的缺陷并確保無縫的客戶體驗是必不可少的。 API測試包括：

• 服務測試
• 合同測試
• 組件測試
• 場景測試
• 負載/性能測試
• 安全測試
• 全渠道測試

執行API測試具有挑戰性，因為它需要一種技術方法來針對各種消息格式和協議設計測試用例。它還需要了解組織的業務規則，以一起正確使用正確的API。嘗試使用手動方法測試API非常耗時，并且可能導致測試推遲到開發周期的后期。

自動化的API測試使您能夠對應用程序進行防彈防御。它可以盡早發現錯誤，評估構建的強度，并導致更快的軟件發布。由于API測試可以自動化并且可以連續運行，因此您可以確保應用程序符合業務期望，同時還可以驗證功能準確性。

自動化API測試的利弊

有了正確的API測試工具和流程，您的團隊將獲得自動化的所有好處。沒有它們，API測試會很快變得不堪重負。

優點

• 提供端到端方案的可維護的自動化。
• 打開開發人員與測試之間的溝通渠道。
• 減少診斷和修復時間。

缺點

• 測試人員不知道如何測試API或如何使用API。
• 需要專業技能和工具才能獲得全面的測試范圍。
• 沒有人愿意這樣做。

您可以通過將高級測試技術集成到現有測試中來克服這些挑戰。首先，讓我們看一下API測試的創建。

創建API測試的挑戰

建立API測試自動化實踐的最大挑戰之一就是創建API測試。適當的測試提出了入門（或擴展現有的API測試套件）的障礙。

此問題的一部分是純粹基于技術知識或書面API規范（如果存在）編寫API測試所需的領域知識。這不是測試人員的常用領域。大多數具備必要知識的開發人員都不會參與此級別的測試。他們在其他地方有優先事項。

考慮兩種互補的方法：

• 自上而下的方法。測試方案是根據常規應用程序的使用和測試創建的。
• 自下而上的方法。測試基于設計意圖。

結合使用自頂向下和自底向上方法進行API測試創建

大多數應用程序提供并使用多個API。有些是眾所周知的。有些甚至可能被記錄在案。引擎蓋下通常有很多活動部件，因此開始進行API測試非常困難。

在自上而下的方法中，API交互是通過工具自動化發現的，這是通常使用和集成測試的一部分。

另一個攻擊角度是自下而上的方法，是根據設計意圖創建API測試。它通常是組件測試的一部分，并借助工具進行輔助。

自上而下（集成測試）和自下而上（組件測試）方法的結合克服了測試創建的障礙，并增加了API測試的覆蓋范圍。請參見下圖。

按用途創建API測試

捕獲API測試方案的最佳方法之一是在生產和測試中都使用產品的現有用法。利用智能記錄和回放功能，可以創建可重復使用的測試和方案。

使用SOAtest Smart API Test Generator等工具，您可以記錄在應用程序內部發生的API交互。該工具使用機器學習將復雜的流量組織成API使用模式。這樣就可以使用現有的手動測試來創建一套API測試，以使用UI提取、過濾和創建API測試方案。

然后，SOAtest使用AI來識別模式并建立數據關系以創建API測試模板。您可以修改和重復使用帶有變體的模板。這些測試可用于安全性和性能測試。更重要的是，這些測試一旦創建，便會與UI和基礎應用程序分離，并且其依賴關系可以僅通過API測試來行使。

將API流量記錄和分析到測試場景中，可以擴展到使用Selenium等工具進行的自動化UI測試。發起API調用的應用程序的任何使用，無論是手動還是自動的，都可以用來創建API測試。也可以將錄制的方案與可追溯性要求相關聯。

記錄后，可以在SOAtest中對這些方案進行調查和修改，如下所示。

SOAtest檢測各種API調用和發生的數據交互。然后可以根據需要修改方案和數據有效載荷。一旦理解了模式，就可以將斷言插入場景中以驗證正確的值和行為。

完全基于現有測試技術創建即用型API測試套件的能力可以快速創建具有重用和擴展功能的測試。這是通過API測試的最大障礙之一的捷徑。

通過（服務）設計創建API測試

您可能會想，“我們不知道API的設計。其中大多數都沒有記錄！”在大多數情況下，這是正確的。但是，仍然可以通過查看應用程序中顯式或隱式的服務定義和協定，將現有信息中的API測試組合在一起，以幫助從下至上擴展API測試的覆蓋范圍。

就API規范而言，大多數服務在swagger文檔或WSDL中都有定義。SOAtest可以閱讀這些定義并創建API測試方案模板。它包括定義中所有客戶端的測試用例。您可以編輯和操作模板以創建有意義的API測試。

SOAtest提供了許多用于從模板創建無腳本測試的選項，包括基于隨機數的參數化數據或先前的測試結果，如下例所示。

通過使用簡單的復制和粘貼技術，無腳本的測試創建以及靈活的測試數據管理，SOAtest提供了一種構建測試套件的簡便方法。這并不是要取代自上而下的方法，而是要對其進行補充。如果手動或UI測試缺少API的重要部分（由覆蓋結果告知），則自下而上的方法將填補這些空白。但是，如果不了解覆蓋范圍，就很難確定要測試的內容和缺少的內容。

了解測試范圍

覆蓋范圍取決于上下文，意味著幾件事。通常，它是代碼、API和要求范圍。您需要了解所有這些內容，以清晰了解測試工作的完成程度。

• 單元測試——關注的是代碼覆蓋率。有多少代碼具有與執行相關的測試？
• API——重要的是要知道要測試哪些，以及每個API的使用程度。
• 需求——每個需求都必須進行測試，以證明其正確實施。

這些重疊的問題在項目生命周期的不同時間都很重要。例如，如果您要跟蹤的是API測試覆蓋率，則重要的是要確保測試充分覆蓋了API，并在缺少的地方進行現有測試。最好的方式是從服務定義中進行查看，如下圖所示。

SOAtest跟蹤執行的每個測試以及涵蓋的API：完全、部分或根本不包括。知道缺少哪些測試，可以讓我們根據服務定義進行自下而上的測試，或者在可能的情況下基于新的基于UI的測試。它還指出測試失敗的地方（紅色），將我們的注意力轉移到需要更新或植入中有問題的測試。

Parasoft DTP（開發測試平臺）充當各種測試實踐結果的中央存儲庫和樞紐，并根據不同類型的覆蓋范圍提供了項目所在位置的高級視圖，如以下儀表板所示。

此視圖合并了靜態代碼分析、單元測試、API以及手動和自動UI測試的匯總結果。這是測試金字塔的全部色域。它從各個方面提供了完整的覆蓋范圍：API、需求和代碼覆蓋范圍。

從JIRA中保存的用戶故事的角度考慮需求范圍。功能測試儀表板（如下所示）包括JIRA Story Status小部件，這是跟蹤需求覆蓋率的一種方法。

更仔細地查看JIRA狀態，鼠標懸停信息指示通過、未通過、未完成或未通過測試的測試數量。

您可以在詳細的可跟蹤性報告中進一步深入了解，以找出缺少哪些需求，未通過其測試等等。

您可以通過深入研究可追溯性報告來進一步調查，以了解哪些測試正在影響這個故事。

此外，您可以根據需要將此覆蓋范圍鏈接到API和代碼覆蓋范圍。您可以從此處導航至API測試，以確定需要進行哪些更改以及需要進行哪些其他測試。這種全面的匯總視圖提供了最完整的測試狀態信息。隨著開發人員聚集在一個完整的應用程序上，隨著時間的推移，測試覆蓋率“增長”，新的代碼被API和為相關需求創建的單元測試“覆蓋”。

總結

API測試的重要性已為軟件開發組織所認可，但是他們經常難以充分采用該實踐。努力的一部分是建立一組測試，因為手動測試的創建很復雜并且需要熟悉的技術知識。甚至采用API測試的團隊也面臨著增加其API測試覆蓋面的挑戰，因為其中許多沒有記錄在案。

諸如SOAtest之類的高級功能測試工具可以基于分析手動測試和常規應用程序使用中的使用行為，使用自上而下的方法來幫助自動化API測試創建。這種智能的測試生成功能可幫助團隊快速，輕松地根據現有實踐創建測試。

使用SOAtest自動化可以同時采用互補的自下而上的方法，以根據服務定義構建無腳本測試。隨著完整的覆蓋率分析，您可以使用自上而下和自下而上的技術隨著時間的推移來擴展API測試的覆蓋率。由于API測試的工作水平遠低于UI測試，因此您可以放心，所構建的一致而全面的測試將持續很長時間。