夏同飛，鄭　浩

(1. 國網(wǎng)信通產(chǎn)業(yè)集團安徽繼遠軟件有限公司，安徽 合肥 230088； 2. 國網(wǎng)安徽省電力公司，安徽 合肥 230061)

?

大型軟件回歸測試用例選擇優(yōu)化策略

夏同飛1，鄭浩2

(1. 國網(wǎng)信通產(chǎn)業(yè)集團安徽繼遠軟件有限公司，安徽 合肥 230088； 2. 國網(wǎng)安徽省電力公司，安徽 合肥 230061)

摘要:在軟件回歸測試時需要制定測試策略，選擇有效測試用例進行測試以避免測試的盲目性. 針對大型軟件回歸測試用例的選擇問題本文提出一種新的選擇方法并對其進行算法設(shè)計和實現(xiàn). 本文運用Uml用例圖來描述系統(tǒng)功能模塊間的關(guān)系，將UML圖轉(zhuǎn)換為有向圖并通過有向圖的遍歷算法輸出回歸測試時需要測試的模塊. 通過實例研究表明，運用此方法能夠顯著提高回歸測試中測試的效率和準確性，在保證了回歸測試覆蓋度的同時減少了測試的冗余度.

關(guān)鍵詞:回歸測試； 測試用例； UML用例圖； 軟件測試； 黑盒測試

在軟件研發(fā)過程中設(shè)計人員通過架構(gòu)設(shè)計將軟件系統(tǒng)分割為多個功能模塊，但由于需求變更或缺陷修復(fù)經(jīng)常要對某些代碼進行修改，而大型軟件有多個功能，它們之間有各種關(guān)聯(lián)關(guān)系,僅僅測試修改的模塊是不夠的，需要進行所謂的回歸測試. 回歸測試是指修改了舊代碼后，重新進行測試以確認修改沒有引入新的錯誤或?qū)е缕渌a產(chǎn)生錯誤[1]. 回歸測試在整個軟件測試過程中占有很大的工作量比重，軟件開發(fā)的各個階段都會進行多次回歸測試. 據(jù)估計，回歸測試在整個測試預(yù)算中占80%，在軟件維護中占50%[2]. 如果對回歸測試用例不做選擇與優(yōu)化將給軟件測試工作帶來大量重復(fù)無效的工作，影響測試人員工作興趣與發(fā)現(xiàn)問題的敏感度. 在漸進和快速迭代開發(fā)中，新版本的連續(xù)發(fā)布使回歸測試進行的更加頻繁，而在極限編程開發(fā)模式下，更是要求每天都進行若干次回歸測試[3]. 因此，通過選擇正確的回歸測試策略來提高回歸測試的速度和有效性是非常有意義的.

回歸測試的目的一是要對新修改的部分增加測試用例重新測試，二是測試其他模塊是否會受到影響. 在回歸測試開始前測試人員一般已有一個用例庫，對于大型軟件模塊眾多，每次回歸測試執(zhí)行所有模塊測試用例是沒有必要也不現(xiàn)實的. 而憑個人經(jīng)驗選擇需要測試的模塊又是不夠科學(xué)可靠的. 此外測試人員一般無法得到軟件代碼，即使能得到，通過分析代碼來確定模塊間關(guān)系也需要大量時間，無法滿足快速回歸的要求. 需要有個簡單而精準的方法找出修改模塊會受到影響的模塊進行測試. 本文介紹的重點內(nèi)容即是通過算法自動在大量的模塊中選擇有影響有關(guān)聯(lián)的模塊來幫助測試人員選擇回歸測試用例.

1基于模塊關(guān)系的回歸測試選擇方案

由于在快速迭代的回歸測試過程中，大型軟件代碼龐大復(fù)雜，測試人員沒有精力從代碼級別研究修改帶來的影響，有研究人員給出了基于模型的影響分析方法[4-7]，這些方法跟蹤模型各元素間的依賴關(guān)系來給出修改影響分析而不需要接觸源代碼，給我們一定的啟發(fā).

