面向對象程序的異常分析與測試方法述評

摘要：從異常處理的分析方法和測試技術兩個方面概述當前對異常處理的研究現狀，分析和比較了一些典型方法；簡要介紹了在C++程序中異常測試技術改進和工具實現方面所做的工作；探討了異常分析和測試的若干研究方向。

關鍵詞：異常處理; 分析與測試； 控制流圖； 形式推理； 覆蓋準則

中圖分類號：TP311.5文獻標志碼：A

文章編號：1001－3695(2007)08－0025－05

對于一個良好設計的程序而言，一般都有對預期錯誤的處理方式。早期的編程語言通過檢查返回值進行相應的處理；現在，許多程序設計語言（如C++、Java和Ada等）的異常處理機制（即一種運行時錯誤通知機制）是一個非常好的替代。異常處理機制將程序的正常控制代碼和異常處理代碼分離，在錯誤即將發生前檢查其前置條件來阻止它，努力使程序正常運行。該方式使得程序的基本功能更突出、錯誤處理的復雜性更加清晰可見。然而，正確使用異常機制并非易事，大部分開發人員都低估了進行異常處理所需的技巧。異常的不正確使用會帶來諸多問題，如對象狀態不一致、內存泄漏、系統崩潰等。1996年ArianeV號火箭的爆炸就是由一個未被捕獲的異常引起的[1]。

異常處理作為許多面向對象程序設計語言的組成部分，為開發可靠性軟件系統提供了強有力的支持[2]。由于異常的廣泛使用（Sinha和Robilard等人[3，4]的統計表明約占代碼的10%）以及極易被誤用，出現了不少專門用于異常機制改進[5~8]、分析[3，4，9~11]和測試[12~16]的方法與技術，并組織了探討面向對象系統中異常處理的專題會議[17]和專輯[18，19]。

1異常處理機制簡介

異常處理的概念最早由Goodenough于1975年提出[20]。隨后，Yemini[21]和Knudsen[22]等人對異常條件和異常進行了更為明確的定義，并形成如下共識：異常是程序執行過程中不正常的狀態，需要額外計算的支持；當這種非常規狀態被探測到時，相應的異常就被拋出。異常處理器（exception handler）則是被自動觸發去執行響應異常發生的代碼域。

經過近三十年的發展，異常處理機制已經形成了多種變體，但其異常模型大致可分為三種[4，23]：a）終止模型。當引發了異常且被異常處理器處理后，控制不返回到發生異常的那一點，而是轉移到異常處理器之后的第一條語句。b）恢復模型。異常處理完畢后，控制返回到發生異常的那一點繼續執行。c）重試模型。異常處理后，控制返回到發生異常點所在的語法模塊并重新執行。其中較為普遍使用的是終止模型，C++和Java程序均采用該模型。

在面向對象程序中，Ada和C++中的異常是基本數據類型的變量或類實例對象，而Java中的異常則必須是類實例對象。此外，Ada語言對異常的處理和C++、Java還存在一些不同，文獻[24]作了詳細的對比。在Java中異常對象有嚴格的層次結構[25]，即所有的異常類別都派生自基類exception。C++程序中則不那么嚴格，開發者也可根據需要自定義異常類和異常層次結構，它們可以不從exception類派生[26]。異常發生時對異常處理器的選擇主要是異常類型的匹配，匹配過程按照異常類層次自底向上實施。當在該類異常層次沒有找到適當的處理器時，查找上一層次的處理器直至找到類型最為接近的處理器。

程序中出現的異常可以根據產生形式分為兩類。

定義1顯式異常（explicit exception）。通過程序中的throw語句拋出的異常。

定義2隱式異常（implicit exception）。通過調用例行程序庫（如API函數）或由運行時環境拋出的異常。

異常處理也是一種程序控制結構，主要有三個組成部分，即提煉異常（try警戒區，也稱做防護域）、拋出異常（throw語句）和捕獲異常（catch子句）。Try語句提供一種通過異常處理器進行代碼防護的機制。每個catch子句對應一種特定異常類型，并當這種類型所包含的異常被拋出時執行。Finally塊是可選的，塊中的代碼不論控制是否轉移出try塊總能被執行。典型的面向對象程序有專門的異常堆棧用于記錄異常，一個異常可以在該堆棧上向上傳播。若一個方法的異常沒有在該方法內被捕獲，則傳播到該方法的上層調用者，稱該過程為異常傳播。

