陳立哲,吳 際,楊海燕,張 奎

(北京航空航天大學(xué) 計算機學(xué)院,北京 100 191)

單塊架構(gòu)(monolithic)由于模塊化問題而難以管理、擴展和維護[1],很難有效應(yīng)對Web 應(yīng)用系統(tǒng)復(fù)雜化問題.很多大型互聯(lián)網(wǎng)企業(yè)像Netflix,Amazon 和Spotify 等,采用了微服務(wù)架構(gòu)來重構(gòu)它們的業(yè)務(wù)系統(tǒng).

微服務(wù)架構(gòu)(microservices)[2?5]是一種高度模塊化的架構(gòu)模式,它提倡將應(yīng)用系統(tǒng)根據(jù)業(yè)務(wù)種類和關(guān)系劃分成一組服務(wù),每個服務(wù)能夠被獨立部署到生產(chǎn)環(huán)境、運行在獨立的進程中,服務(wù)間采用輕量級通信機制交換信息.與單塊架構(gòu)相比,微服務(wù)架構(gòu)具有業(yè)務(wù)內(nèi)聚、易擴展、高容錯、平滑升級等特點,更能適應(yīng)Web 應(yīng)用系統(tǒng)的業(yè)務(wù)快速擴展和迭代的現(xiàn)實場景.

微服務(wù)系統(tǒng)通過不斷迭代來擴展功能.每輪迭代都會改變服務(wù)本身及其依賴關(guān)系,可能引入新的故障,需要通過回歸測試來保證系統(tǒng)質(zhì)量[6].回歸測試最直接的策略就是重復(fù)執(zhí)行原有全部測試用例,但這種策略會造成不必要的資源浪費.為此,很多關(guān)于回歸測試技術(shù)的研究提出:可以針對特定目標(例如保持覆蓋性、降低成本、關(guān)注變更等)進行有選擇性的測試,提高有限資源的使用效率[7].其中,測試用例集選擇、排序和縮減是3 種主要的回歸測試技術(shù)[6].

測試用例集縮減是一個NP 完全問題,旨在獲得原測試用例集的一個子集,該子集能夠保持原測試用例集的覆蓋能力[6].其典型技術(shù)有啟發(fā)式方法、基于模型的方法和測試數(shù)據(jù)聚類的方法等,這些技術(shù)大都需要完整一致的系統(tǒng)規(guī)約和架構(gòu)描述作為輸入才能實施.而在工程實踐中,測試人員很難獲得微服務(wù)系統(tǒng)的規(guī)約與架構(gòu)信息[8],這涉及管理和技術(shù)兩個層面的因素:在管理層面,各個服務(wù)獨立開發(fā)運維、高度自治,難以統(tǒng)一維護所有服務(wù)及其版本演化過程的文檔;在技術(shù)層面,受延遲綁定、請求轉(zhuǎn)發(fā)等機制的影響,特別是智能化網(wǎng)關(guān)的引入,使得服務(wù)之間調(diào)用關(guān)系變得不可預(yù)測,難以獲得確定的服務(wù)調(diào)用關(guān)系描述.這導(dǎo)致在微服務(wù)系統(tǒng)的回歸測試中難以應(yīng)用現(xiàn)有技術(shù).另一方面,現(xiàn)有測試用例集縮減技術(shù)大都關(guān)注軟件自身實現(xiàn)的正確性,很少考慮用戶使用場景,這可能造成測試場景和使用場景發(fā)生偏離,測試用例集不能聚焦用戶關(guān)注的服務(wù),導(dǎo)致測試效率降低.例如:為特定用戶群體定制的迭代版本只依賴部分服務(wù),強調(diào)對所有服務(wù)的覆蓋可能會造成不必要的測試.

值得注意的是:在微服務(wù)系統(tǒng)持續(xù)交付過程中,可以采集到大量的API 網(wǎng)關(guān)層日志.API 網(wǎng)關(guān)層是用于集中分發(fā)服務(wù)請求的關(guān)鍵組件,其日志記錄了微服務(wù)系統(tǒng)運行過程中的每一次API 請求,內(nèi)容包括調(diào)用者IP、被請求的URL 和狀態(tài)碼等信息,主要用于監(jiān)控服務(wù)運行狀況.借鑒Web日志挖掘技術(shù)[9],能夠從API 網(wǎng)關(guān)層日志中生成反映用戶使用場景的服務(wù)調(diào)用路徑信息,進而關(guān)聯(lián)到測試用例中,作為縮減測試用例集的依據(jù).

本文提出了一種基于API 網(wǎng)關(guān)層日志挖掘的微服務(wù)回歸測試用例集縮減技術(shù),主要包括日志挖掘、測試用例關(guān)聯(lián)和縮減這3 個環(huán)節(jié).首先,在日志挖掘環(huán)節(jié),從API 網(wǎng)關(guān)層日志中提取數(shù)據(jù)集,進而設(shè)計頻繁模式挖掘算法,從數(shù)據(jù)集中挖掘用戶使用頻繁的服務(wù)及其調(diào)用關(guān)系,即服務(wù)調(diào)用頻繁路徑;其次,在測試用例關(guān)聯(lián)環(huán)節(jié),將服務(wù)調(diào)用頻繁路徑匹配到對應(yīng)測試用例上,以賦予測試用例關(guān)于用戶使用場景的信息——支持度;最后,在縮減環(huán)節(jié),基于支持度對測試用例進行啟發(fā)式搜索,找到符合覆蓋準則的測試用例縮減集.為驗證方法的有效性,基于實際項目數(shù)據(jù)對該方法進行了實驗和分析,結(jié)果表明:該方法既易于實現(xiàn),也能提高測試效率.

本文第1 節(jié)概要介紹微服務(wù)回歸測試和Web日志挖掘的相關(guān)研究.第2 節(jié)詳細闡述本文所提測試用例集縮減技術(shù)的各個環(huán)節(jié).第3 節(jié)簡要敘述實驗驗證及分析.第4 節(jié)進行總結(jié).

1 相關(guān)研究

1.1 微服務(wù)回歸測試

