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

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

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

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

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

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

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

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

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

1 相關研究

1.1 微服務回歸測試

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

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

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

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

1.2 Web日志挖掘

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

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

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

2 方法描述

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

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

2.1 API網關層日志挖掘

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

2.1.1 數據預處理

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

(1)數據清洗

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

(2)用戶請求識別

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

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

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

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

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

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

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

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

(3)用戶請求鏈生成

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

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

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

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

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

(4)事務集生成

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

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

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

2.1.2 頻繁模式挖掘

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

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

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

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

定義1.頻繁路徑集F={t|c(t)>m,t∈D},Fk是長度為k頻繁路徑構成的集合,即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]框架設計,偽代碼見表3.

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

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

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

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

2.2.1 測試用例匹配

測試用例匹配主要是建立頻繁路徑與測試用例之間的對應關系,由于單元測試不涉及服務調用關系,不在本文討論范圍,本文主要關注服務測試和端到端測試.

(1)服務測試匹配

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

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

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

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

④其他情況.

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

(2)端到端測試匹配

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

2.2.2 支持度歸一化

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

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

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

2.3 測試用例集縮減

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

2.3.1 啟發(fā)式搜索

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

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

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

基于定義3 即可設計從測試用例集生成搜索圖的算法,偽代碼見表4.該算法遍歷所有測試用例,為測試用例創(chuàng)建一個新節(jié)點添加到圖中(第1 行~第3 行),支持度屬性為公式(1)中的cu,并構造該節(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é)點的轉移值,該值為相連節(jié)點的支持度與邊上屬性的和,進而查找轉移值最大的第1 個相連節(jié)點(第4 行~第12 行),然后從圖中移除當前節(jié)點及其邊,并將新找到的節(jié)點作為當前節(jié)點繼續(xù)遍歷過程(第13 行~第15 行).該算法的終止條件主要有兩個:一個是圖為空,另一個則是已經搜索到的測試用例集滿足覆蓋性判定要求(第4 行).

2.3.2 覆蓋性判定

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

3 實驗驗證

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

3.1 系統(tǒng)介紹

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

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

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

3.2 實驗設計

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

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

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

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

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

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

實驗步驟如下.

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

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

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

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

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

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

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

S7.挖掘第7 輪的API 網關層日志記錄,獲得頻繁路徑集,標記為FP7;

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

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

3.3 實驗結果與分析

(1)實驗1 結果與分析

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

Table 8 S tatistical data of T1 in the experiment 1表8 實驗1 中T1 相關數據

Table 9 S tatistical data of T2 in the experiment 1表9 實驗1 中T2 相關數據

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

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

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

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

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

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

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

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

(2)實驗2 結果與分析

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

Table 13 Statistical data in the experiment 2表13 實驗2 的相關數據

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

3.4 實驗結論

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

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

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

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

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

4 總結與下一步工作

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

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

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

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

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