對傳統(tǒng)的軟件交付方式的影響

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

資源受限

首先也是最重要的一點(diǎn)是，由于許多工人根本無法以與辦公室相同的能力在家工作，因此資源限制繼續(xù)上升。此外，由于許多企業(yè)正在利用全球系統(tǒng)集成商的資源，因此不同地區(qū)已經(jīng)建立了有關(guān)工作條件的特定規(guī)則。許多組織根本無法抗衡這種影響，因此領(lǐng)導(dǎo)者正在尋找解決方案，以更少的資源來實(shí)現(xiàn)相同的測試要求。

遠(yuǎn)程團(tuán)隊(duì)合作

接下來，組織需要考慮受約束的團(tuán)隊(duì)和遠(yuǎn)程團(tuán)隊(duì)的協(xié)作方式。有趣的是，持續(xù)的隔離狀態(tài)如何造成不適感，從而嚴(yán)重影響遠(yuǎn)程工作的團(tuán)隊(duì)。這是因?yàn)?，對于我們這些在辦公室工作的人來說，走進(jìn)某人的辦公室并就最新版本進(jìn)行對話太容易了。

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

軟件交付機(jī)制

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

與此挑戰(zhàn)相關(guān)的是組織必須考慮的實(shí)際交付機(jī)制。在為客戶重新考慮和設(shè)計(jì)數(shù)字體驗(yàn)的同時(shí)，我們需要考慮如何通過DevOps管道開發(fā)、測試和交付數(shù)字內(nèi)容。

轉(zhuǎn)向云生態(tài)系統(tǒng)和低代碼開發(fā)平臺

COVID-19大流行促使許多組織通過將其軟件轉(zhuǎn)移到云生態(tài)系統(tǒng)和低代碼開發(fā)平臺中來實(shí)現(xiàn)其交付機(jī)制的現(xiàn)代化，以便地理上分離的開發(fā)人員和測試人員可以協(xié)作并迭代以提供最佳體驗(yàn)。

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

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

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

通常，憑借這些競爭力，您最終會犧牲過程質(zhì)量。與以往相比，確保質(zhì)量至上至關(guān)重要，以確保通過數(shù)字體驗(yàn)與您直接互動的客戶不會受到影響。在受限的環(huán)境中繼續(xù)提供優(yōu)質(zhì)體驗(yàn)的最佳方法是為您的測試實(shí)踐尋求“效率調(diào)節(jié)器”。

效率調(diào)節(jié)器為您節(jié)省時(shí)間

這些“效率調(diào)節(jié)器”是什么？它們有幾種不同的形式：

• 智能測試設(shè)計(jì)和優(yōu)化
• 對代碼覆蓋率的綜合要求
• 智能測試執(zhí)行

智能測試設(shè)計(jì)與優(yōu)化

在現(xiàn)代應(yīng)用程序中要測試的東西太多了，包括前端UI，包括數(shù)據(jù)庫在內(nèi)的中間件服務(wù)，后端系統(tǒng)和第三方依賴項(xiàng)。這些每一層都增加了整個(gè)測試過程的復(fù)雜性。許多軟件測試工具供應(yīng)商提供解決方案來測試此體系結(jié)構(gòu)。但是重要的是要確保您可以準(zhǔn)確地完整地測試每個(gè)組件，從編寫第一行代碼到完成的應(yīng)用程序中的智能UI測試，一直到整個(gè)過程。

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

對代碼覆蓋率的全面要求

僅僅創(chuàng)建一堆測試是不夠的。為了快速驗(yàn)證應(yīng)用程序，您需要了解每個(gè)測試如何與業(yè)務(wù)需求相關(guān)聯(lián)，以便您可以了解優(yōu)先級以及優(yōu)先級與基礎(chǔ)代碼的相關(guān)性，以便可以開始了解測試的完整性。

因此，對于受約束的測試團(tuán)隊(duì)來說，一個(gè)強(qiáng)大的效率修改器是建立一種測試實(shí)踐，在該實(shí)踐中，測試用例與業(yè)務(wù)需求和開發(fā)代碼緊密耦合，以創(chuàng)建全面而全面的質(zhì)量視圖。

智能測試執(zhí)行

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

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

• 快速識別那些會影響更改的測試用例。
• 將它們鏈接到相關(guān)需求。
• 了解優(yōu)先級。
• 確切地告訴您的測試團(tuán)隊(duì)他們需要做什么。

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