對于微服務(wù)系統(tǒng),回歸測試在其每一輪迭代都有發(fā)生,單元測試、服務(wù)測試和端到端測試都需要進行回歸以保證系統(tǒng)質(zhì)量.微服務(wù)單元測試主要用于發(fā)現(xiàn)服務(wù)內(nèi)部代碼實現(xiàn)存在的缺陷,可以通過單元測試工具完成,例如xUnit[10]、Mockito[11]等,其回歸測試技術(shù)與單塊架構(gòu)軟件基本一致.服務(wù)測試和端到端測試關(guān)注服務(wù)之間的連通性,涉及多個服務(wù)及其之間的調(diào)用關(guān)系.由于服務(wù)自治、動態(tài)綁定、訪問限制帶來的挑戰(zhàn)[12],服務(wù)測試與端到端測試的回歸測試技術(shù)與單塊架構(gòu)軟件差別較大,是研究和實踐關(guān)注的重點[13].

在測試用例選擇方面,主要是基于系統(tǒng)迭代時發(fā)生的變化來篩選相關(guān)聯(lián)的測試用例[6].由于傳統(tǒng)黑盒測試技術(shù)也適用于單個服務(wù)回歸測試,大部分研究工作都關(guān)注服務(wù)之間組合關(guān)系的變化,包括接口變化[14,15]、業(yè)務(wù)流程變化[14?17]和動態(tài)綁定關(guān)系變化[15,16]等方面.其中,文獻[14,16]采用路徑分析方法,該方法比較迭代前后服務(wù)之間的調(diào)用路徑變化,進而選擇包含這些路徑變化的測試用例;文獻[17]提出一種圖遍歷技術(shù),該方法與路徑分析方法類似,但更貼近代碼層面,需要代碼生成的控制流圖作為輸入;文獻[15]分析服務(wù)接口契約的依賴和沖突關(guān)系變化來篩選測試用例.值得注意的是:很多研究都將服務(wù)之間的調(diào)用關(guān)系抽象為有向圖,并將測試用例抽象為圖上的路徑.

在測試用例排序方面,基于覆蓋性的排序研究占多數(shù).文獻[18]提出了一種基于服務(wù)貢獻度的排序技術(shù),該技術(shù)將服務(wù)及其調(diào)用關(guān)系類比程序控制結(jié)構(gòu)并為其分配貢獻度,進而計算測試用例的整體貢獻度,貢獻度高的測試用例排序靠前.文獻[19]提出了一種基于多因素度量的測試用例排序技術(shù),通過計算工作流分支(WBs)、XPath 重寫圖分支(XRGBs)和WSDL 元素(WEs)等因素的綜合度量,結(jié)合所需覆蓋準則對測試用例排序.在基于多因素排序的技術(shù)中,貪心算法被較多采用[20],爬山算法和遺傳算法也偶有采用[21].考慮到微服務(wù)架構(gòu)與關(guān)系圖的相似性,文獻[22]提出了一種基于圖的微服務(wù)分析和測試框架,該框架通過微服務(wù)系統(tǒng)的需求規(guī)約(BDD)生成關(guān)系圖,遍歷關(guān)系圖得到所有服務(wù)調(diào)用路徑集合,進而從目標服務(wù)是否迭代、調(diào)用關(guān)系優(yōu)先級和追溯的規(guī)約層級等方面來對調(diào)用路徑對應(yīng)的測試用例排序.

在測試用例縮減方面,除了直接應(yīng)用單塊架構(gòu)軟件的啟發(fā)式方法、基于模型的方法和測試數(shù)據(jù)聚類等方法外,文獻[23]提出了一種基于多目標優(yōu)化的方法,使得測試用例集的覆蓋性、可靠性和執(zhí)行開銷等目標綜合最優(yōu).文獻[24]提出了一種基于Petri 網(wǎng)的方法,該方法從微服務(wù)系統(tǒng)業(yè)務(wù)規(guī)則的Petri 網(wǎng)模型制定縮減規(guī)則,進而結(jié)合輸入?yún)?shù)組合方式縮減測試用例集合.從近幾年檢索到的論文數(shù)量上看,測試用例集縮減方面的研究明顯少于測試用例選擇和排序.

1.2 Web日志挖掘

Web日志記錄了用戶訪問和資源使用信息,是Web 系統(tǒng)知識挖掘的一種主要數(shù)據(jù)來源[9].Web日志蘊含了用戶訪問和系統(tǒng)運行的知識,常被用于性能分析、流量分析、服務(wù)改進、用戶行為建摸和商業(yè)智能化等目的.Web日志挖掘過程通常包括數(shù)據(jù)預(yù)處理、模式發(fā)現(xiàn)和模式應(yīng)用這3 個步驟.其中:數(shù)據(jù)預(yù)處理階段對原始日志數(shù)據(jù)進行清理整合,轉(zhuǎn)換為格式化數(shù)據(jù)集;模式發(fā)現(xiàn)階段則根據(jù)不同目標,采用相應(yīng)的數(shù)據(jù)挖掘技術(shù),從格式化數(shù)據(jù)集中生成感興趣的模式集合,例如統(tǒng)計分析、路徑分析、關(guān)聯(lián)規(guī)則挖掘、序列模式挖掘和聚類等等;模式應(yīng)用階段則是對挖掘到的模式集合進行分析和應(yīng)用,例如基于關(guān)聯(lián)模式向用戶推薦其感興趣的商品[25]等等.

