parasoft告訴你的企業(yè)怎樣實現(xiàn)測試自動化

---

 作為進入市場戰(zhàn)略的一部分，企業(yè)越來越關注客戶體驗，而客戶體驗的關鍵部分是他們以快速，無縫的方式遍歷軟件的能力。為了減少不良客戶體驗的風險，組織將質(zhì)量計劃加倍，軟件開發(fā)行業(yè)也將持續(xù)測試作為主流活動。

什么是連續(xù)測試？

 連續(xù)測試是軟件測試的一項原則，在該原則中，所有測試始終在執(zhí)行，從而為應用程序的質(zhì)量和運行狀況提供連續(xù)的反饋。但是為了實現(xiàn)連續(xù)測試，組織必須首先采用測試自動化。測試自動化的類型很多，涵蓋了從UI層開始的應用程序的整個范圍，中間件系統(tǒng)甚至后端系統(tǒng)。了解如何盡可能有效地引入這些不同類型的測試自動化實踐，可以使您邁向連續(xù)測試的道路。

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

 現(xiàn)在已經(jīng)被廣泛接受的測試金字塔（由Michael Cohen和Martin Fowler推廣）為不同類型的測試活動確定了最佳策略。在最代表測試數(shù)量最多的基礎上，我們希望建立廣泛的單元測試和API測試，這些測試最容易在自動化中運行，但通常需要技術技能來構建。到達測試金字塔的頂部，您會發(fā)現(xiàn)自動UI測試和手動測試。我們希望這種類型的測試活動在頂部，因為這是確保客戶體驗的唯一方法。

 大多數(shù)人專注于UI測試的“自動化手冊”方法，而單元開發(fā)人員則以“開發(fā)人員應測試”的心態(tài)專注于測試金字塔的底部和頂部。盡管這些做法很重要，但專注于頂部和底部會在UI和代碼之間的API層中間產(chǎn)生間隙。但是，這種差距只會變得越來越嚴重，Programmable Web最近的一項調(diào)查預測，到2021年，將有22,000多個公開可用的API。API測試比以往任何時候都更加重要，需要成為持續(xù)測試策略不可或缺的一部分你正在建造。

通過測試自動化實現(xiàn)連續(xù)測試的3個步驟

之前，我曾討論過如何根據(jù)組織的獨特需求選擇最佳的API測試解決方案，并根據(jù)行業(yè)和應用程序提出了可能需要的關鍵功能。從一個API測試解決方案開始很有幫助，該解決方案可以隨著您的API測試成熟度的增長而增長。選擇工具后，如何開始？這是三個關鍵步驟，可以更快地實現(xiàn)功能測試自動化并實現(xiàn)連續(xù)測試。

慧都科技是parasoft一級授權代理商，如果您想了解parasoft各類產(chǎn)品，請咨詢 ~幫您選擇適合您的最佳產(chǎn)品

步驟1：建立您現(xiàn)有的自動化API的廣泛測試范圍

 要創(chuàng)建廣泛的自動化測試，可以從Web記錄和API合同構建無腳本測試，然后使用這些測試來連續(xù)驗證API的運行狀況，確保API能夠按設計的方式運行。將此視為API的單元測試，但無需費力-這不僅是一種有價值的測試技術，而且它也是您可以執(zhí)行的最早的功能測試驗證類型之一，因為API的服務合同通常是首先要做的事情之一在創(chuàng)建新功能部件或功能時進行編寫。

 例如，假設團隊在我們的銀行應用程序中添加了一些新功能。第一步，開發(fā)團隊發(fā)布了新的服務定義。在這種情況下，將生成一張草率的文檔。被添加的新服務是RequestLoan服務。該服務接受一系列輸入，并與貸款提供者響應以獲取新貸款。為了測試該服務，我可以使用Swagger YAML，并為每個單獨的操作創(chuàng)建一系列客戶端。

 這些客戶之一就是請求貸款服務。我可以創(chuàng)建一個正向和負向的系列輸入，以驗證該服務的行為是否適當。然后，我可以將這些測試重新用于回歸目的。

 當然，盡管這種測試非常有價值，但這只是API測試難題的一半，因為它無法驗證API的實際使用方式。輸入步驟2。

步驟2：彌合UI和API之間的鴻溝

 API測試策略的第二部分是能夠將您對應用程序的人工使用建模為完整的API測試方案。您可以通過利用人工智能來增強您的能力，從而在用戶瀏覽您的應用程序時了解幕后實際發(fā)生的事情，并將這些幕后事務解釋為API調(diào)用，從而開始彌合測試金字塔中的空白。這種類型的測試可讓您將用戶體驗與關鍵的API測試保持一致。

 人工智能是該策略的關鍵組成部分，因為我們可以可靠地使用人工智能來幫助我們將這些通信分解為關系和模式，以了解如何測試應用程序的業(yè)務規(guī)則。我們可以將其與我們的單元級API測試結合起來，以廣泛涵蓋我們的API范圍。