模塊間相互關(guān)聯(lián)往往是因為共用資源(資源可以是數(shù)據(jù)表，文件、 流向多個模塊的數(shù)據(jù)等)或彼此的相互調(diào)用子模塊造成的. 而有時模塊修改造成的影響是要通過多個模塊的傳遞才會影響到另一模塊. 對于大型軟件可能模塊眾多，關(guān)聯(lián)模塊路徑較長，測試者在回歸測試過程中沒有太多時間研究所有關(guān)聯(lián)模塊，我們可以引入自動搜索功能來自動增加需要測試的關(guān)聯(lián)模塊. 對于這種分析多個元素相互聯(lián)系方式的問題我們應(yīng)該使用圖結(jié)構(gòu)來解決[8].

圖1　關(guān)聯(lián)規(guī)則示例Fig.1　The example of correlations rule

測試人員在軟件設(shè)計時期可以得到軟件架構(gòu)設(shè)計文檔，并且有充分的時間做產(chǎn)品分析，因此可以在此期間詳細畫出各模塊間的關(guān)聯(lián)關(guān)系圖，基于各模塊測試人員應(yīng)該一起進行討論，貢獻自己了解的那一部分，共同完成該系統(tǒng)的各功能模塊的關(guān)聯(lián)關(guān)系圖[8]，如圖1 所示. 當測試開始后測試工作進度緊張，測試人員可能在回歸測試時沒有時間研究規(guī)模龐大的模塊關(guān)聯(lián)圖，此時應(yīng)該使用計算機程序算法將圖形化的模塊關(guān)聯(lián)關(guān)系抽取出來，針對某一模塊的改動自動搜索出有影響的模塊. 隨著測試工作的深入，測試人員對大型軟件越來越熟悉，每輪測試后應(yīng)該對關(guān)聯(lián)關(guān)系圖進行更新和修正，以確保測試的準確性[9].

1.1解決方案基本思路

通過有向圖的結(jié)構(gòu)來確定各功能模塊的關(guān)系，當一個模塊發(fā)生變化時利用有向圖深度優(yōu)先遍歷的算法搜索有關(guān)聯(lián)的模塊來確定需要測試的其他模塊. 首先需要引入工具能形象快捷地畫出各功能模塊之間的關(guān)聯(lián)關(guān)系，然后從圖形文件中檢索出關(guān)系結(jié)構(gòu)，形成可供算法處理的數(shù)據(jù)結(jié)構(gòu)，最后當某一功能節(jié)點變更后通過算法輸出所有有關(guān)聯(lián)的模塊，相應(yīng)增加關(guān)聯(lián)模塊的測試優(yōu)先級，避免遺漏.

1.2工具選擇

很多研究人員做了通過UML圖模型自動生成測試用例的研究[10-13]，這對解決這一問題提供了思路. 在軟件工程中通常用UML來進行建模，而UML用例圖和測試用例有一定對應(yīng)關(guān)系，可以通過UML的用例圖來實現(xiàn)測試用例對應(yīng)需求模塊的圖形關(guān)系. 使用UML圖中的用例圖清晰指明各功能模塊的關(guān)聯(lián)關(guān)系，可以把這些功能模塊作為圖的頂點，關(guān)聯(lián)關(guān)系作為圖的邊，圖的頂點與測試用例所覆蓋需求名稱對應(yīng). Rational rose 工具作為業(yè)內(nèi)通用UML工具且生成的MDL文件為明文形式很方便我們通過程序進行分析[10].

規(guī)則定義： 在用例圖中模塊之間關(guān)系相連，會相互影響，而影響也會傳導(dǎo)，一個模塊修改后通過關(guān)系傳導(dǎo)會影響到多個模塊. 我們要通過圖結(jié)構(gòu)的算法在錯綜復(fù)雜的關(guān)系中把修改一個模塊所有受影響的模塊全部搜索出來. 因此首先做如下約定.

約定一：由于共用資源(包括數(shù)據(jù)表，文件等)是產(chǎn)生模塊關(guān)聯(lián)的重要元素，所以必須在用例圖中畫出，對于如“更新數(shù)據(jù)庫”等模塊應(yīng)該有一條指向數(shù)據(jù)文件的關(guān)系，而對于“查詢數(shù)據(jù)庫”之類獲取信息的模塊應(yīng)該有一條關(guān)系從數(shù)據(jù)庫/數(shù)據(jù)文件指向查詢模塊，以表示信息傳遞. 其他規(guī)則與UML用例圖相同.