在針對Web日志的各種數(shù)據(jù)挖掘技術(shù)中,頻繁模式挖掘技術(shù)是最早被研究、也是應(yīng)用最為廣泛的技術(shù)之一[26],它能從Web日志中挖掘出用戶頻繁訪問模式和系統(tǒng)資源之間的頻繁關(guān)聯(lián)模式,通常被作為發(fā)現(xiàn)頻繁路徑、關(guān)聯(lián)規(guī)則和序列模式等目標的支撐技術(shù).頻繁模式挖掘問題可描述如下:給定集合D={T1,T2,T3,…,Tn},每個事務(wù)Ti都是項集合的子集,當確定一個頻繁閾值s(0

微服務(wù)系統(tǒng)的API 網(wǎng)關(guān)層日志記錄了其運行過程中的每一次API 請求.在工程實踐中,開發(fā)運維人員主要關(guān)注故障記錄和調(diào)試信息,而占據(jù)日志數(shù)量絕大部分的請求成功記錄通常被忽略.事實上,這些正常數(shù)據(jù)蘊含了一段時間內(nèi)用戶對不同業(yè)務(wù)場景的關(guān)注程度和服務(wù)之間的動態(tài)關(guān)聯(lián)等知識,同樣具有很高的價值.因此,本文基于頻繁模式挖掘技術(shù),對微服務(wù)系統(tǒng)API 網(wǎng)關(guān)層日志進行挖掘,從而獲得用戶頻繁關(guān)注的服務(wù)調(diào)用路徑,用于測試用例集縮減.

2 方法描述

本文提出的技術(shù)主要解決在微服務(wù)系統(tǒng)工程實踐中難以獲得系統(tǒng)規(guī)約和架構(gòu)描述時如何縮減測試用例的問題,其輸入主要有API 網(wǎng)關(guān)層日志和原測試用例集,輸出為測試用例縮減集,過程主要包括API 網(wǎng)關(guān)層日志挖掘、測試用例匹配和測試用例縮減這3 個環(huán)節(jié),如圖1所示.下面詳細描述各個環(huán)節(jié).

Fig.1 Sketch map of the method process圖1 方法過程示意圖

2.1 API網(wǎng)關(guān)層日志挖掘

該環(huán)節(jié)從API 網(wǎng)關(guān)層日志中挖掘出服務(wù)調(diào)用頻繁路徑,主要包括數(shù)據(jù)預(yù)處理和頻繁模式挖掘兩項活動.其中:數(shù)據(jù)預(yù)處理從日志數(shù)據(jù)中構(gòu)造用戶請求鏈并生成待挖掘的事務(wù)集,頻繁模式挖掘則基于挖掘算法從事務(wù)集中抽取服務(wù)調(diào)用頻繁路徑.

2.1.1 數(shù)據(jù)預(yù)處理

數(shù)據(jù)預(yù)處理是從原始數(shù)據(jù)中獲得挖掘所需格式化數(shù)據(jù)的重要過程,一般占整個數(shù)據(jù)挖掘工作量的60%[9].微服務(wù)系統(tǒng)中的API 網(wǎng)關(guān)日志,其形式可能隨系統(tǒng)運維要求、記錄機制等各有不同,但一般都包含了請求時間、請求者地址、服務(wù)名稱、負載均衡器分配的服務(wù)實例地址、狀態(tài)碼、響應(yīng)時間、http 代理等信息.本方法即針對包含上述信息的API 網(wǎng)關(guān)日志進行預(yù)處理,包括數(shù)據(jù)清洗、用戶請求識別、用戶請求鏈生成和事務(wù)集生成等4 個步驟.

(1)數(shù)據(jù)清洗

數(shù)據(jù)清洗即是從API 網(wǎng)關(guān)日志中剔除故障請求記錄和系統(tǒng)信息(例如自檢),僅保留請求成功記錄,即響應(yīng)狀態(tài)碼為“2xx”的請求記錄,并從中篩選出上述所需字段信息,形成結(jié)構(gòu)化數(shù)據(jù)集.

(2)用戶請求識別

API 網(wǎng)關(guān)日志中的請求包括來自系統(tǒng)外部的用戶請求以及服務(wù)之間的調(diào)用請求,本步驟即是將用戶請求記錄識別出來,作為構(gòu)造用戶請求調(diào)用鏈的起點.可以采用以下規(guī)則識別出用戶請求記錄:

規(guī)則1.若某請求記錄的請求者地址不在微服務(wù)系統(tǒng)已注冊服務(wù)列表中,則該請求是用戶請求.

微服務(wù)系統(tǒng)中的服務(wù)通常需要在服務(wù)注冊中心進行注冊和發(fā)布,例如zookeeper 或者eureka,如果能從中獲得已注冊微服務(wù)列表,就可以準確判定哪些請求是用戶請求.該規(guī)則屬于直接判定規(guī)則.該規(guī)則需要服務(wù)注冊中心可用且已注冊服務(wù)列表實時更新,否則判定會失效.

規(guī)則2.若某請求記錄的請求方代理為瀏覽器程序,則該請求是用戶請求.

用戶發(fā)起的請求通常需要通過各種瀏覽器程序,例如Chrome,Firefox 等等,如果http 代理信息中包含這些瀏覽器程序信息,則該記錄往往是用戶請求記錄.該規(guī)則屬于間接判定規(guī)則,對于非人工的外部請求無法識別,同時還要維護用戶使用的瀏覽器程序列表,以增加判定的準確性.

規(guī)則3.解析出所有服務(wù)名稱及其對應(yīng)實例地址的列表,若某請求記錄的請求者地址不在列表中,則該請求是用戶請求.

對于給定的API 網(wǎng)關(guān)日志,需要關(guān)注的是被請求服務(wù)的情況,沒有被請求的服務(wù),可以認為不屬于信息挖掘?qū)ο?該規(guī)則也屬于間接判定規(guī)則,無需獲取或維護額外信息,僅靠API 網(wǎng)關(guān)日志信息即可進行判定;但對于日志增量的場景,則每次都需要重新掃描全部日志.

應(yīng)當根據(jù)實際應(yīng)用來采用合適的判定規(guī)則.當然,還可以根據(jù)額外記錄的日志信息來增加判定規(guī)則,例如增加請求觸發(fā)頁面信息,如果該信息不為空,說明該請求是通過前端頁面觸發(fā),可判定該請求為用戶請求.

(3)用戶請求鏈生成

用戶請求鏈生成以用戶請求為起點,構(gòu)建與之關(guān)聯(lián)的服務(wù)調(diào)用關(guān)系,包括聚集與用戶請求相關(guān)聯(lián)的服務(wù)間請求列表和從該關(guān)聯(lián)請求列表生成調(diào)用鏈等活動,流程圖如圖2所示.

Fig.2 Flow chart of user request chain generation圖2 用戶請求鏈生成流程圖

