API為企業提供了快速創新的靈活性，并將其核心產品擴展到新用戶。但是，這種靈活性也帶來了測試的巨大復雜性?；谀Ｐ偷姆椒捎糜谄ヅ洮F代軟件交付的速度和可變性。

嚴格的API測試必須克服大量的復雜性，并考慮大量可能的測試用例。到達端點所需的消息數據必須“覆蓋”值的每個不同數據組合。其中包括用戶輸入的數據值，以及他們針對系統執行的獨特操作。它還包括由用戶活動生成的機器數據，例如內容類型和會話ID。

API測試還必須考慮數據可以通過API流動的過程。它們必須涵蓋API動作和方法的組合，這些組合可以在到達特定端點的方式上轉換數據。

但是API并不是孤立存在的。根據定義，它們連接了多個系統或組件，因此從某種意義上來說，每個測試都是端對端測試。因此，一組嚴格的API測試必須考慮大量組合動作或方法，這些動作或方法可以在數據流經連接的API時對其進行轉換。

一個不切實際的簡化示例將包括1000個用戶輸入數據的組合、1000個機器生成的數據的不同組合以及1000個通過組合動作的不同歷程：

已經有10億種組合，每種組合都可以進行API測試。因此，嚴格的API測試必須選擇許多可以在沖刺中執行的測試用例，同時仍要保留足夠的API測試覆蓋率。

測試太多，時間不夠！

不幸的是，API測試中使用的測試技術通常過于手工和不系統，無法進行嚴格的API測試。關鍵業務API可能會在測試生命周期的每個點上受到未充分測試的風險：

1. 在測試工具中或通過腳本一一創建API測試太慢且臨時性，甚至無法達到可能的組合的一小部分。
2. 從服務定義和需求很難定義預期結果。再次猜測響應是否“正確”會破壞API測試的可靠性。
3. 因此，測試數據缺少嚴格的API測試所需的大多數組合。低多樣性的生產數據副本側重于過去發生的預期情況。它們缺少異常值和否定組合，以及缺乏用于測試未發布功能的數據。
4. 在執行API測試時，通常無法訪問內部和第三方系統。組件可能未完成或正在由另一個團隊使用，或者第三方可能未提供用于測試的沙箱。因此，環境限制進一步破壞了API測試的敏捷性。

相反，測試復雜的API鏈需要一種集成的自動化方法。API測試人員必須能夠確定API測試嚴格性所需的最小一組API測試，并系統地創建執行它們所需的測試數據和環境。

基于模型的API測試

為了克服API調用鏈的復雜性，團隊可以從基于模型的API測試方法中受益，在該方法中，測試人員可以從易于使用的模型中生成進行嚴格的API測試所需的一切。

運作方式如下：

• 基于模型的測試生成將創建API測試，以“覆蓋”跨API鏈的數據和方法的每種不同組合。這將數學算法應用于數學上精確的模型。這些模型是通過導入的服務定義和消息記錄快速構建的。通過拖放可重復使用的流程圖，可以對復雜的API鏈進行端到端測試，從而可以在較短的迭代時間內進行嚴格的測試。
• 每次測試都會同時生成準確的測試數據和預期結果。預期的結果只是流程圖中的終點，并且Test Modeller還會為其生成的每個測試“及時”查找或制作數據。 API測試人員可以在模型級別選擇廣泛的數據生成功能和可重復的測試數據管理（TDM）流程。這些解決方案在測試生成過程中“及時”解決，編譯針對每個端到端測試量身定制的一致數據集。
• 虛擬數據生成產生模擬缺少或不可用組件所需的請求-響應對。虛擬數據生成為每個可能的請求創建準確的響應。在測試生成或執行期間也稱為可重復的TDM過程，以確保從中央模型生成的每個測試都配備有準確的測試數據和環境。

通過這種集成方法，質量檢查團隊可以自行生成嚴格的API測試所需的一切。維護中央流程圖可以使測試、數據和虛擬服務保持一致，并在短迭代中測試復雜的API鏈。