對傳統的軟件交付方式的影響

隨著組織繼續應對COVID-19的影響，企業正在研究如何在“新現實”中重新定義測試實踐。持續的大流行以多種方式損害了組織測試和交付軟件的能力。

資源受限

首先也是最重要的一點是，由于許多工人根本無法以與辦公室相同的能力在家工作，因此資源限制繼續上升。此外，由于許多企業正在利用全球系統集成商的資源，因此不同地區已經建立了有關工作條件的特定規則。許多組織根本無法抗衡這種影響，因此領導者正在尋找解決方案，以更少的資源來實現相同的測試要求。

遠程團隊合作

接下來，組織需要考慮受約束的團隊和遠程團隊的協作方式。有趣的是，持續的隔離狀態如何造成不適感，從而嚴重影響遠程工作的團隊。這是因為，對于我們這些在辦公室工作的人來說，走進某人的辦公室并就最新版本進行對話太容易了。

社交互動的這種水平使我們能夠討論我們的日常任務以及對質量和過程的擔憂。以純遠程身份工作會限制這些活動，并使我們處于完全孤立的狀態，或者對于大多數組織而言，使我們完全分心。尋找與遠程團隊合作的正確方法是一項挑戰，因此您需要在溝通不足和溝通過大之間取得平衡。擁有正確的協作軟件、治理和最佳實踐，可以幫助組織在新的現實中蓬勃發展。

軟件交付機制

接下來，IT組織必須從根本上重新考慮其軟件交付機制。對于向客戶提供數字體驗的組織而言，“移動優先”開始變得尤為重要。這一點特別重要，因為您無法在商店中與客戶進行實際互動。它嚴重影響了呼叫中心。現在，數字化業務在很大程度上代表了您的品牌。一切都變成了純數字領域：從通過應用程序訂購食物、在線銀行、訂購和交付關鍵藥品，甚至買衣服。組織需要能夠快速發展并迅速將這些體驗交付給這個瞬息萬變的世界，以使他們與客戶之間失去聯系。

與此挑戰相關的是組織必須考慮的實際交付機制。在為客戶重新考慮和設計數字體驗的同時，我們需要考慮如何通過DevOps管道開發、測試和交付數字內容。

轉向云生態系統和低代碼開發平臺

COVID-19大流行促使許多組織通過將其軟件轉移到云生態系統和低代碼開發平臺中來實現其交付機制的現代化，以便地理上分離的開發人員和測試人員可以協作并迭代以提供最佳體驗。

我們看到向Salesforce，Guidewire，Mendix等平臺的遷移正在增加。對于資源有限的組織來說，不僅可以實現快速交付，還可以利用這些平臺固有的所有功能。

最重要的是，隨著通過CI管道進行軟件開發和部署的方式現代化，我們看到了向Azure運維，Pivotal Cloud和Amazon Web Services（AWS）等云平臺的遷移。

軟件IT公司必須忍受。他們必須在有限的資源下，以更快的速度向客戶提供高度互動的數字體驗。但是必須付出一些。

通常，憑借這些競爭力，您最終會犧牲過程質量。與以往相比，確保質量至上至關重要，以確保通過數字體驗與您直接互動的客戶不會受到影響。在受限的環境中繼續提供優質體驗的最佳方法是為您的測試實踐尋求“效率調節器”。

效率調節器為您節省時間

這些“效率調節器”是什么？它們有幾種不同的形式：

• 智能測試設計和優化
• 對代碼覆蓋率的綜合要求
• 智能測試執行

智能測試設計與優化

在現代應用程序中要測試的東西太多了，包括前端UI，包括數據庫在內的中間件服務，后端系統和第三方依賴項。這些每一層都增加了整個測試過程的復雜性。許多軟件測試工具供應商提供解決方案來測試此體系結構。但是重要的是要確保您可以準確地完整地測試每個組件，從編寫第一行代碼到完成的應用程序中的智能UI測試，一直到整個過程。