其中,關(guān)聯(lián)請求列表的形成基于微服務(wù)架構(gòu)的另一重要組件“服務(wù)調(diào)用鏈監(jiān)控”來實現(xiàn).服務(wù)調(diào)用鏈監(jiān)控主要通過“埋點”技術(shù),在微服務(wù)系統(tǒng)運行過程中采集、分析和展示服務(wù)調(diào)用情況,為故障診斷、性能優(yōu)化等提供支撐,例如,大眾點評的CAT,Twitter 的Open Zipkin 以及Naver Pinpoint 等.關(guān)聯(lián)同一用戶請求的服務(wù)請求共享同一個追蹤標識(trace id),故通過判定追蹤標識的一致性即可形成用戶請求對應(yīng)的關(guān)聯(lián)請求列表.

請求調(diào)用鏈的樹形結(jié)構(gòu)特征則使得其生成需要采用遞歸算法來實現(xiàn),表1 展示了一種基于深度優(yōu)先的遞歸算法.該算法遍歷關(guān)聯(lián)請求列表中的每條日志(第1 行),如果日志數(shù)據(jù)不在當前請求鏈中,則基于該日志構(gòu)造請求鏈上的新節(jié)點(第2 行~第4 行),并以該節(jié)點作為根節(jié)點、以剩余日志數(shù)組遞歸執(zhí)行算法(第5 行),直至關(guān)聯(lián)請求列表遍歷完成退出遞歸.

Table 1 Request chains generation algorithm表1 基于深度優(yōu)先的調(diào)用鏈生成算法

(4)事務(wù)集生成

由于用戶請求鏈的數(shù)據(jù)結(jié)構(gòu)為樹形結(jié)構(gòu),生成待挖掘事務(wù)集的過程就是生成從根節(jié)點到所有葉子節(jié)點路徑序列的過程.算法也是基于深度優(yōu)先搜索樹結(jié)構(gòu),偽代碼見表2.

Table 2 Transaction set generation algorithm表2 基于深度優(yōu)先的事務(wù)集生成算法

該算法在搜索過程中通過一個棧結(jié)構(gòu)來生成從根節(jié)點到葉子節(jié)點的路徑(第1 行),若棧頂節(jié)點沒有后繼節(jié)點,則倒排棧元素構(gòu)成一條事務(wù)(第2 行、第3 行);若有后繼節(jié)點,則遞歸處理(第4 行~第6 行).當前節(jié)點處理完后彈棧(第9 行).

2.1.2 頻繁模式挖掘

頻繁模式挖掘算法的類型多種多樣,例如基于候選集拼接的算法、基于樹的算法和基于遞歸后綴的算法,分別適用于不同的挖掘場景[26],應(yīng)用時可能需要根據(jù)實際情況進行調(diào)整和重構(gòu).對于微服務(wù)系統(tǒng)的頻繁調(diào)用路徑挖掘場景,挖掘算法需要考慮以下兩個特點.

(1)從數(shù)據(jù)集來看,每個服務(wù)在調(diào)用路徑上的位置不能交換,即項集是有序的,屬于序列模式挖掘[26].同時,由于調(diào)用路徑上的相鄰服務(wù)之間必須存在調(diào)用關(guān)系,則一個調(diào)用路徑的子路徑必須是連通的,例如“a→b→c”的子路徑可以是“a→b”或者“b→c”,但不能是“a→c”.可以計算出,長度為n的調(diào)用路徑存在n(n+1)/2 個子路徑;

(2)從挖掘目標來看,最終輸出的頻繁路徑應(yīng)當包含盡可能多的服務(wù).例如,“a→b”和“a→b→c”如果都是頻繁的,那么只需要輸出“a→b→c”作為頻繁路徑.即:對于輸出的頻繁路徑,不存在任何一條包含它路徑也是頻繁的,屬于最大頻繁模式挖掘[24].

