相信在網際網路領域的公司，對於微服務應該一點不陌生，越來越多的公司會採取這樣的一種架構

微服務的特點：

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

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

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

這裡只是簡單的分享了一下對於微服務下的測試的需要考慮的問題，對於需要轉型微服服的小夥