2異常分析

2．1基于程序結構的異常分析

基于面向對象程序中的類控制流圖（含方法內控制流圖CFG和方法間控制流圖ICFG）的分析，Sinha等人首先在方法內控制流圖中增加異常退出節點來表達異常流信息[3，27]。擴展后的CFG包含分別代表throw語句、catch處理器和finally塊的節點及代表常規、異常控制流的邊。Throw節點通常有一個或多個異常退出后繼節點，分別表示throw語句拋出的多種異常類型。他們采用類型推理技術[28]用于確定潛在的異常類型并創建一條由異常退出節點指向對應異常類型處理器的邊。當異常在過程間傳播時，通過在ICFG基礎上增加方法間異常流邊來表示異常在方法間的傳播與捕獲。該方法能很好地重用原有不考慮異常情況下的程序控制結構信息，所得到的結果直觀并容易進行可視化表示；其缺點是僅處理了顯式異常的情形，并且存儲程序控制結構圖的開銷大。類型推理技術對包含異常結構的ICFG圖的準確程度有重要影響。目前常用的有類型約束求解[28]、指向分析[29]和流敏感分析[30]等技術。

除了上述控制流分析中進行異常流的擴展外，Shelekhov等人[9]對存在異常時如何進行數據流分析進行了探討。將異常邊、異常塊和異常退出節點擴充到程序控制流圖中將潛伏的異常流明確化表示。實現過程中，數據流用靜態單一賦值（static single assignment， SSA）[31]的形式表示，在靜態錯誤檢查器OSA[32]的輔助下展開數據流分析。該方法較Chatterjee等人提出的類型推理方法[29]簡便，但同樣面臨著存儲程序結構信息的空間開銷，并且在實際實現上對Java程序的諸多功能進行了裁減，如不能處理運行時異常。

Choi等人[10]提出了潛在異常拋出指令（potential exceptionthrowing instruction， PEI），即那些有潛在能力拋出一個異常的指令。有時一個語句可能存在多條潛在異常指令。基于PEI的識別，通過如下方式構造分解的控制流圖（factored CFG，FCFG）：對于顯式異常，采用與Sinha提出的擴展控制流類似的技術；對于隱式異常，由于PEI非常頻繁，不為每一條PEI創建一條異常邊，而是用一條分解的異常邊表示由基本語句塊（基本塊是指控制僅從塊尾轉移的連續語句序列）指向所有可能的異常處理器的異常流。Choi同樣描述了怎樣用可達定義和活動變量分析進行數據流的分析，并且通過方法間的流敏感分析創建方法間的FCFG。該方法的顯著優點在于處理了隱式異常，并且通過運用基本塊節省了一定的存儲開銷（能節省71%的節點存儲和64%的邊存儲）。其缺點是：雖然實施了方法間異常流的表示，但對異常傳播的建模仍不明確；沒有對finally語句塊進行處理；沒有提供一種很好的異常類型匹配方法。

此外，Harrold等人在分析異常處理結構時發現，程序的控制依賴關系受潛在非返回調用點（potentially nonreturning call sites， PNRCs）的影響。他們提出了一種基于語句的兩階段控制依賴（有基于節點和基于語句的兩種表示。基于節點會導致CFG中節點過多而實用性不強；基于語句比基于節點的準確性要低）

分析算法[3]：首先標志出由于throw語句和終止語句引出的PNRC集合，并計算出部分控制依賴；再通過部分控制依賴計算出整個程序的控制依賴關系。

2．2基于形式推理的異常分析

形式推理技術在異常處理結構的分析中作用顯著，2．1節提到的類型約束求解技術就是典型應用之一。Yi[33]首先用抽象表示的方法設計如何進行異常分析，隨后進行了未捕獲異常探測的成本效益分析與改進[34]，發現基于集合約束求解的技術能獲得較快的求解速度。Glynn等人[35]通過分析異常的形式邏輯和定義異常匹配規則，成功地運用基于類型推理系統探測非嚴格語言中未捕獲到的異常。對于面向程序而言，其異常結構的形式化分析主要有以下兩種方式。