基于上述特點,提出如下定義:S={S1,S2,S3,…,Sm}為服務(wù)集合,序列Ti=〈S1,S2,S3,…,Sk〉(0

定義1.頻繁路徑集F={t|c(t)>m,t∈D},Fk是長度為k頻繁路徑構(gòu)成的集合,即Fk={t|len(t)=k,t∈F}.

推論1.如果一條路徑t不是頻繁的,則包含t的路徑也不是頻繁的.

定義2.最大頻繁路徑集P={p|q∈P∧q?p,p∈F}.

推論2.如果一條路徑t是最大頻繁路徑,則t的所有子路徑都不是最大頻繁路徑.

本文所描述的頻繁路徑挖掘算法是從D挖掘最大頻繁路徑集P的算法,參照Apriori 算法[26]框架設(shè)計,偽代碼見表3.

Table 3 Frequent calling paths mining algorithm表3 頻繁路徑挖掘算法

首先,可以根據(jù)定義1 直接計算F1(第2 行);其次,在推理1 的基礎(chǔ)上,通過得到Fk和F1的笛卡爾積,生成長度為k+1 路徑的候選集(第5 行),進而根據(jù)定義1,從候選集中篩選出Fk+1(第6 行~第9 行);最后,根據(jù)定義2 和推理2,從長度最長的頻繁路徑集到F1依次確定最大頻繁路徑集(第14 行~第22 行).

2.2 測試用例關(guān)聯(lián)

該環(huán)節(jié)主要建立服務(wù)調(diào)用頻繁路徑與測試用例的對應(yīng)關(guān)系,并將支持度信息賦值給相應(yīng)測試用例,主要包括測試用例匹配和支持度歸一化這兩項活動.其中:測試用例匹配從頻繁路徑集中搜索與測試用例關(guān)聯(lián)的服務(wù)調(diào)用路徑;支持度歸一化將支持度轉(zhuǎn)化為0 到1 區(qū)間內(nèi)的數(shù)值,為后續(xù)啟發(fā)式搜索提供輸入.

2.2.1 測試用例匹配

測試用例匹配主要是建立頻繁路徑與測試用例之間的對應(yīng)關(guān)系,由于單元測試不涉及服務(wù)調(diào)用關(guān)系,不在本文討論范圍,本文主要關(guān)注服務(wù)測試和端到端測試.

(1)服務(wù)測試匹配

服務(wù)測試關(guān)注服務(wù)之間的調(diào)用關(guān)系,其測試用例可以直接轉(zhuǎn)化為一條服務(wù)調(diào)用路徑(或稱為測試路徑).匹配過程中,從最長的頻繁路徑開始搜索,對每條頻繁路徑與測試路徑進行匹配,可能出現(xiàn)以下4 種結(jié)果.

①精確匹配到一條頻繁路徑;

②測試路徑是一條或多條頻繁路徑的子路徑;

③有一條或多條頻繁路徑是該測試路徑的子路徑;

④其他情況.

對于匹配結(jié)果①,直接將精確匹配的頻繁路徑關(guān)聯(lián)到測試用例上;對于匹配結(jié)果②,說明測試路徑是頻繁的,但不是最大頻繁的,故將匹配到的所有頻繁路徑中支持度最大的頻繁路徑關(guān)聯(lián)到測試用例上;對于匹配結(jié)果③,雖然該測試路徑本身不是頻繁的,但其包含最大頻繁路徑,故將匹配到所有頻繁路徑中長度最長的頻繁路徑關(guān)聯(lián)到測試用例上;對于匹配結(jié)果④,直接判定為不頻繁,不關(guān)聯(lián)任何頻繁路徑.

(2)端到端測試匹配

端到端測試的測試用例可能對應(yīng)一組服務(wù)調(diào)用路徑(或稱為測試路徑集合),需要對測試路徑集合中的每一條測試路徑進行匹配.匹配結(jié)果的處理方式與服務(wù)測試匹配類似,但將頻繁路徑對應(yīng)到整個測試用例上時,需選擇長度最長的頻繁路徑進行關(guān)聯(lián).

2.2.2 支持度歸一化

考慮到啟發(fā)式搜索需要關(guān)注測試用例之間的差異性,需統(tǒng)一支持度和差異值的取值范圍,故頻繁路徑的支持度不能直接賦予與之關(guān)聯(lián)的測試用例,需要進行歸一化處理.同時,長度更長的頻繁路徑對系統(tǒng)的覆蓋程度更高,應(yīng)優(yōu)先于長度短的頻繁路徑,為此,本文將[0,1)區(qū)間劃分為kmax段(kmax為k的最大值),將Fk中頻繁路徑p的支持度換算到半開區(qū)間[(k?1)/kmax,k/kmax)上,換算公式為

其中,c為p的頻次,n為事務(wù)集D的規(guī)模,cu為歸一化后的支持度.

歸一化之后,即可將支持度賦予關(guān)聯(lián)的測試用例.對于未匹配到頻繁路徑的測試用例,則支持度賦值為0.

2.3 測試用例集縮減

該環(huán)節(jié)基于支持度對原測試用例集搜索其子集,進而輸出符合覆蓋準則要求的測試用例縮減集,主要包括啟發(fā)式搜索和覆蓋性判定這兩項活動.其中:啟發(fā)式搜索方法基于圖搜索方法提出,覆蓋性判定則確認搜索到的測試用例子集滿足覆蓋要求.

2.3.1 啟發(fā)式搜索

啟發(fā)式搜索的目的在于找到一組支持度較大且相互間差異也較大的測試用例集合:支持度較大說明測試用例集符合用戶關(guān)切,差異較大是為了使測試用例集盡快收斂于覆蓋準則要求.注意到支持度屬于測試用例自身屬性,差異性屬于測試用例兩兩關(guān)系的屬性,故可以構(gòu)建一個圖來建模這兩項參數(shù),圖的節(jié)點表示測試用例,圖的邊表示測試用例之間的差異性.則測試用例搜索可以轉(zhuǎn)化為對圖的遍歷問題.

定義3.測試用例搜索圖G=(N,E),其中:N為節(jié)點集合,表征每個測試用例,每個節(jié)點包含2 個屬性,即測試用例的標識和支持度;E為邊的集合,表征測試用例之間的關(guān)系,每條邊有1 個屬性,即邊兩端所表征測試用例的差異性量化值.

本文使用杰卡德距離[25]量化測試用例的差異性,具體做法為:獲得測試用例a和b覆蓋的服務(wù),分別形成集合Sa和Sb,計算兩個集合的杰卡德距離dj,即:

基于定義3 即可設(shè)計從測試用例集生成搜索圖的算法,偽代碼見表4.該算法遍歷所有測試用例,為測試用例創(chuàng)建一個新節(jié)點添加到圖中(第1 行~第3 行),支持度屬性為公式(1)中的cu,并構(gòu)造該節(jié)點與已有節(jié)點的邊也添加到圖中(第4 行~第11 行),邊的屬性通過公式(2)計算獲得.

Table 4 Searching graph generation algorithm表4 搜索圖生成算法

由于搜索測試用例的目標是使得測試用例的支持度較大且相互間差異也較大,故本文采用一種啟發(fā)式算法——貪心算法,來遍歷搜索圖,算法偽代碼見表5.

Table 5 Searching graph traversal algorithm表5 搜索圖遍歷算法

該算法從圖中支持度最大的節(jié)點開始遍歷(第1 行、第2 行),計算當前節(jié)點到每一個相連節(jié)點的轉(zhuǎn)移值,該值為相連節(jié)點的支持度與邊上屬性的和,進而查找轉(zhuǎn)移值最大的第1 個相連節(jié)點(第4 行~第12 行),然后從圖中移除當前節(jié)點及其邊,并將新找到的節(jié)點作為當前節(jié)點繼續(xù)遍歷過程(第13 行~第15 行).該算法的終止條件主要有兩個:一個是圖為空,另一個則是已經(jīng)搜索到的測試用例集滿足覆蓋性判定要求(第4 行).

2.3.2 覆蓋性判定

為了確保啟發(fā)式搜索獲得的測試用例集是“覆蓋安全”[12,28]的,需要判定其是否滿足特定的覆蓋準則,例如服務(wù)覆蓋、調(diào)用關(guān)系覆蓋、特定調(diào)用路徑覆蓋和功能覆蓋等等.實現(xiàn)過程中,需將選定的覆蓋準則定義為函數(shù),并將該函數(shù)的指針傳入搜索圖生成算法中作為搜索過程終止的條件.本文在實驗中使用調(diào)用關(guān)系覆蓋進行覆蓋性判定,即,搜索獲得的測試用例集所包含服務(wù)調(diào)用關(guān)系必須覆蓋原測試用例集所包含的服務(wù)調(diào)用關(guān)系.設(shè)表示測試用例縮減集中的服務(wù)調(diào)用關(guān)系集合,RT表示原測試用例集中的服務(wù)調(diào)用關(guān)系集合,則該覆蓋準則可定義為.

3 實驗驗證

為驗證技術(shù)的有效性,使用某集成辦公系統(tǒng)開發(fā)過程的數(shù)據(jù)進行了實驗.

3.1 系統(tǒng)介紹

該集成辦公系統(tǒng)基于微服務(wù)架構(gòu)設(shè)計開發(fā),為多部門、多密級和跨地域的機構(gòu)人員提供服務(wù).系統(tǒng)提供的功能包括綜合信息展示、公文流轉(zhuǎn)、流程審批、計劃管理、機構(gòu)人員管理、合同管理、經(jīng)費管理和物資管理等.由于業(yè)務(wù)類型和數(shù)據(jù)安全等問題,該系統(tǒng)由多個團隊聯(lián)合開發(fā),開發(fā)周期經(jīng)歷了7 個輪次的迭代,根據(jù)測試過程數(shù)據(jù)統(tǒng)計了每個迭代輪次的服務(wù)數(shù)量(個)、API 網(wǎng)關(guān)日志數(shù)量(條)以及服務(wù)測試和端到端測試的測試用例數(shù)量(個)、發(fā)現(xiàn)的缺陷數(shù)量(個)和執(zhí)行時間(時)情況(測試執(zhí)行方式為手工測試與自動化測試工具相結(jié)合的方式),見表6.

Table 6 Statistical data of an integrated business system表6 某綜合業(yè)務(wù)系統(tǒng)開發(fā)過程統(tǒng)計數(shù)據(jù)

從表6 可以看出:在早期的3 次迭代中,服務(wù)和測試用例的數(shù)量增長較快,屬于系統(tǒng)構(gòu)建階段;在后兩次迭代中,服務(wù)和測試用例的數(shù)量增長較慢,屬于改進階段.隨著測試用例數(shù)量的增加,執(zhí)行測試所需的人天數(shù)也隨之增加,發(fā)現(xiàn)的缺陷數(shù)卻在減少,第4 輪、第5 輪的缺陷數(shù)遠低于前3 輪.一方面,這是系統(tǒng)不斷改進的結(jié)果;另一方面,系統(tǒng)本身增量不大,但要執(zhí)行的測試用例比以前的迭代輪要多,這就造成了一定程度的浪費.到第6 輪時,由于增加了多密級、跨地域等特性的支撐性服務(wù),測試用例數(shù)量又進一步增加,第7 輪服務(wù)基本穩(wěn)定,但測試執(zhí)行過程依然花費了比之前所有輪次更多的資源,類似于前5 輪的變化.與此同時,API 網(wǎng)關(guān)層日志的數(shù)量迅速增加,記錄了系統(tǒng)在各種業(yè)務(wù)場景下的大量用戶操作信息,具備實施本文提出方法的輸入條件.

3.2 實驗設(shè)計

為了驗證本文提出的技術(shù)是否能夠有效縮減測試用例集,并且分析API 網(wǎng)關(guān)層日志規(guī)模對縮減效果的影響,基于項目數(shù)據(jù)采用后驗方式進行實驗驗證,即:在已知測試用例執(zhí)行結(jié)果的情況下,統(tǒng)計縮減后測試用例集數(shù)量、發(fā)現(xiàn)缺陷數(shù)量和執(zhí)行時間,計算評價指標,進而與原始數(shù)據(jù)進行對比分析.設(shè)計如下兩個實驗.

(1)實驗1:測試用例縮減效果實驗.

依據(jù)文獻[6],實驗采用測試用例集縮減率Pe(公式(3))和缺陷發(fā)現(xiàn)能力影響率Pi(公式(4))這兩個指標分析基于本文技術(shù)縮減后測試用例集的有效性:

從公式(3)可知:Pe越大,測試用例縮減得越多,節(jié)省測試資源越多;從公式(4)可知:Pi越小,縮減后測試用例集的缺陷發(fā)現(xiàn)能力越接近原測試用例集.

為了驗證用戶使用信息能否在測試用例集縮減中起到積極作用,實驗中將本文所提技術(shù)與一種經(jīng)典的隨機搜索[6]進行對比,即隨機地從原測試用例集中構(gòu)造測試用例縮減集,并保證滿足測試覆蓋準則.偽代碼見表7,其搜索過程結(jié)束條件就是測試覆蓋準則滿足(第1 行),當不滿足覆蓋準則時,從原測試用例集中隨機選擇一個測試用例并添加到測試用例縮減集中(第2 行、第3 行).在本實驗中,隨機搜索采用的覆蓋準則與本文所提技術(shù)保持一致,即要求縮減后測試用例集覆蓋原測試用例集的服務(wù)調(diào)用關(guān)系.

Table 7 Random searching algorithm表7 隨機搜索算法

實驗步驟如下.

S1.挖掘第k(1≤k≤6)輪的API 網(wǎng)關(guān)層日志記錄,獲得頻繁路徑集,標記為FPk;

S2.將第k+1 輪的測試用例分為沿用測試用例集和新增測試用例集,即完全沿用自第k輪的測試用例,在該系統(tǒng)中與第k輪測試用例完全相同,新增測試用例則為第k+1 輪根據(jù)系統(tǒng)增量新生成的測試用例;

S3.基于S1 中獲得的頻繁路徑集對S2 中的沿用測試用例集進行縮減,并將縮減后的測試用例集與S2 中的新增測試用例集合并,作為第k+1 輪縮減后的測試用例集T1;

S4.采用隨機搜索技術(shù)對S2 中的沿用測試用例集進行縮減,并將縮減后的測試用例集與S2 中的新增測試用例集合并,作為第k+1 輪用于對比的測試用例集T2;

S5.對照測試記錄統(tǒng)計T1和T2的缺陷發(fā)現(xiàn)數(shù)量,計算各自的Pe和Pi,然后進行對比分析;

S6.統(tǒng)計縮減后測試用例執(zhí)行時間,計算測試用例縮減后節(jié)省的時間.同時,統(tǒng)計每輪迭代生成T1過程的時間開銷,進而驗證測試用例縮減帶來的時間收益;

(2)實驗2:API 網(wǎng)關(guān)層日志規(guī)模對縮減效果的影響實驗.

S7.挖掘第7 輪的API 網(wǎng)關(guān)層日志記錄,獲得頻繁路徑集,標記為FP7;

S8.基于FPk(1≤k≤7)對第7 輪測試用例集進行縮減,分別得到7 個縮減后的測試用例集;

S9.計算對比縮減后測試用例集的Pe和Pi,分析API 網(wǎng)關(guān)層日志規(guī)模對縮減效果的影響.

3.3 實驗結(jié)果與分析

(1)實驗1 結(jié)果與分析

根據(jù)實驗1 的過程,挖掘出第1 輪~第6 輪的API 網(wǎng)關(guān)層日志,并將結(jié)果分別用于第2 輪~第7 輪測試用例集的縮減,然后統(tǒng)計縮減后的測試用例數(shù)、發(fā)現(xiàn)的缺陷數(shù)以及工作量,并計算Pe和Pi.其中,測試用例集T1相關(guān)數(shù)據(jù)見表8,測試用例集T2相關(guān)數(shù)據(jù)見表9.同時,統(tǒng)計每輪迭代生成T1過程的時間開銷,計算環(huán)境為英特爾酷睿i7 處理器、32GB 內(nèi)存和CentOS7.6 操作系統(tǒng),相關(guān)數(shù)據(jù)見表10.

Table 8 S tatistical data of T1 in the experiment 1表8 實驗1 中T1 相關(guān)數(shù)據(jù)

Table 9 S tatistical data of T2 in the experiment 1表9 實驗1 中T2 相關(guān)數(shù)據(jù)

Table 10 Time expenses in T1 generation and the time saved using test suite minimization表10 T1 生成過程的時間開銷和測試用例縮減后節(jié)省的時間

從表8 和表9 中的數(shù)據(jù)可以看出:兩種測試用例縮減技術(shù)在滿足覆蓋準則的條件下,都能縮減測試用例集的規(guī)模,對其缺陷發(fā)現(xiàn)能力的影響各有差異.為了直觀比較兩種方法縮減測試用例的效果,分別將Pe和Pi繪制成折線圖,其中,Pe對比折線圖如圖3所示,Pi對比折線圖如圖4所示.

從圖3 中可以看出:本文提出的測試用例縮減技術(shù)與基于隨機搜索的測試用例縮減技術(shù)都能大幅減少測試用例的規(guī)模,進而減少測試執(zhí)行所需的工作量,并且縮減能力大致相當,約40%左右.同時也表明了在微服務(wù)系統(tǒng)實際使用過程中,各個服務(wù)調(diào)用頻率確實存在差異.從圖4 可知:基于隨機搜索技術(shù)縮減的測試用例集合T2的缺陷發(fā)現(xiàn)能力同樣產(chǎn)生了明顯下降,降幅達到至少30%以上;特別是在新增測試用例較少時,其缺陷發(fā)現(xiàn)能力受影響越大.這說明:由于服務(wù)之間關(guān)聯(lián)的動態(tài)性,微服務(wù)架構(gòu)的服務(wù)測試不能簡單參照單塊架構(gòu)的測試覆蓋準則,否則會造成不少缺陷被遺漏的情況.與之相對的,基于本文提出技術(shù)縮減的測試用例集合T1的缺陷發(fā)現(xiàn)能力并未受到太大影響,降幅不超過10%;尤其是在新增測試用例較少時,基本能維持原有測試用例集的缺陷發(fā)現(xiàn)能力.這主要是因為T1在滿足測試覆蓋準則的同時,一并考慮了系統(tǒng)實際運行過程的用戶使用信息,從而保留了頻次高的服務(wù)調(diào)用路徑對應(yīng)的測試用例,這些路徑類似于高速公路中“樞紐”,請求頻次多、用戶使用場景覆蓋較為全面,相應(yīng)地,測試用例對整體測試用例集缺陷發(fā)現(xiàn)能力的貢獻更為突出.

通過表10 數(shù)據(jù)可知:本次實驗中T1生成過程的時間開銷不超過1 小時,遠遠小于測試用例縮減后節(jié)省的時間,說明本文所提技術(shù)在實驗中確實起到了節(jié)省測試時間的作用.同時,本文所提技術(shù)的時間開銷主要集中在日志挖掘環(huán)節(jié),對于近百萬級規(guī)模的日志挖掘時間相對較長,這是由于未做增量式挖掘而造成每次迭代都要完整掃描整個日志數(shù)據(jù)的緣故,是下一步需要改進的地方.

Fig.3 Pe comparison line chart of two test suites圖3 兩種測試用例集的Pe 對比折線圖

Fig.4 Pi comparison line chart of two test suites圖4 兩種測試用例集的Pi 對比折線圖

另外,由于第2 輪、第3 輪迭代中T1和T2都出現(xiàn)了遺漏的缺陷,為了進一步分析本文所提技術(shù)的應(yīng)用效果,我們對第2 輪、第3 輪迭代中T1和T2遺漏的缺陷和已發(fā)現(xiàn)的缺陷進行了梳理,根據(jù)案例過程文檔定義的缺陷等級(致命、嚴重、一般、建議)和這些缺陷對應(yīng)測試用例的支持度(見公式(1))平均值進行了統(tǒng)計對比,見表11和表12.

從表11 和表12 的缺陷等級分布對比可看出:T1發(fā)現(xiàn)了全部“嚴重”等級以上的缺陷,遺漏的缺陷主要是“建議”等級的缺陷;而T2在各個等級的缺陷上均有遺漏.這進一步說明了本文所提技術(shù)在保留測試用例發(fā)現(xiàn)缺陷的能力上要好于僅考慮測試覆蓋準則的隨機搜索技術(shù).同時,T1遺漏缺陷對應(yīng)的測試用例支持度平均值為0,表明這些缺陷分布在日志中未出現(xiàn)或出現(xiàn)頻次小于頻繁閾值的業(yè)務(wù)上,具有明顯的規(guī)律性,可以從已移除的測試用例中增選支持度為0 的測試用例,對缺陷發(fā)現(xiàn)能力的“缺損”進行彌補.

Table 11 Statistical data of defects found and missed in the second and third rounds by T1表11 第2 輪、第3 輪T1 發(fā)現(xiàn)和遺漏的缺陷情況統(tǒng)計

Table 12 Statistical data of defects found and missed in the second and third rounds by T2表12 第2 輪、第3 輪T2 發(fā)現(xiàn)和遺漏的缺陷情況統(tǒng)計

(2)實驗2 結(jié)果與分析

根據(jù)實驗2 的過程,挖掘出第7 輪的API 網(wǎng)關(guān)層日志,結(jié)合實驗1 中對前6 輪日志的挖掘結(jié)果,分別用于第7 輪測試用例集的縮減,然后統(tǒng)計縮減后的測試用例數(shù)量、發(fā)現(xiàn)缺陷數(shù)量,進而計算Pe和Pi,結(jié)果見表13.

Table 13 Statistical data in the experiment 2表13 實驗2 的相關(guān)數(shù)據(jù)

從表13 中的數(shù)據(jù)可以看出:日志規(guī)模對測試用例集的規(guī)?？s減程度和缺陷發(fā)現(xiàn)能力都有影響,日志規(guī)模越大、覆蓋面越全,測試用例集縮減效果就越好.這是由于從API 網(wǎng)關(guān)層日志中挖掘到的頻繁路徑更豐富,匹配到的測試用例集更多,對原先支持度為0 的測試用例也被賦予了支持度,為啟發(fā)式搜索提供的信息量更大,有利于搜索到更優(yōu)的測試用例集.

3.4 實驗結(jié)論

綜合上述兩個實驗結(jié)果,可得出以下結(jié)論.

(1)本文提出的測試用例縮減技術(shù)能夠縮減測試用例規(guī)模40%以上,且從缺陷等級上看,其缺陷發(fā)現(xiàn)能力要好于單純考慮測試覆蓋準則的隨機搜索技術(shù);

(2)本文提出的測試用例縮減技術(shù)對原測試用例集缺陷發(fā)現(xiàn)能力的降幅不超過10%,且遺漏的缺陷主要分布在日志中未出現(xiàn)或很少出現(xiàn)的業(yè)務(wù)上;

(3)本文提出的測試用例縮減技術(shù)受API 網(wǎng)關(guān)層日志規(guī)模的影響,日志規(guī)模越大、覆蓋面越全,測試用例集縮減效果就越好.

需要說明的是:受項目素材限制,上述結(jié)論是否適用于不同領(lǐng)域、各種規(guī)模的微服務(wù)系統(tǒng),還需要進一步開展工程實證.

4 總結(jié)與下一步工作

本文闡述了一種基于API 網(wǎng)關(guān)層日志挖掘的微服務(wù)系統(tǒng)測試用例集縮減技術(shù),詳細描述了該技術(shù)的框架和每個步驟環(huán)節(jié),并通過實驗對其有效性進行了驗證.該技術(shù)不要求微服務(wù)系統(tǒng)規(guī)約和架構(gòu)描述作為輸入信息,而是從API 網(wǎng)關(guān)層日志挖掘服務(wù)及其調(diào)用關(guān)系,并作為測試用例縮減的依據(jù),適用于微服務(wù)系統(tǒng)工程實踐.該技術(shù)挖掘出的頻繁路徑信息真實反映了服務(wù)動態(tài)運行情況,使測試用例集側(cè)重用戶使用頻次高的業(yè)務(wù)功能,避免測試場景偏離使用場景,一定程度上提高了測試效率.該技術(shù)包含了覆蓋準則的判定要求,是“覆蓋安全”的方法.該技術(shù)各環(huán)節(jié)均可使用程序?qū)崿F(xiàn),無需手工干預(yù),能夠自動化縮減測試用例集.

