李艷麗 張宗勇 馮捷 李志輝

摘要：隨著互聯(lián)網(wǎng)金融的發(fā)展，金融業(yè)務(wù)變得更加復(fù)雜，產(chǎn)品功能迭代更加快速.為了支持業(yè)務(wù)的發(fā)展，金融應(yīng)用開始進(jìn)行支持Dubbo協(xié)議的開發(fā).現(xiàn)有的接口測(cè)試框架和工具在支持Dubbo協(xié)議、多人協(xié)作及測(cè)試用例維護(hù)及數(shù)據(jù)分析上都存在問題：首先，沒有很好的工具支持Dubbo協(xié)議的測(cè)試，已有的Dubbo測(cè)試框架無法很好地推廣;其次，復(fù)雜業(yè)務(wù)會(huì)涉及多個(gè)應(yīng)用，目前的框架很少考慮多系統(tǒng)間的自動(dòng)化配合;再次，單機(jī)版自動(dòng)化測(cè)試工具或純編碼方式的自動(dòng)化測(cè)試框架不利于多人協(xié)作編寫自動(dòng)化測(cè)試用例及腳本的維護(hù);最后，數(shù)據(jù)分析一般是查看單個(gè)子系統(tǒng)測(cè)試用例的執(zhí)行結(jié)果，無法很好地對(duì)數(shù)據(jù)進(jìn)行全局分析.為了更好地管理大批量用例及支持多子系統(tǒng)版本迭代，在已有老框架基礎(chǔ)上，使用分布式技術(shù)設(shè)計(jì)并實(shí)現(xiàn)了一個(gè)靈活的可視化的Dubbo接口自動(dòng)化測(cè)試平臺(tái)：基于界面操作，提供基于可視化的數(shù)據(jù)驅(qū)動(dòng)及關(guān)鍵字驅(qū)動(dòng)方式，支持編寫復(fù)雜測(cè)試用例，并基于接口解析的方式，自動(dòng)生成測(cè)試用例.詳細(xì)表述了可視化的Dubbo接口測(cè)試平臺(tái)的架構(gòu)、用例管理及用例執(zhí)行;展示了新平臺(tái)與老框架的耗時(shí)對(duì)比、用例增長(zhǎng)對(duì)比和新平臺(tái)日常自動(dòng)化執(zhí)行情況.

關(guān)鍵詞：可視化; 分布式; 自動(dòng)化測(cè)試平臺(tái);接口自動(dòng)解析;用例管理; 用例執(zhí)行; 負(fù)載均衡

中圖分類號(hào)：TP399

文獻(xiàn)標(biāo)志碼：A

DOI： 10.3969/j.issn.1000-5641.2019.04.012

0 引言

隨著互聯(lián)網(wǎng)金融的發(fā)展，金融業(yè)務(wù)變得更加復(fù)雜，金融產(chǎn)品功能迭代更加快速[1].為了保證應(yīng)用功能的質(zhì)量，金融機(jī)構(gòu)都在探索如何更好地做自動(dòng)化測(cè)試[2].根據(jù)業(yè)界標(biāo)準(zhǔn)的金字塔模型，接口服務(wù)占32.63%，對(duì)比UI （User Interface）自動(dòng)化，接口自動(dòng)化測(cè)試性價(jià)比更高.在互聯(lián)網(wǎng)企業(yè)中，目前使用最廣泛的為RPC[3]（Remote Procedure Call，遠(yuǎn)程過程調(diào)用）協(xié)議Dubbo[4].對(duì)于Dubbo服務(wù)，迫切需要方便的自動(dòng)化測(cè)試工具來對(duì)Dubbo協(xié)議接口進(jìn)行測(cè)試，以提高工作效率.目前主要通過兩種方式來測(cè)試Dubbo接口：第一種是在已有測(cè)試工具上做擴(kuò)展，即在擴(kuò)展路徑下放入需要的jar包，這樣測(cè)試人員可以通過編寫腳本或簡(jiǎn)單界面的方式來編寫自動(dòng)化測(cè)試用例.但這種方式一般是單機(jī)版，不利于多人協(xié)作開發(fā)及自動(dòng)化測(cè)試用例的整合，且編碼工作量巨大可維護(hù)性差.第二種方式是開發(fā)專門的自動(dòng)化測(cè)試框架，使用編碼的方式進(jìn)行自動(dòng)化，本文測(cè)試團(tuán)隊(duì)目前使用的就是這種方式，即測(cè)試人員搭建開發(fā)環(huán)境，使用自動(dòng)化框架開發(fā)自動(dòng)化測(cè)試用例.但使用這種方式，有兩個(gè)問題，第一，這種自動(dòng)化方式很難推廣普及.因?yàn)獒槍?duì)不同網(wǎng)段的測(cè)試環(huán)境，自動(dòng)化開發(fā)環(huán)境需要同步搭建，另外每位自動(dòng)化測(cè)試人員都需要搭建對(duì)應(yīng)的自動(dòng)化開發(fā)環(huán)境，對(duì)于功能測(cè)試任務(wù)繁重的測(cè)試人員，時(shí)間上不能保證.第二，數(shù)據(jù)相對(duì)分散，第一種自動(dòng)化測(cè)試方式也存在同樣的這個(gè)問題.自動(dòng)化測(cè)試代碼編寫好之后，一般通過jenkins來定時(shí)執(zhí)行，并且需要通過開發(fā)新的平臺(tái)來搜集jenkins執(zhí)行數(shù)據(jù)，測(cè)試人員需要在不同的平臺(tái)查看需要的信息.

基于上述原因，本文設(shè)計(jì)并實(shí)現(xiàn)了一種新的針對(duì)Dubbo協(xié)議的接口自動(dòng)化測(cè)試平臺(tái)，平臺(tái)基于Web界面操作，提供基于可視化的數(shù)據(jù)驅(qū)動(dòng)及關(guān)鍵字驅(qū)動(dòng)方式，支持編寫復(fù)雜測(cè)試用例，并基于接口解析方式，自動(dòng)生成測(cè)試用例.通過統(tǒng)一的可視化方式編寫和調(diào)試測(cè)試用例，測(cè)試用戶能很方便地完成測(cè)試用例的編寫、執(zhí)行及測(cè)試結(jié)果的查看：失敗原因分析可以對(duì)失敗的原因進(jìn)行分類，讓測(cè)試人員更好地發(fā)現(xiàn)用例編寫和代碼問題.