API測試的重點(diǎn)觀點(diǎn)

API測試是在服務(wù)或組件級別驗(yàn)證應(yīng)用程序中的接口的實(shí)踐。這些API是機(jī)器彼此之間進(jìn)行通信的機(jī)制，一旦將它們組合在一起，它們通常就成為應(yīng)用程序的切入點(diǎn)。尤其是在當(dāng)今面向服務(wù)或微服務(wù)體系結(jié)構(gòu)的世界中，這一關(guān)鍵的集成點(diǎn)對于創(chuàng)建數(shù)字體驗(yàn)至關(guān)重要。

通常，移動應(yīng)用程序只是一系列服務(wù)的前端，而這些服務(wù)就是為您提供關(guān)鍵業(yè)務(wù)價(jià)值的東西。因此，組織需要與其他測試技術(shù)同時(shí)創(chuàng)建全面的API測試實(shí)踐。

這說起來容易做起來難，但是，因?yàn)榇蠖鄶?shù)API接口的文檔記錄不充分，或者包含一系列隱藏的和未記錄的API。對于測試團(tuán)隊(duì)來說，要了解如何按順序測試所有API以及確保他們正確涵蓋了正確的用例數(shù)量，確實(shí)是一個(gè)挑戰(zhàn)。

如何將API測試納入您的測試實(shí)踐中

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

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

同時(shí)，您可以使用創(chuàng)建純Selenium UI級別測試。UI測試是整個(gè)測試實(shí)踐的重要組成部分，但是純粹以UI為中心的測試策略可能會引起可維護(hù)性問題。使用AI來識別測試腳本穩(wěn)定性問題，并可以在運(yùn)行時(shí)自我修復(fù)測試。

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

如果您已經(jīng)有現(xiàn)有的基于Selenium的UI測試，則可以使用提取相關(guān)的API調(diào)用并將其提供給API測試引擎。通過盤點(diǎn)可用接口并為這些接口創(chuàng)建自動化測試，您可以快速開始構(gòu)建API測試實(shí)踐。

我如何知道何時(shí)完成API測試？

這是一個(gè)非常復(fù)雜的問題。您怎么知道什么時(shí)候經(jīng)過足夠的測試？關(guān)于這個(gè)主題有很多爭論，但是我認(rèn)為它可以分解為三個(gè)指標(biāo)。

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

獲取代碼覆蓋率

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

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

獲取API覆蓋率

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

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

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

獲取需求范圍

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

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

有人認(rèn)為需求覆蓋率是這三種技術(shù)中最重要的-理想情況下是100％覆蓋率。但是，實(shí)際上，必須結(jié)合使用所有三個(gè)指標(biāo)才能充分了解何時(shí)具有可接受的發(fā)布風(fēng)險(xiǎn)級別。

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

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

如前所述，智能測試執(zhí)行是一個(gè)籠統(tǒng)的術(shù)語，是指僅執(zhí)行驗(yàn)證更改所需的測試的過程。這些更改可能來自代碼或要求。

通過在CI/CD或DevOps流程中執(zhí)行智能測試執(zhí)行，您可以執(zhí)行適當(dāng)?shù)?/span>API測試以驗(yàn)證不斷變化的體系結(jié)構(gòu)。通過不為每個(gè)構(gòu)建執(zhí)行完整的測試套件，您可以顯著減少從缺陷檢測到修復(fù)之間的時(shí)間。在資源有限的世界中，這些快速的反饋周期至關(guān)重要。

總結(jié)

世界已經(jīng)改變。面對現(xiàn)實(shí)吧。在可預(yù)見的將來會是這樣。但是我們不需要把這個(gè)看作煩惱的時(shí)間。相反，我們可以將其用作數(shù)字轉(zhuǎn)換的機(jī)會。

通過向內(nèi)看我們的質(zhì)量流程并確定要添加效率調(diào)節(jié)器的領(lǐng)域，我們可以以更有利的位置擺脫這一大流行。API測試是組織可以采用的許多實(shí)踐之一，可以為我們的應(yīng)用程序的可靠性和可擴(kuò)展性提供有價(jià)值的見解。

要了解有關(guān)構(gòu)建API測試實(shí)踐的更多信息，請觀看我們的點(diǎn)播網(wǎng)絡(luò)研討會。