然后，針對每一條異常表達式構造一個約束求解表達式。一個方法內的所有異常語句就形成了約束求解系統。文獻[37]已經證明：對于一個程序形成的約束求解集合至少能求得一個解。一般來講，程序中的異常類型并非無窮多個（即是可枚舉的），所以迭代不動點方法是最為普遍的求解以上約束系統計算出方法內未捕獲住異常的技術。通過為方法間異常交互及傳播定義約束規則可進行良好的擴展。

這種將源語言建模和約束求解系統相結合的方法有堅實的理論基礎。文獻[11]中已經證明了其正確性和完整性。該方法不需要存儲程序控制流的節點和邊信息，所關注的絕大部分是異常處理語句（含少量如類聲明、方法調用等常規語句），大大提高了未捕獲異常的分析效率。其不足主要表現在：a）雖然作了某種程度的可視化努力[38]，但這種形式推理仍不如結構分析直觀。b）即便基本上只處理異常語句，但約束表達式的復雜性和數量仍不小。當處理大規模的系統時求解時間一般較長。c）只能對顯式異常進行分析。

在面向對象程序中，異常控制流和常規控制流通常交織在一起，在分析異常控制信息時往往不可避免地分析常規控制流（如Sinha和Choi等人的方法），這樣會造成存儲開銷過大。Jo等人基于以上異常約束規則集的求解技術實現了異常流和常規流的去耦（分離）表示[39]，同時也提供了將常規流和異常流進行合成表示的方法。異常流的去耦表示有利于對異常結構的專注分析，并能為開發人員在適當的位置放置異常處理器提供指導。一般而言，常規流和異常流存在一定程度上的相互依賴關系，去耦表示會導致這部分信息的丟失。

另一種有效的異常形式推理是Robillard等人提出的以面向對象系統演化為目的、幫助開發人員進行異常推理的模型[4]。該模型中定義了如下三個推理函數：encounters(s) → E表示在代碼域s中可能遇到的異常類型集；catches(g， c) → E表示在防護域g中被catch子句c捕獲的異常類型集；uncaught(g) → E表示在防護域g中不被任何catch子句捕獲的異常類型集。接下來通過計算程序域s中每一指令i的generates(i)（由于被0除等系統操作導致的異常類型）、propagate(i)（由于函數調用傳播而來的異常集）和raises(i)（顯式拋出的異常集）來完成以上三個推理函數的計算，進而進行某個程序域中局部異常流的分析或整個系統的全局異常流的建模表示。該推理技術的優缺點與Jo的方法類似，只是Robillard的方法能對隱式異常進行處理。

2．3異常分析技術對比

3異常測試技術

Cristian的實驗研究表明[40]，異常處理代碼比程序中的其他部分更易包含缺陷，因此十分有必要加強對該部分代碼的測試。廣義上講，異常分析是對異常結構進行的一種靜態測試。本章從動態測試面向對象程序中的異常結構的角度進行綜述。

3．1基于代碼覆蓋的測試

異常處理機制的引入使程序中產生了新型的結構性元素，如異常控制流路徑。那么對這些程序進行控制流或數據流的測試時，除了要滿足傳統的結構性覆蓋準則外，還需要對異常結構進行充分的覆蓋以便檢測出潛伏的異常缺陷。Sinha等人[12]基于2.1節在包含異常程序結構性表示的基礎上，針對異常流提出了如表2所示的六種覆蓋準則。與傳統的結構性覆蓋準則類似，這些異常覆蓋準則同樣存在層次關系（圖1）。圖1中同時提供了與一般結構性覆蓋準則層次對應的關系。

這種基于結構覆蓋的異常測試方法能夠得到已有成熟測試技術的指導，易被開發或測試人員所接受。由于有CFG/ICFG的支持，可視化程度高且便于缺陷的快速定位。值得注意的是，從CFG/ICFG靜態分析得到的異常路徑并非都是可行路徑，在測試用例的生成之前需要進行不可行路徑的剔除。雖然已有不少面向路徑的測試數據自動生成方法[41]，但對于復雜類型語言（如面向對象語言）的處理都有各自的局限性。況且要使以較小概率出現的異常發生，其約束條件更嚴格，從而難以求解。

