李艷麗 張宗勇 馮捷 李志輝

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

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

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

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

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

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

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

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

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

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

1 相關(guān)工作

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

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

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

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

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

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

2 測試平臺

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

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

2.1 用例管理

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

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

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

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

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

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

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

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

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

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

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

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

由于接口測試用例數(shù)量也很多，同一時間并發(fā)請求數(shù)也會很多，這對緩存訪問有很高的要求：并且根據(jù)執(zhí)行的負(fù)載均衡策略，同一個應(yīng)用的測試用例會分配在同一臺work執(zhí)行器上，新平臺會把測試用例執(zhí)行的上下文信息存儲在本地緩存服務(wù)Ehcache[24]上，以提高執(zhí)行速度.而用戶登陸信息及執(zhí)行中使用到的Dubbo服務(wù)信息是存儲在緩存服務(wù)器Redis[25]上，并根據(jù)負(fù)載均衡策略從work執(zhí)行器集群中選擇一臺進(jìn)行執(zhí)行，work執(zhí)行器從ZooKeeper注冊中心選擇可用的業(yè)務(wù)服務(wù)器，發(fā)請求給業(yè)務(wù)服務(wù)并獲取響應(yīng)結(jié)果.測試用例的數(shù)據(jù)保存在數(shù)據(jù)庫中，數(shù)據(jù)庫使用MySQL，一主一從.新平臺中所有文件都保存在分布式文件服務(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)識性信息印pId.選取執(zhí)行work的規(guī)則算法偽代碼見算法1.

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

2.3 用例執(zhí)行

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

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

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

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

2.4 用例編寫示例

編寫示例為兩個系統(tǒng)之間的測試串聯(lián)，主要涉及兩個子系統(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ā)迭代，一個子系統(tǒng)或工具類會對應(yīng)多個版本，需要選擇選擇依賴的子系統(tǒng)及對應(yīng)的版本進(jìn)行添加，依賴關(guān)系可視化頁面展示如圖5所示.

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

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

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

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

3 實驗

3.1 實驗環(huán)境

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

3.2 新平臺與老框架耗時對比數(shù)據(jù)

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

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

3.3 新平臺與老框架自動化接口測試用例增長對比數(shù)據(jù)

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

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

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

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

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

4 結(jié)論與展望

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

【參考文獻(xiàn)】

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

[2] 周永紅，張彥祥.金融軟件的自動化測試探索與創(chuàng)新之路[J].中國金融電腦，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ù)器的研究與實現(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.