簡化微服務(wù)的測試拾氓，設(shè)計(jì)思路呈現(xiàn)。前面有一篇文章《如何構(gòu)建微服務(wù)架構(gòu)》底哥，其中介紹了微服務(wù)架構(gòu)生態(tài)的很多方面咙鞍，本文是從其中引發(fā)出來的一個(gè)話題。
00 測試概述
軟件測試的目的是趾徽，保證程序員編寫的程序達(dá)到他的預(yù)期結(jié)果续滋，保證發(fā)布的產(chǎn)品是產(chǎn)品經(jīng)理（產(chǎn)品設(shè)計(jì)人員）的真實(shí)意愿表現(xiàn)。這些都需要軟件測試來監(jiān)督實(shí)現(xiàn)孵奶，避免將有缺陷的軟件發(fā)布到生產(chǎn)環(huán)境疲酌。
軟件測試種類有很多，粗略的劃分為：單元測試了袁、集成測試朗恳、端到端測試。從其他的角度來說早像，又有回歸測試僻肖、自動(dòng)化測試、性能測試等卢鹦。當(dāng)我們項(xiàng)目進(jìn)行服務(wù)化改造之后，尤其是進(jìn)行了微服務(wù)設(shè)計(jì)之后，測試的工作就更加困難了冀自。很多項(xiàng)目都是以獨(dú)立服務(wù)的形式發(fā)布的揉稚，這些服務(wù)的發(fā)布怎么能保證是進(jìn)行了充分測試了的？測試的入口應(yīng)該是哪里熬粗？是直接進(jìn)行集成測試搀玖，還是做端到端的用戶體驗(yàn)測試，好像都不太合適驻呐。按照分層測試的思想灌诅，于是就有服務(wù)測試的話題。服務(wù)的測試?yán)碚摵推渌臏y試應(yīng)該是大體類似的含末，其中比較特殊的是猜拾，如何提供方便快捷的服務(wù)測試入口。
01 微服務(wù)測試
目前常見的微服務(wù)設(shè)計(jì)都是會(huì)采用一些分布式服務(wù)框架佣盒，這些框架從通信協(xié)議上分有兩種：
- 公共標(biāo)準(zhǔn)的HTTP協(xié)議的挎袜；
- 基于私有的RPC調(diào)用協(xié)議。
第一種http協(xié)議的微服務(wù)接口肥惭，比如使用spring boot開發(fā)的服務(wù)盯仪，這樣的服務(wù)的測試工具應(yīng)該有很多，postman是一個(gè)常用的工具蜜葱。如果想為測試人員做點(diǎn)事情的話全景，可以根據(jù)服務(wù)注冊中心做個(gè)所有服務(wù)的列表。
第二種以私有協(xié)議暴露的服務(wù)的測試是非常麻煩的牵囤，也是本文主要討論的解決辦法蚪燕。最初我們?yōu)榱舜蛲ǚ?wù)接口和測試人員之間的屏障，為了能讓測試人員方便地測試到RPC協(xié)議的服務(wù)接口奔浅，我們?yōu)槊總€(gè)服務(wù)接口寫了一個(gè)客戶端馆纳，將其轉(zhuǎn)換為http協(xié)議暴露，這是一種解決辦法汹桦。但是鲁驶，這樣無形中增加了很多開發(fā)人員的工作量，而且測試服務(wù)的質(zhì)量還依賴于客戶端編寫的質(zhì)量舞骆，明顯的是費(fèi)力不討好工作钥弯。
作為程序員，懶惰是其本性督禽，于是就想辦法改變這種微服務(wù)測試苦難的現(xiàn)狀脆霎。怎么能構(gòu)建一個(gè)項(xiàng)目，它能提供所有服務(wù)的客戶端狈惫，新開發(fā)一個(gè)服務(wù)只需要做極少的工作就能生成一個(gè)服務(wù)的測試客戶端睛蛛，快速的將接口提交測試？這是我們下面討論的問題（開始造輪子）。
02 基于RPC協(xié)議的微服務(wù)測試的設(shè)計(jì)思路
微服務(wù)設(shè)計(jì)的項(xiàng)目一般都是基于分布式服務(wù)的注冊和發(fā)現(xiàn)機(jī)制的忆肾，所有的服務(wù)都是在一個(gè)注冊中心集中存儲(chǔ)的荸频。而且一般的分布式服務(wù)框架都支持豐富的服務(wù)調(diào)用方式，有基于Spring xml配置的客冈、Spring 注解旭从、和API等調(diào)用方法，為我們編寫公共的服務(wù)測試工具提供了便利的條件场仲。
我們設(shè)計(jì)的服務(wù)測試工具在整個(gè)分布式服務(wù)架構(gòu)中所扮演的角色就是如下圖所示和悦，是所有的服務(wù)提供者的公共客戶端。
根據(jù)上述服務(wù)測試工具的定位渠缕，我們開始設(shè)計(jì)該測試工具鸽素，主要的宗旨是：
- 簡化測試人員工作。
- 簡化服務(wù)開發(fā)人員工作褐健。
- 保證測試質(zhì)量付鹿。
下面描述一下我們的微服務(wù)測試工具的設(shè)計(jì)思路，主要分為如下幾步：
第一步是從服務(wù)注冊中心獲取到所有的服務(wù)接口蚜迅，并將這些接口可視化地展示給測試人員舵匾，測試人員可以選擇需要測試的服務(wù)接口。
第二步就是將服務(wù)的每個(gè)接口以一種易讀易用的方式暴露給測試人員谁不，目前能想到的就是將接口的請求參數(shù)轉(zhuǎn)化為xml或者json的形式展示給測試人員坐梯，方便他們填寫測試用例。我們采用的是xml格式刹帕，示例如下：
<?xml version="1.0" encoding="UTF-8"?>
<java.util.List>
<com.unicom.front.model.MucfcBussOrderRequest>
<systemCode>0</systemCode>
<flowNo>0</flowNo>
<charSet>0</charSet>
<requestTime>0</requestTime>
<signType>0</signType>
<signMsg>0</signMsg>
<operatorName>0</operatorName>
<operatorId>0</operatorId>
<orderId>0</orderId>
<woAccountId>0</woAccountId>
<serialNumber>0</serialNumber>
<certType>0</certType>
<certCode>0</certCode>
<expandAttribute>
<entry>
<java.lang.Object>0</java.lang.Object>
<java.lang.Object>0</java.lang.Object>
</entry>
<entry>
<java.lang.Object>0</java.lang.Object>
<java.lang.Object>0</java.lang.Object>
</entry>
</expandAttribute>
</com.unicom.front.model.MucfcBussOrderRequest>
</java.util.List>
第三步吵血，將測試人員提交的服務(wù)測試請求中的參數(shù)轉(zhuǎn)換為xml報(bào)文參數(shù)轉(zhuǎn)換為請求對象，以便使用統(tǒng)一的API接口偷溺，調(diào)用到后端服務(wù)蹋辅。
第四步，發(fā)起服務(wù)調(diào)用挫掏，這一步一般使用API的方式來調(diào)用服務(wù)侦另，這是因?yàn)槲覀冏龅墓ぞ呤墙y(tǒng)一的服務(wù)調(diào)用入口，能夠根據(jù)請求參數(shù)動(dòng)態(tài)地調(diào)用不同的服務(wù)尉共。
第五步褒傅，將服務(wù)的響應(yīng)參數(shù)再次轉(zhuǎn)換為xml或者json展示給測試人員查看，這時(shí)候可以順便返回一些調(diào)用耗時(shí)等附加數(shù)據(jù)袄友，幫助測試人員判斷服務(wù)的效率等情況殿托。
03 微服務(wù)測試拓展功能
遵循著我們設(shè)計(jì)這個(gè)服務(wù)測試系統(tǒng)的宗旨，盡可能的簡化一切服務(wù)測試過程剧蚣。其中還有一些服務(wù)測試基礎(chǔ)功能之外的拓展功能：
- 有規(guī)律（規(guī)則）請求參數(shù)的自動(dòng)化生成支竹，例如請求流水號旋廷、請求時(shí)間、手機(jī)號唾戚、身份證號等柳洋，減少測試人員的填寫參數(shù)時(shí)間待诅。
- 后臺保存服務(wù)測試的請求參數(shù)和響應(yīng)參數(shù)叹坦，方便回歸測試。
- 實(shí)現(xiàn)了回歸測試卑雁，在服務(wù)代碼有變動(dòng)之后募书，可根據(jù)保存的請求參數(shù)進(jìn)行回歸測試，并且可以和之前的響應(yīng)參數(shù)進(jìn)行對比测蹲，以便驗(yàn)證是否影響到當(dāng)前測試服務(wù)接口莹捡。
- 服務(wù)的并發(fā)測試，在提交測試請求的時(shí)候可以指定每個(gè)服務(wù)測試請求的測試次數(shù)扣甲，這時(shí)后臺會(huì)模擬多線程調(diào)用服務(wù)篮赢，可實(shí)現(xiàn)對服務(wù)接口的并發(fā)測試。
- 多個(gè)測試環(huán)境自由切換琉挖，通過選擇不同環(huán)境的注冊中心赃额，來實(shí)現(xiàn)其他環(huán)境的測試这揣，如集成、系統(tǒng)等環(huán)境。
- 服務(wù)測試出現(xiàn)異常的時(shí)候孽水，將異常堆棧信息直接展示在測試人員面前，方便他排查問題誊册。
- 實(shí)現(xiàn)定時(shí)回歸測試波岛，有時(shí)候我們的測試環(huán)境也需要保持一定的穩(wěn)定性，因?yàn)榻?jīng)常會(huì)有別的系統(tǒng)發(fā)起聯(lián)調(diào)測試险耀。定時(shí)回歸測試弄喘，既能及時(shí)發(fā)現(xiàn)后端系統(tǒng)對我們服務(wù)的影響，又能保證我們服務(wù)的持續(xù)穩(wěn)定地對外提供服務(wù)甩牺。
- 開發(fā)公共的mock測試服務(wù)（未實(shí)現(xiàn)）蘑志，有些時(shí)間避免后端未開發(fā)完成的服務(wù)耽誤我們服務(wù)的測試，有時(shí)候也需要mock掉后端服務(wù)柴灯，這看起來更像是單元測試卖漫，但是實(shí)際的開發(fā)測試環(huán)境是復(fù)雜的，這種情況也是時(shí)常發(fā)生的赠群。但是每個(gè)服務(wù)都要單獨(dú)開發(fā)的話羊始，又有些麻煩，于是就想設(shè)計(jì)一個(gè)萬能的mock服務(wù)查描。
04 結(jié)束語
上面的介紹的微服務(wù)測試工具和其中一些思想突委，都是我廠幾個(gè)同事一起討論實(shí)踐過程柏卤，在此分享出來希望能對各位有幫助，最好能減少我們這類程序員們的一些疑惑匀油。
作為一個(gè)開發(fā)人員說起測試顯得有些不夠?qū)I(yè)缘缚，如果有哪些地方描述的不合適的，請各位測試專業(yè)大神指點(diǎn)敌蚜，歡迎拍磚桥滨。
