企業越來越注重客戶體驗，將其作為進入市場戰略的一部分，而客戶體驗的關鍵一環是他們能夠以快速和無縫的方式穿越你的軟件。為了降低不良客戶體驗的風險，企業正在加倍努力地實施質量計劃，軟件開發行業也正在將持續測試作為一種主流活動。

什么是持續測試？

持續測試是軟件測試的一個原則，在這個原則下，你的所有測試都在一直執行，對你的應用程序的質量和健康狀況進行持續反饋。但為了實現持續測試，企業必須首先采用測試自動化。測試自動化有很多類型，從UI層開始，到中間件系統，甚至是后端系統，跨越了應用程序的寬度。了解如何盡可能高效地引入這些不同類型的測試自動化實踐，可以讓你走向持續測試的道路。

構建正確的測試自動化策略

現在被廣泛接受的測試金字塔（由Michael Cohen和Martin Fowler推廣）確定了不同類型測試活動的最佳策略。在基層，代表著最大數量的測試，希望建立廣泛覆蓋的單元和API測試，這些測試在自動化中最容易運行，但通常需要技術技能來構建。到了測試金字塔的頂端，你會發現自動化UI測試和手動測試。我們希望這種類型的測試活動在頂部，因為這是確保客戶體驗的唯一方法。

大多數人把注意力集中在測試金字塔的底部和頂部，對UI測試采取 "把人工的東西自動化 "的做法，對單元測試采取 "開發人員應該測試 "的心態。雖然這些做法很重要，但專注于頂部和底部，在中間的API層，在UI和代碼之間造成了差距。但這種差距只會繼續變得越來越麻煩，Programmable Web最近的一項調查預測，到2021年將有超過22000個公開的API。API測試比以往任何時候都更加關鍵，需要成為你正在構建的持續測試策略的一個集成部分。

利用測試自動化實現持續測試的3個步驟

之前曾討論過如何為您的組織的獨特需求選擇最佳的API測試解決方案，并根據您的行業和應用程序，指出了您可能需要的關鍵功能。從一個API測試解決方案開始是很有幫助的，它可以隨著您的API測試成熟度的增長而增長。一旦你選擇了一個工具，您該如何開始？以下是三個關鍵步驟，以更快地實現功能測試自動化，并實現您的持續測試。

第1步：為您現有的API建立廣泛的自動化測試覆蓋范圍。

為了創建一套廣泛的自動化測試，您可以從網絡錄音和API合同中構建無腳本測試，然后使用這些測試來持續驗證您的API的健康狀況，確保API按照設計工作。把它想象成API的單元測試，但不需要進行磨合--這不僅是一種有價值的測試技術，而且也是您可以做的最早的功能測試驗證類型之一，因為API的服務合同通常是在創建新特性或功能時最先編寫的東西之一。

舉個例子，假設團隊在銀行應用中增加了一些新功能。作為第一步，開發團隊發布了一個新的服務定義。在這種情況下，生成了一個swagger文檔。正在添加的新服務是RequestLoan服務。這個服務需要一系列的輸入，并響應新貸款的貸款提供者。為了測試這個服務，可以消耗Swagger YAML，并為每個單獨的操作創建一系列客戶端。

其中一個客戶將是請求貸款服務，可以創建一系列的輸入，包括正向和負向輸入，以驗證該服務的行為是否恰當。然后將這些測試重新用于回歸目的。當然，雖然這種類型的測試非常有價值，但它只是API測試難題的一半，因為它不能驗證API的實際使用情況。進入第二步。

第二步：彌補UI和API之間的差距

API測試策略的第二部分是能夠將人類對應用的使用建模為完整的API測試場景。您可以開始通過利用人工智能來彌補測試金字塔中的這一差距，以增強您的能力，了解用戶在瀏覽您的應用程序時在幕后實際發生了什么，并將這些幕后事務解釋為API調用。這種類型的測試允許您將用戶體驗與您的關鍵API測試相一致。

AI是戰略的關鍵組成部分，因為可以可靠地使用AI來幫助我們將這些通信分解為關系和模式，了解應用程序如何被測試的業務規則。可以將其與單元級API測試結合起來，以獲得廣泛的API頻譜覆蓋。

繼續前面的例子，你會注意到，申請貸款服務需要申請的其他方面的輸入。具體來說：

現在，雖然可以任意提供customerID和from accountAccountID，但是需要創建一個動態場景，在這個場景中，首先查詢個人用戶以獲得客戶ID和賬戶ID，這樣就可以將這些信息交給請求貸款服務，并確保動態場景如所述工作。確保使用的是真實的動態數據，可以確保那些由于API相互交互而存在的行為能夠得到充實。

這些類型的技術將使我們能夠轉變左API測試實踐，并在盡可能早的階段為應用創造廣泛的覆蓋面。一旦實現了這一目標，這一實踐還有第三個關鍵的組成部分，那就是我們理解和適應變化的能力。

第3步：通過可維護的變革管理程序確保信心。

很多人的功能測試計劃，一旦他們的應用發生變化，就會落空。這是一種常見的情況，因為測試人員把大部分時間都花在了構建豐富而偉大的API測試上，卻在應用的API發生變化時中斷了。這可能會產生累積效應，降低對API測試策略的信心，因為測試人員將大部分時間用于維護他們的API測試，而不是建立新的價值。

變更管理是任何功能測試策略的關鍵一環，而AI在這里也可以成為一個關鍵的推動者。通過自動掃描服務定義（是的，與最初創建測試用例所用的服務定義相同）來識別您的API何時發生了變化，您可以了解您何時會受到影響，然后建立一個模板，將現有服務遷移到新版本。

回到銀行應用例子的第一部分，這里在我的應用中添加一個新的服務，這實際上代表了API的變化。由于這里使用服務定義創建了第一輪基線測試，現在可以將服務定義的不同版本相互比較，不僅可以識別出有什么變化，而且可以建立一個地圖來更新我現有的測試用例。