在最新版的Parasoft SOAtest中，我們為客戶帶來了人工智能，以幫助他們入門并通過有效的API測試策略進行擴展。

Parasoft始終有一個核心任務–簡化測試自動化–這在整個Parasoft工具套件中都顯而易見，從靜態分析到帶有服務虛擬化的環境模擬。但是，與最新版本的SOAtest相比，簡單的想法從未出現過。在此版本中，我們通過創建一個簡單且優雅的解決方案來幫助組織不僅開始使用API測試，而且還為支持敏捷開發的可擴展且可維護的API測試策略奠定了基礎，從而消除了與API測試相關的復雜性。

使API測試“容易”

當我們討論開發這種新的測試自動化概念時，我們的首席執行官Elizabeth Kolawa有一個簡單的準則。她說：“輕松一點。”這個簡單的陳述變成了對與現代測試相關的當前挑戰的深入分析，并得出了關鍵的認識：

軟件測試行業中的工具并沒有將重點放在敏捷世界的簡單性上。

敏捷主要是針對發展的活動。用最基本的術語來說，敏捷是一種軟件開發方法，傳統上跨越項目持續時間的典型SDLC活動被分解成稱為sprint的小塊。通常，一個Sprint為2到3周，在Sprint中，開發活動集中于新功能和增強功能。

一個Sprint看起來像這樣：

Sprint從設計和創建階段開始，在此階段中，新功能被分解為用戶故事，確定范圍，然后開發立即開始構建。在sprint結束時，可能有也可能沒有釋放活動，但是無論如何，都會獲得反饋，然后開始另一個sprint，并且該過程一遍又一遍地重復。

敏捷使組織可以花錢，因為在每個sprint期間收集的反饋可以應用于下一個sprint，并有助于指導，調整和聚焦項目。這對開發非常有用，但是如果您查看sprint的測試部分，它會變得復雜起來。

由于邏輯原因，直到進入Sprint為止，Test才能訪問測試新功能和增強功能。測試團隊需要等到開發團隊構建完所有功能之后，因此測試從一開始就總是落后于開發。

為什么測試不能跟上發展的步伐

隨著sprint的繼續和測試人員依賴UI測試（手動與用戶界面進行交互），此問題只會加劇。 UI測試是最常見的測試實踐，因為它易于使用–易于將UI中的操作與用戶故事相關聯，易于在眾多測試人員中擴展，并且具有記錄和回放功能，進行第一輪自動化很容易。

但是UI測試存在很多問題：

• UI測試效率低下，存在隱性成本。UI測試的最根本挑戰是，當將UI測試作為復制品進行開發時，修復缺陷所需的開發時間。通常，當測試人員開始缺陷發現過程時，他們從探索性測試開始（方法是在應用程序中搜索意外行為）。當發現缺陷時，他們需要對其進行復制以進行開發，這涉及編寫“復制步驟”。當開發人員收到這些說明時，他們需要找到測試正在使用的應用程序的版本，將其站起來，并逐步執行UI。如果缺陷重現，則他們必須將該缺陷與基礎代碼相關聯以確定根本原因。開發工作開始進行，要求他們將應用程序拆開，修復缺陷，然后重新構建應用程序，然后再進行質量檢查。這進一步延遲了軟件交付過程并減慢了整個流程。
• 用戶界面測試無法全面測試應用程序。在UI層進行的測試可以端對端地驗證應用程序的流程，但不一定測試系統內部的整個寬度。通常，將新功能引入應用程序后，它需要更改或更新現有接口。使用新功能時，其中某些組件可能無法訪問，但如果未經測試，則會給組織帶來重大風險。
• 測試無權訪問代碼，因此他們很難將其在UI中執行的操作映射到基礎源。結果，構建的測試無法提供完整的API覆蓋范圍。事情經常被遺漏。當需要運行整個回歸周期時，可能會發現關鍵缺陷。通常，這種后期周期缺陷檢測會導致明顯的發布延遲，并增加測試的總成本。
• 維護UI自動化很困難。測試難以跟上開發步伐的主要原因是因為花太多時間來管理損壞的UI測試。實際上，多達80％的測試時間花費在手動執行UI測試或修復由于應用程序更改而中斷的自動UI測試上。

上述因素中的每一個都會導致sprint的顯著延遲，但是考慮到傳統項目周期的工作原理，則是一系列這些sprint，然后是強化或回歸周期。

在測試的每個步驟中，測試都在努力跟上開發的步伐——但是由于傳統上使用的測試技術，他們永遠無法獲得所需的全部和完整的全面測試。

