微服務是Devops場景下熱門的開發架構，在大型項目中被廣泛采用。它把一個大型的單個應用程式和服務拆分為數十個的支援微服務，獨立部署、互相隔離，通過擴充元件來處理功能瓶頸問題，比傳統的應用程式更能有效利用計算資源。微服務之間無需關心對方的模型，它通過事先約定好的接口進行資料流轉，使業務可以高效響應市場變化。但微服務一個明顯的表象就是随着服務的增多，傳統的測試模式受到很大制約，無法有效進行下去，威脅到整體系統品質。所有J2EE代碼層白盒采集工具都無法區分覆寫和具體功能的對應關系，隻能以背景模式“籠統“的采集一個階段的總的覆寫，無法滿足對于Devops下對于故障定位、深度測試分析以及靈活釋出算法的要求。
星雲測試（www.teststars.cc）釋出分布式微服務精準測試解決方案，是目前市場上唯一可達到在複雜分布式系統中，跨多個伺服器進行代碼白盒級分析、實作請求分布式追蹤的測試平台。其中産品内的穿透子產品，可以支援各種主流微服務通信架構。例如httpclient，springcloud微服務架構、阿裡dubbo微服務架構，以及消息隊列，将并發通路場景下跨多個服務多組代碼邏輯分離并重建追蹤出來。實作業務邏輯的代碼在開發層面通過微服務離散後，在測試階段則可以反向複原整個完整代碼執行視圖。精準測試裡面的穿線概念（Threadingtest）增加了第三層含義，即針對的分布式服務的穿透能力。
微服務場景下，一個完整請求會跨多個計算（服務）節點，而對于以節點為剖面的各種測試和監控手段都變得不那麼直接和有效。一個請求鍊路的失效和性能故障等問題，從一個計算節點剖面去分析是很困難的，因為在一個計算節點剖面上的資料是混合型資料，而無法區分這裡面的資料來自于那個請求。原始的方法無法将一個調用鍊路上的所有資訊完整的重新刻畫出來。業界流行的APM技術可以某種程度實作這種調用鍊路分析，該項技術主要用于監控，展現的資料是元件級的，而且為了性能考慮還經常抽取樣 本，無法達到測試要求的代碼級的分析。
微服務采用的“分而治之”的政策，而精準測試對于微服務的測試和營運管控上采用的是“概覽全局”的政策。精準測試在編譯階段，重新将微服務所有子產品視為一個完整項目，統一編譯和插裝，經過插裝後的代碼重新部署到原有節點上。在微服務的啟動過程中附加上分布式追蹤所需要的agent啟動，即可完成微服務場景下達到測試用例級的代碼全調用路徑分析。由于微服務有多個程式子產品，星雲測試平台支援子產品級增量編譯模式，即每次編譯替換某一個子產品就可以生成一個新的版本，而無需将所有微服務子產品全新編譯。
穿透和分布式追蹤的原理，這裡要重點将以下星雲測試JavaEE應用伺服器agent的能力。agent提供了一個虛拟jsp的技術，通過agent啟動的被測應用，都附加了一個虛拟jsp，位址類似于
http://www.appundertest.com/teststars.jsp。 通路這個頁面可以用來指本機的使用者，一般這個設定和精準測試示波器的登入使用者需要一緻。設定完成後，對被測試應用的請求将附加上一個使用者辨別的cookie資訊，這個資訊會在微服務的多層架構中一直攜帶和穿透。例如從浏覽器發起的一個帶着使用者辨別資訊的請求，到了應用服務的處理線程中，這個線程執行的所有代碼将附加上這個使用者資訊，如果應用在向後調用其他的節點的服務，則這個使用者資訊會繼續向後傳遞，直到最後的執行節點。由于每個節點的代碼均有精準測試系統插裝的代碼，會自動的向使用者請求發起端的示波器回饋資料，那麼就可以實作将整個調用鍊路上的代碼邏輯發送給示波器。示波器收到資料後，将動态資料和代碼編譯階段的程式靜态資料結合起來，即可展示全鍊路的程式調用路徑資訊。從另外角度，當微服務系統有多個請求同時并行的時候，那麼每個示波器收到的是自己對應的請求代碼的全鍊路執行情況，而其他示波器使用者和其他普通使用者的資料則不會被收錄進來。
上圖是一個spring cloud微服務架構下兩個節點的調用圖。當從第一層入口元件通路後，入口元件向後調用下一層節點的時候，後一層節點的運作線程自動取到了前一層節點的使用者資訊，并且加入到了第二層節點的運作線程控件。這樣，通過精準測試示波器（登入使用者辨別和請求辨別一緻）就可以收到兩個節點的資料。實作多個使用者同時通路分布式應用的時候，不同使用者出發的資料自動分離，路由到對應的示波器，最終對應到用例上。