如何進行微服務的測試

對于測試工作而言，微服務架構(gòu)對于傳統(tǒng)的架構(gòu)引入了更多的復雜性。一方面，隨著微服務數(shù)量的增長，測試的用例也會持續(xù)增長;另一方面，由于微服務之間存在著一定的依賴性，在測試過程中如何來處理這些依賴，就變得極為重要。

本節(jié)將從微服務架構(gòu)的單元測試、集成測試和系統(tǒng)測試三個方面來展開討論。

微服務的單元測試

單元測試要求將測試范圍局限在服務內(nèi)部，這樣可以保證測試的隔離性，將測試的影響減少到最小。在實際編碼之前，TDD要求程序員先編寫測試用例。當然，一開始，所有的測試用例應該是全部失敗的，然后再寫代碼讓這些測試用例逐個通過。也就是說，編寫足夠的測試用例使測試失敗，編寫足夠的代碼使測試成功。這樣，程序員編碼的目的就會更加明確。

當然，編寫測試用例并非是TDD的全部。在測試成功之后,還需要對成功的代碼及時進行重構(gòu)，從而消除代碼的“壞味道”。

1.為什么需要重構(gòu)代碼

所謂重構(gòu)，簡而言之，就是在不改變代碼外部行為的前提下，對代碼進行修改，以改善程序的內(nèi)部結(jié)構(gòu)。

重構(gòu)的前提是代碼的行為是正確的，也就是說，關(guān)于代碼功能已經(jīng)經(jīng)過測試，并且測試通過了，這是重構(gòu)的前提。只有正確的代碼才有重構(gòu)意義。

那么，既然代碼都正確了，為什么還要花費時間再去改動代碼、重構(gòu)代碼呢?

重構(gòu)的原因是大部分程序員無法寫出完美的代碼。他們無法對自己編寫的代碼完全信任，這也是需要對自己所寫的代碼進行測試的原因，重構(gòu)也是如此。歸納起來，以下幾方面是軟件需要重構(gòu)的原因。

• ·軟件不一定一開始就是正確的。天才程序員只是少數(shù)，大多數(shù)人不可避免會犯錯，所以很多程序員無法一次性寫出正確的代碼，只能不斷地測試、不斷地重構(gòu)，以改善代碼。連MartinFowler這樣的大師都承認自己的編碼水平也同大多數(shù)人一樣，是需要測試及重構(gòu)的。
• ·隨著時間推移，軟件的行為變得難以理解。這種現(xiàn)象特別集中在一些規(guī)模大、歷史久、代碼質(zhì)量差的軟件里面。這些軟件的實現(xiàn)，或者脫離了最初的設計，或者混亂不堪，讓人無法理解，特別是缺少“活文檔”來進行指導，這些代碼最終會“腐爛變味”。
• ·能運行的代碼，并不一定是好代碼。任何程序員都能寫出計算機能理解的代碼，唯有寫出人類容易理解的代碼，才是優(yōu)秀的程序員。

正是目前軟件行業(yè)這些事實的存在，促使重構(gòu)成為TDD中必不可少的實踐之一。程序員對程序進行重構(gòu)，是出于以下的目的。

• 消除重復。代碼在首次編碼時，單純只是為了讓程序通過測試，其間可能會有大量的重復代碼，以及“僵尸代碼”的存在，所以需要在重構(gòu)階段消除重復代碼。
• 使代碼易理解、易修改。在一開始，程序員優(yōu)先考慮的是程序的正確性，在代碼的規(guī)范上并未加以注意，所以需要在重構(gòu)階段改善代碼。
• 改進軟件的設計。好的想法也并非一氣呵成，當對以前的代碼有更好的解決方案時，果斷進行重構(gòu)來改進軟件設計。
• 查找Bug，提高質(zhì)量。良好的代碼不但能讓程序員易懂易于理解，同樣，也能方便程序員來發(fā)現(xiàn)問題，修復問題。測試與重構(gòu)是相輔相成的。
• 提高編碼效率和編碼水平。重構(gòu)技術(shù)利于消除重復代碼，減少冗余代碼，提升程序員的編碼水平。程序員編碼水平的提升，同時也將體現(xiàn)在其編碼效率上。