從多應(yīng)用角度出發(fā)，目前接口測(cè)試都側(cè)重于單應(yīng)用系統(tǒng)的自動(dòng)化，很難支持系統(tǒng)間的自動(dòng)化.本文新的Dubbo接口測(cè)試平臺(tái)（簡(jiǎn)稱新平臺(tái)）通過子系統(tǒng)間依賴方式，支持一個(gè)用例管理中包含多個(gè)業(yè)務(wù)子系統(tǒng)接口的調(diào)用，從而可以測(cè)試復(fù)雜業(yè)務(wù)功能鏈路：工具集成模塊，可以方便引入并使用外部類.

除此之外本文新平臺(tái)還提供了數(shù)據(jù)分析功能.詳細(xì)的執(zhí)行日志、多種類型的報(bào)表，能方便地讓測(cè)試人員查看自動(dòng)化執(zhí)行數(shù)據(jù)及代碼覆蓋率，方便分析測(cè)試用例新增及修改狀況：報(bào)表導(dǎo)出功能能方便在本地查看并整合數(shù)據(jù).

綜上所述，本文貢獻(xiàn)點(diǎn)總結(jié)如下.

（1）設(shè)計(jì)并實(shí)現(xiàn)一種針對(duì)Dubbo協(xié)議的分布式接口自動(dòng)化測(cè)試平臺(tái)，通過可視化方式支持Dubbo協(xié)議的自動(dòng)化測(cè)試，使自動(dòng)化測(cè)試更容易普及.

（2）可視化的方式支持?jǐn)?shù)據(jù)驅(qū)動(dòng)、順序測(cè)試用例上下文串聯(lián)、多子系統(tǒng)間測(cè)試用例串聯(lián)和使用外部封裝的工具類.

（3）測(cè)試用例通過平臺(tái)方式集中管理，方便迭代和維護(hù);支持?jǐn)?shù)據(jù)分析，包括用例執(zhí)行情況及代碼覆蓋率，方便測(cè)試人員根據(jù)質(zhì)量報(bào)告增加測(cè)試用例和測(cè)試場(chǎng)景覆蓋，減少漏測(cè).

1 相關(guān)工作

自動(dòng)化測(cè)試是把以人為驅(qū)動(dòng)的測(cè)試行為轉(zhuǎn)化為機(jī)器執(zhí)行的一種過程.通常在測(cè)試用例設(shè)計(jì)完成并通過評(píng)審之后，由測(cè)試人員根據(jù)測(cè)試用例中描述的過程按步驟執(zhí)行測(cè)試，并將得到的實(shí)際結(jié)果與期望的結(jié)果進(jìn)行比較.自動(dòng)化測(cè)試使這個(gè)過程通過工具或框架的方式由機(jī)器自動(dòng)運(yùn)行，從而在版本迭代時(shí)，自動(dòng)執(zhí)行重復(fù)的手工測(cè)試，縮短測(cè)試時(shí)間，提高測(cè)試效率.按照分層的自動(dòng)化測(cè)試概念，自動(dòng)化測(cè)試分為UI測(cè)試、集成接口測(cè)試、單元測(cè)試這3層.UI測(cè)試是對(duì)UI層的功能進(jìn)行測(cè)試.集成接口測(cè)試關(guān)注的是一個(gè)函數(shù)、類（方法）提供的接口是否可靠.單元測(cè)試關(guān)注的是代碼的實(shí)現(xiàn)邏輯.分層模型為倒金字塔形，表示不同階段所投入自動(dòng)化測(cè)試的比例，越往上層，維護(hù)成本越高.正常的產(chǎn)品測(cè)試行為為單元測(cè)試、接口測(cè)試及UI測(cè)試.對(duì)比接口，UI層的元素會(huì)時(shí)常會(huì)發(fā)生改變.因而接口自動(dòng)化測(cè)試是相對(duì)有效的一種自動(dòng)化方式.

已有的典型的工具為SoapUI[5]. SoapUI主要關(guān)注SOAP[6]、HTTP REST的服務(wù)測(cè)試.對(duì)于Dubbo[4，7]的測(cè)試，SoapUI支持可擴(kuò)展方式，在SoapUI的擴(kuò)展路徑下放入Dubbo的jar包，然后通過編寫腳本方式發(fā)送請(qǐng)求.SoapUI是單機(jī)版本，代碼導(dǎo)出方式為xml文件，這種方式在多人協(xié)作開發(fā)及測(cè)試用例整合方面很繁瑣.Jmeter[8]可以測(cè)試接口，但主要用于性能測(cè)試，其編寫Dubbo測(cè)試用例的方式與SoapUI相同，通過可擴(kuò)展方式支持.LoaderRunner[9]也是通過擴(kuò)展方式支持，測(cè)試人員需要掌握函數(shù)編寫腳本，其也是用于性能測(cè)試，但需要付費(fèi)才能使用.目前開源的測(cè)試框架大都是支持HTTP[10]協(xié)議的自動(dòng)化測(cè)試，通過編碼方式來編寫自動(dòng)化測(cè)試用例.開源自動(dòng)化測(cè)試平臺(tái)Phoenix Framework[11]，提供了HTTP及mobile自動(dòng)化測(cè)試方法，針對(duì)接口測(cè)試，請(qǐng)求參數(shù)及請(qǐng)求發(fā)送都需要編碼實(shí)現(xiàn)，測(cè)試人員需要搭建測(cè)試環(huán)境才能做接口測(cè)試.WTAF[12]基于IBM開源框架STAF（SoftwareTest Automation Framework）[13]提出了一個(gè)模型，引入CVS Server維護(hù)測(cè)試用例變更并調(diào)用STAF的服務(wù)，使測(cè)試用例分布式執(zhí)行，測(cè)試人員需要通過代碼編寫測(cè)試用例，并通過xml設(shè)定用例執(zhí)行規(guī)則，通過STAF的接口來調(diào)用服務(wù)包編寫好的腳本，這個(gè)框架強(qiáng)依賴STAF，借鑒了腳本的分布式執(zhí)行，但并沒有很好的可視化頁(yè)面輔助測(cè)試人員方便地編寫調(diào)試測(cè)試用例.

基于數(shù)據(jù)驅(qū)動(dòng)的自動(dòng)化測(cè)試框架，其基本思想是將測(cè)試案例和測(cè)試數(shù)據(jù)分開，對(duì)于每一個(gè)測(cè)試用例，可以根據(jù)不同的測(cè)試數(shù)據(jù)產(chǎn)生不同的執(zhí)行結(jié)果.此種方式在初始建立測(cè)試數(shù)據(jù)時(shí)耗費(fèi)巨大，同時(shí)要求測(cè)試人員具備專業(yè)的編程功底，而且在處理復(fù)雜業(yè)務(wù)的自動(dòng)化測(cè)試時(shí)，需要編寫大量的代碼來保證測(cè)試用例的關(guān)聯(lián).關(guān)鍵字驅(qū)動(dòng)的自動(dòng)化測(cè)試則擴(kuò)展了數(shù)據(jù)驅(qū)動(dòng)的自動(dòng)化測(cè)試，用關(guān)鍵字代替測(cè)試數(shù)據(jù)來控制測(cè)試案例的執(zhí)行，減少了維護(hù)案例的開銷[14].不同格式的測(cè)試數(shù)據(jù)和結(jié)果數(shù)據(jù)都統(tǒng)一成Json[15]格式，方便處理和結(jié)果校驗(yàn)[16].

