基于實例的自動測試維護代價研究

摘 要：不考慮自動測試的維護代價，盲目進行自動化測試是有風險的。以畫板程序升級為例，詳細介紹了它的修改過程和相應測試程序的維護代價，然后利用COCOMO度量方法，對測試程序與被測試程序的維護代價作一個比較，說明測試程序和被測試程序一樣，需要反復維護才能進行回歸測試。通過實例和理論分析使測試者清醒認識自動測試的維護代價，合理利用自動化測試。

關鍵詞：軟件升級； 回歸自動測試； 維護代價； COCOMO

中圖分類號：TP311.56 文獻標志碼：A 文章編號：1001-3695(2008)08-2374-03

Case study on maintenance cost for regression test automation based on prototype

KAN Hong-xing1，2，CHU Wei2， HU Chun-ling1

（1. Laboratory of Network Intelligent Information Management， Hefei University， Hefei 230022， China; 2.School of Management， Hefei University of Technology， Hefei 230009，China）

Abstract:Carrying on the test automation blindly will have the risk， without considering the test automation maintenance cost. Took the drawing board as the example， this paper introduced its revision process and the corresponding test program maintenance cost in detail. Compared the test program maintenance cost with its test object maintenance by COCOMO measurement method， automation regression test must be maintained repeatedly like its test object before testing. Test automation maintenance cost would be known soberly and test automation would be used reasonably by example and the theoretical analysis.

Key words：software update； regression test automation； maintenance cost； COCOMO

隨著軟件業的迅速發展，軟件測試技術的自動化是軟件測試的發展趨勢。在某些情況下，自動測試確實有自己的優勢，如在分布式系統測試^[1]、完整的代碼覆蓋測試^[1]、大容量數據測試^[2]中，手工測試很難做到完美，甚至根本無法測試。但不能因此而認為自動測試就是解決測試問題的“銀彈”（silver bullet）^[3]。實際上，即使適合自動測試的軟件項目，如果不能恰當地應用自動化測試，其投資的成本會遠遠高于手工測試，即自動測試存在一定的風險性^[4]。

Douglas Hoffman的投資回報（ROI）分析模型指出^[5]，由于自動測試要編寫測試程序，一次自動測試成本要遠大于一次手工測試，自動測試成本是在反復回歸測試中得到回收的。但如果考慮回歸測試時測試程序的維護成本，則反復回歸測試后自動測試成本將不一定會小于手工測試，自動測試風險發生。因此自動測試風險發生與否，很大程度上取決于每次回歸測試時測試程序的維護成本^[4]。

隨著Boehm“軟件工程經濟學”的推廣^[6]，人們已經認識到軟件系統維護的代價，但對于自動化測試程序的維護卻并不為許多測試者重視，如Douglas Hoffman在定量分析自動測試的投資回報過程中就忽視了測試程序的維護代價^[5]； Fewster和Graham通過實例說明以增量模式開發的軟件，很適合利用自動測試，但在整個論述過程中也沒有考慮測試程序的維護代價^[7]；甚至一些知名軟件公司一開始也盲目投資自動化測試，忽視了測試程序的維護代價^[8]；文獻[4]雖然討論了測試程序的維護代價，但卻沒有分析測試程序維護的原因和過程。實際上，測試腳本是交互應用或部分非交互應用的測試自動化中必要的組成部分，它是由腳本語言編寫的，因此自動化測試是一種編程測試，測試程序需要工程化，更需要維護。

本文通過實例和一定的理論分析，使測試人員清楚地認識到自動回歸測試測試程序與應用程序一樣，在每次回歸測試之前都需要維護，防止盲目進行自動化測試。

1 Drawlet畫板

1.1 畫板程序及其功能

Drawlet畫板是一個Java版的程序，由Beck和Cunningham共同開發^[9]。畫板具有可擴展性，可根據用戶的需要增加或減少繪畫功能。本文研究的應用程序叫做SimpleApplet，它是Drawlet類庫的一部分。SimpleApplet可以通過Web瀏覽器運行，它支持直線、矩形、自由曲線、圓角巨型、多邊型、橢圓等基本圖形的繪畫，同時還配有調色板、填充樣式、文本輸入等功能。SimpleApplet的頂層UML類圖如圖1所示。

1.2 畫板程序的升級

Rajlich和Gosavi為了研究軟件升級后代碼所發生的改變量，他們給畫板程序升級，增加了權限功能，即讓用戶擁有創造、修改、移動自己所畫圖形的權利，而別的用戶不擁有這一權限^[10]。畫板增加權限后，運行新版SimpleApplet，會出現一個會話框，要求用戶通過賬號和密碼登錄，或注冊一個新用戶。用戶登錄后在畫布上所畫的任何圖形，別的用戶不能更改和移動；會話框還具有偵聽功能，偵聽用戶是否按了某個按鈕，然后作相應的處理。升級后的SimpleApplet頂層UML類圖如圖2所示。