2.何時應該進行重構(gòu)

那么，程序員應該在何時進行重構(gòu)呢?

• 隨時重構(gòu)。也就是說，將重構(gòu)當作是開發(fā)的一種習慣，重構(gòu)應該與測試一樣自然。
• 事不過三，三則重構(gòu)。當代碼存在重復時，就要進行重構(gòu)了。
• 添加新功能時。添加了新功能，對原有的代碼結(jié)構(gòu)進行了調(diào)整，意味著需要重新進行單元測試及重構(gòu)。
• 修改錯誤時。修復錯誤后，同樣也是需要重新對接口進行單元測試及重構(gòu)的。
• 代碼審查。代碼審查是發(fā)現(xiàn)“代碼壞味道”非常好的時機，自然也是進行重構(gòu)的絕佳機會。

3.代碼的“壞味道”

如果一段代碼是不穩(wěn)定或有一些潛在問題的，那么代碼往往會包含一些明顯的痕跡，就好像食物要腐壞之前，經(jīng)常會發(fā)出一些異味一樣，這些痕跡就是代碼“壞味道”。以下就是常見的代碼“壞味道”。

• DuplicatedCode（重復代碼）:重復是萬惡之源。解決方法是將公共函數(shù)進行提取。
• LongMethod（過長函數(shù)）:過長函數(shù)會導致責任不明確、難以切割、難以理解等一系列問題。解決方法是將長函數(shù)拆分成若干函數(shù)。
• LargeClass（過大的類）:會導致職責不明確、難理解。解決方法是拆分成若干類。
• LongParameterList(過長參數(shù)列）:過長參數(shù)列其實是沒有真正地遵從面向?qū)ο蟮木幋a方式，對于程序員來說也是難以理解的。解決方法是將參數(shù)封裝成結(jié)構(gòu)或類。
• DivergentChange（發(fā)散式變化）:當對多個需求進行修改時，都會動到這種類。解決方法是對代碼進行拆分，將總是一起變化的東西放在一起。
• ShotgunSurgery（霞彈式修改）:其實就是在沒有封裝變化處改動一個需求，然后會涉及多個類被修改。解決方法是將各個修改點集中起來，抽象成一個新類。
• FeatureEnvy（依戀情結(jié)）:一個類對其他類存在過多的依賴，比如某個類使用了大量其他類的成員，這就是FeatureEnvy。解決方法是將該類并到所依賴的類里面。
• DataClumps（數(shù)據(jù)泥團）:數(shù)據(jù)泥團是常一起出現(xiàn)的大堆數(shù)據(jù)。如果數(shù)據(jù)是有意義的，解決方法是就將結(jié)構(gòu)數(shù)據(jù)轉(zhuǎn)變?yōu)閷ο蟆?/li>
• PrimitiveObsession(基本類型偏執(zhí)）:熱衷于使用int、long、String等基本類型。其解決方法是將其修改成使用類來替代。
• SwitchStatements ( switch驚悚現(xiàn)身）:當出現(xiàn) switch語句判斷的條件太多時，則要考慮少用switch語句，采用多態(tài)來代替。
• ParallelInheritanceHierarchies(平行繼承體系）:過多平行的類，使用類繼承并聯(lián)起來。解決方法是將其中一個類去掉繼承關(guān)系。
• LazyClass(冗贅類）:針對這些冗贅類，其解決方法是把這些不再重要的類里面的邏輯合并到相關(guān)類，并刪除舊的類。
• SpeculativeGenerality(夸夸其談未來性）:對于這些沒有用處的類，直接刪除即可。
• TemporaryField (令人迷惑的暫時字段）:對于這些字段，解決方法是將這些臨時變量集中到一個新類中去管理。
• MessageChains（過度耦合的消息鏈）:使用真正需要的函數(shù)和對象，而不要依賴于消息鏈。
• MiddleMan（中間人）:存在這種過度代理的問題，其解決方法是用繼承替代委托。
• InappropriateIntimacy(狎昵關(guān)系）:兩個類彼此使用對方的private值域。解決方法是劃清界限拆散，或合并，或改成單項聯(lián)系。
• AlternativeClasseswithDifferentInterfaces(異曲同工的類）:這些類往往是相似的類，卻有不同的接口。解決方法是對這些類進行重命名、移動函數(shù)或抽象子類重復作用的類，從而合并成一個類。
• IncompleteLibraryClass（不完美的庫類）:解決方法是包一層函數(shù)或包成新的類。
• DataClass（純稚的數(shù)據(jù)類）:這些類很簡單，往往僅有公共成員變量或簡單的操作函數(shù)。解決方法是將相關(guān)操作封裝進去，減少public成員變量。
• RefusedBequest（拒絕遺贈）:這些類的表現(xiàn)是父類里面方法很多，但子類只用到有限幾個。解決方法是使用代理來替代繼承關(guān)系。
• Comments(過多的注釋）:注釋多了，就說明代碼不清楚了。解決方法是寫注釋前先重構(gòu)，去掉多余的注釋，“好代碼會說話”。

4.減少測試的依賴

首先，我們必須承認，對象間的依賴無可避免。對象與對象之間通過協(xié)作來完成功能，任意一個對象都有可能用到另外對象的屬性、方法等成員。但同時也認識到，代碼中的對象過度復雜的依賴關(guān)系往往是不提倡的，因為對象之間的關(guān)聯(lián)性越大，意味著代碼改動一處，影響的范圍就會越大，而這完全不利于系統(tǒng)的測試、重構(gòu)和后期維護。所以在現(xiàn)代軟件開發(fā)和測試過程中應該盡量降低代碼之間的依賴。

相比于傳統(tǒng)JavaEE的開發(fā)模式，DI（依賴注人）使代碼更少地依賴容器，并削減了計算機程序的耦合問題。通過簡單的new操作，構(gòu)成程序員應用的 POJO對象即可在JUnit或TestNG下進行測試。即使沒有Spring或其他loC容器，也可以使用mock來模擬對象進行獨立測試。清晰的分層和組件化的代碼將會促進單元測試的簡化。例如，當運行單元測試的時候，程序員可以通過stub或mock來對DAO或資源庫接口進行替代，從而實現(xiàn)對服務層對象的測試，這個過程中程序員無須訪問持久層數(shù)據(jù)。這樣就能減少對基礎(chǔ)設施的依賴。

在測試過程中，真實對象具有不可確定的行為，有可能產(chǎn)生不可預測的效果（如股票行情、天氣預報），同時，真實對象存在以下問題。

• 真實對象很難被創(chuàng)建。
• 真實對象的某些行為很難被觸發(fā)。
• 真實對象實際上還不存在（和其他開發(fā)小組或和新的硬件打交道）等。

正是由于上面真實對象在測試的過程中存在的問題，在測試中廣泛地采用mock測試來代替。

在單元測試上下文中，一個mock對象是指這樣的一個對象——它能夠用一些“虛構(gòu)的占位符”功能來“模擬”實現(xiàn)一些對象接口。在測試過程中，這些虛構(gòu)的占位符對象可用簡單方式來模仿對于一個組件期望的行為和結(jié)果，從而讓程序員專注于組件本身的徹底測試，而不用擔心其他依賴性問題。

mock對象經(jīng)常被用于單元測試。用mock對象來進行測試，就是在測試過程中，對于某些不容易構(gòu)造（如HttpServletRequest必須在Servlet容器中才能構(gòu)造出來）或不容易獲取的比較復雜的對象(如JDBC中的ResultSet對象)，用一個虛擬的對象( mock對象)來創(chuàng)建以便測試的測試方法。

mock最大的功能是把單元測試的耦合分解開，如果編寫的代碼對另一個類或接口有依賴，它能夠模擬這些依賴，并驗證所調(diào)用的依賴行為。

mock對象測試的關(guān)鍵步驟如下。

• 使用一個接口來描述這個對象。
• 在產(chǎn)品代碼中實現(xiàn)這個接口。
• 在測試代碼中實現(xiàn)這個接口。
• 在被測試代碼中只是通過接口來引用對象，所以它不知道這個引用的對象是真實對象，還是mock對象。

目前，在Java陣營中主要的mock測試工具有Mockito、JMock、EasyMock 等。

5.mock與stub的區(qū)別

mock和 stub都是為了替換外部依賴對象，mock不是stub，兩者有以下區(qū)別。

• 前者稱為mockist TDD，而后者一般稱為classic TDD。
• 前者是基于行為的驗證（Behavior Verification )，后者是基于狀態(tài)的驗證(State Verification )。
• 前者使用的是模擬的對象，而后者使用的是真實的對象。

現(xiàn)在通過一個例子來看看mock與 stub之間的區(qū)別。假如程序員要給發(fā)送mail的行為做一個測試，就可以像下面這樣寫一個簡單的stub。

//待測試的接口 
public interface Mailservice(）{ 
public void send(Message msg); 
} 
/lstub測試類 
public class MailServiceStub implements MailService i 
private List<Message>messages = new ArrayList<Message>(); 
public void send (Message msg){ 
messages.add (msg); 
} 
public int numberSent( { 
return messages.size(）; 
} 
} 
} 

也可以像下面這樣在stub 上使用狀態(tài)驗證的測試方法。

public class orserStateTester{ 
Order order = new Order(TALISKER， 51）; 
MailServiceStub mailer = new MailserviceStub(); 
order.setMailer(mailer); 
order.fill (warehouse); 
//通過發(fā)送的消息數(shù)來驗證 
assertEquals(1 , mailer.numberSent(）;} 
} 

當然這是一個非常簡單的測試，只會發(fā)送一條message。在這里程序員還沒有測試它是否會發(fā)送給正確的人員或內(nèi)容是否正確。

如果使用mock，那么這個測試看起來就不太一樣了。


lass OrderInteractionTester. .. 
public void testorderSendsMail工fUnFilled() { 
Order order =new Order (TALISKER ，51）; 
Mock warehouse = mock(Warehouse.class）; 
Mock mailer = mock(MailService.class）; 
order.setMailer((Mailservice)mailer.proxy()); 
order.expects(once()).method ("hasInventory").withAnyArgument() 
.will(returnvalue(false)); 
order.fill（(Warehouse) warehouse.proxy() 
} 

在這兩個例子中，使用了stub和mock來代替真實的MailService對象。所不同的是，stub使用的是狀態(tài)確認的方法，而mock使用的是行為確認的方法。

想要在stub中使用狀態(tài)確認，需要在stub中增加額外的方法來協(xié)助驗證。因此stub實現(xiàn)了MailService但是增加了額外的測試方法。

微服務的集成測試

集成測試也稱組裝測試或聯(lián)合測試，可以說是單元測試的邏輯擴展。它最簡單的形式是把兩個已經(jīng)測試過的單元組合成一個組件，測試它們之間的接口。從使用的基本技術(shù)上來講，集成測試與單元測試在很多方面都很相似。程序員可以使用相同的測試運行器和構(gòu)建系統(tǒng)的支持。集成測試和單元測試一個比較大的區(qū)別在于，集成測試使用了相對較少的mock。

例如，在涉及數(shù)據(jù)訪問層的測試時，單元測試會簡單地模擬從后端數(shù)據(jù)庫返回的數(shù)據(jù)。而集成測試時，測試過程中則會采用一個真實的數(shù)據(jù)庫。數(shù)據(jù)庫是一個需要測試資源類型及能暴露問題的極好的例子。

在微服務架構(gòu)的集成測試中，程序員更加關(guān)注的是服務測試。

1.服務接口

在微服務的架構(gòu)中，服務接口大多以RESTfulAPI的形式加以暴露。REST是面向資源的，使用HTTP協(xié)議來完成相關(guān)通信，其主要的數(shù)據(jù)交換格式為JSON，當然也可以是XML、HTML、二進制文件等多媒體類型。資源的操作包括獲取、創(chuàng)建、修改和刪除資源，它們都可以用HTTP協(xié)議的GET、POST、PUT和DELETE方法來映射相關(guān)的操作。

在進行服務測試時，如果只想對單個服務功能進行測試，那么為了對其他相關(guān)的服務進行隔離，則需要給所有的外部服務合作者進行打樁。每一個下游合作者都需要一個打樁服務，然后在進行服務測試的時候啟動它們，并確保它們是正常運行的。程序員還需要對被測試服務進行配置，保證能夠在測試過程中連接到這些打樁服務。同時，為了模仿真實的服務，程序員還需要配置打樁服務，為被測試服務的請求發(fā)回響應。

下面是一個采用Spring 框架實現(xiàn)的關(guān)于“用戶車輛信息”測試接口的例子。

import org.junit.*; 
import org.junit.runner.*; 
import org.springframework.beans.factory.annotation.*; 
import org.springframework.boot.test.autoconfigure.web.servlet.*; 
import org.springframework.boot.test.mock.mockito.*; 
import static org.assertj.core.api.Assertions.*; 
import static org.mockito.BDDMockito.*; 
import static org.springframework.test.web.servlet.request.MockMvc 
RequestBuilders.*; 
import static org.springframework.test.web.servlet.result.MockMvc 
ResultMatchers.*; 
@RunWith(SpringRunner.class) 
@WebMvcTest(UserVehicleController.class) 
public class MyControllerTests{ 
@Autowired 
private MockMvc mvc; 
@MockBean 
private UserVehicleService userVehicleService; 
@Test 
public void testExample( throws Exception { 
given(this.userVehicleService.getVehicleDetails("sboot")) 
.willReturn(new VehicleDetails("BMW","X7"））; 
this.mvc.perform(get("/sboot/vehicle").accept(MediaType.TEXT_ 
PLAIN）） 
.andExpect(status().isok()).andExpect(content(). 
string("BMW x7"））; 
) 
} 
} 

在該測試中，程序員用mock模擬了/sboot/vehicle接口的數(shù)據(jù)VehicleDetails("BMW","X7")，并通過MockMvc來進行測試結(jié)果的判斷。

2.客戶端

有非常多的客戶端可以用于測試RESTful服務。可以直接通過瀏覽器來進行測試，如在本書前面介紹過的RESTClient、Postman等。很多應用框架本身提供了用于測試RESTful API的類庫，如Java平臺的像Spring的RestTemplate 和像Jersey的Client API等，.NET平臺的RestSharp ( http:1restsharp.org）等。也有一些獨立安裝的REST測試軟件，如SoapUI ( ttps:/www.soapui.org )，當然最簡潔的方式莫過于使用cURL在命令行中進行測試。

下面是一個測試Elasticsearch是否啟動成功的例子,可以在終端直接使用cURL來執(zhí)行以下操作。

scurl 'http://localhost:9200/?pretty' 

cURL提供了一種將請求提交到Elasticsearch的便捷方式，然后可以在終端看到與下面類似的響應。

"cluster name": "elasticsearch", 
"cluster uuid" :"uqcQAMTtTIO6CanROYgveQ", 
"version":{ 
"number": "5.5.0"， 
"build_hash":"260387d" , 
"build_date":"2017-06-30T23:16:05.735Z""， 
"build_snapshot" :false, 
"lucene version":"6.6.O" 
}， 
"tagline":"You Know, for Search" 
} 

微服務的系統(tǒng)測試

引入微服務架構(gòu)之后，隨著微服務數(shù)量的增多，測試用例也隨之增多，測試工作也越來越依賴于測試的自動化。Maven或Gradle等構(gòu)建工具，都會將測試納入其生命周期內(nèi)，所以，只要寫好相關(guān)的單元測試用例，單元測試及集成測試就能在構(gòu)建過程中自動執(zhí)行，構(gòu)建完成之后，也可以馬上看到測試報告。

在系統(tǒng)測試階段，除了自動化測試外，手工測試仍然是無法避免的。Docker等容器為自動化提供了基礎(chǔ)設施，也為手工測試帶來了新的變革。

在基于容器的持續(xù)部署流程中，軟件會經(jīng)歷最終被打包成容器鏡像，從而可以部署到任意環(huán)境而無須擔心工作變量不一致所帶來的問題。進入部署階段意味著集成測試及單元測試都已經(jīng)通過了。

但這顯然并不是測試的全部，很多測試必須要在上線部署后才能進行，如一些非功能性的需求。

同時，用戶對于需求的期望是否與最初的設計相符，這個也必須要等到產(chǎn)品上線后才能驗證。所以，上線后的測試工作仍然是非常重要的。

1.冒煙測試

所謂冒煙測試，是指對一個新編譯的軟件版本在需要進行正式測試前，為了確認軟件基本功能是否正常而進行的測試。軟件經(jīng)過冒煙測試之后，才會進行后續(xù)的正式測試工作。冒煙測試的執(zhí)行者往往是版本編譯人員。

由于冒煙測試耗時短，并且能夠驗證軟件大部分主要的功能，因此在進行CI/CD每日構(gòu)建過程中，都會執(zhí)行冒煙測試。

⒉藍綠部署

藍綠部署通過部署新舊兩套版本來降低發(fā)布新版本的風險。其原理是，當部署新版本后（綠部署），老版本（藍部署）仍然需要保持在生產(chǎn)環(huán)境中可用一段時間。如果新版本上線，測試沒有問題后，那么所有的生產(chǎn)負荷就會從舊版本切換到新版本中。

以下是一個藍綠部署的例子。其中，vl代表的是服務的舊版本（藍色），v2代表的是新版本（綠色），如圖4-2所示。

這里面有以下幾個注意事項。

• 藍綠兩個部署環(huán)境是一致的，并且兩者應該是完全隔離的(可以是不同的主機或不同的容器）。
• 藍綠環(huán)境兩者之間有一個類似于切換器的裝置用于流量的切換，如可以是負載均衡器、反向代理或路由器。
• 新版本（綠部署）測試失敗后，可以馬上回溯到舊版本。
• 藍綠部署經(jīng)常與冒煙測試結(jié)合使用。
• 實施藍綠部署，整個過程是自動化處理的，用戶并不會感覺到任何宕機或服務重啟。

3.A/B測試

A/B測試是一種新興的軟件測試方法。A/B測試本質(zhì)上是將軟件分成A、B兩個不同的版本來進行分離實驗。AB測試的目的在于通過科學的實驗設計、采樣樣本、流量分割與小流量測試等方式來獲得具有代表性的實驗結(jié)論，并確保該結(jié)論在推廣到全部流量之前是可信賴的。例如，在經(jīng)過一段時間的測試后，實驗結(jié)論顯示，B版本的用戶認可度較高，于是，線上系統(tǒng)就可以更新到B版本上來。

4.金絲雀發(fā)布

金絲雀發(fā)布是增量發(fā)布的一種類型，它的執(zhí)行方式是在原有軟件生產(chǎn)版本可用的情況下，同時部署一個新的版本。這樣，部分生產(chǎn)流量就會引流到新部署的版本，從而來驗證系統(tǒng)是否按照預期的內(nèi)容執(zhí)行。這些預期的內(nèi)容可以是功能性的需求，也可以是非功能性的需求。例如，程序員可以驗證新部署的服務的請求響應時間是否在1秒以內(nèi)。

如果新版本沒有達到預期的效果，那么可以迅速回溯到舊版本上去。如果達到了預期的效果，那么可以將生產(chǎn)流量更多地引流到新版本上去。

金絲雀發(fā)布與A/B測試非常類似，兩者往往結(jié)合使用。而與藍綠部署的差異在于，金絲雀發(fā)布新舊版本并存的時間更長久一些。