互聯(lián)網(wǎng)企業(yè)在多元化業(yè)務(wù)需求下，子系統(tǒng)中存在較多的共享業(yè)務(wù)，企業(yè)一般會(huì)選擇服務(wù)化架構(gòu)來搭建業(yè)務(wù)子系統(tǒng).服務(wù)化的核心是RPC，由客戶端和服務(wù)端這兩部分組成，服務(wù)提供方所提供的方法需要由服務(wù)調(diào)用放以網(wǎng)絡(luò)的形式進(jìn)行遠(yuǎn)程調(diào)用，這個(gè)過程稱為RPC請(qǐng)求：服務(wù)提供方根據(jù)服務(wù)調(diào)用方提供的參數(shù)執(zhí)行指定的服務(wù)方法，執(zhí)行完成后再將執(zhí)行結(jié)果響應(yīng)給服務(wù)調(diào)用方，這是一次RPC調(diào)用.Dubbo是一個(gè)分布式服務(wù)化治理框架，是一種RPC框架，提供對(duì)多種基于長(zhǎng)連接的NIO （New Input/Output）[17]框架抽象封裝，包括多種線程模型、序列化，以及“請(qǐng)求一響應(yīng)”模式的信息交換方式.200keeper[18]是Apache Hadoop的子項(xiàng)目，是一個(gè)典型的分布式一致性解決方案，是Google Chubby[19]的開源實(shí)現(xiàn).

現(xiàn)階段并沒有很好的工具支持基于Dubbo的應(yīng)用系統(tǒng)的自動(dòng)化測(cè)試.目前本文團(tuán)隊(duì)使用的測(cè)試方式為自身研發(fā)的自動(dòng)化測(cè)試框架（簡(jiǎn)稱老框架），該框架通過maven[20j管理;測(cè)試人員通過在pom.xml中添加待測(cè)jar包并執(zhí)行框架提供的命令來生成待測(cè)接口;測(cè)試人員通過編碼方式組裝Dubbo請(qǐng)求并對(duì)響應(yīng)結(jié)果進(jìn)行驗(yàn)證：在固定的文件夾TestCase中存放測(cè)試數(shù)據(jù)，命名規(guī)則為Dubbo服務(wù)接口名稱為子文件夾名稱：每個(gè)服務(wù)接口對(duì)應(yīng)不同的測(cè)試方法，測(cè)試數(shù)據(jù)存放在excel文件中，文件名稱根據(jù)待測(cè)試方法來命名：測(cè)試人員需要通過編碼組裝接口的請(qǐng)求對(duì)象和返回對(duì)象，并調(diào)用測(cè)試方法：框架根據(jù)數(shù)據(jù)和組裝的Dubbo請(qǐng)求生成TestNG[21]的測(cè)試用例，并執(zhí)行，框架自動(dòng)生成接口類并自動(dòng)生成自動(dòng)化測(cè)試用例，一定程度上減少了測(cè)試人員測(cè)試單接口用例的負(fù)擔(dān).但對(duì)于復(fù)雜場(chǎng)景，涉及多個(gè)測(cè)試方法的串聯(lián)，測(cè)試人員需要在請(qǐng)求中加復(fù)雜邏輯進(jìn)行用例的串聯(lián)，并且分不同的分支來判斷響應(yīng)結(jié)果的差異，這對(duì)測(cè)試人員的代碼能力要求很高.特別是針對(duì)不同測(cè)試環(huán)境，由于數(shù)據(jù)的變更，需要對(duì)請(qǐng)求及驗(yàn)證代碼重新編寫及調(diào)試，則需要懂得編程的自動(dòng)化測(cè)試人員編寫測(cè)試用例代碼，因此很難在功能測(cè)試人員中推廣和普及.

基于老框架，本文提出了一種可視化的平臺(tái)進(jìn)行Dubbo自動(dòng)化測(cè)試——Dubbo接口測(cè)試平臺(tái)測(cè)試平臺(tái)通過版本方式管理測(cè)試用例，基于可視化的方式支持?jǐn)?shù)據(jù)驅(qū)動(dòng)，利用關(guān)鍵字方式支持測(cè)試接口的上下文傳遞，從而支持測(cè)試復(fù)雜的業(yè)務(wù)場(chǎng)景.并且通過多種的測(cè)試用例重用方式，簡(jiǎn)化了測(cè)試用例編寫，降低了案例維護(hù)開銷，測(cè)試用例執(zhí)行模塊化、分布式的策略，在測(cè)試用例快速增長(zhǎng)時(shí)，可以方便地對(duì)測(cè)試用例執(zhí)行機(jī)器進(jìn)行擴(kuò)展.同時(shí)，平臺(tái)提供可視化配置方式支持版本測(cè)試用例定時(shí)執(zhí)行，以及豐富的日志和報(bào)表數(shù)據(jù)支持用例執(zhí)行分析減少了漏測(cè).

2 測(cè)試平臺(tái)