與圖1比較，圖2中出現了兩個最新增加的類，即Owner-Identity 和SimpleListener。在類OwnerIdentity中可實現權限設計，包括一些基本用戶數據，如用戶ID和用戶姓名等，用戶可通過會話框修改用戶姓名和ID，也可通過會話框偵聽，偵聽用戶是否按了某個按鈕，然后作相應的處理。偵聽是在類SimpleListener中實現的。

1.3 AbstractFigure類的修改

由上分析可知，升級后的系統要在抽象的AbstractFigure類中增加三個新的公共方法，分別是setFigureOwner()、int getFigureOwnerID()和String getFigureOwnerName()。

setFigureOwner()方法設置用戶ID和用戶姓名;getFigureOwnerID()方法讀取用戶ID; getFigureOwnerName()方法讀取用戶姓名。增加了新方法后，則要對move(…)和translate(…)方法進行修改，增加參數：securemove(…，int FigureOwnerID)，securetranslate(…， intFigureOwnerID) 。同樣調用move和translate方法的函數也要進行修改，增加相應的參數。

就AbstractFigure類來說，代碼修改的大致情況如下：

public class AbstractFigure{…

private int FFigureOwnerID; //新增加的成員變量

private String FFigureOwnerName;// 新增加的成員變量

public setFigureOwner(int FigureOwnerID， String FigureOwnerName)

{FFigureOwnerID=FigureOwnerID;

FFigureOwnerName=FigureOwnerName;}//新增加的方法

public int getFigureOwnerID()

{Return FFigureOwnerID;}//新增加的方法

public String getFigureOwnerName()

{Return FFigureOwnerName;}//新增加的方法

public securemove(…，int FigureOwnerID)

{…If FFigureOwnerID=FigureOwnerID

Then …

}//修改的方法

public securetranslate(…，int FigureOwnerID)

{.

If FFigureOwnerID=FigureOwnerID

Then …

}//修改的方法

}

上面的代碼只反映了類AbstractFigure的修改情況，與老版本的AbstractFigure類相比，共修改了10行代碼。實際上，在升級中還要修改與AbstractFigure相關的類，因為類在互相調用時會傳播類的變化，如從類A傳遞信息給類B要通過類X，當類A發生變化時，類B和類X都要發生改變^[10]。因此，SimpleApplet的升級將導致大量代碼的修改。

2 自動回歸測試

2.1 回歸測試程序的維護

應用程序升級后要進行回歸測試，以保證它們經過修改后仍能正確運行。本文的自動測試工具采用的是JUint，它是由 Erich Gamma 和 Kent Beck 編寫的一個回歸測試框架。

根據Mats SkoglundPer和Runeson的研究^[8]，自動回歸測試的過程可分為四個階段，分別是環境設置、編譯配置、執行單元測試和執行功能測試。在任一階段，如果測試程序執行不成功的話都要對其進行修改。對本例來說，由于軟件的升級并沒有導致運行環境的改變，測試程序的環境設置無須修改，而在其他幾個階段測試程序都要進行一定的修改。就AbstractFi-gure類來說，其升級后如要對它進行自動測試，JUnit測試代碼要做如下修改：

public class TestSample extends TestCase{…

public void testsetFigureOwner()

{AbstractFigure Figure = new AbstractFigure();

result = Figure.setFigureOwnerID(12345， kan);

assertTrue(result);}//新增加類的測試

public void testgetFigureOwnerID()

{AbstractFigure Figure = new AbstractFigure();

result = Figure.getFigureOwnerID(12345);

assertTrue(result);}//新增加類的測試

public void testgetFigureOwnerName()

{AbstractFigure Figure = new AbstractFigure();

result = Figure.getFigureOwnerName(12345);

assertTrue(result);}//新增加類的測試

public void testsecuremove()

{…

AbstractFigure Figure = new AbstractFigure();

result = Figure.getFigureOwnerID();

assertTrue(result);//新增加參數的測試

…}

public void testsecuretranslate()

{

…

AbstractFigure Figure = new AbstractFigure();

result = Figure.getFigureOwnerName();

assertTrue(result);//新增加參數的測試

…

}

…}

從代碼的修改情況看，JUnit測試程序與回歸測試之前相比，增加了15行代碼。

2.2 被測試程序和測試程維護代價的比較

根據COCOMO軟件維護量的估算原理^[6]，軟件維護的規模和開發規模成正向關系，即軟件的規模越大，開發的時間越長，維護的成本也越大。令某程序總的開發成本為V，第i次維護的成本為Ci，則有

Ci=αi×V（0＜αi＜1； i =1，2，…， n）（1）

正常情況下，維護的成本不會超過開發成本^[6]，所以0＜αi＜1。這里稱αi為第i次維護代價調整因子。Boehm認為αi可由式（2）確定：

αi=ACT×∏15j=1(VAFj)（2）