設計和優化這些必要測試的捷徑是利用人工智能。組織正在尋找結合人工智能的智能解決方案，以優化測試創建過程。這可以采取智能代碼掃描的形式，以識別代碼編寫過程中的不良做法，自動生成單元測試，識別API序列中的模式和關系，以創建全面的測試方案。最后，在UI層使用基于AI的自我修復功能來從更改的應用程序界面中恢復。

對代碼覆蓋率的全面要求

僅僅創建一堆測試是不夠的。為了快速驗證應用程序，您需要了解每個測試如何與業務需求相關聯，以便您可以了解優先級以及優先級與基礎代碼的相關性，以便可以開始了解測試的完整性。

因此，對于受約束的測試團隊來說，一個強大的效率修改器是建立一種測試實踐，在該實踐中，測試用例與業務需求和開發代碼緊密耦合，以創建全面而全面的質量視圖。

智能測試執行

現在，一旦您完成了一系列測試，并且了解了如何通過將測試結果與需求聯系起來就可以從優先級的角度對測試結果進行操作，那么您就需要能夠以最有效的方式執行那些測試。大多數組織會在一夜之間運行整個測試套件。然后，第二天花一半時間仔細研究這些結果，以嘗試確定是否確實出現了問題或是否存在“自動化噪音”。

提高測試執行效率的最佳方法是執行智能測試執行。這僅是您需要運行以驗證對應用程序所做的更改的那些測試用例的執行。通過使用諸如智能測試執行之類的技術，您可以：

• 快速識別那些會影響更改的測試用例。
• 將它們鏈接到相關需求。
• 了解優先級。
• 確切地告訴您的測試團隊他們需要做什么。

上面列出了許多質量難題。這些測試實踐中的許多實踐已被廣泛理解，例如測試數據庫的能力或測試UI的能力。但是API測試是一門經常被忽視并留在應用程序測試后期的學科。

API測試的重點觀點

API測試是在服務或組件級別驗證應用程序中的接口的實踐。這些API是機器彼此之間進行通信的機制，一旦將它們組合在一起，它們通常就成為應用程序的切入點。尤其是在當今面向服務或微服務體系結構的世界中，這一關鍵的集成點對于創建數字體驗至關重要。

通常，移動應用程序只是一系列服務的前端，而這些服務就是為您提供關鍵業務價值的東西。因此，組織需要與其他測試技術同時創建全面的API測試實踐。

這說起來容易做起來難，但是，因為大多數API接口的文檔記錄不充分，或者包含一系列隱藏的和未記錄的API。對于測試團隊來說，要了解如何按順序測試所有API以及確保他們正確涵蓋了正確的用例數量，確實是一個挑戰。

如何將API測試納入您的測試實踐中

一旦組織決定接受API測試作為效率修改器，關鍵是要以有意義的方式開始。啟動此過程的最佳方法是確定應用程序體系結構中可用API的清單。Parasoft SOAtest的智能API測試生成器使您可以通過記錄應用程序與API服務之間的交互來發現API。

該技術利用人工智能（AI）通過了解API序列中的模式和關系來提供有意義的API測試。然后，它使用它來創建自動運行的API測試，以連續運行以驗證各種系統組件之間的交互。

同時，您可以使用創建純Selenium UI級別測試。UI測試是整個測試實踐的重要組成部分，但是純粹以UI為中心的測試策略可能會引起可維護性問題。使用AI來識別測試腳本穩定性問題，并可以在運行時自我修復測試。

雖然這不是本次對話的重點，但將這兩個組件組合在一起可以確保廣泛地覆蓋應用程序，并有助于您確信應用程序界面不會受到威脅。

如果您已經有現有的基于Selenium的UI測試，則可以使用提取相關的API調用并將其提供給API測試引擎。通過盤點可用接口并為這些接口創建自動化測試，您可以快速開始構建API測試實踐。

我如何知道何時完成API測試？