約定二：通過模塊間的分解包含關(guān)系可生成一張多頂點的有向圖，其中模塊為頂點，關(guān)系為弧. 當一個模塊修改后對于該模塊通過關(guān)系弧能到達的所有模塊稱為該模塊的直接影響模塊組.

約定三：對于修改模塊和其直接影響模塊組以外的模塊在圖中做深度優(yōu)先遍歷，如果能到達修改模塊或直接影響模塊組中的模塊則這些模塊為間接受影響模塊.

通過找出所有直接影響模塊組和所有間接影響模塊組可以確定回歸測試需要測試的模塊，從而根據(jù)實際情況選擇回歸測試用例以達到優(yōu)化.

1.3操作步驟實例解析

以一個超市進貨管理系統(tǒng)來說明操作方法.

1) 用例圖描述：圖2 所示用例圖為該系統(tǒng)的部分用例圖，分為3個角色：商品管理員，收銀員，系統(tǒng)管理員. 商品管理員負責貨品的管理，可以添加、 修改貨品并將數(shù)據(jù)存入貨品數(shù)據(jù)庫，還可以查詢存入的貨品； 收銀員給客戶結(jié)賬的時候系統(tǒng)會更新柜臺商品數(shù)據(jù)庫； 當貨品缺貨時收銀員可以選擇庫存的貨品上架，貨品上架后，貨品數(shù)據(jù)庫減少一條記錄，柜臺數(shù)據(jù)庫增加一條數(shù)據(jù).

圖2　系統(tǒng)UML圖實例Fig.2　UML use-case diagram

2) MDL文件解析： 數(shù)據(jù)結(jié)構(gòu)中，圖必須有頂點和頂點間的弧，只有確定這兩個要素才能運用到具體的算法中. 業(yè)界通用的UML工具rational rose當狀態(tài)圖畫畫好之后會存儲在一個MDL文件中，通過文本形式打開MDL文件，可以看到圖3所示的usecase節(jié)點結(jié)構(gòu). 這些Object UseCase 是需求細分模塊，可以作為有向圖的頂點. 圖4為MDL文件中用例間的關(guān)聯(lián)關(guān)系結(jié)構(gòu)截圖，顯示了源點和終點可以作為有向圖的弧可以作為圖結(jié)構(gòu)的弧. 從文件內(nèi)容得出，可以通過編寫程序讀取MDL文件中的內(nèi)容并存儲到圖結(jié)構(gòu)的頂點和弧中來確定UML圖的算法模型. 通過這種精確的方法可以在回歸測試開始時清晰地分析出受影響的模塊和不受影響的模塊. 一方面避免漏測某些隱藏較深的關(guān)聯(lián)模塊，另一方面避免測試的盲目性，簡化測試用例規(guī)模，能夠加快回歸測試效率，提高測試覆蓋度，滿足大型軟件迭代開發(fā)和長期頻繁維護升級的快速響應(yīng)需要.

圖3　MDL文件Usecese結(jié)構(gòu)Fig.3　The Usecase struct in MDL file

圖4　MDL文件關(guān)聯(lián)關(guān)系結(jié)構(gòu)Fig.4　The association struct in MDL file

3) 針對修改模塊找出關(guān)聯(lián)模塊：當系統(tǒng)部分需求發(fā)生變化時，除了要測試變化的模塊還需要同時測試關(guān)聯(lián)模塊.

4) 最后在制定測試策略時選擇覆蓋這些需求功能的用例來進行回歸測試.

1.4實際驗證

為了驗證思路的正確性，通過一個軟件研發(fā)中常見的情況予以說明.

1) 為了適應(yīng)用戶需求，系統(tǒng)的“新增貨品”模塊發(fā)生變更，增加了物品信息字段.