看起來像這樣：

通常，他們將能夠驗證新特性和功能，但無法完成完整的測試范圍。

對于許多測試人員而言，這令人沮喪，但這不是他們的錯——鑒于工具市場中存在的功能，這只是物競天擇的本質。危險的部分是，如果沒有這些質量實踐，缺陷就會滲入生產并侵蝕從敏捷中獲得的可觀收益。

API測試呢？它可以節省敏捷性嗎？

大家都認為，與UI測試相比，API測試可以更精確地找出缺陷的根本原因，因為API測試更接近代碼，更易于自動化，并且更能抵抗應用程序更改。同樣，API測試提供了一種更好的缺陷再現形式，以及開發和測試之間的通信，因為測試工件代表了這兩個領域的融合。（在最近的文章中，我探討了API測試，它是什么以及如何構建全面的API測試策略。您可以閱讀以獲取更多信息關于這種極其有效的測試實踐。）

在API層進行測試是進行敏捷開發的好方法，特別是因為在經過壓縮的時間軸下，它可以使測試人員驗證功能，并且API測試具有高度可重用性。

此外，API測試具有以下優勢，可以簡化并支持敏捷測試：

與UI測試相比，縮短了缺陷修復時間

如果API測試失敗，則可以肯定地知道在代碼中哪里查找。開發人員喜歡從測試人員那里獲得API測試，因為開發人員可以直接針對他們的應用程序執行它們，而無需連接整個環境。他們可以在開始修復缺陷時不斷地重新運行它們。

縮短的缺陷修復時間意味著，通常提供API測試和UI測試時，開發可以更快地修復錯誤。考慮敏捷性涉及的時間范圍時，這正是我們所需要的。一旦發現缺陷，就會向開發人員提供API測試，他們可以使用它來查找、修復和驗證缺陷，而無需重新構建整個應用程序，從而節省了大量時間。這正是我們敏捷所需的速度

API測試是“自動化就緒”

API表示在應用程序后臺進行的無形通信。通訊的無形特性有助于自動化過程。使應用程序達到可以在API級別開始與之交互的程度所需要的復雜性要比完整站立整個應用程序所需的復雜度要小得多，因此您可以在UI級別進行操作。

因此，可以在SDLC的早期階段輕松地以自動化方式運行API測試。我的大多數客戶都在運行單元測試的同時運行它們，這取決于代碼簽入的功能。這些API測試運行還可以以更簡單的方式與錯誤跟蹤系統相關聯，以便在解決缺陷后，可以輕松地在開發和測試之間來回傳遞隨附的API測試。這極大地減少了整個移交過程，因為測試人員可以從錯誤跟蹤系統收到有關缺陷已解決的通知，并查看自動化測試，而不是提交缺陷，提供重現步驟，然后等待開發中的新構建，驗證分辨率的案例。這些API測試可以輕松地內置到回歸套件中，并可以重復使用。

API測試比UI測試更能適應變化

作為研究的一部分，我們發現80％的開發時間都花在了管理和更新因更改而中斷的UI測試上。變更是敏捷的主要殺手，但是由于增加了代碼簽入和敏捷引入的時間框架，變更是不變的。

如果組織完全依賴UI測試，則應用程序更改可能會毀滅性的，因為為驗證關鍵功能而構建的許多測試用例都只是停止工作。敏捷性的主要原則之一是能夠打開一角錢，這意味著UI和功能一直在變化，而支持和維護這些測試的負擔可能會給測試團隊帶來巨大壓力。另一方面，API測試甚至看不到用戶界面。API還具有內置的特定版本控制功能，該功能使測試人員可以在應用程序進行更改時保持穩定性。此外，API是通過服務合同定義的，可以在應用程序進行這些更改時用來更新測試用例。

API測試可以使組織能夠在開發的早期階段輕松測試應用程序，并在開發和測試之間提供有效的通信機制，從而高度抵抗變更，從而節省敏捷性。將API測試作為測試策略基礎的組織可以利用他們提供的敏捷性來真正應對測試挑戰。

那么為什么組織API不進行測試？

即使具有API測試帶來的所有好處，業界仍然專注于UI測試：

我們認為這是因為測試人員不知道如何測試API和/或不知道他們的應用程序如何使用API。從何處著手開始對應用程序進行API測試并不清楚，而了解如何以有意義的方式將所有“難題”組裝在一起需要應用程序領域知識。