Dubbo接口測(cè)試平臺(tái)（新平臺(tái)）架構(gòu)見圖1.如圖1所示，數(shù)據(jù)流（實(shí)線）表示測(cè)試平臺(tái)的不同模塊，數(shù)據(jù)流（虛線）表示測(cè)試平臺(tái)與外部的關(guān)聯(lián)數(shù)據(jù)和子系統(tǒng).Dubbo接口測(cè)試平臺(tái)核心包括6個(gè)部分：子系統(tǒng)管理、權(quán)限管理、接口管理、測(cè)試用例管理、測(cè)試用例執(zhí)行器、工具類管理，子系統(tǒng)管理展示了待測(cè)的子系統(tǒng)的詳細(xì)信息，包括所屬測(cè)試團(tuán)隊(duì)、對(duì)應(yīng)IP地址、部署的jar/war包信息、系統(tǒng)負(fù)責(zé)人等相關(guān)信息.權(quán)限管理主要對(duì)測(cè)試人員訪問子系統(tǒng)的權(quán)限進(jìn)行設(shè)置，一個(gè)測(cè)試人員可以屬于多個(gè)測(cè)試組，一個(gè)測(cè)試組包含多個(gè)子系統(tǒng)，只有加入了測(cè)試組才能對(duì)該測(cè)試組下的子系統(tǒng)用例進(jìn)行增、刪、改操作.接口管理展示了待測(cè)子系統(tǒng)的所有Dubbo接口列表，在測(cè)試之前，首先上傳待測(cè)試系統(tǒng)的jar/war包，根據(jù)Dubbo協(xié)議解析出對(duì)應(yīng)接口列表，包括包名、方法名、請(qǐng)求參數(shù)、返回參數(shù)：除了自動(dòng)解析的接口，還可以手動(dòng)添加接口，根據(jù)接口是否發(fā)生變更，狀態(tài)可分為新增及更新，如果在測(cè)試過程中，接口發(fā)生了變更，則狀態(tài)由新增變更為更新.測(cè)試用例管理和測(cè)試用例執(zhí)行器主要是測(cè)試用例的增刪、改查及執(zhí)行.工具類管理主要是對(duì)外部封裝的工具類進(jìn)行管理，展示工具類的方法列表、參數(shù)及調(diào)用方式.新平臺(tái)的核心是輸出日志和執(zhí)行數(shù)據(jù)，并在數(shù)據(jù)分析模塊分析處理數(shù)據(jù)并生成報(bào)表.

與外部數(shù)據(jù)相關(guān)的兩個(gè)模塊為外部關(guān)聯(lián)數(shù)據(jù)和外部關(guān)聯(lián)系統(tǒng).外部關(guān)聯(lián)數(shù)據(jù)模塊包括數(shù)據(jù)集文件和配置文件.基于數(shù)據(jù)驅(qū)動(dòng)的思想，一個(gè)測(cè)試用例可以對(duì)應(yīng)多條測(cè)試數(shù)據(jù)，測(cè)試人員可以在excel編輯需要的測(cè)試數(shù)據(jù)集.測(cè)試用例中的數(shù)據(jù)參數(shù)化支持，除了可以使用數(shù)據(jù)集的數(shù)據(jù)，還可以使用配置文件中的數(shù)據(jù).數(shù)據(jù)集和配置文件的數(shù)據(jù)都通過Dubbo接口測(cè)試平臺(tái)核心模塊進(jìn)行導(dǎo)入和導(dǎo)出.外部關(guān)聯(lián)系統(tǒng)主要包括jar包管理平臺(tái)、ZooKeeper服務(wù)注冊(cè)中心、業(yè)務(wù)應(yīng)用服務(wù)器.jar包管理平臺(tái)通過maven私服搭建，測(cè)試文件都存儲(chǔ)在平臺(tái)上，通過配置maven的GAV（Groupld，Artifactld，Version）信息，新平臺(tái)核心模塊自動(dòng)下載待測(cè)包.ZooKeeper服務(wù)注冊(cè)中心通過ZooKeeper統(tǒng)一管理業(yè)務(wù)服務(wù).接口測(cè)試平臺(tái)核心模塊通過ZooKeeper服務(wù)中心獲取業(yè)務(wù)服務(wù)列表并發(fā)送服務(wù)調(diào)用請(qǐng)求至業(yè)務(wù)應(yīng)用服務(wù)器，并獲取服務(wù)響應(yīng)數(shù)據(jù).

2.1 用例管理

用例管理模塊的架構(gòu)圖如圖2所示.用例管理中，測(cè)試用例以子系統(tǒng)分類，分別對(duì)應(yīng)不同的權(quán)限，包括用例的新、增、改及執(zhí)行等權(quán)限.接口列表、配置信息、工具類都是子系統(tǒng)級(jí).根據(jù)待測(cè)試功能進(jìn)行分類，一個(gè)子系統(tǒng)的測(cè)試用例分為多個(gè)場(chǎng)景，一個(gè)場(chǎng)景下又有多條測(cè)試用例.

在用例編寫中，一部分用例需要準(zhǔn)備或清理相同的數(shù)據(jù)來保證用例的正確執(zhí)行，場(chǎng)景前置和后置腳本，可以保證批量用例的環(huán)境準(zhǔn)備，避免用例編寫中的重復(fù)工作.

通過初始化原子用例生成模塊，測(cè)試人員可以選擇需要測(cè)試的接口列表批量生成測(cè)試用例和對(duì)應(yīng)接口步驟.隨著版本迭代，一個(gè)子系統(tǒng)會(huì)對(duì)應(yīng)多個(gè)版本，測(cè)試人員可以通過頁(yè)面自動(dòng)切換版本來查看對(duì)應(yīng)的測(cè)試信息.

一個(gè)用例包含前置腳本、后置腳本、測(cè)試步驟和執(zhí)行策略.測(cè)試步驟分為接口步驟和腳本步驟.一個(gè)接口步驟包括6部分：前置腳本、請(qǐng)求報(bào)文、返回報(bào)文、異常信息、后置腳本和斷言.腳本步驟僅支持腳本編寫.創(chuàng)建接口步驟時(shí)，選擇待測(cè)試的接口，此模塊會(huì)展示對(duì)應(yīng)的請(qǐng)求及返回的參數(shù)，并自動(dòng)根據(jù)參數(shù)類型填入默認(rèn)值.測(cè)試人員需要做的是準(zhǔn)備測(cè)試數(shù)據(jù)，發(fā)送請(qǐng)求，并通過返回自動(dòng)添加驗(yàn)證信息.腳本步驟主要是在步驟級(jí)別編寫腳本，方便測(cè)試人員合理設(shè)計(jì)自動(dòng)化用例.一個(gè)測(cè)試用例需要包含多個(gè)測(cè)試步驟來完成單個(gè)功能點(diǎn)的測(cè)試.測(cè)試用例的執(zhí)行策略分為兩種：一種是如果一個(gè)步驟執(zhí)行失敗，后續(xù)步驟停止執(zhí)行;另一種是即使前面步驟執(zhí)行失敗，后續(xù)步驟也需要繼續(xù)執(zhí)行，類似TestNG的softAssert操作.此模塊通過添加開關(guān)來設(shè)置步驟失敗執(zhí)行策略，默認(rèn)為關(guān)閉，即失敗后停止，以避免不必要的執(zhí)行耗時(shí).

