持續(xù)演進(jìn)的接口自動(dòng)化測(cè)試方案
部門：美業(yè)測(cè)試
接口自動(dòng)化測(cè)試是個(gè)老生常談的話題，基本上每個(gè)測(cè)試團(tuán)隊(duì)都會(huì)涉及，市面上大部分文章會(huì)從如何設(shè)計(jì)框架去講解。但是這一次我想回歸自動(dòng)化的根本價(jià)值，從持續(xù)演進(jìn)的解決方案出發(fā)，講解有贊測(cè)試團(tuán)隊(duì)的心路歷程和對(duì)于接口自動(dòng)化的理解，歡迎交流。
一、價(jià)值
有贊測(cè)試團(tuán)隊(duì)肩負(fù)的一個(gè)使命是：打造高效且可靠的產(chǎn)品交付能力。為了完成這個(gè)使命，我們會(huì)借助各種工具，而接口自動(dòng)化就是其中的一把利器。
如何讓接口自動(dòng)化的價(jià)值最大化，首先需要想清楚如何去評(píng)估接口自動(dòng)化的質(zhì)量，有贊測(cè)試團(tuán)隊(duì)是這樣思考的：
最大化提升回歸測(cè)試的效率
消滅更多的測(cè)試盲點(diǎn)
接下來(lái)介紹的持續(xù)演進(jìn)的方案都是基于這兩個(gè)方向去努力的
為了讓大家更好地理解我們的演進(jìn)思路，我先簡(jiǎn)單介紹一下我們業(yè)務(wù)的服務(wù)器架構(gòu)，接口自動(dòng)化的測(cè)試目標(biāo)。
客戶端：渠道較多，分Web、H5、小程序、APP、Pad，通過(guò)youzan.com域名請(qǐng)求，統(tǒng)一接入到公司網(wǎng)關(guān)層Nginx集群，反向代理轉(zhuǎn)發(fā)到對(duì)應(yīng)業(yè)務(wù)的Web服務(wù)器。
Web服務(wù)器：這一層是Nodejs實(shí)現(xiàn)，涉及邏輯主要是路由轉(zhuǎn)發(fā)、登陸態(tài)校驗(yàn)。
后端服務(wù)器：電商系通用的Java微服務(wù)架構(gòu)，API1和API2是接入層，涉及邏輯主要是請(qǐng)求轉(zhuǎn)發(fā)和非業(yè)務(wù)相關(guān)的通用處理。Service1這一層才是真正的業(yè)務(wù)邏輯層，大概有30多個(gè)微服務(wù)應(yīng)用，互相之間使用dubbo協(xié)議通信。
所以，接口自動(dòng)化面臨2種選型：
模擬客戶端進(jìn)行HTTP請(qǐng)求，優(yōu)勢(shì)是能快速覆蓋用戶場(chǎng)景，劣勢(shì)是需要構(gòu)建大量的數(shù)據(jù)，后期維護(hù)成本高。
基于dubbo協(xié)議進(jìn)行請(qǐng)求，優(yōu)勢(shì)是能Mock依賴數(shù)據(jù)，劣勢(shì)是前期腳本編寫成本高，且不支持預(yù)發(fā)執(zhí)行。
該如何選擇呢？小朋友才做選擇題，成年人我們都要了，兩者互相結(jié)合，揚(yáng)長(zhǎng)避短。
三、如何提升回歸測(cè)試效率
這里需要從三個(gè)階段來(lái)看：回歸測(cè)試前、回歸測(cè)試中、回歸測(cè)試后。
回歸測(cè)試前，我們通過(guò)2個(gè)事情來(lái)提升效率：
1、精準(zhǔn)定位自動(dòng)化測(cè)試覆蓋范圍
最原始的范圍依據(jù)是根據(jù)功能測(cè)試用例來(lái)，但這不是客觀合理的，我們從對(duì)外暴露的接口數(shù)和后端Service層應(yīng)用的代碼覆蓋率去評(píng)估。
我們基于JaCoCo進(jìn)行二次開(kāi)發(fā)實(shí)現(xiàn)增量代碼覆蓋率統(tǒng)計(jì)，可以拿到每次執(zhí)行自動(dòng)化后的指令級(jí)覆蓋(Instructions,C0coverage)，分支（Branches,C1coverage）、圈復(fù)雜度(Cyclomatic Complexity)、行覆蓋(Lines)、方法覆蓋(non-abstract methods)、類覆蓋(classes)。通過(guò)這些信息我們可以對(duì)我們的自動(dòng)化進(jìn)行查漏補(bǔ)缺。
通過(guò)解析前端路由文件，獲取線上正在使用的接口數(shù)，作為基準(zhǔn)，對(duì)比自動(dòng)化執(zhí)行請(qǐng)求的接口數(shù)，可以快速告訴各個(gè)模塊負(fù)責(zé)人覆蓋盲點(diǎn)。
可以自定義指定線程池，例如大小，超時(shí)等等 降低資源消耗：通過(guò)重用已經(jīng)創(chuàng)建的線程來(lái)降低線程創(chuàng)建和銷毀的消耗
每一項(xiàng)測(cè)試數(shù)據(jù)的清理，都是一個(gè)任務(wù)類，所有的任務(wù)類都繼承了一個(gè)抽象類，在action方法里定義了數(shù)據(jù)清理的接口請(qǐng)求 在每次創(chuàng)建數(shù)據(jù)后，實(shí)例化任務(wù)類，然后添加到隊(duì)列里 所有測(cè)試用例執(zhí)行完成后，afterTest里遍歷隊(duì)列依次數(shù)據(jù)清理
采用這個(gè)方式的優(yōu)勢(shì)：
自動(dòng)化測(cè)試任務(wù)中途異常退出結(jié)束了，也可以清理掉已創(chuàng)建的數(shù)據(jù)
支持多份的同樣數(shù)據(jù)清理，數(shù)據(jù)之間不受影響
無(wú)需用完立刻刪除，統(tǒng)一清理，且支持并發(fā)，高效
四、消滅更多的測(cè)試盲點(diǎn)
在對(duì)應(yīng)的后臺(tái)應(yīng)用上找到購(gòu)買商品的Topic A 在BCP平臺(tái)建立一個(gè)監(jiān)聽(tīng)A廣播消息的Channel B 消費(fèi)A的廣播消息時(shí)觸發(fā)接口請(qǐng)求，查詢買家的權(quán)益信息，檢查是否對(duì)于的優(yōu)惠券信息 接口請(qǐng)求回來(lái)的數(shù)據(jù)和A廣播發(fā)出的消息體，作為對(duì)賬規(guī)則的數(shù)據(jù)來(lái)源 在規(guī)則庫(kù)創(chuàng)建好對(duì)賬規(guī)則，進(jìn)行線上每一筆數(shù)據(jù)的校驗(yàn)
Agent包括阿里開(kāi)源的Sandbox和我們開(kāi)發(fā)的插件，插件里實(shí)現(xiàn)了流量抓取、保存和回放的邏輯。以Java Agent的方式掛載到生產(chǎn)環(huán)境的機(jī)器，就可以開(kāi)始采集流量了 一次流量錄制包括一次入口調(diào)用和若干次子調(diào)用（Dubbo、NSQ、MyBatis、Redis、HBase），通過(guò)traceid將入口調(diào)用和子調(diào)用綁定成一次完整的記錄，監(jiān)聽(tīng)BEFORE、RETRUN、THROW事件機(jī)制獲取每次調(diào)用的傳參和返回 
每一個(gè)完整流量的traceid和調(diào)用鏈路，會(huì)生成一個(gè)MD5值，判斷是否有重復(fù)，若有，測(cè)試用例熱度+1，若無(wú)，創(chuàng)建新的測(cè)試用例保存 測(cè)試環(huán)境部署被測(cè)代碼，也掛載上Agent，創(chuàng)建任務(wù)執(zhí)行線上流量保存下來(lái)的測(cè)試用例，支持Mock dubbo consumer和中間件調(diào)用 執(zhí)行返回的response和線上采集的進(jìn)行Json diff，分析差異化判斷是否是BUG。下圖是我們項(xiàng)目實(shí)際的使用流程：
線上流量采集，還原真實(shí)用戶場(chǎng)景，覆蓋率高
自動(dòng)分析生成測(cè)試用例，省去手動(dòng)編寫和后期維護(hù)工作，大大提升效率
支持自定義Mock，將后端服務(wù)隔離，進(jìn)行模塊化測(cè)試，代替單元測(cè)試的完美方案
