關於微服務測試的思考

相信在互聯網領域的公司，對於微服務應該一點不陌生，愈來愈多的公司會採起這樣的一種架構

微服務的特色：

•     業務拆成獨立的系統，可單獨發佈，部署。
•     適合水平擴展，同時也成熟配套的服務治理
•     系統複雜度增高，端到端的一個業務可能調用十幾個甚至幾十個系統。調試和測試包括環境複雜度增，Debug問題難度加大。

那麼測試活動相比傳統行業須要作出一些調整，你可能會面臨

• 快速的建立一套穩定的測試環境（保證全部服務的聯通性，全部數據庫的數據是最新產線的，對於使用場景你能夠須要區分是單組件，仍是幾個組件，仍是集成環境的幾種模式，不一樣環境對於系統的一些配置多是不一樣的。）  
• 測試策略的識別：哪些需求是單個組件就能夠完成，哪些需求是須要組件與組件以前的連調，哪些是須要端到端的測試
• 測試工具的配套，單組件測試的狀況下你須要對上下游系統的MOCK，這種MOCK分爲有邏輯的MOCK（簡單模擬該系統邏輯）， 和無邏輯的MOCK（只有作response的擋板），有些多是JAVA RPC程序調用，有些是簡單HTTP應用調用，須要在正在開始測試前準備好
• 微服務下系統非功能測試的考慮：
  • 聯通性
  • 數據一致性（分佈式事務的保證或者業務間數據一致性， 如商品支付了你得給人加積分啊這樣的）
  • 服務容錯性（當某服務不可用是是否作了服務降級）
  • 服務調用性能（是否會由於某個系統處理慢出現超時）
  • 還有一些不肯定的問題（基於使用的技術作積累發現的一些問題
• 當前不管是傳統All In One的仍是微服務的都須要有自動化測試的迴歸，都知道自動化測試也是分層的，可是作的好的穩定的我以爲並很少，我司也只是作了接口驅動業務的主流程測試（沒有專業的自動化團隊每一個人都須要參與自動化，作對於團隊最有價值的事，保證系統主要業務功能）
  • 單元測試（能多作固然最好，可是實際並無多少公司有，或者也很少）
  • API測試（這裏主要講的是業務驅動）
  • 契約測試（只是爲了保證接口與相應是咱們以前約定的，契約測試是一種方法，可是不非得就要作，保證的方法能夠是其餘）
  • 集成測試（有條件的，作幾個冒煙的用例就好了，畢竟集成後，環境複雜自動化的穩定性未必高）
  • UI測試（我一直不怎麼建議作這個，你們隨意，我這裏指的是WEB非APP）

 

這裏只是簡單的分享了一下對於微服務下的測試的須要考慮的問題，對於須要轉型微服服的小夥伴有一些幫助。