面向方面測試方法的研究
2008-12-31 00:00:00葛君偉樊寧方義秋
計算機應用研究 2008年12期
（重慶郵電大學 GIS研究所， 重慶 400065）
摘 要：
面向方面編程(AOP)允許程序員將跨越多個模塊的橫切關注行為封裝到一個可重用的模塊中，極大地增強了系統的可維護性和代碼的重用性。但這樣的新特性也給測試帶來了新的挑戰，因為方面與原始模塊之間錯綜復雜的依賴關系可能導致新的錯誤，從而使得傳統的測試方法不能很好適應。以AOP錯誤模型為基準，對四種具有代表性的AOP測試方法發現錯誤的能力和有效性進行了深入詳細的研究和對比，分析總結了目前面向方面測試技術領域存在的主要問題以及將來的發展方向。
關鍵詞：面向方面編程； 橫切行為； 依賴關系； 錯誤模型； 面向方面測試方法
中圖分類號：TP311 文獻標志碼： A
文章編號：10013695(2008)12362803
Research of aspectoriented testing approaches
GE Junwei， FAN Ning， FANG Yiqiu
(GIS Research Center， Chongqing University of Posts Telecommunications， Chongqing 400065， China)
Abstract:
Aspectoriented programming(AOP) allows programmers package the behavior that span multiple modules into a reusable module， which improves codes’ reusability and maintainability greatly. But these new characteristics bring new challenges to program testing， because of the complex dependencies of both aspects and original modules， which make traditional testing approaches can not adapt completely. This paper deeply and indetail studied and contrasted several aspectoriented testing approaches in terms of their ability and effectiveness to find faults， and analyzed and summarized the problems that exist in the scope of aspectoriented testing technologies and the future development trend.
Key words：AOP; crosscutting behavior; dependence; faultmodel; aspectoriented testing approaches
軟件測試是軟件開發過程中一個重要的組成部分，它貫穿于軟件開發的整個生命周期，是對軟件產品（包括階段性產品）進行驗證和確認的活動過程，其目的是盡快發現軟件產品中所存在的各種問題。
傳統的面向過程的測試已經相當成熟，面向對象測試技術的研究也在如火如荼地進行中。而對于面向方面軟件的測試，卻少有人關注：a）由于人們對AOP的研究主要集中在問題分析、軟件設計以及實現技術上，很少關注其測試技術和方法的研究；b）由于面向方面程序本身的特性，使得面向方面測試的策略和技術有很大不同，不能直接沿用傳統的軟件測試方法，給軟件本身的測試帶來了復雜性和不確定性；c）AOP是通過切點在給定的連接點與類型間聲明處截聽系統的運行，以此來實現對系統中橫切關注點的分離，但這種機制有可能改變或增加基礎代碼的特性，尤其對程序中的動態行為影響更大。以上這些問題給AOP的測試帶來了很大的困難。
1 AOP的錯誤分析
AspectJ是當前最流行的AOP編程語言，大部分面向方面的研究均以其為基礎，下面要介紹的AOP錯誤模型也是在對AspectJ語言的結構和特性進行深入研究之后提出的。
11 AspectJ
AspectJ是施樂公司開發的基于Java語言的AOP擴展，它既是一種AOP語言規范，又是一種語言實現。AspectJ的語言構造是從Java語言中擴展而來的，因此所有合法的Java程序也都是合法的AspectJ程序。AspectJ編譯器生成的是符合Java字節碼規范的.class文件，這使得所有符合規范的Java虛擬機均可以解釋、執行其所生成的代碼[1]。由于選擇了Java作為自己的語言基礎，AspectJ具有Java語言的所有優點。為了更好地支持AOP思想，AspectJ在Java語言的基礎上擴展了以下語言構造[2~4]：
a)連接點。它是AOP中最基本的元素，表示程序控制流中的某些點（如一個函數、一個屬性、一個類型等）及軟件系統中的橫切關注點。連接點是一個抽象的概念，不用顯式定義。
b)切點。它是連接點的集合，通過designator（指示符，它指示連接點應該在什么時候連接到切點）明確定義需要收集的連接點和有關參數值，它是聯系方面與類的橋梁。
c)通知（advice）。被特定事件觸發的邏輯，一個advice的行為可以被織入到調用者與被調用者的隊列之間。Advice通常可分為三類：(a)Before advice，在連接點之前執行。(b)After advice，在連接點之后執行。(c)Around advice，一個around advice圍繞在連接點的周圍，它可能改變連接點的主體，甚至替代之。換句話說，around advice可以繞過與之相匹配的連接點的集合，或者使連接點的執行受制于around advice。
d)類型間聲明。允許程序員修改程序的靜態結構、名稱，添加類的屬性、方法以及修改類之間的繼承關系。
e)方面。類似于面向對象中類的概念，是對系統中橫切關注點的封裝。除了具有面向對象中類的特性外，方面還包括了橫切關注點的行為和狀態描述。
12 AOP錯誤來源
當系統出現故障時，首先要做的就是診斷系統故障并探測錯誤的來源。AOP中有四種可能的錯誤來源：a)在核心關注點（類）中的錯誤，不受織入活動的影響；b)在方面中的錯誤（獨立于上下文）；c)當單個方面與核心關注點產生交互時，方面的織入可能會改變原始程序的數據或控制依賴；d)當多個方面同時織入系統中，可能產生突發的錯誤。
13 AOP錯誤模型
任何系統的測試策略必須對程序執行過程中可能發生的錯誤類型具有某種理解，因為如果對于想要尋找的錯誤沒有一點了解，那么系統性的測試純屬無稽之談。Binder[5]強調，任何一種合理的測試策略必須以某種錯誤模型為導向，而這個錯誤模型描述了接受測試的、可能含有錯誤的系統的內在聯系和構件。同時，錯誤模型也經常用來描述軟件系統錯誤的性質和類別。Alexander等人[6]在對AspectJ語言特有的結構進行謹慎的思考和分析之后提出了一個AOP錯誤模型，雖然該模型仍然有待完善，但它確實邁出了系統化測試AOP的第一步。這個模型包含了六類錯誤：
a)切點的定義強度不正確。切點通過designator明確定義了需要收集的不同類型的連接點。但是，如果切點定義太強，會造成原本必需的連接點被遺漏；如果切點定義太弱，又可能會選擇一些并不需要的連接點。這兩種情況都有可能在方面織入時引發錯誤的系統行為。
b)方面的優先順序不正確。在AOP中，可能存在多個advice共同作用于一個連接點的情況。在這種狀況下，必須對advice織入連接點的順序進行控制。在AspectJ中，織入順序的控制通常是由對方面的優先順序進行規定來完成的。例如，兩個方面都需要在同一個連接點處執行before advice，此時優先級高的方面享有最先執行的權利。如果沒有規定方面優先級，advice的織入順序同樣也是不明確的。當然，如果織入的advice相互獨立，也就不必再規定優先級了。
c)建立期望的后置條件失敗。核心關注點的客戶期望關注點的行為符合他們的設計契約，當然客戶也有責任保證一個方法的前置條件要優先于對它的調用。當前置條件滿足時，客戶想當然地認為方法調用的后置條件也應該得到滿足，這是一個行為繼承的基本需求。客戶希望后置條件得到滿足，而不去關心方面是否已經被織入了，所以關注點的行為契約在方面織入后仍然需要得到保證。對于一個正確的行為來說，被織入的advice必須允許核心關注點中的方法滿足它們的后置條件。如何定義一個advice，使之在所有可能織入的上下文環境和所有可能的方面組合中都不違背設計契約，仍然是一個挑戰，同時也可能是一個錯誤來源。
d)保持狀態不變量失敗。關注點的行為是根據對象狀態的實際表現和作用于狀態之上的方法來進行定義的。 除了要建立方法的后置條件，方法還必須要保證狀態不變量得到滿足。
e)控制流的關注不正確。切點通過designator來對連接點進行選擇，選擇的結果在織入時確定。但是，做出正確選擇所需的信息常常要在運行時才能獲取，有時連接點只能在一個特定的上下文環境中選取， 而這樣的上下文可能存在于一個特殊對象的控制結構之內，或者是某個程序點之下出現的控制流之內。
f)錯誤地改變了控制流依賴。Around advice的織入可能導致方面中的代碼取代原始程序中的代碼。在這樣的情況下，雖然程序還能繼續運行，但控制流的結構及其相應的依賴已經改變了，這就有可能對方法或數據的語義行為造成影響。
2 AOP測試方法
21 基于數據流的單元測試方法
Zhao Jianjun[7]提出了一種基于數據流的方法對AOP進行單元測試，這里的單元測試同OOP（objectoriented programming）中的并不相同。因為方面可以破壞類的封裝，類不再是一個封裝良好、內聚良好的代碼單元。而且，一個類可能被多個方面影響（這樣的類被稱做類聚簇，clustering class），一個方面也可能影響到多個類（這樣的方面稱做方面聚簇，clustering aspect）。對于每個類和方面，可以進行三層測試：a)Intramodule，主要針對單個模塊，如一條advice或一個方法；b)Intermodule，將一個公共模塊連同它要間接或直接調用的一些模塊放到一起測試；c)Intraaspect或intraclass，主要針對可以在方面或類之外訪問并可以被方面或類的用戶以任何順序調用的模塊。
基于數據流的測試方法主要關注程序中每個變量的賦值分配。Zhao Jianjun提出的方法使用控制流圖來計算方面或類的defuse對，然后根據計算結果來選取合適的測試策略。關于更詳細的建立控制流圖的算法、三層測試策略以及defuse對的計算，可以參考文獻[7]。這種測試方法的主要問題就是：around advice可能會改變方法的行為控制或數據依賴，也就是說，defuse對的計算結果可能被改變。未來的研究工作應傾向于：a）不但要解決目前存在的問題，而且要使之可以測試方面與類的混合；b）以測試方面或類的繼承性為導向；c）開發一種基于數據流測試工具。基于狀態的錯誤類型往往都與錯誤的數據流聯系甚密[8]，所以這種方法可以檢測“保持狀態不變量失敗”這種錯誤。
22 基于狀態的測試方法
方面的織入可能會改變核心關注點的狀態模型，從而給系統引入一些新的狀態以及引起類違反它們自己的狀態不變量。為了捕捉方面對類的狀態模型的影響，Xu Dianxiang等人[9]對OOP中的FREE（flattened regular expression）狀態模型進行擴展，得到了面向方面的狀態模型（aspectual state model，ASM），然后將ASM變換成一棵狀態遷移樹。該樹每一條樹根到最終葉節點的路徑構成一個測試用例，它可以用來充分測試對象的行為、方面與類之間的交互。具體的狀態遷移樹轉換算法參考文獻[9]，這里不再贅述。
FREE狀態模型類似于UML中的狀態圖，可用來描述對象的狀態和行為，在對其進行擴展之后得到的ASM可以表示AOP中的連接點、切點和advice等基本語言構造。圖1是一個簡單的ASM示例圖，A、B、C、D、E代表了五種狀態。初始狀態A與結束狀態B之間有一個條件轉變M1[cond1]，意思就是如果條件cond1得到滿足，消息M1就使狀態A遷移到B。在圖中的三個連接點處M1可能受到三種advice的影響：
a)Before advice。[cond2]為真，M1在entry join point處的before advice使A轉向C。
b)After advice。[cond3]為真，M1在exit join point處的after advice使A轉向E。
c)Around advice。[cond4]為真，M1在around join point處的around advice使A轉向D。
這種基于狀態的測試方法的主要思想就是通過算法將ASM轉換為狀態遷移樹，然后根據每條樹根到葉節點的路徑所表示的消息序列生成相應的測試組。在狀態遷移樹中，每條從根到葉節點的路徑（狀態遷移的序列）表示對象行為的一個測試需求。如果消息序列上的變量被指定了滿足相應條件的特定值，那么這個測試需求就變成了一個具體的測試用例[9]。
基于狀態的測試方法一直受困于狀態數爆炸的困擾。所以在以后的研究中，有必要在狀態遷移樹中挑選出那些最有價值、最重要的路徑。該方法可以識別出兩種錯誤，即切點的定義強度不正確和保持狀態不變量失敗。
23 基于AFG的測試方法
Xu Weifeng等人[10]提出了基于方面流圖AFG（aspect flow graph）的測試方法。AFG對應于OOP中的類流圖，但AFG也表示由方面引入類的控制流。AFG是由ASSM（aspect scope state model，方面域狀態模型）與方法和advice的數據流圖合并而成的。其中，ASSM可以表示AOP中的狀態遷移，是由類狀態模型與方面狀態模型合并而成的。
a)類狀態模型。由FREE狀態模型與方法流圖合并而成，描述了一個特殊類的狀態遷移行為。
b)方面狀態模型。ASM由四種狀態和三條邊組成。四種狀態分別是起始狀態α、結束狀態ω以及action prior和action posterior兩種特殊狀態。在ASM中方面的數據流走向可以簡單地如圖2所示。其中：before advice、arbitrary action及after advice在方面中屬于特殊的行為。從圖2可以看出，before advice使方面從起始狀態α遷移到了狀態action prior；after advice使方面的 狀態由action posterior轉換到結束狀態ω；而arbitrary action可以觸發狀態action prior遷移到狀態action posterior。
根據覆蓋測試的原則，可以利用AFG和遷移樹來產生可執行的、基于代碼的測試用例。詳細的創建AFG和遷移樹的步驟參閱文獻[10]。
基于AFG的方法可以表示靜態應用的advice，但對于動態應用的advice（這種advice的應用取決于運行時動態的上下文環境），AFG卻無能為力，這是該方法的一個主要缺陷。作者認為這種測試方法可以檢測兩種錯誤，即控制流的關注不正確和錯誤地改變了控制流依賴。但近來，Naqvi等人[8]在研究中發現，基于AFG的方法并不能檢測到控制流的關注不正確，因為該類型的錯誤大都起因于AOP中的動態行為，而AFG是一個靜態織入模型，它并不適用于這種錯誤。
24 獨立的測試方面
在AspectJ中，方面并不是實例化的單元，它沒有獨立存在的實體或存在物，這對單元測試的進行來說是非常困難的。但在其他的一些AOP語言編寫的系統中，如JAML（Java aspect markup language），就為獨立測試方面提供了可能性。在JAML中，方面由兩種模塊來進行表述：a）方面模塊，封裝了方面的行為；b）方面綁定，描述了基礎程序與方面的合成。
在JAML程序中，主要利用JamlUnit對上述兩個模塊分別進行單元測試。JamlUnit是對Junit的擴展，可以作為單元測試方面時的框架。而對方面進行單元測試必須重視兩個問題[11]：a)方面的實現結果是否與程序的要求相一致；b)驗證切點的定義，即 檢查連接點是否與切點相匹配；驗證切點是否捕捉到了正確的連接點；檢驗切點是否能包含或排除指定的連接點。
雖然利用JamlUnit可以對方面的實現和切點的定義進行測試，但文獻[11]著重描述了對方面實現的測試，而對方面與類的交互等并沒有過多涉及。JamlUnit包含了一組Java Helper類，這就使得開發人員可以通過模擬運行時的上下文信息和連接點，用規則的Junit測試用例來對方面代碼進行獨立的單元測試。但是該方法也存在著問題：a)對于如何選擇有意義的模擬連接點還沒有相應的準則；b）如果遇到稍復雜的AOP，JamlUnit對運行上下文的模擬就變得非常困難。
3 存在的問題及研究方向
在對上述的AOP錯誤模型和測試方法進行仔細分析和研究之后，筆者認為，目前大部分AOP測試方法都是從面向對象測試技術擴展而來的，該領域還存在著很多問題：
a)沒有成熟統一的測試方法、標準和工具作為依托，國內外的研究還都處于起步階段，參與的研究人員非常少。
b)現有的錯誤模型是在對AspectJ獨有的特性進行分析研究之后提出的，它只是向系統化測試AOP邁出的第一步，仍然需要完善。對于其他語言平臺，該模型的適用性仍需進行相關研究。
c)現有測試方法的測試能力都非常有限，大都只能處理AOP中的局部錯誤類型，沒有哪一種測試方法可以有效覆蓋錯誤模型中所有的錯誤，缺乏全面的考慮。
d)目前的面向方面測試方法還僅僅處于對代碼的測試分析上，而對于軟件開發生命周期中其他階段的測試并沒有相關的研究。
在未來的工作中，應繼續著重研究AOP中的交互問題（方面與類的交互、方面之間的交互等）以及測試覆蓋率問題；再者，就像前文中提到的一樣，軟件測試應該貫穿于整個軟件開發生命周期與軟件項目同時開始，從產品的需求分析審查到最后的驗收測試，直至軟件發布，因此，面向方面軟件開發要想成為主流的開發技術，這方面也是以后研究的一個熱點領域；最后，面向方面軟件開發是一種新型的編程思想，所以測試方法的研究就不能一味地局限在傳統測試思想的模式下，應不斷開拓新思路，如可以考慮利用方面來對方面進行測試等。
4 結束語
AOP很好地解決了OOP中代碼混亂和分散的問題，與其他程序一樣，面向方面的軟件質量一樣需要通過測試來進行驗證。本文簡述了AspectJ及AOP的基本概念，依據錯誤模型分別對四種各有側重點的測試方法進行深入詳細的研究，分析對比了它們各自的優勢以及存在的不足，闡述了目前該測試領域的研究現狀并針對存在的問題以及未來的研究發展提出了自己的意見和見解。面向方面軟件測試技術擁有良好的前景，隨著技術的不斷發展、參與科研人員的不斷增多以及研究的不斷深入，將會出現專門適用于面向方面的測試方法，能夠對面向方面軟件開發過程實現全面、 有效和系統化的測試。
參考文獻：
[1]LADDAD R.通過AspectJ更好地了解AOP[J].劉克科，譯.程序員，2002(11):6163.
[2] 王申源，董傳良，劉英丹.面向方面的編程的研究與實現[J].計算機應用研究，2004， 21 (11):220223.
[3] 徐寶文，周超洪，周天琳，等.面向方面的程序設計:概念、實現與未來[J].計算機與數字工程，2005， 33 (8):110.
[4] 郭東亮，張立臣.面向方面軟件開發[J].計算機應用，2002， 22 (8):3638.
[5] BINDER R V. Testing objectoriented systems: models， patterns and tools[M]. Boston: AddisonWesley，2000.
[6] ALEXANDER R T， BIEMAN J M， ANDREWS A A. Towards the systematic testing of aspectoriented programs， CS4105[R]. Frot Collins: Colorado State University， 2004.
[7] ZHAO Jianjun. Dataflowbased unit testing of aspectoriented programs[C]//Proc of the 27th International Annual Conference onComputer Software and Applications. Washington DC: IEEE ComputerSociety， 2003:188197.
[8] NAQVI S A A， ALI S， KHAN M U. An evaluation of aspect oriented testing techniques[C]//Proc of IEEE International Conference on Emerging Technologies. 2005:461466.
[9] XU Dianxiang， XU Weifeng， NYGARD K. A statebased approach to testing aspectoriented programs， NDSUCSTR04XU03[R]. Fargo: North Dakota State University， 2004.
[10] XU Weifeng， XU Dianxiang， GOEL V， et al. Aspect flow graph for testing aspectoriented programs[EB/OL].(200408).http://www.cs.ndsu.nodak.edu/wxu/research/4361I ljd.pdf.
[11] LOPES C V， NGO T C. Unittesting aspectual behavior[C]//Proc of the 1st Workshop on Testing AspectOriented Programs. 2005.
[12] KICZALES G， LAMPING J ，MENDHEKAR A， et al.Aspectoriented programming[C]//Proc of the 11th European Conference on ObjectOriented Programming. Berlin: SpringerVerlag， 1997:220242.
[13] KICZALES G， HILSDALE E， HUGUNIN J， et al. An overview ofAspeclJ[C]//Proc of the 15th European Conference on ObjectOrientedProgramming Berlin: SpringerVerlag， 2001:237353.
[14] MCGREGOR J D， SYKES D A.面向對象的軟件測試[M].楊文宏，李新輝，楊沽，等譯.北京:機械工業出版社，2002.
[15] JORGENSEN P C.軟件測試[M].韓柯，杜旭濤，譯.北京:機械工業出版社，2003.
[16] [EB/OL].(200308).http://www.aspectJ.org.
[17] 古樂，史九林.軟件測試技術概論[M].北京：清華大學出版社，2003.
[18] BRUEGGE B， DUTOIT A H.面向對象軟件工程[M].葉俊民，汪望珠，譯.2版.北京：清華大學出版社，2006.
[19] DENARO G，MONGA M. An experience on verification of aspect properties[C]//Proc of the 4th International Workshop on Principles of Software Evolution. New York: ACM Press， 2002.
[20] LADDAD R. AspectJ in action: practical aspectoriented programming[M]. [S.l.]: Manning Publications，2003.