從技術(shù)落地的角度考慮,下一步將開展如下3 個方面的工作.

(1)本文提出的技術(shù)主要關(guān)注對原有測試用例集的縮減,未考慮系統(tǒng)變化對測試用例選擇的影響,故縮減后的測試用例集不能發(fā)現(xiàn)未實現(xiàn)服務(wù)調(diào)用關(guān)系中的缺陷,實驗中是通過直接沿用新增測試用例彌補這一覆蓋性.我們將研究日志變化與微服務(wù)系統(tǒng)變化之間的關(guān)系,進而將日志變化作為參考因素,對新增的測試用例進行選擇;

(2)本文提及的日志挖掘技術(shù)是非增量式的,每一輪迭代都要重復(fù)掃描整個日志內(nèi)容,這在實際應(yīng)用過程中會造成一定的計算資源開銷.我們將結(jié)合增量式日志挖掘方法改進本文所提技術(shù),并探討模式挖掘的可復(fù)用工作模式,一次挖掘、多處使用,進一步提升技術(shù)性能;

(3)本文所提技術(shù)在本質(zhì)上是通過挖掘日志信息獲得用戶使用模式,進而將其作為測試用例縮減的參考因素.事實上,該技術(shù)并不依賴于API 網(wǎng)關(guān)層,對于其他架構(gòu)特征,例如服務(wù)網(wǎng)格等,只要能獲得服務(wù)調(diào)用日志數(shù)據(jù),便可應(yīng)用本技術(shù).下一步將嘗試在不同領(lǐng)域、不同架構(gòu)模式的系統(tǒng)中應(yīng)用本技術(shù),采用更多的項目素材進行工程實證研究.