其中：ACT表示測試程序在每次維護中代碼所發生的變化；VAF（value adjust factor）表示與維護成本相關的15個成本調整系數，每個成本調整系數有5個級別，每個級別都對應一個具體的數據。表1就是15個成本調整系數其相關值^[6]。

根據表1，15個成本調整系數由四大類組成，分別為產品屬性、計算機屬性、人員屬性和項目屬性。由式（1）（2）知，ACT和15個調整系數決定了每次程序維護的代價。就本例來說，無論是測試程序還是被測試程序，其產品屬性、計算機屬性、人員屬性和項目屬性應該是大致相同的，因此ACT決定了它們各自維護代價的大小。

令V1為測試程序在維護前的代碼行數，M1為測試程序維護后修改的代碼行數，ACT1為測試程序代碼修改百分比；令V2為被測試程序在維護前（升級前）的代碼行數，M2為被測試程序升級后修改的代碼行數，ACT2為被測試程序代碼修改百分比；令β為測試程序和被測程序維護代價的比值，則根據式（1）（2）有

β=（M1/V1×∏15j=1(VAFj)×V1）/（M2/V2×

∏15j=(VAFj)×V2）=M1/M2（3）

表1 軟件維護工作量調整系數屬

性成本調整系數等級很低低標準高很高產品

屬性RELY可靠性1.351.151.000.981.10DATA數據庫規模0.941.001.081.16CPLX產品復雜性0.700.851.001.151.30計算機

屬性TIME時間約束1.001.111.30STO主存儲器約束1.001.061.21VIR虛擬機易變性0.871.001.151.30TURN周轉時間0.871.001.071.15人員

屬性ACAP分析員能力1.461.191.000.860.71AEXP應用經驗1.291.131.000.910.82PCAP程序員能力1.421.171.000.860.70VEXP虛擬機經驗1.211.101.000.90LEXP編程經驗1.141.071.000.95項目

屬性MODP編程規范1.241.101.000.910.82TOOL工具使用1.241.101.000.910.83SCED開發進度1.231.081.001.041.10

由實例分析可知，對類AbstractFigure來說，M1=15，M2=10，利用式(3)可得測試程序的維護代價是被測試程序的1.5倍。

3 結束語

投資自動測試不是一勞永逸的，當一個系統升級后，它的自動測試程序必須要經過維護，然后才能進行回歸測試，這一點在投資自動測試之前必須有清醒認識，否則可能會使得自動化測試的投資永遠得不到回收。

本文首先通過一個畫板程序的實例說明了其升級和回歸測試的維護過程，通過實踐證明自動測試的維護代價是不可忽略的；然后又利用COCOMO度量方法，從理論上說明了測試程序的維護代價與被測試程序一樣，是真實存在的。雖然本文只對畫板程序的一部分AbstractFigure類進行了詳細的分析，但它足以說明測試程序需要維護才能進行回歸測試。

本文對畫板的升級是個極端的例子，因為升級改變了原來程序的設計結構，無論是對測試程序還是被測程序來說，都造成了大量代碼的修改，這也從另一方面說明軟件設計的重要性，良好的結構設計不但有利于系統本身的維護，也有利于自動測試程序的維護。

參考文獻：

[1]STOBIE K. Too darned big to test [J]. Queue， 2005，3(1):30-37.

[2]BERNER S， WEBER R， KELLE R R. Observations and lessons learned from automated testing[C]// Proc of the 27th International Conference on Software Engineering. Missouri: IEEE Press， 2005: 571-579.

[3]Jr BROOKS F P .No silver bullet essence and accidents of software engineering[J]. Computer，1987，20(4):10-19.

[4]楊善林，闞紅星，余本功.一種軟件自動測試成本估算控制模型[J]. 電子學報，2007，35(8):1588-1591.

[5]HOFFMAN D. Cost benefits ananlysis of test automation[EB/OL]. （1999）. http://www.softwarequalitymethods.com/Papers/Star99%20model%20Paper.pdf.

[6]BOEHM B W. 軟件工程經濟學[M].李師賢，譯.北京:機械工業出版社， 2004.

[7]FEWSTER M， GRAHAM D. Software test automation[M]. Boston MA： Addison-Wesley，1999：143-167.

[8]SKOGLUND M，RUNESON P. A case study on testware maintenance and change strategies in system evolution[DB/OL]. （2004）. http://www.ieeexplore.ieee.org/iel5/9383/29793/01357831.pdf.

[9]RoleModel Software Inc. Drawlets[DB/OL]. （2007）.http://www.rolemodelsoftware.com/drawlets.

[10]RAJLICH V， GOSAVI P. A case study of unanticipated incremental change[C]// Proc of the International Conference on Software Maintenance. Los Alamitos， CA: Computer Society， 2002: 359-368.

注：本文中所涉及到的圖表、注解、公式等內容請以PDF格式閱讀原文