由于組織仍傾向于利用集中式測試實踐，因此測試人員需要對所有不同的應用程序界面有深入的了解，并知道如何正確地將它們組合在一起。這不是一件簡單的任務。

API測試仍然被認為是無人區。在最近的調查中，我們詢問了一系列負責組織中API測試的開發人員和測試人員。

• 70％的測試人員表示開發負責API測試。
• 為什么？“開發團隊創建了API，并且在構建API時，他們還應該構建API測試以驗證它們是否按所述方式工作”
• 80％的開發人員表示測試負責API測試
• 為什么？“我們創建這些API是面向外部的，并通過服務合同對其進行了記錄。測試團隊應參加并驗證API是否按照說明進行工作”

如您所見，對于誰最終負責API測試，有些困惑。我們一直在解決這個問題。我們認為API測試是開發人員和測試人員以不同形式承擔的責任，但正是這種脫節導致API測試覆蓋率較低。

API級別的測試需要專門的技能和工具，才能獲得全面的測試范圍。這不是直觀的。市場上有一些工具正在嘗試幫助組織制定API測試策略，但是絕大多數工具都需要大量的技術知識來構建全面的API測試。此外，測試人員仍然需要了解API的工作原理，這需要領域知識。結果，組織傾向于為API測試做最少的工作，這與敏捷性的需求相反。

用于測試自動化的人工智能

為什么是AI，為什么是現在？解決此行業問題的唯一方法是構建可消除API測試復雜性的工具。我們從事軟件測試自動化領域已有三十年了，那時，我們積累了大量數據，以幫助我們了解構建全面的API測試所需的條件。如今，人工智能正在幫助我們利用專業知識來簡化整個行業的測試人員對API測試的挑戰。

智能API測試生成器

全新的Parasoft SOAtest智能API測試生成器是從頭開始構建的，可幫助降低API測試的復雜性。Smart API Test Generator是適用于Chrome的插件，該插件使用人工智能將手動UI測試轉換為自動化API測試，從而降低了采用API測試所需的技術技能，并幫助組織制定可擴展的全面API測試策略。

那么它是怎樣工作的？

將UI活動轉換為自動API測試

Smart Generator在執行手動測試時監視后臺流量，分析該流量，并使用人工智能自動構建一組有意義的API測試方案。在構建這些API測試時，智能生成器首先識別API調用，然后發現模式并分析它們之間的關系，以便它可以生成完整的API測試方案，而不僅僅是一系列API測試。

減少了API測試的學習難度

Smart Generator為測試人員提供了一個輕松的地方來開始構建API測試，因此他們不必觸摸與手動構建API測試相關的困難活動，即找到正確的服務定義，了解數據有效負載或對測試進行測試并再次了解請求和響應之間的關系，以便您可以開始建立斷言。

取而代之的是，智能生成器會根據測試人員在使用UI時觀察到的活動自動完成所有這些繁重的工作。一般而言，這可以幫助新手用戶更好地了解API測試，因為他們可以將在UI中執行的活動映射到已創建的API測試，并更好地了解UI與基礎API調用之間的關系，從而有助于推動未來的API測試工作。

幫助用戶建立全面的API測試策略

盡管API測試是最有效的軟件測試方法之一，但許多組織尚未成功采用該方法，因為它需要專門的技能和工具。為了幫助組織采用全面的API測試實踐，Parasoft SOAtest提供了易于使用的可視化工具，使API測試初學者可以在比其他工具更少的時間內開始創建強大的API方案。智能生成器彌合了差距，使新手用戶進入了API測試世界

總結

敏捷開發可以幫助組織更快地向市場交付高質量的軟件，但是由于缺乏所需的技術來幫助組織快速全面地測試其應用程序，因此，加速交付所帶來的風險侵蝕了Agile的潛在利益。現在該是組織提高對API測試的了解的時候了。

可靠的API測試策略將使組織能夠從其敏捷轉換中獲得最大價值。為了實現這一點，測試工具應該對我們有用，而最新版本的Parasoft SOAtest正是這樣做的。SOAtest的新Smart API Test Generator降低了與API測試相關的復雜性，降低了其采用的障礙，并幫助組織引入了可管理，可維護和可擴展的測試策略。自己嘗試一下！

慧都大數據，一直致力于將復雜的數據轉為清晰的見解，通過端到端的方案，將更好的滿足企業定制化生產的需求，提高企業運營效率。

如果您的企業也有生產質量分析、設備故障預測、工業大數據分析、能耗異常分析等需求，歡迎撥打慧都熱線023-68661681或，為您免費提供大數據相關業務咨詢！