新平臺(tái)基于數(shù)據(jù)驅(qū)動(dòng)，主要體現(xiàn)在3個(gè)方面：配置信息、數(shù)據(jù)集和工具類.對(duì)于不同的測(cè)試環(huán)境，配置項(xiàng)管理通過鍵值對(duì)方式支持變量配置，同一個(gè)key，可以對(duì)應(yīng)多個(gè)value值，根據(jù)環(huán)境配置來區(qū)分此配置項(xiàng)在哪個(gè)環(huán)境測(cè)試環(huán)境生效.可以在腳本中把配置項(xiàng)作為變量使用，來編寫不同場(chǎng)景的測(cè)試用例及驗(yàn)證.對(duì)于同一個(gè)接口，不用數(shù)據(jù)對(duì)應(yīng)不同的場(chǎng)景及驗(yàn)證點(diǎn)，在編寫測(cè)試用例時(shí)會(huì)需要多條測(cè)試數(shù)據(jù).此模塊提供數(shù)據(jù)集的功能，可以通過excel方式批量導(dǎo)入測(cè)試數(shù)據(jù)，并展示為Json[15]格式，可以在測(cè)試腳本中把key值作為變量進(jìn)行使用.新平臺(tái)同時(shí)提供Web頁(yè)面方式，支持對(duì)Json數(shù)據(jù)的新、增、改，方便測(cè)試數(shù)據(jù)的使用.對(duì)于外部封裝的工具類，可以直接以工具類的方式上傳到平臺(tái)，然后添加需要的工具類作為待測(cè)子系統(tǒng)的依賴子系統(tǒng).工具類中的方法可以直接在腳本中使用或者作為接口來使用.

在單版本測(cè)試過程中，開發(fā)代碼有缺陷會(huì)導(dǎo)致接口及代碼變更.本文設(shè)計(jì)的新平臺(tái)會(huì)檢測(cè)jar/war包變更，自動(dòng)發(fā)現(xiàn)接口變更，并在接口中標(biāo)記此變更，在執(zhí)行中，可以實(shí)時(shí)看到執(zhí)行日志，方便查看用例的執(zhí)行情況及測(cè)試流程數(shù)據(jù)是否正確.

在此模塊中定義了一些關(guān)鍵字來輔助測(cè)試用例的編寫.關(guān)鍵字如表1所示.

通過關(guān)鍵字$app.addContext（key，value）和$app.getContext （key），測(cè)試人員可以方便地實(shí)現(xiàn)步驟間數(shù)據(jù)的傳遞，從而快速編寫多接口測(cè)試用例.

在編寫測(cè)試用例過程中，部分功能點(diǎn)的測(cè)試是多個(gè)接口的不同組合，此模塊提供了測(cè)試用例及相關(guān)步驟復(fù)制的功能.測(cè)試用例的復(fù)制分為3個(gè)級(jí)別：子系統(tǒng)級(jí)別、測(cè)試用例級(jí)別和測(cè)試步驟級(jí)別.用例同步模塊是指開發(fā)迭代過程中，新的待測(cè)版本生成，測(cè)試人員可以通過Web頁(yè)面選擇從哪個(gè)舊的版本中復(fù)制哪些測(cè)試用例到新的版本，這是子系統(tǒng)級(jí)別的用例復(fù)制.對(duì)于測(cè)試用例級(jí)別，測(cè)試人員可以通過可視化方式，復(fù)制測(cè)試用例到不同的場(chǎng)景，并通過修改用例名稱和新增、修改測(cè)試步驟來生成新的測(cè)試用例，測(cè)試步驟創(chuàng)建后，所有的步驟會(huì)顯示在案例管理的左側(cè)，可以通過拖拽方式復(fù)制測(cè)試步驟來組裝新的測(cè)試用例.

2.2 新平臺(tái)技術(shù)架構(gòu)及多系統(tǒng)多版本用例執(zhí)行的負(fù)載均衡策略

此模塊主要介紹新平臺(tái)的技術(shù)架構(gòu)和多子系統(tǒng)多版本下的負(fù)載均衡策略.新平臺(tái)技術(shù)架構(gòu)如圖3所示.

測(cè)試人員通過前端控制臺(tái)界面對(duì)用例進(jìn)行操作，新平臺(tái)通過NGINX[22]實(shí)現(xiàn)Web請(qǐng)求的分發(fā)，NGINX負(fù)責(zé)Web層的負(fù)載均衡.Web應(yīng)用以集群形式部署在多個(gè)tomcat上，主要負(fù)責(zé)可視化的編寫與調(diào)試.用例的執(zhí)行是在work測(cè)試執(zhí)行器上執(zhí)行，新平臺(tái)中work測(cè)試執(zhí)行器也是以集群方式部署.Web服務(wù)和work服務(wù)都注冊(cè)在Eureka[23]上.針對(duì)高并發(fā)及可能出現(xiàn)的服務(wù)異常及子系統(tǒng)、版本個(gè)數(shù)及自動(dòng)化測(cè)試用例的日益增加，新平臺(tái)對(duì)測(cè)試用例執(zhí)行實(shí)現(xiàn)了自定義的負(fù)載均衡策略，這部分包含在Web中的執(zhí)行負(fù)載均衡模塊.

由于接口測(cè)試用例數(shù)量也很多，同一時(shí)間并發(fā)請(qǐng)求數(shù)也會(huì)很多，這對(duì)緩存訪問有很高的要求：并且根據(jù)執(zhí)行的負(fù)載均衡策略，同一個(gè)應(yīng)用的測(cè)試用例會(huì)分配在同一臺(tái)work執(zhí)行器上，新平臺(tái)會(huì)把測(cè)試用例執(zhí)行的上下文信息存儲(chǔ)在本地緩存服務(wù)Ehcache[24]上，以提高執(zhí)行速度.而用戶登陸信息及執(zhí)行中使用到的Dubbo服務(wù)信息是存儲(chǔ)在緩存服務(wù)器Redis[25]上，并根據(jù)負(fù)載均衡策略從work執(zhí)行器集群中選擇一臺(tái)進(jìn)行執(zhí)行，work執(zhí)行器從ZooKeeper注冊(cè)中心選擇可用的業(yè)務(wù)服務(wù)器，發(fā)請(qǐng)求給業(yè)務(wù)服務(wù)并獲取響應(yīng)結(jié)果.測(cè)試用例的數(shù)據(jù)保存在數(shù)據(jù)庫(kù)中，數(shù)據(jù)庫(kù)使用MySQL，一主一從.新平臺(tái)中所有文件都保存在分布式文件服務(wù)器NFS上.

執(zhí)行負(fù)載均衡模塊中的負(fù)載均衡策略基于spring cloud round Ribbon[26]，自定義了負(fù)載均衡規(guī)則HashRule，此類繼承自AbstractLoadBalancerRule.RequestConteXt類定義了子系統(tǒng)運(yùn)行的線程上下文，可以獲取當(dāng)前子系統(tǒng)的標(biāo)識(shí)性信息印pId.選取執(zhí)行work的規(guī)則算法偽代碼見算法1.