繼續(xù)前面的示例，您會發(fā)現(xiàn)請求貸款服務需要我應用程序其他區(qū)域的輸入。特別：

 現(xiàn)在，盡管我可以任意提供customerID和accountAccountID，但我確實需要它們存在于我的應用程序中。因此，我將需要創(chuàng)建一個動態(tài)方案，在該方案中，我首先查詢單個用戶以獲得客戶ID和帳戶ID，以便我可以將該信息傳遞給請求貸款服務，并確保動態(tài)方案按所述方式工作。確保我正在使用真實的動態(tài)數(shù)據(jù)，以確保可以充實因API相互交互而存在的行為。

 這些類型的技術將使我們能夠向左移API測試實踐，并在可能的最早階段為我們的應用程序創(chuàng)建廣泛的覆蓋范圍。一旦實現(xiàn)，此實踐的第三個關鍵組成部分就是我們理解和適應變化的能力。

步驟3：通過可維護的變更管理過程確保信心

 我已經(jīng)與很多人談論過他們的功能測試計劃，一旦他們的應用程序更改了，他們的計劃就停滯了。這是常見的情況，因為測試人員將大部分時間都花在構建豐富而出色的API測試上，而只是在應用程序的API發(fā)生更改時才讓它們中斷。這可能會產(chǎn)生累積效應，從而降低對API測試策略的信心，因為測試人員將大量時間用于維護API測試，而不是建立新的價值。

 變更管理是任何功能測試策略的關鍵部分，而AI在這里也可以成為關鍵的推動者。通過自動掃描服務定義（是的，與最初創(chuàng)建測試用例的服務定義相同）來確定您的API何時更改，您可以了解何時會受到影響，然后構建用于將現(xiàn)有服務遷移到新服務的模板版。

 回到銀行應用程序示例的第一部分，我聲明了將新服務添加到我的應用程序中。這實際上代表API的更改。自從我使用服務定義創(chuàng)建了第一輪基準測試以來，我現(xiàn)在可以相互比較服務定義的不同版本，不僅可以識別已更改的內(nèi)容，還可以構建一個映射來更新現(xiàn)有的測試用例：

 在查看變更模板后，不難看出，不僅添加了新服務，而且還重構了我現(xiàn)有的許多服務。在上圖中，您會注意到讓客戶擁有一系列新字段。使用變更管理工作流程，您可以主動識別服務變更，同時管理現(xiàn)有測試用例的更新，以便您可以盡快從變更中恢復。

 可以說，這是在制定其功能測試策略時必須建立的最重要的實踐，并且從一開始就對質(zhì)量有理解和承諾將有助于您和您的組織采用這種實踐。

片狀測試環(huán)境如何？

 因此，憑借出色的測試自動化功能，可以輕松地在此處停止測試。但是請說您花了很多時間來構建這種豐富而強大的功能測試策略，并將其作為自動夜間連續(xù)測試過程的一部分在您的環(huán)境中運行測試，并且在查看結果時您會發(fā)現(xiàn)很大一部分您的測試因系統(tǒng)無法控制而失敗。這是否意味著您的測試不合格？您現(xiàn)在對技術超出測試范圍的系統(tǒng)負責嗎？

這不是一個罕見的故事。我們知道功能測試只能與執(zhí)行它們的測試環(huán)境一樣有效。不穩(wěn)定，不可用或只是普通的不穩(wěn)定測試環(huán)境會降低我們從功能測試工具中獲得的投資回報。因此，我必須至少簡短地提到穩(wěn)定測試環(huán)境的最佳方法之一，那就是：服務虛擬化。

 不要與虛擬機（即硬件虛擬化）相混淆，服務虛擬化使您能夠實際模擬在不同硬件之間進行通信的服務。例如，考慮一個調(diào)用數(shù)據(jù)庫的應用程序。您在測試環(huán)境中實際上是否需要該數(shù)據(jù)庫？如果沒有所需的數(shù)據(jù)怎么辦？使用服務虛擬化，您可以記錄與數(shù)據(jù)庫的事務，然后使用該記錄創(chuàng)建該數(shù)據(jù)庫的模擬版本，以及針對測試環(huán)境所需的所有行為。但是，當然，它并不僅限于數(shù)據(jù)庫-它可以是任何類型的服務，例如SOAP或REST API，甚至是TCP和微服務。

作為制定可持續(xù)的API測試策略的一部分，您需要制定可持續(xù)的服務虛擬化策略，首先要回答以下問題：

哪些服務適合虛擬化？

如何創(chuàng)建虛擬服務？

如何維護虛擬環(huán)境？

如何將虛擬環(huán)境部署為持續(xù)測試策略的一部分？

 服務虛擬化是可持續(xù)的連續(xù)測試策略的關鍵推動力，但是了解在何處，何時引入它以及如何使其盡可能有效是成功的關鍵。

怎么辦？

 通過此文章您或許對如何將API測試集成為持續(xù)測試策略的一部分有了更好的了解，在軟件開發(fā)的初期階段與API測試工具供應商合作將提高您的開發(fā)速度，更快地交付產(chǎn)品，祝您持續(xù)測試愉快！

---

慧都科技是parasoft一級授權代理商，如果您想購買parasoft產(chǎn)品，請咨詢 ~

更多parasoft文章資訊敬請關注慧都科技。