此外，Mayer等人[13，42]提出了一個描述Java語言序列執行語義、包含異常和非結構化控制流的模型，并用基于該模型的診斷技術進行程序調試。建模算法分三步自動實現Java程序源代碼向診斷模型的轉換，主要是基于構造一個多向、模塊化的CFG，該圖提供了控制變量值的前向和后向計算。所建立的模型能處理循環、多態方法調用等動態特征，并能定位程序中一般的功能性缺陷。其缺點在于模型（擴展后的CFG）復雜、不直觀從而不利于理解，且有存在沖突的可能；所提出的異常調試技術未得到實際程序實例的檢驗。

3．2基于對象狀態的測試

雖然異常處理機制能探測并糾正運行時的錯誤條件，但編寫異常處理代碼時仍要注意保持應用程序的一致性。因為程序運行時可能會由于一個處理不當的異常導致程序中對象狀態的不一致。Fetzer等人首先按如下方式定義原子性失效和非原子性失效[14]。

定義3對象圖（object graph）。一個對象o的對象圖以o為根，節點表示對象中基本數據類型的實例或對象，邊表示節點間的組成或引用關系。

定義4前置（后置）調用對象圖（pre/postinvocation object graph）。對象o上方法m被調用之前的對象狀態圖稱做前置調用對象圖，是對象在方法調用前的快照；恰當m的調用由于異常返回后的對象狀態圖稱做后置調用對象圖，是方法由于異常返回后的對象快照。

定義5（非）原子性失效（failure atomic/nonatomic）。類C中的方法m是原子性失效，當且僅當對類C的對象o和o對m的調用由于異常返回，且m調用前后o的前置調用對象圖與后置對象圖相等；否則，稱之為非原子性失效。

如果異常處理能確保失效的原子性，該異常處理是原子的，反之稱為非原子異常處理。異常處理的原子性與異常安全[43]、異常中立[1]的要求是一致的。基于上述形式化的分析，Fetzer等人提出了一個兩階段的非原子失效方法的標志與轉換方法：探測階段通過異常的自動注入來檢測出非原子失效方法；掩蔽階段則是將非原子失效方法轉換為原子失效方法。轉換與事務處理類似，通過將對象狀態回滾到對象先前內部狀態一致的檢查點處。它們基于C/C++解釋器CINT和Java包裝生成器JWG實現測試系統對C++和Java語言的處理（還能實現Java字節碼的轉換），經過實例程序的檢驗表明，基于對象狀態的異常測試技術相當有效。主要不足在于這種功能性測試很難保證測試的充分性，對異常錯誤的定位不準確。

3．3構件程序中的異常測試

構件軟件的測試有著與傳統軟件測試不同的特點，對其中異常處理的測試也如此。Ghosh等人[15]提出了一種針對第三方構件測試運行時異常測評方法：首先運用失效模擬工具模擬產生操作系統級別的錯誤，如內存定位錯誤、網絡問題和文件I/O問題等。分析這些系統級錯誤對第三方構件的影響，用以評估構件對運行時異常的處理能力。該方法實現簡單且能自動進行；其不足是只能檢測隱式異常錯誤，并且所實現的原型工具相當粗糙。

除了測試是保證構件中異常處理正確性的手段外，針對構件特征對其異常處理策略進行改進也是一個研究熱點。Romanovsky[44]介紹了一種結構化的異常處理方法用于基于構件的系統開發。首先用包裝器技術實現單個構件級的錯誤和異常定位；再在原子動作概念的基礎上實現異常處理的系統級集成。Rubira等人[45，46]擴充已有構件的構造，提出了理想容錯構件（idealized faulttolerant component， IFTC）。IFTC由相互分離且定義良好的兩個活動域（常規活動和反常活動）組成，有常規響應、接口異常和失效異常這三類響應。容錯構件內的異常由應用級異常處理器（ALE handlers）進行處理。構件構建系統時，構件間傳播的異常則由連接器級異常處理器（CLE handlers）負責處理。通過在兩個實例系統上的實驗表明，他們的方法是可行的。

3．4Web應用中的異常測試

Web程序的分布、并發和異質等特點給異常結構的分析與測試帶來困難。Fu等人進行了Web程序中異常處理代碼的結構性覆蓋測試的研究[16]。他們使用如圖2所示的兩階段異常—捕獲鏈分析算法實現程序中的異常流分析。其中，DataReach過濾過程主要用于清除不可行（或不可達）的異常—捕獲路徑。與第2章介紹的異常分析方法不同的是，該方法是基于對象的，通過不同的new()語句區分異常對象，并且著重關注過程間傳播的異常類型。為了檢驗異常流結構性測試方法的效率，他們實現了一個異常缺陷植入框架，通過定義異常定義—捕獲準則計算覆蓋率。四個實例程序的測試表明，它能獲得84%左右的異常—捕獲路徑覆蓋。但該方法尚存在只針對部分異常類型以及測試的準確性依賴于指向和可達性分析等不足。