負(fù)載均衡算法為從線程上下文中獲取待測(cè)子系統(tǒng)對(duì)應(yīng)版本的appld，找到正常工作，并且內(nèi)存、磁盤空間及CPU都沒有超負(fù)荷運(yùn)行的work實(shí)例列表個(gè)數(shù)，對(duì)appld做取模操作，得到分發(fā)的機(jī)器索引，并拿到對(duì)應(yīng)的work實(shí)例.再次判斷work實(shí)例沒有在緩存非不宜使用列表中，并且服務(wù)是正常的，則返回此work實(shí)例.hashKey為從線程上下文中獲取的子系統(tǒng)的appld，allServers、reachableServers為從Eureka中讀取到的所有的及可用的work服務(wù)實(shí)例.根據(jù)各work機(jī)器信息判斷哪些機(jī)器信息指標(biāo)信息超負(fù)載，加入緩存列表中.servers保存所有可用的且滿足機(jī)器資源要求的work服務(wù)實(shí)例.針對(duì)單個(gè)appld選取的work實(shí)例保存在server中.在獲取server的過程中，嘗試10次，如果還是沒有找到對(duì)應(yīng)的work實(shí)例，則返回null.

2.3 用例執(zhí)行

此模塊包括獲取執(zhí)行上下文及執(zhí)行用例.執(zhí)行維度主要分為4種方式：子系統(tǒng)級(jí)別、場(chǎng)景級(jí)別、用例級(jí)別和步驟級(jí)別.用例執(zhí)行架構(gòu)如圖4所示.

在執(zhí)行用例之前，需要獲取執(zhí)行的準(zhǔn)備信息，即執(zhí)行上下文信息，包括依賴的其他子系統(tǒng)、配置項(xiàng)信息、使用的工具類中的方法、其他步驟的返回值及ZooKeeper中注冊(cè)的Dubbo服務(wù)信息.針對(duì)Dubbo請(qǐng)求，需要從ZooKeeper中獲取注冊(cè)的服務(wù)信息，有了這些信息，用例才能執(zhí)行.由于自動(dòng)化測(cè)試用例數(shù)量很多，同一時(shí)間并發(fā)請(qǐng)求數(shù)也會(huì)很多，則執(zhí)行上下文會(huì)存儲(chǔ)在本地緩存服務(wù)Ehcache上，執(zhí)行中用到的標(biāo)記信息及測(cè)試人員登陸信息存儲(chǔ)在緩存服務(wù)器Redis上.用例執(zhí)行會(huì)發(fā)請(qǐng)求給業(yè)務(wù)子系統(tǒng)，然后根據(jù)執(zhí)行情況生成對(duì)應(yīng)的日志，執(zhí)行日志及生成的代碼覆蓋率報(bào)告存儲(chǔ)在NFS服務(wù)器上.對(duì)于執(zhí)行結(jié)果，包括返回報(bào)文和執(zhí)行成功率及代碼覆蓋率數(shù)據(jù)會(huì)存儲(chǔ)在數(shù)據(jù)庫(kù)中.可以通過手動(dòng)觸發(fā)或通過定時(shí)調(diào)度方式來執(zhí)行單個(gè)子系統(tǒng)單個(gè)版本的所有測(cè)試用例，并生成日志報(bào)告及執(zhí)行報(bào)告和代碼覆蓋率報(bào)告.用例執(zhí)行報(bào)告包括測(cè)試用例總數(shù)、測(cè)試步驟數(shù)、測(cè)試用例成功數(shù)、成功率、失敗數(shù)、失敗原因分析和失敗用例詳情.可以通過頁(yè)面方式點(diǎn)擊方式來查看失敗的測(cè)試用例及失敗詳情，并可定位到失敗的步驟.測(cè)試用例級(jí)別的執(zhí)行會(huì)同時(shí)執(zhí)行測(cè)試用例下的所有步驟，并生成日志.測(cè)試步驟級(jí)別的執(zhí)行支持單個(gè)步驟的執(zhí)行，并支持步驟間上下文的串聯(lián).在調(diào)試測(cè)試用例過程中，可以僅執(zhí)行單個(gè)步驟來查看結(jié)果，而不用執(zhí)行所有的步驟，極大地節(jié)省了測(cè)試用例的調(diào)試時(shí)間.

在執(zhí)行過程中，可以對(duì)測(cè)試步驟、測(cè)試用例和測(cè)試場(chǎng)景進(jìn)行標(biāo)記禁用，有此標(biāo)記的測(cè)試用例在各級(jí)別的執(zhí)行中都會(huì)被略過，并且在報(bào)表中不會(huì)被統(tǒng)計(jì).

覆蓋率報(bào)告展示了自動(dòng)化測(cè)試用例對(duì)于開發(fā)代碼的覆蓋情況.從報(bào)告中，可以看到哪些代碼被覆蓋，哪些沒有覆蓋，并可以通過Dubbo服務(wù)接口關(guān)鍵字搜索到相關(guān)的類文件來查看相關(guān)接口的覆蓋情況，從而幫助測(cè)試人員更好地設(shè)計(jì)自動(dòng)化測(cè)試用例，避免漏測(cè).

2.4 用例編寫示例

編寫示例為兩個(gè)系統(tǒng)之間的測(cè)試串聯(lián)，主要涉及兩個(gè)子系統(tǒng)A、B和工具類tool-util.如果A系統(tǒng)需要調(diào)用B系統(tǒng)的Dubbo接口bizOrderAiFacade的方法bizOrder，用于落業(yè)務(wù)單操作并使用工具類的方法打印自定義日志，則A系統(tǒng)需要添加B系統(tǒng)和工具類tool-util作為依賴.由于開發(fā)迭代，一個(gè)子系統(tǒng)或工具類會(huì)對(duì)應(yīng)多個(gè)版本，需要選擇選擇依賴的子系統(tǒng)及對(duì)應(yīng)的版本進(jìn)行添加，依賴關(guān)系可視化頁(yè)面展示如圖5所示.

編寫測(cè)試用例.測(cè)試步驟為落業(yè)務(wù)單、支付、交易通知，第一步，創(chuàng)建接口步驟，選擇接口方法bizOrderAiFacade的方法bizOrder，并使用變量的形式給參數(shù)賦值：第二步，選擇A系統(tǒng)的接口TransAiFacade中方法payOrder做支付操作;第三步，選擇接口MessageNotifyAiFacade的方法payNotify做交易通知.在每個(gè)步驟編寫完之后，可以執(zhí)行單個(gè)步驟或整個(gè)測(cè)試用例并獲取執(zhí)行結(jié)果.界面展示如圖6所示.