2) 測試人員通過本方法進行用例選擇. 首先通過深度優(yōu)先遍歷找出有直接影響的模塊，分別是：“填寫貨物信息”，“存入貨品數(shù)據(jù)庫”，“ 貨品數(shù)據(jù)庫”，“ 查詢貨品數(shù)據(jù)庫”. 然后找出有間接影響的模塊，方法是遍歷所有模塊頂點，如果與這些模塊存在路徑則標記為有間接影響的模塊. 在本實例中有以下模塊被間接影響：“進貨管理”，“修改貨品”，“更新貨品信息”，“存入貨品數(shù)據(jù)庫”，“貨品查詢”，“顯示貨品信息”，“上架管理”，“顯示庫存信息”，“上架”，“刪除貨品數(shù)據(jù)庫中的上架貨品”.

3) 結(jié)果分析：當增加了物品信息字段，會對貨品數(shù)據(jù)庫結(jié)構(gòu)產(chǎn)生直接影響，增、 刪、 改、 查數(shù)據(jù)都需要做相應(yīng)修改，因此用到這些功能的模塊都需要測試，分析以上列出的直接影響和模塊都涉及到了貨品數(shù)據(jù)庫，是正確的. 而“選擇貨品”，“更新柜臺商品”，“結(jié)賬”，“缺陷管理”等模塊與新增貨品沒有聯(lián)系，不需要測試，步驟中也沒有列出. 因此思路是正確的.

4) 如果不用此方法選擇測試用例，可能會出現(xiàn)以下情況： ① 測試人員只選擇貨品數(shù)據(jù)庫直接關(guān)聯(lián)的“進貨管理模塊”用例進行測試，而對“顯示庫存信息”，“上架”等受間接影響?？斓臏y試則可能會遺漏，產(chǎn)生測試隱患. 而實際上貨品數(shù)據(jù)庫字段改變會影響所有查詢、 顯示該數(shù)據(jù)庫信息的模塊. ② 選擇所有模塊用例進行回歸. 這樣會把一些沒有影響的模塊也測試了，不但不能發(fā)現(xiàn)問題而且還影響了測試響應(yīng)速度. ③ 分析所有模塊源代碼來選擇測試用例，這將耗費大量時間與精力，這種方法在大型軟件快速回歸測試中是不現(xiàn)實的.

2策略實現(xiàn)

本文中的策略主要是通過圖的深度優(yōu)先算法來實現(xiàn)，因此首先要創(chuàng)建圖的數(shù)據(jù)結(jié)構(gòu).

2.1數(shù)據(jù)結(jié)構(gòu)

按照計算機基礎(chǔ)課程數(shù)據(jù)結(jié)構(gòu)中有向圖的十字鏈表結(jié)構(gòu)來實現(xiàn)策略，本文用Java語言描述

算法 1數(shù)據(jù)結(jié)構(gòu)

2.2圖的創(chuàng)建方法

算法 2圖的創(chuàng)建

2.3根據(jù)系統(tǒng)變化情況輸出有直接影響的模塊

算法 3輸出直接影響的模塊

2.4輸出受變化功能模塊間接影響的功能模塊

算法 4輸出間接影響的模塊

3結(jié)束語

本文通過UML圖，理清了軟件各模塊的直接關(guān)系，研究了通過圖的遍歷算法輸出修改一個模塊可能會影響到的其他模塊. 通過這個策略優(yōu)化回歸測試用例選擇方法，提高測試準確性，避免測試漏測失誤. 加快測試速度以適應(yīng)快速多版本迭代的開發(fā)模式.

參考文獻：

[1]Muccini H, Dias M, Richardson D. Towards software architecture-based regression testing[J]. ACM SIGSOFT Software Engineering Notes, 2005, 30(4): 1-7.

[2]Harrold M J. Reduce, reuse, recycle, recover: techniques for improved regression testing[C]. Proceedings of the IEEE International Conference on Software Maintenance. Netherlands: IEEE, 2009: 5.

[3]李丹，劉杰. 軟件回歸測試及其實踐[J]. 電子產(chǎn)品可靠性與環(huán)境試驗，2001，2(6): 23-25.

Li Dan, Liu Jie. Software regression testing and its application[J]. Electronic Product Reliability and Enviromental Test, 2001, 2(6): 23-25. (in Chinese)

[4]Briand L C, Labiche Y, Sullivan L O. Impact analysis and change management of UML models[C]. International Conference on Software Maintenance. Netherlands: IEEE, 2003: 256-265.