4異常分析與測試工具

迄今為止，已經出現不少異常分析或測試的原型工具。其中最為典型的有以下幾種：a）Harrold領導Aristotle研究小組開發的Java 字節碼分析框架JABA（記為T1）[3]；b）Robillard等人的Jex工具（T2）[4，47]能產生異常結構視圖，并能輔助開發人員進行異常流的推理；c）Shelekhov等人基于OSA形成的Java語言數據流分析工具（T3）[9]；d）Mayer等人則實現了一個能很好地調試異常和非結構化控制流的智能調試引擎JADE（T4）[13]；e）Fetzer等人實現的非原子性異常探測與掩蔽系統（T5）[14]。上述工具的簡單對比如表3所示。

5本文工作

本文以面向對象程序設計語言中具有代表意義的C++為例，擴展已有的顯式異常分析技術，對隱式異常也進行了全面的分析并提出了過程間（內）控制流圖的構造方法[48，49]。分析時克服了Choi等人提出的潛在異常拋出指令PEI粒度過細的不足，將異常語句分為一般異常語句ES和潛在異常語句PES兩類。這樣構造出來的ICFG更簡潔。通過詞法、語法分析很容易分析出ES和PES語句，進而得到整個程序可能出現的異常類型集；再分析該集合中異常的繼承關系并將它們組織成異常繼承層次結構圖（記做EIHG）。EIHG中有兩類節點，即標準異常類型和自定義異常類型。

基于程序代碼的抽象語法樹AST和EIHG按如下步驟進行包含異常結構的控制流圖分析：a）按傳統方法構造出方法內控制流圖CFG。b）為每個方法的退出節點構造一個伴隨節點，用于記錄在該方法范圍內未捕獲的異常統計信息。從每個未捕獲住的異常類型節點連一條有向邊到該伴隨節點。c）自底向上遞歸構造方法間控制流圖ICFG。以ICFG提供的結構信息為基礎給出一個C++程序健壯性改進模型。

同時本文還提出了針對異常動態測試的兩種策略，即基于約束求解的異常測試策略和統計結構性異常測試策略。最后，在VisualC++6.0的環境下初步實現了一個針對C++的異常分析與測試工具，并將其融合進C++程序測試平臺CppTest[50，51]。

6結束語

總結已有的針對異常處理的分析和測試技術，還有如下方向值得深入研究：a）一般而言，異常出現的可能性比較小，在產生面向路徑的測試用例時異常路徑的前置條件很難滿足[53]。因而對應的約束求解很困難，有待于建立更為有效的約束求解系統；并且，面向狀態的異常測試用例生成技術尚無相關研究。b）對于當前應用甚廣的軟件形態——構件軟件和Web程序，一方面要研究異常處理機制在該軟件形態下的增強或改進技術，另一方面從其中的異常處理代碼的分析與測試入手，保證獲得高可靠性的軟件系統。c）研制自動化程度高、可視化和交互性強的異常分析與測試工具或原型也是一個極具現實意義的課題。

參考文獻：

［1］CARGILL T. Exception handling: a 1 sense of security[J]. C++ Report， 1994，6(9):2124.