單個(gè)測(cè)試用例包括用例名稱、測(cè)試用例屬于哪個(gè)場(chǎng)景、測(cè)試用例步驟數(shù)、用例優(yōu)先級(jí)、權(quán)重、執(zhí)行時(shí)間的執(zhí)行、修改、刪除、用例前置后置、數(shù)據(jù)集及日志查看.圖6的最左側(cè)展示的是已有的步驟.編寫測(cè)試用例可以通過拖拽的方式來復(fù)制測(cè)試步驟.

以第二個(gè)步驟payOrder： TransAiFacade（方法名：接口名）查看單個(gè)步驟，頁(yè)面展示如圖7所示.

測(cè)試步驟包括前置腳本（BeforeMethod）、后置腳本（AfterMethod），腳本里可以使用工具類的方法，比如日志打印.接口請(qǐng)求參數(shù)及返回?cái)?shù)據(jù).請(qǐng)求參數(shù)的賦值可以參數(shù)化：idempo-tentFlag通過配置項(xiàng)的方式賦值;paymentld通過上下文的方式賦值.斷言可以通過3種方式編寫：添加斷言（添加單條驗(yàn)證點(diǎn)）、批量添加斷言、腳本方式驗(yàn)證.點(diǎn)擊運(yùn)行，獲取測(cè)試用例執(zhí)行結(jié)果.

3 實(shí)驗(yàn)

3.1 實(shí)驗(yàn)環(huán)境

實(shí)驗(yàn)環(huán)境共有9臺(tái)RedHat 6.5的測(cè)試機(jī)器：1臺(tái)部署NGINX和Redis;2臺(tái)部署Web;3臺(tái)部署測(cè)試用例執(zhí)行器;1臺(tái)部署MySQL主庫(kù);1臺(tái)部署備庫(kù);1臺(tái)部署NFS.3臺(tái)測(cè)試用例執(zhí)行器配置為8個(gè)主頻為2.4 GHz的Intel Skylake CPU芯片，內(nèi)存為16 GB，磁盤容量為80 GB;2臺(tái)Web配置為2個(gè)主頻為2.4 GHz的Intel Broadwell CPU芯片，內(nèi)存為4 GB，磁盤容量為80 GB; NGINX和NFS機(jī)器配置分別為2個(gè)主頻為2.4 GHz的Intel Broadwell CPU芯片，內(nèi)存為8 GB，磁盤容量為80 GB;1臺(tái)MySQL主庫(kù)為16個(gè)主頻為2.4 GHz的CPU E5-2695芯片，內(nèi)存為32 GB，磁盤容量為250 GB;老框架運(yùn)行環(huán)境為Windows 7，配置為1個(gè)主頻為2.5 GHz的Intel i3-3120M CPU，內(nèi)存為8 GB，磁盤容量為200 GB.

3.2 新平臺(tái)與老框架耗時(shí)對(duì)比數(shù)據(jù)

表2為新平臺(tái)與老框架的耗時(shí)數(shù)據(jù)，使用第2.4節(jié)中的用例編寫示例.從表2的數(shù)據(jù)可以看出，平臺(tái)化后，測(cè)試人員不用花費(fèi)時(shí)間搭建開發(fā)環(huán)境來編寫測(cè)試用例，投入到自動(dòng)化測(cè)試的人數(shù)越多，節(jié)省的時(shí)間越多.由于新平臺(tái)會(huì)解析接口參數(shù)，并且能自動(dòng)生成單接口測(cè)試用例，測(cè)試人員只需要對(duì)請(qǐng)求參數(shù)賦值，并把賦值參數(shù)化以適配多環(huán)境，大大節(jié)省了單步驟測(cè)試用例準(zhǔn)備及多環(huán)境適配的時(shí)間.

由于老框架同一個(gè)接口方法的請(qǐng)求參數(shù)代碼只有1份，在處理復(fù)雜場(chǎng)景時(shí)需要處理多種情況的串聯(lián)，耗時(shí)較多.新平臺(tái)對(duì)于多環(huán)境適配，需要在配置文件中，對(duì)于相同的鍵，新增value值，相對(duì)耗時(shí)較少.對(duì)于測(cè)試結(jié)果，新平臺(tái)提供了豐富的日志及執(zhí)行策略，失敗原因分析可以快速定位問題，相比原來的查看jenkins批量執(zhí)行日志，單個(gè)子系統(tǒng)平均幾百個(gè)用例，節(jié)省的時(shí)間是按小時(shí)計(jì)算的.總地來說，可視化的新平臺(tái)在用例編寫、執(zhí)行及結(jié)果分析上節(jié)省了5倍時(shí)間.用例數(shù)越多，參與自動(dòng)化的人員越多，節(jié)省發(fā)的時(shí)間越多.

3.3 新平臺(tái)與老框架自動(dòng)化接口測(cè)試用例增長(zhǎng)對(duì)比數(shù)據(jù)

圖8展示了新平臺(tái)與老框架按月統(tǒng)計(jì)（1月份6月份）的測(cè)試用例增長(zhǎng)數(shù)據(jù)，每個(gè)月月底統(tǒng)計(jì)當(dāng)月的測(cè)試用例增長(zhǎng)情況.從數(shù)據(jù)可以看出，老框架的測(cè)試用例數(shù)據(jù)為以百位增長(zhǎng)，新平臺(tái)的自動(dòng)化用例則以千位增長(zhǎng).每個(gè)月的數(shù)據(jù)增長(zhǎng)有變化，主要是由功能測(cè)試人員的時(shí)間決定，如果功能測(cè)試任務(wù)較重，則花費(fèi)在自動(dòng)化上的時(shí)間會(huì)減少.新平臺(tái)門檻相對(duì)較低，測(cè)試人員在功能測(cè)試的同時(shí)，可以基于新平臺(tái)編寫自動(dòng)化用例進(jìn)行測(cè)試.

3.4 子系統(tǒng)執(zhí)行數(shù)據(jù)

目前新平臺(tái)子系統(tǒng)個(gè)數(shù)有247個(gè)，執(zhí)行的用例數(shù)為16 271個(gè)，總體成功率為79.2%，平均行覆蓋率30%.日常自動(dòng)化數(shù)據(jù)選取當(dāng)日測(cè)試用例總數(shù)最高的10個(gè)子系統(tǒng)，用例執(zhí)行數(shù)據(jù)如表3所示.