這是一個非常復雜的問題。您怎么知道什么時候經過足夠的測試？關于這個主題有很多爭論，但是我認為它可以分解為三個指標。

• 代碼覆蓋率
• API覆蓋率
• 需求范圍

獲取代碼覆蓋率

代碼覆蓋率在很大程度上很容易獲得。您可以使用代碼級監視器來對應用程序進行檢測，并通過API來執行應用程序。代碼級監視器將識別與之交互的類和方法，并將該信息傳遞回您的報告和分析引擎中。

就其本質而言，API不會通過API公開所有可用的代碼功能，因此您的組織需要確定API可以訪問哪些代碼。掌握了這些信息后，就可以為要通過API測試實現的代碼覆蓋率級別設置一個閾值。通常，達到80％是一個不錯的水平。

獲取API覆蓋率

代碼覆蓋只是故事的一部分。您還希望查看API覆蓋率。API覆蓋率是一種指標，用于指示在可訪問的可用API總數中，您的自動化API測試中測試了其中的多少API。在許多情況下，盡管您實現了較高的代碼覆蓋率，但由于您尚未驗證某些關鍵的API，因此在應用程序中仍有風險。

也許這些關鍵的API僅涉及代碼的一小部分，因此它們在整個代碼覆蓋范圍中迷失了，但是由于它們涉及關鍵的組成部分，因此如果行為不當或被故意濫用，則會帶來巨大的風險。

通過在服務定義中可用的服務（例如Swagger，開放式API等）與在API測試中訪問的那些端點之間得出差異，可以通過自動化測試解決方案實現API覆蓋。通過此度量，您將能夠查看所覆蓋的服務總數與可用服務總數之間的關系。通常，取決于API的大小，達到90％是一個不錯的水平。

獲取需求范圍

最后，我們需要討論需求范圍。盡管代碼覆蓋率和API覆蓋率表明了您正在觸摸的應用程序所占的百分比，但它們并沒有表明它是否能達到您對客戶的期望。

需求覆蓋是將需求與測試方案相關聯的過程。您必須確定自動化測試方案可以從技術層面驗證用例。然后，您將能夠通過執行了解是否滿足您的所有要求。如果沒有，哪些要求仍然存在？他們的業務重點是什么？

有人認為需求覆蓋率是這三種技術中最重要的-理想情況下是100％覆蓋率。但是，實際上，必須結合使用所有三個指標才能充分了解何時具有可接受的發布風險級別。

如何縮短缺陷識別與修復之間的差距？

在遠程工作環境中，持續反饋至關重要。我們必須能夠以有意義的方式并盡快地應對數字體驗中出現的質量問題。由于API表示您可以最接近代碼而無需實際查看源代碼，因此它們代表了質量工程的良好第一道防線，以識別何時將缺陷引入到應用程序中并有可能傳播給用戶。自動化的API測試可讓您持續驗證API。可能作為CI/CD管道中的構建步驟。確保此過程可擴展的關鍵是接受智能測試執行。

如前所述，智能測試執行是一個籠統的術語，是指僅執行驗證更改所需的測試的過程。這些更改可能來自代碼或要求。

通過在CI/CD或DevOps流程中執行智能測試執行，您可以執行適當的API測試以驗證不斷變化的體系結構。通過不為每個構建執行完整的測試套件，您可以顯著減少從缺陷檢測到修復之間的時間。在資源有限的世界中，這些快速的反饋周期至關重要。

總結

世界已經改變。面對現實吧。在可預見的將來會是這樣。但是我們不需要把這個看作煩惱的時間。相反，我們可以將其用作數字轉換的機會。

通過向內看我們的質量流程并確定要添加效率調節器的領域，我們可以以更有利的位置擺脫這一大流行。API測試是組織可以采用的許多實踐之一，可以為我們的應用程序的可靠性和可擴展性提供有價值的見解。

要了解有關構建API測試實踐的更多信息，請觀看我們的點播網絡研討會。