原創|使用教程|編輯:鄭恭琳|2021-03-01 14:00:08.613|閱讀 200 次
概述:微服務致力于將傳統的單片應用程序分解為小型的,可伸縮的,可單獨部署的服務。一些微服務體系結構在反應性環境中運行,在該環境中,服務可以異步通信而不會阻塞答復。
# 界面/圖表報表/文檔/IDE等千款熱門軟控件火熱銷售中 >>
相關鏈接:
微服務致力于將傳統的單片應用程序分解為小型的,可伸縮的,可單獨部署的服務。一些微服務體系結構在反應性環境中運行,在該環境中,服務可以異步通信而不會阻塞答復。
當系統的某些部分出現故障或行為異常時,這些基于微服務的環境不太容易出現故障。對于完整功能,仍然需要所有依賴項的正確操作,但是此方法的主要優點是它提供的去耦。
微服務是獨立的,這意味著它們可以根據需要進行單獨部署,擴展和更改。這允許快速迭代。但是,為了實現更快的迭代和可靠的服務,現在更加關注API——面向公眾的API和依賴關系內部使用的API。
在測試微服務時,會出現大量新挑戰。
向微服務的轉變為軟件團隊帶來了新的挑戰,降低了過渡時的投資回報率。
在API層進行更多交互以實現自動化
微服務之間的相互依賴性要求在API層的幕后進行更多的切換和交互。充分的測試要求我們不僅了解這些交互,而且能夠隔離它們并進行測試。
平行發展的障礙
微服務在修改和重新部署方面很敏捷,但是測試它們的復雜性減慢了并行開發的速度。這種復雜性是由于服務之間的大量交互。它使測試環境變得復雜,并且使人們無法理解正在發生的事情。
對傳統測試方法的影響
微服務與傳統測試不一致,傳統測試通常依賴于同步請求/回復交互。微服務有時會部署在具有新協議和消息格式以及異步通信的反應性,事件驅動的體系結構中。
更多潛在故障點
增加的交互作用和依賴性增加了潛在的故障點。并且由于服務的響應性,新事件流可能會亂序觸發并崩潰。
開發障礙
轉向微服務架構有很多好處,但付出的代價往往使開發團隊無法實現創收功能的實現。除非消除測試和并行開發障礙,否則很難實現真正的ROI。
為了使微服務測試的投資回報率最大化,請遵循以下策略:
通過AI提高功能性API測試覆蓋范圍的質量,以確保已部署的服務滿足要求。
使復雜的,事件驅動的工作流程自動化,以加快測試速度。
改善測試環境,提高測試的可靠性和穩定性。
充分利用微服務測試的三種策略
通過AI增加功能性API測試的覆蓋率
缺乏代碼和測試覆蓋范圍是質量,安全性和客戶體驗的問題。如果僅部分測試了部署的服務,則發現錯誤的是客戶!覆蓋范圍的擴大意味著更多的測試。為了實現這一目標,需要測試自動化以利用現有的Selenium UI測試快速創建功能來加速功能測試。
除此之外,自動進行需要在服務之間交換數據的API序列的驗證至關重要。這些API序列中的大多數都是基于自動UI測試中API流量的“記錄”。可以克隆并轉化這些API序列以增加測試覆蓋率。
測試自動化程度的提高通過確定故障點來減少解決問題的時間。
減少“調試”測試失敗所花費的時間意味著更多的時間測試功能。
自動化的API測試是用于非功能測試的平臺,因為可以使用相同的測試資產和測試框架來自動進行真實的序列以進行負載和性能測試。
自動化復雜的,事件驅動的工作流程
功能測試范圍的增加要求測試數據的更多排列。測試自動化通過直接通過API提供端到端方案的大量數據排列來提供幫助。
測試數據管理是測試自動化的關鍵功能。它需要保留測試數據的安全性(如果基于生產數據)和數據的參數化,以支持新的復雜場景。
為了驗證正確的行為,需要對服務交互的可見性。要使事件驅動的體系結構具有可見性,那就是服務虛擬化。虛擬化通過成為集成在一起的各種應用程序中間的代理而有所幫助。例如,通過創建虛擬服務來模擬舊數據庫,可以監視來自舊系統和被測試微服務的請求。
監視事件驅動的體系結構中的交互的功能非常有用。當數據在系統之間移動時,服務虛擬化使我們能夠自動驗證那些復雜的工作流程。斷言放置在虛擬化服務中,以確保正確的請求/響應事務,從而可以監視和驗證復雜的事件驅動的交互。
穩定,隔離和左移微服務測試
服務虛擬化使服務模擬更上一層樓。它模擬了API交互的復雜,有狀態的行為,以使功能測試自動化與難以管理的下游依賴關系保持穩定和隔離。可以為每個開發人員和測試人員復制此虛擬化的穩定測試環境,從而消除了現實環境的復雜性,同時保留了測試所需的行為。這進一步實現了對微服務清單的連續驗證,包括作為CI/CD/DevOps管道一部分的客戶端系統測試。
在許多組織中,測試是頭等大事。換句話說,與API或單元測試相比,手動或UI測試花費了更多的測試時間和精力。這些組織知道他們需要更好的覆蓋范圍,但是UI測試更容易理解和定義(用戶界面更直觀)。結果,較少的技術(和較便宜的)資源可以進行測試。
軟件組織通常希望使他們當前正在執行的測試自動化(主要是UI測試)。盡管這樣做有幫助,但UI自動化不穩定且需要不斷維護。另外,UI級別上遇到的大多數問題都是API層上的錯誤的結果。缺乏對潛在活動和交互的可見性意味著浪費時間確定根本原因。
愿意進行測試轉換的組織可以通過結合使用自上而下和自下而上的方法來進行測試,從而獲得經過更好測試的產品,并節省時間和金錢。一種新的測試策略具有很高的ROI,因為經過充分驗證的API可以減少UI的不穩定性,這意味著更好的客戶體驗。
現在可以通過減少測試創建時間來實現更高級別的測試覆蓋率。在API級別上增加對交互的可見性意味著減少了平均修復時間。開發人員將更快地發現更多問題。這是一項雙贏的項目,只需相對少量的投資即可獲得較高的投資回報率。
這三種策略通過利用AI驅動的測試創建,API測試自動化和服務虛擬化,從根本上簡化了測試創建過程。在不影響產品進度的情況下,通過更好的代碼覆蓋率來改進測試,從而產生更好的微服務。采用這些策略有助于軟件團隊實現他們想要在測試中實現的投資回報率。
本站文章除注明轉載外,均為本站原創或翻譯。歡迎任何形式的轉載,但請務必注明出處、不得修改原文相關鏈接,如果存在內容上的異議請郵件反饋至chenjj@fc6vip.cn