執(zhí)行耗時(shí)包含了接口實(shí)際調(diào)用時(shí)間（請(qǐng)求發(fā)送到業(yè)務(wù)子系統(tǒng)到請(qǐng)求返回），訪問數(shù)據(jù)庫(kù)時(shí)間及腳本中設(shè)定的Sleep時(shí)間.批量執(zhí)行時(shí)間都控制在30 min左右.

對(duì)于平臺(tái)的擴(kuò)展性，根據(jù)執(zhí)行的負(fù)載均衡算法，work機(jī)器實(shí)例增加，算法會(huì)動(dòng)態(tài)獲取可用的work實(shí)例進(jìn)行Hash，從而達(dá)到彈性擴(kuò)容的目的.

4 結(jié)論與展望

為了更好地測(cè)試互聯(lián)網(wǎng)金融使用Dubbo協(xié)議的應(yīng)用，快速編寫并管理大批量用例及更好地支持多子系統(tǒng)版本迭代和測(cè)試用例數(shù)據(jù)分析，本文使用分布式技術(shù)設(shè)計(jì)并實(shí)現(xiàn)了一個(gè)靈活的Dubbo接口自動(dòng)化測(cè)試平臺(tái).首先介紹了測(cè)試平臺(tái)的架構(gòu)：然后著重介紹了用例管理和用例執(zhí)行，并介紹了多子系統(tǒng)多版本用例的并發(fā)執(zhí)行及執(zhí)行中使用的負(fù)載均衡策略，最后介紹了日常自動(dòng)化執(zhí)行情況、用例及步驟耗時(shí)，并以一個(gè)具體例子說明測(cè)了試用例的編寫，雖然新平臺(tái)降低了自動(dòng)化門檻，大大節(jié)省了用例編寫時(shí)間，但批量執(zhí)行單個(gè)子系統(tǒng)的測(cè)試用例時(shí)還需要考慮并發(fā)執(zhí)行，進(jìn)一步減少執(zhí)行時(shí)間.

【參考文獻(xiàn)】

[1] 席濤，鄭賢強(qiáng)大數(shù)據(jù)時(shí)代互聯(lián)網(wǎng)產(chǎn)品的迭代創(chuàng)新設(shè)計(jì)方法研究[J].包裝工程，2016， 37（8）： 1-4.

[2] 周永紅，張彥祥.金融軟件的自動(dòng)化測(cè)試探索與創(chuàng)新之路[J].中國(guó)金融電腦，2018（1）：64-68.

[3]TAY B H，ANANDA A L.A survey of remote procedure calls [J]. ACM SIGOPS Operating Systems Review，1990， 24（3）： 68-79.

[4]APACHE SOFTWARE FOUNDATION. Apache Dubbo [OB/OL]. [2018-06-20]. http：//Dubbo.apache.org/.

[5]SoapUI. Available [EB/OL]. （2017-12-04）[2018-07-01]. https：// www.soapui.org/

[6]SOAP. WWW， Service Architecture， Soap [EB/OL]. （2016-07-17）[2018-07-01]. https：//www.service-architecture.com/articles/web-services/soap html.

[7] 楊超.基于分布式服務(wù)框架Dubbo的集群式服務(wù)器的研究與實(shí)現(xiàn)[D].北京：北京郵電大學(xué)，2017

[8]Apache JMeterrM. The Apache Software Foundation [EB/OLl. （2016-07-17） [2018-07-01]. http：//jmeter.apacheorg/index.html.

[9]MICRO FOCUS. LoadRunner Load Testing Software[EB/OL]. （2017-08-30）[2018-07-01]. https：//www.microf-ocus com/en-us/products/loadrunner-load-testing/overview

[10] NIELSEN H F，GETTYS J，BAIRD-SMITH A，et al. Network performance effects of HTTP/I.1 [J]. ACMSigcomm Computer Communication Review， 1997， 27（4）： 155-166

[11] MENG F Y.Phoenix Framewor [EB/OL]. （2016-07-17）[2018-07-01]. http：//www.cewan.la/

[12]SHANG Y，ZHANG x L，F(xiàn)ENG Y B，et al.Research and application of automated testing tool based on STAF[C]//Proceedings of the 2nd International Conference on Computer Science and Electronics Engineering. Paris：Atlantis Press， 2013： 2336-2339.

[13] SOURCE FORGE. Software Testing Automation Framework （STAF） [EB/OL]. （2016-12-31）[2018-07-01].http： //staf.sourceforge. net/index.php.

[14]HE z H，ZHANG x，ZHU x Y.Design and implementation of automation testing framework based on keyworddriven [J]. Applied Mechanics and Materials， 2014， 602/603/604/605： 2142-2146.

[15] ECMA INTERNATIONAL. The JSON Data Interchange Syntax[EB/OL]. （2016-12-31）[2018-07-01l. http：//www.ecma-international. org/publications/files/ECMA-ST/ECMA-404 . p df.

[16]JOY J， SINGH D P. A generic framework design to enhance capabilities of an enterprise test automation frame-work [C]// International Conference on Applied and Theoretical Computing and Communication Technology.IEEE， 2016： 207-212.

[17]GRIFFIN L， RYAN K， DE LEASTAR E， et al. Scaling instant messaging corumuniction services： A comparisonof blocking and non-blocking techniques [C]// 2011 IEEE Symposium on Computers and Communications. IEEE，2011： 550-557.

[18] JUNQUEIRA F， REED B. ZooKeeper： Distributed Process Coordination [M]. [S.l]： O'Reilly Media， Inc. 2013.

[19] BURROWS M. The Chubby lock service for loosely-coupled distributed systems [C]// OSDI'06： 7th USENIXSymposium on Operating Systems Design and Implementation. USENIX Association， 2006： 335-350.

[20] MAVEN. The Apache Software Foundation [EB/OL]. [2018-07-01]. https：//maven.apache.org/what-is-maven.html.

[21] TestNG. The Apache Software Foundation [EB/OL]. （2017-12-19）[2018-07-01l. http：//testng.org/doc/docum-entation-main.html.

[22]REESE W. Nginx： The high-performance web server and reverse proxy [J]. Linux Journal， 2008， 2008（173）： 2.

[23] GITHUB. Netflix， Eureka [EB/OL]. [2018-07-01]. https：//github.com/Netflix/eureka.

[24] EHCACHE. Software AG USA [EB/OL]. （2017-05-25）[2018-07-01]. http：//www.ehcache.org/about/index.html.

[25] REDIS. Redis Labs [EB/OL]. （2017-07-00）[2018-07-01]. https：//redis.io/topics/introduction.

[26] Netflix， Ribbon [EB/OL]. （2018-04-28）[2018-07-01]. https：//github.com/Netflix/ribbon.