[2］MILLER R， TRIPATHI A. Issues with exception handling in objectoriented systems[C]//Proc of ECOOP’97， Lecture Notes in Computer Science.Finland:SpringerVerlag，1997:85103.

[3］SINHA S， HARROLD M J. Analysis and testing of programs with exception handling constructs[J]. IEEE Trans on Software Eng， 2000，26(9):849－871.

[4］ROBILLARD M P， MURPHY G C. Static analysis to support the evolution of exception structure in objectoriented systems[J]. ACM Trans on Software Eng and Methodology，2003，12(2):191－221.

[5］GARCIA A F， BEDER D M， RUBIRA C M F. An exception hand￣ling software architecture for developing faulttolerant software[C]//Proc of HASE 2000.New Mexico:[s.n.]， 2000:311－320.

[6］ISSARNY V， BENATRE J P. Architecturebased exception handling[C]//Proc of the 34th Annual Hawaii Int’l Conf on System Scie￣nces.Washington D C:[s.n.]， 2001:110.

[7］LIPPERT M， LOPES C V. A study on exception detection and hand￣ling using aspectoriented programming[C]//Proc of the 22nd Int’l Conf of Software Engineering (ICSE).Orlando:ACM Press， 2000:418－427.

[8］JIANG Shujuan， XU Baowen. An efficient and reliable objectoriented exception handling mechanism[J]. ACM SIGPLAN Notices， 2005， 40(2):27－32.

[9］SHELEKHOV V I， KUKSENKO S V. Data flow analysis of Java programs in the presence of exceptions[C]//Proc of PSI’99.Novoqibirsk:[s.n.]， 2000:389－395.

[10］CHOI J D， GROVE D， HIND M， et al. Efficient and precise mode￣ling of exceptions for the analysis of Java programs[C]//Proc of PASTE’99.NewYork:ACM， 1999:21－31.

[11］CHANG B M， JO J W， YI K. Interprocedural exception analysis for Java[C]//Proc of the 2001 ACM Symposium on Applied Computing (SAC).New York:[s.n.]， 2001:620－625.

[12］SINHA S， HARROLDM J. Criteria for testing exceptionhandling constructs in Java programs， OSUCISRC－6/99TR16[R].Columbus，Ohio:Ohio State Univ， 1999.

[13］MAYER W， STUMPTNER M. Extending diagnosis to debug programs with exceptions[C]//Proc of ASE’03.Montreal:[s.n.]， 2003:240－244.

[14］FETZER C， FELBER P， HOGSTEDT K. Automatic detection and masking of nonatomic exception handling[J]. IEEE Trans on Software Eng， 2004，30(8):547－560.

[15］GHOSH A K， SCHMID M. An approach to testing COTS software for robustness to operating system exceptions and errors[C]//Proc of the 10th Int’l Symposium on Software Reliability Engineering (ISSRE).Los Alamitos:IEEE Computter Socity Press，1999:166174.

[16］FU C， RYDER B， MILANOVA A， et al. Testing of Java Web ser￣vices for robustness[C]//Proc of ISSTA’04.Boston:[s.n.]， 2004:23－34.

[17］ROMANOVSKY A， DONY C， TRIPATHI A， et al. Exception hand￣ling in objectoriented systems: towards emerging application areas and new programming paradigms[C].//Proc of ECOOP. Germany:[s.n.]，2003.

[18］MITCHELL S E， BURNS A， WELLINGS A J.MOPping up exceptions[J]//Exception handling for a 21st century programming language proceedings.ACM SIGAda Ada Letters，2001，21(3):80－92.

[19］ROMANOVSKY A， DONY C， KNUDSEN J L， et al. Advances in exception handling techniques[M].[S.l.]: SpringerVerlag， 2001.

[20］GOODENOUGH J B. Exception handling: issues and a proposed notation[J]. Communications of the ACM， 1975，18(12):683－696.

[21］YEMINI S， BERRY D M. A modular verifiable exceptionhandling mechanism[J].ACM Trans Prog Lang Sys，1985，7(2):214－243.

[22］KNUDSEN J L. Better exceptionhandling in blockstructured systems[J]. IEEE Software， 1987，17(2):40－49.

[23］BUHR P A， ANDMOK W R. Advanced exception handling mechanisms[J]. IEEE Trans on Software Eng， 2000，26(9):820－836.

[24］STROHMEIER A， CHACHKOV S. A sidebyside comparison of exception handling in Ada and Java[J]. ACM SIGAda Ada Letters， 2001，21(3):41－56.

[25］GOSLING J， JOY B， STEELE G. The Java language specification[K]. [S.l.]: AddisonWesley， 1996.

[26］STROUSTRUP B. The C++ programming language [M]. 3rd ed.[S.l.]: AddisonWesley， 1997.

[27］SINHA S， HARROLD M J. Analysis of programs with exception hand￣ling constructs[C]//Proc of Int’l Conf of Software Maintenance (ICSM).Bethesda:[s.n.]，1998:348－357.

[28］PLEVYAK J， CHIEN A. Precise concrete type inference for objectoriented languages[C]//Proc of the 9th Ann Conf ObjectOriented Programming Systems， Languages， and Applications.Bologna:[s.n.]， 1994:324－340.

[29］CHATTERJEE R， RYDER B G， LANDI W A. Complexity of concrete typeinference in the presence of exceptions[C]//Proc of European Symp Programming. 1998:57－74.

[30］SINHA S， HARROLD M J. Control flow analysis of programs with exception handling constructs， OSUCISRC－7/98TR25[R].Columbus，Ohio: Ohio State Univ， 1998.

[31］CYTRON R， FERRANTE J， ROSEN B K， et al. Efficient computing static single assignment form and the control dependence graph[J]. ACM Trans Prog Lang Sys，1991，13(4):451－490.

[32］Static error checker (OSA)[EB/OL]. http://www.xds.ru/osa/.

[33］YI K. An abstract interpretation for estimating uncaught exception in standard ML programs[J]. Science of Computer Programming， 1998，31(1):147173.

[34］YI K， RYU S. A costeffective estimation of uncaught exceptions in standard ML programs[J]. Theoretical Computer Science， 2001，277(1):185－217.

[35］GLYNN K， STUCKEY P J， SULZMANN M， et al. Exception analysis for nonstrict languages[J]. ACM SIGPLAN Notices， 2002，37(9):98109.

[36］JO J W， CHANG B M， YI K. An uncaught exception analysis for Java[J]. Journal of Systems and Software， 2004，72(1): 59－69.

[37］HEINTZE N. Setbased program analysis[D]. Pittsburgh，PA: Carnegie Mellon University， 1992.

[38］CHANG B M， JO J W， ANDHER S H. Visualization of exception propagation for Java using static analysis[C]//Proc of the 2nd Int’l Workshop on Source Code Analysis and Manipulation.Montreal:IEEE， 2002:173182.

[39］JO J W， CHANG B M. Constructing control flow graph for Java by decoupling exception flow from normal flow[C]//Proc of ICCSA 2004， LNCS 3043.Assisi， Italy:[s.n.]， 2004:106113.

[40］CRISTIAN F. Exception handling and tolerance of software faults[M]//LYU M.Software fault tolerance.[S.l.]:Wiley，1995:81107.

[41］單錦輝， 王戟， 齊治昌. 面向路徑的測試數據自動生成方法述評[J]. 電子學報， 2004，32(1):109113.

[42］MAYER W， STUMPTNER M. Debugging program exceptions[C]//Proc of the 14th Int’ Workshop on Principles of Diagnosis.Washington DC:[s.n.]， 2003:119124.

[43］ABRAHAMS D. Exceptionsafety in generic components[EB/OL]. 2003(2005－0510).[2006－07－05].http://www.boost.org/more/generic_exception_safety.html.

[44］ROMANOVSKY A. Exception handling in componentbased system development[C]//Proc of COMPSAC.2001:580－586.

[45］FERREIRA G R M， RUBIRA C M F， LEMOS R. Explicit representation of exception handling in the development of dependable componentbased systems[C]//Proc of HASE’01. 2001:182193.

[46］GUERRA P A C， FILHO F C， PAGANO V A， et al. Structuring exception handling for dependable componentbased software systems[C]//Proc of the 30th Euromicro Conf. 2004:575－582.

[47］ROBILLARD M P， MURPHY G C. Analyzing exception flow in Java programs[C]//Proc of ESEC/FSE’99，LNCS 1687.1999: 322－337.

[48］閆偉. 面向對象單元測試中的異常測試研究[D]. 武漢: 華中科技大學圖書館， 2004.

[49］毛澄映， 盧炎生. C++程序異常處理的分析與測試技術研究[J]. 小型微型計算機系統， 2006，27(3):481－485.

[50］毛澄映， 盧炎生. 分支測試中測試路徑用例的簡化生成方法[J]. 計算機研究與發展， 2006，43(2):321－328.

[51］盧炎生， 毛澄映. 面向對象簇級測試中類間測試序確定方法研究[J]. 小型微型計算機系統， 2005，26(6):995－999.

[52］TRACEY N， CLARK J， MANDER K， et al. An automated framework for structural testdata generation[C]//Proc of ASE’98.Hawa￣ii:IEEE Computer Society Press， 1998:285－288.

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