當AI趕上API測試 — 敏捷開發已迎來革新時代！

本文的靈感來源於正在使用的一款自動化測試工具，我目前還處於邊學習邊運用的階段，不過它的API測試功能使人驚歎（雖然我尚未徹底摸透）。接下來，我將對這一功能的理解作一個簡單的陳述。在其新版本中，經過建立一個簡單且優雅的解決方案來幫助組織不只開始使用API測試，並且還爲支持敏捷開發的可擴展且可維護的API測試策略奠基了基礎，從而消除了與API測試相關的複雜性。

使API測試更「容易」

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

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

敏捷主要是針對發展的活動。用最基本的術語來講，敏捷是一種軟件開發方法，傳統上跨越項目持續時間的典型SDLC活動被分解成稱爲sprint的小塊。一般，一個Sprint爲2到3周，在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測試的複雜性。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測試實踐，它還提供了易於使用的可視化工具，使API測試初學者能夠在比其餘工具更少的時間內開始建立強大的API方案。智能生成器彌合了差距，使新手用戶進入了API測試世界。

那麼這是什麼意思？

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

可靠的API測試策略將使組織可以從其敏捷轉換中得到最大價值。爲了實現這一點，測試工具應該對咱們有用，而咱們正在使用的軟件的最新版本正是這樣作的。其新的組件Smart API Test Generator下降了與API測試相關的複雜性，下降了其採用的障礙，並幫助組織引入了可管理、可維護和可擴展的測試策略。本身也來嘗試一下吧！