[5]Briand L C, Labiche Y, Sullivan L O, et al. Automated impact analysis of UML models[J]. Journal of Systems and Software, 2006, 79(3): 339-352.

[6]Tang P H. Design based change impact modeling for object-oriented software[D]. New York: State University of New York, 2003.

[7]王映輝，王立福. 軟件體系結(jié)構(gòu)演化模型[J]. 電子學(xué)報，2005, 3(8): 1381-1386.

Wang Yinghui, Wang Lifu. Research about model and ripple effect analysis of software architecture evolution[J]. Journal of Electronics, 2005, 3(8):1381-1386. (in Chinese)

[8]羅文兵，趙亮，趙洪宇. 基于圖分析的測試用例集優(yōu)化[J]. 計算機工程，2010，15(36): 92-96.

Luo Wenbing, Zhao Liang, Zhao Hongyu. Test suite optimization based on graph analysis[J]. Computer Engineering, 2010, 15(36): 92-96. (in Chinese)

[9]李寧，李戰(zhàn)懷. 基于黑盒測試的軟件測試策略研究與實踐[J]. 計算機應(yīng)用研究，2009，3(26): 923-926.

Li Ning, Li Zhanhuai. Research and practice of software test policies based on black box testing[J]. Application Research of Computers, 2009，3(26): 923-926. (in Chinese)

[10]張毅坤，施鳳鳴. 從Rose的規(guī)約文件自動生成測試用例[J]. 計算機應(yīng)用，2003，12(23): 12-16.

Zhang Yikun, Shi Fengming. Automatic test cases generation from rational rose specification files[J].Computer Applications, 2003, 12(23): 12-16. (in Chinese)

[11]蘇翠翠，王曉軍. 基于UML活動圖的測試用例生成方法研究[J]. 計算機技術(shù)與發(fā)展，2010，8(20): 49-51.

Su Cuicui, Wang Xiaojun. Research on automatic generating test cases method based on UML activity diagram[J]. Computer Technology and Development, 2010, 8(20): 49-51. (in Chinese)

[12]蔡素梅，梅登華. 基于動態(tài)切片和UML圖的回歸測試用例生成[J]. 計算機工程, 2009, 8(35): 70-72.

Cai Sumei, Mei Denghua. Regression test case generation based on dynamic slicing and UML diagram[J].Computer Engineering, 2009, 8(35): 70-72. (in Chinese)

[13]葉皚，蘇厚勤. 基于UML活動圖的系統(tǒng)測試方法研究[J]. 計算機應(yīng)用與軟件, 2010, 12(27): 132-134.

Ye Ai, Su Houqin. Study on UML activity diagram-based system testing method[J].Computer Applications and Software, 2010, 12(27): 132-134. (in Chinese)

Regression Test Case Selection Stratege for Large Scale Software

XIA Tongfei1, ZHENG Hao2

(1. Anhui Jiyuan Software Co. Ltd., State Grid Information & Telecommunication Group, Hefei 230088, China;2. State Grid Anhui Electric Power Company, Hefei 230061, China)

Abstract:It is necessary to make the test strategy in software regression test and the effective test case can avoid the blindness of the test.,In order to solve the problem of how to choose valid regression test cases for large scale software, a new selection method and the algorithm design for this method were proposed in this paper. In this method,UML use-case diagram was used to describe correlations among modules of software system.After converting the UML diagram to directed graph, the modules which need to be tested will be output by using traversing graph algorithm during regression testing.It is validated through a case study that this method can improve the efficiency and accuracy of testing ,and avoid redundancy test case selection and keep the high testing coverage.

Key words:regression testing; test case; UML use-case diagrams; software tetsing; black box testing

中圖分類號:TP311

文獻標識碼:A

doi:10.3969/j.issn.1671-7449.2016.02.003

作者簡介：夏同飛(1979-)，男，工程師，主要從事軟件項目管理、 軟件測試的研究.

基金項目：國家電網(wǎng)公司科技資助項目(2014-06-487-S)

收稿日期:2015-07-12

文章編號:1671-7449(2016)02-0106-08