摘要：如何有效地獲取具有代表性的差錯(cuò)數(shù)據(jù)進(jìn)行差錯(cuò)注入仍是故障注入技術(shù)一個(gè)有待深入研究的問題。文中通過故障注入實(shí)驗(yàn)分析了程序的“故障-差錯(cuò)-異?！眰鞑C(jī)理，說明了從異常層次進(jìn)行程序錯(cuò)誤行為分析及其差錯(cuò)數(shù)據(jù)收集的合理性。該研究為當(dāng)前具有較大規(guī)模的、具有異常處理機(jī)制的程序進(jìn)行差錯(cuò)數(shù)據(jù)的收集提供了新途徑。

關(guān)鍵詞：異常；故障注入；軟件差錯(cuò)

中圖分類號：TP311 文獻(xiàn)標(biāo)識碼：A 文章編號：1009-3044（2014）30-7077-03

Analysis of Programs “fault-error-exception/failure” Process Based on Exception Control Flow

SUN Ya

（School of Software， Tongji University， Shanghai 201804， China）

Abstract： Its still a key question to fault-injection technique that how to effectively generate representative error set that emulates software fault. In this paper， the propagation process of “fault-error-exception” chain in program is analyzed with fault injection experiment， which rationalizes the point to analyze program erroneous behavior from the aspect of exception control flow. This research provides a new means to analyze the erroneous behavior and generate the valid error set for the large-scale program with exception handling mechanism automatically.

Key words： exception； fault injection； software error

故障注入技術(shù)通過人為地對軟件或計(jì)算系統(tǒng)注入故障，加速其失效而達(dá)到驗(yàn)證目標(biāo)軟件的容錯(cuò)機(jī)制、評估軟件可靠性的目的[1]。如何獲取建立故障或差錯(cuò)模型是該技術(shù)在實(shí)現(xiàn)過程中的關(guān)鍵[2]。對于軟件而言，在進(jìn)行差錯(cuò)注入之前，具有代表性的差錯(cuò)集合獲取需要分析目標(biāo)軟件的功能特性及其在故障激活后所表現(xiàn)出的錯(cuò)誤行為[1-2]。但該過程需要分析大量故障或失效數(shù)據(jù)，周期很長。

程序的異常處理機(jī)制是提高軟件可靠性的重要手段之一。該機(jī)制通過異常的引發(fā)、捕捉及其錯(cuò)誤處理代碼的執(zhí)行，可將程序從錯(cuò)誤狀態(tài)恢復(fù)到正常狀態(tài)，避免軟件失效的發(fā)生 [3]。所以，當(dāng)該類程序中的故障在激活之后，會(huì)有一定的幾率被異常處理機(jī)制偵測，最終引起異常。這說明程序中異常可看作程序故障激活后的一種表現(xiàn)形式。該文通過以Ipbench作為實(shí)驗(yàn)負(fù)載，對其進(jìn)行基于正交缺陷分類[1]（orthogonal defect classification， ODC）故障的故障注入實(shí)現(xiàn)，分析了具有異常處理機(jī)制的程序中故障激活后如何引起異常的發(fā)生，描述了該類程序中“故障-差錯(cuò)-異常/失效”的傳播關(guān)系。

1 程序“故障-差錯(cuò)-異常/失效”機(jī)理分析

圖1 在“故障-差錯(cuò)-失效”基礎(chǔ)上考慮了異常處理環(huán)節(jié)

程序的“故障-差錯(cuò)-失效”過程已經(jīng)得到了準(zhǔn)確地描述[2]。在具有異常處理機(jī)制的程序中，故障激活后所生成的差錯(cuò)經(jīng)傳播后若被異常處理機(jī)制偵測，則異常發(fā)生。若對該異常處理不當(dāng)，則可引起程序失效[3]，過程呈現(xiàn)“故障-差錯(cuò)-異常/失效”特征。所以，可將異常看作一般差錯(cuò)在程序中的一種表象。程序“故障-差錯(cuò)-異常/失效”過程如圖1所示。

以Ipbench中的_validate_cell函數(shù)為例，結(jié)合ODC故障注入實(shí)驗(yàn)的實(shí)施過程，對“故障-差錯(cuò)-異?！眰鞑C(jī)理進(jìn)行分析，如下：

1） 故障激活所生成的差錯(cuò)直接引發(fā)異常，如圖2所示：<1>若第5、7行發(fā)生if語句丟失，則該控制故障使得raise語句執(zhí)行而引發(fā)異常；<2>若第5行if語句的not關(guān)鍵詞丟失，則該控制故障使得raise語句在錯(cuò)誤判斷下得到執(zhí)行而引發(fā)異常；<3>若第4行中instance[‘cell_name]被錯(cuò)誤的編寫成instance[‘cellname]，則該賦值故障使得cell_name值發(fā)生錯(cuò)誤。該差錯(cuò)可使得第5行if語句的判斷為True，讓原本不會(huì)被執(zhí)行的raise語句得到執(zhí)行而引發(fā)異常。

圖2 故障激活所生成的差錯(cuò)直接引發(fā)異常程序示例

2） 故障激活所產(chǎn)生的差錯(cuò)經(jīng)過傳播后引發(fā)異常，如圖3所示：<1>若instance在傳入_validate_cell之前存在賦值故障，則該故障可導(dǎo)致第4行語句中的instance[‘cell_name]數(shù)據(jù)出錯(cuò)，使得第5行if語句判斷為True，在raise語句得到執(zhí)行后引發(fā)異常；<2>第7行中如果_cell_read_only函數(shù)存在接口故障，該故障激活后生成的差錯(cuò)通過函數(shù)的返回值使得if語句判斷為True，在第8行raise語句執(zhí)行后引發(fā)異常。

圖3 故障激活所產(chǎn)生的差錯(cuò)經(jīng)過傳播后引發(fā)異常程序

3） 無故障、無差錯(cuò)情況下，外界輸入或外界資源違反軟件規(guī)格約束而導(dǎo)致異常的引發(fā)。異常處理機(jī)制是軟件錯(cuò)誤處理的常用手段之一，對于在外界輸入或外界資源違反軟件規(guī)格約束的情況下，程序則利用該機(jī)制進(jìn)行錯(cuò)誤的偵測，并以異常的形式暴露該類錯(cuò)誤的發(fā)生，若異常未被程序捕捉，則該類異常會(huì)導(dǎo)致程序崩潰[4]。文獻(xiàn)[4]對Android平臺上約800個(gè)應(yīng)用組件進(jìn)行了6，000，000次基于外界輸入的健壯性測試。由實(shí)驗(yàn)數(shù)據(jù)表明，約10%的應(yīng)用組件發(fā)生了崩潰且均由未捕捉異常造成。

2 實(shí)驗(yàn)方案介紹

這一章節(jié)將介紹向Ipbench進(jìn)行基于ODC的故障注入，并對該實(shí)驗(yàn)結(jié)果進(jìn)行分析。

2.1 Ipbench的故障注入方案

本文以分布式網(wǎng)絡(luò)基準(zhǔn)程序Ipbench為對象，結(jié)合文獻(xiàn)[1]中具有代表性的ODC故障類型及其分布數(shù)據(jù)進(jìn)行故障注入實(shí)驗(yàn)方案的設(shè)計(jì)與實(shí)施。經(jīng)過對Ipbench的分析，該程序的服務(wù)端與客戶端的總代碼量為1016行，總共具有348個(gè)故障注入點(diǎn)。根據(jù)文獻(xiàn)[1]中的ODC故障類型的分布特點(diǎn)，本故障注入方案中：賦值類故障為89個(gè)，控制類故障為76個(gè)，算法類故障為134個(gè)，接口類故障為14個(gè)，功能類故障為35個(gè)。

2.2實(shí)驗(yàn)流程

根據(jù)上述的故障注入方案，在對目標(biāo)程序進(jìn)行故障注入之后需要重新啟動(dòng)程序。在使用負(fù)載命令使得相關(guān)代碼得到執(zhí)行后，注入的故障得到激活。通過對故障激活后的程序表現(xiàn)，將其與正常無故障情況下的程序輸出進(jìn)行比較，然后判斷當(dāng)前故障是否對程序引起失效，包括：錯(cuò)誤輸出、程序掛起、程序崩潰。并且，記錄當(dāng)前故障是否引起程序異常的發(fā)生、引起何種異常，以達(dá)到收集準(zhǔn)確的實(shí)驗(yàn)數(shù)據(jù)的目的。

2.3 實(shí)驗(yàn)環(huán)境

本實(shí)驗(yàn)在虛擬機(jī)上完成，操作系統(tǒng)為內(nèi)核版本2.6.32的32位Linux，虛擬機(jī)硬件配置為1GB內(nèi)存，Intel（R） Core（TM） i3-3217U@1.80GHz單核CPU。

3 實(shí)驗(yàn)結(jié)果分析

表1 Ipbench與nova組件的故障注入實(shí)驗(yàn)結(jié)果[Ipbench＼&ODC類型＼&正常輸出＼&錯(cuò)誤輸出＼&程序掛起＼&程序崩潰＼&總數(shù)＼&異常＼&總數(shù)＼&異常＼&總數(shù)＼&異常＼&總數(shù)＼&異常＼&賦值＼&17＼&0＼&3＼&0＼&1＼&0＼&68＼&68＼&控制＼&6＼&0＼&3＼&0＼&2＼&0＼&65＼&65＼&算法＼&26＼&3＼&5＼&0＼&18＼&0＼&85＼&82＼&接口＼&1＼&0＼&0＼&0＼&2＼&0＼&11＼&11＼&功能＼&5＼&0＼&1＼&0＼&3＼&0＼&26＼&23＼&總數(shù)＼&55＼&3＼&12＼&0＼&26＼&0＼&255＼&249＼&引發(fā)率＼&5.5%＼&0%＼&0%＼&97.6%＼&]

由表1所示，Ipbench中共注入348個(gè)故障，其中255個(gè)故障導(dǎo)致了程序崩潰，且249次崩潰是由未捕捉異常引起。該程序缺乏合理的異常處理結(jié)構(gòu)對各類異常進(jìn)行捕捉、處理，成為了程序崩潰的主要原因。

實(shí)驗(yàn)中差錯(cuò)得到修正后，程序仍能正常輸出的原因包括但不限于：1）差錯(cuò)相關(guān)的數(shù)據(jù)在被使用前重新得到初始化；2）差錯(cuò)激活情況下的程序執(zhí)行效果與無差錯(cuò)情況下的程序執(zhí)行效果相同；3）差錯(cuò)所引起的異常被捕捉后，程序異常處理例程重新提供正常服務(wù)。

對于第一章節(jié)中1）和2）所描述的“故障-差錯(cuò)-異?！眰鞑ミ^程而言，若排除差錯(cuò)被修正后得到的正常輸入數(shù)據(jù)，Ipbench中由差錯(cuò)引起異常的比例為97.6%。由于實(shí)驗(yàn)規(guī)模的限制，該數(shù)據(jù)并不能代表所有程序的異常引發(fā)率，但可表明程序中一定比例的差錯(cuò)能夠引起程序異常，且該引發(fā)率與程序異常處理結(jié)構(gòu)實(shí)現(xiàn)的不同而不同。對于3）中的軟件健壯性問題，實(shí)際上是通過接口故障引入的，該類故障所生成的差錯(cuò)具有不可忽視的異常引發(fā)率[4]。

4 結(jié)論

本文研究了軟件故障、差錯(cuò)、異常之間的傳播機(jī)理，并通過故障注入實(shí)驗(yàn)證明該機(jī)理分析結(jié)果的正確性和合理性。該研究也為具有異常處理機(jī)制的程序進(jìn)行錯(cuò)誤行為分析及其差錯(cuò)數(shù)據(jù)收集提供了新的途徑。

參考文獻(xiàn)：

[1] Duraes J A，Madeira H S.Emulation of software faults： a field data study and a practical approach[J].IEEE Transactions onSoftware Engineering， 2006， 32（11）： 849-867.

[2] Christmansson J，Chillarege R.Generation of an error set that emulates software faults based on field data[C].Proceedings of the26th IEEE Symposium on Fault Tolerant Computing. Sendai， 1996： 304-313.

[3] Shah H B，Gorg C，Harrold M J.Understanding exception handling： Viewpoints of novices and experts[J].IEEE Transactions on Software Engineering， 2010，36（2）： 150-161.

[4] Amiya K Maji，F(xiàn)ahad A Arshad，et al. An empirical study of the robustness of Inter-component Communication in Android[C].Proceed-ings ofthe 42rd IEEE/IFIP International Conference on Dependable Systems and Networks. Boston ，2012： 1-12.

圖3 故障激活所產(chǎn)生的差錯(cuò)經(jīng)過傳播后引發(fā)異常程序

3） 無故障、無差錯(cuò)情況下，外界輸入或外界資源違反軟件規(guī)格約束而導(dǎo)致異常的引發(fā)。異常處理機(jī)制是軟件錯(cuò)誤處理的常用手段之一，對于在外界輸入或外界資源違反軟件規(guī)格約束的情況下，程序則利用該機(jī)制進(jìn)行錯(cuò)誤的偵測，并以異常的形式暴露該類錯(cuò)誤的發(fā)生，若異常未被程序捕捉，則該類異常會(huì)導(dǎo)致程序崩潰[4]。文獻(xiàn)[4]對Android平臺上約800個(gè)應(yīng)用組件進(jìn)行了6，000，000次基于外界輸入的健壯性測試。由實(shí)驗(yàn)數(shù)據(jù)表明，約10%的應(yīng)用組件發(fā)生了崩潰且均由未捕捉異常造成。

2 實(shí)驗(yàn)方案介紹

這一章節(jié)將介紹向Ipbench進(jìn)行基于ODC的故障注入，并對該實(shí)驗(yàn)結(jié)果進(jìn)行分析。

2.1 Ipbench的故障注入方案

本文以分布式網(wǎng)絡(luò)基準(zhǔn)程序Ipbench為對象，結(jié)合文獻(xiàn)[1]中具有代表性的ODC故障類型及其分布數(shù)據(jù)進(jìn)行故障注入實(shí)驗(yàn)方案的設(shè)計(jì)與實(shí)施。經(jīng)過對Ipbench的分析，該程序的服務(wù)端與客戶端的總代碼量為1016行，總共具有348個(gè)故障注入點(diǎn)。根據(jù)文獻(xiàn)[1]中的ODC故障類型的分布特點(diǎn)，本故障注入方案中：賦值類故障為89個(gè)，控制類故障為76個(gè)，算法類故障為134個(gè)，接口類故障為14個(gè)，功能類故障為35個(gè)。

2.2實(shí)驗(yàn)流程

根據(jù)上述的故障注入方案，在對目標(biāo)程序進(jìn)行故障注入之后需要重新啟動(dòng)程序。在使用負(fù)載命令使得相關(guān)代碼得到執(zhí)行后，注入的故障得到激活。通過對故障激活后的程序表現(xiàn)，將其與正常無故障情況下的程序輸出進(jìn)行比較，然后判斷當(dāng)前故障是否對程序引起失效，包括：錯(cuò)誤輸出、程序掛起、程序崩潰。并且，記錄當(dāng)前故障是否引起程序異常的發(fā)生、引起何種異常，以達(dá)到收集準(zhǔn)確的實(shí)驗(yàn)數(shù)據(jù)的目的。

2.3 實(shí)驗(yàn)環(huán)境

本實(shí)驗(yàn)在虛擬機(jī)上完成，操作系統(tǒng)為內(nèi)核版本2.6.32的32位Linux，虛擬機(jī)硬件配置為1GB內(nèi)存，Intel（R） Core（TM） i3-3217U@1.80GHz單核CPU。

3 實(shí)驗(yàn)結(jié)果分析

表1 Ipbench與nova組件的故障注入實(shí)驗(yàn)結(jié)果[Ipbench＼&ODC類型＼&正常輸出＼&錯(cuò)誤輸出＼&程序掛起＼&程序崩潰＼&總數(shù)＼&異常＼&總數(shù)＼&異常＼&總數(shù)＼&異常＼&總數(shù)＼&異常＼&賦值＼&17＼&0＼&3＼&0＼&1＼&0＼&68＼&68＼&控制＼&6＼&0＼&3＼&0＼&2＼&0＼&65＼&65＼&算法＼&26＼&3＼&5＼&0＼&18＼&0＼&85＼&82＼&接口＼&1＼&0＼&0＼&0＼&2＼&0＼&11＼&11＼&功能＼&5＼&0＼&1＼&0＼&3＼&0＼&26＼&23＼&總數(shù)＼&55＼&3＼&12＼&0＼&26＼&0＼&255＼&249＼&引發(fā)率＼&5.5%＼&0%＼&0%＼&97.6%＼&]

由表1所示，Ipbench中共注入348個(gè)故障，其中255個(gè)故障導(dǎo)致了程序崩潰，且249次崩潰是由未捕捉異常引起。該程序缺乏合理的異常處理結(jié)構(gòu)對各類異常進(jìn)行捕捉、處理，成為了程序崩潰的主要原因。

實(shí)驗(yàn)中差錯(cuò)得到修正后，程序仍能正常輸出的原因包括但不限于：1）差錯(cuò)相關(guān)的數(shù)據(jù)在被使用前重新得到初始化；2）差錯(cuò)激活情況下的程序執(zhí)行效果與無差錯(cuò)情況下的程序執(zhí)行效果相同；3）差錯(cuò)所引起的異常被捕捉后，程序異常處理例程重新提供正常服務(wù)。

對于第一章節(jié)中1）和2）所描述的“故障-差錯(cuò)-異?！眰鞑ミ^程而言，若排除差錯(cuò)被修正后得到的正常輸入數(shù)據(jù)，Ipbench中由差錯(cuò)引起異常的比例為97.6%。由于實(shí)驗(yàn)規(guī)模的限制，該數(shù)據(jù)并不能代表所有程序的異常引發(fā)率，但可表明程序中一定比例的差錯(cuò)能夠引起程序異常，且該引發(fā)率與程序異常處理結(jié)構(gòu)實(shí)現(xiàn)的不同而不同。對于3）中的軟件健壯性問題，實(shí)際上是通過接口故障引入的，該類故障所生成的差錯(cuò)具有不可忽視的異常引發(fā)率[4]。

4 結(jié)論

本文研究了軟件故障、差錯(cuò)、異常之間的傳播機(jī)理，并通過故障注入實(shí)驗(yàn)證明該機(jī)理分析結(jié)果的正確性和合理性。該研究也為具有異常處理機(jī)制的程序進(jìn)行錯(cuò)誤行為分析及其差錯(cuò)數(shù)據(jù)收集提供了新的途徑。

參考文獻(xiàn)：

[1] Duraes J A，Madeira H S.Emulation of software faults： a field data study and a practical approach[J].IEEE Transactions onSoftware Engineering， 2006， 32（11）： 849-867.

[2] Christmansson J，Chillarege R.Generation of an error set that emulates software faults based on field data[C].Proceedings of the26th IEEE Symposium on Fault Tolerant Computing. Sendai， 1996： 304-313.

[3] Shah H B，Gorg C，Harrold M J.Understanding exception handling： Viewpoints of novices and experts[J].IEEE Transactions on Software Engineering， 2010，36（2）： 150-161.

[4] Amiya K Maji，F(xiàn)ahad A Arshad，et al. An empirical study of the robustness of Inter-component Communication in Android[C].Proceed-ings ofthe 42rd IEEE/IFIP International Conference on Dependable Systems and Networks. Boston ，2012： 1-12.

圖3 故障激活所產(chǎn)生的差錯(cuò)經(jīng)過傳播后引發(fā)異常程序

3） 無故障、無差錯(cuò)情況下，外界輸入或外界資源違反軟件規(guī)格約束而導(dǎo)致異常的引發(fā)。異常處理機(jī)制是軟件錯(cuò)誤處理的常用手段之一，對于在外界輸入或外界資源違反軟件規(guī)格約束的情況下，程序則利用該機(jī)制進(jìn)行錯(cuò)誤的偵測，并以異常的形式暴露該類錯(cuò)誤的發(fā)生，若異常未被程序捕捉，則該類異常會(huì)導(dǎo)致程序崩潰[4]。文獻(xiàn)[4]對Android平臺上約800個(gè)應(yīng)用組件進(jìn)行了6，000，000次基于外界輸入的健壯性測試。由實(shí)驗(yàn)數(shù)據(jù)表明，約10%的應(yīng)用組件發(fā)生了崩潰且均由未捕捉異常造成。

2 實(shí)驗(yàn)方案介紹

這一章節(jié)將介紹向Ipbench進(jìn)行基于ODC的故障注入，并對該實(shí)驗(yàn)結(jié)果進(jìn)行分析。

2.1 Ipbench的故障注入方案

本文以分布式網(wǎng)絡(luò)基準(zhǔn)程序Ipbench為對象，結(jié)合文獻(xiàn)[1]中具有代表性的ODC故障類型及其分布數(shù)據(jù)進(jìn)行故障注入實(shí)驗(yàn)方案的設(shè)計(jì)與實(shí)施。經(jīng)過對Ipbench的分析，該程序的服務(wù)端與客戶端的總代碼量為1016行，總共具有348個(gè)故障注入點(diǎn)。根據(jù)文獻(xiàn)[1]中的ODC故障類型的分布特點(diǎn)，本故障注入方案中：賦值類故障為89個(gè)，控制類故障為76個(gè)，算法類故障為134個(gè)，接口類故障為14個(gè)，功能類故障為35個(gè)。

2.2實(shí)驗(yàn)流程

根據(jù)上述的故障注入方案，在對目標(biāo)程序進(jìn)行故障注入之后需要重新啟動(dòng)程序。在使用負(fù)載命令使得相關(guān)代碼得到執(zhí)行后，注入的故障得到激活。通過對故障激活后的程序表現(xiàn)，將其與正常無故障情況下的程序輸出進(jìn)行比較，然后判斷當(dāng)前故障是否對程序引起失效，包括：錯(cuò)誤輸出、程序掛起、程序崩潰。并且，記錄當(dāng)前故障是否引起程序異常的發(fā)生、引起何種異常，以達(dá)到收集準(zhǔn)確的實(shí)驗(yàn)數(shù)據(jù)的目的。

2.3 實(shí)驗(yàn)環(huán)境

本實(shí)驗(yàn)在虛擬機(jī)上完成，操作系統(tǒng)為內(nèi)核版本2.6.32的32位Linux，虛擬機(jī)硬件配置為1GB內(nèi)存，Intel（R） Core（TM） i3-3217U@1.80GHz單核CPU。

3 實(shí)驗(yàn)結(jié)果分析

表1 Ipbench與nova組件的故障注入實(shí)驗(yàn)結(jié)果[Ipbench＼&ODC類型＼&正常輸出＼&錯(cuò)誤輸出＼&程序掛起＼&程序崩潰＼&總數(shù)＼&異常＼&總數(shù)＼&異常＼&總數(shù)＼&異常＼&總數(shù)＼&異常＼&賦值＼&17＼&0＼&3＼&0＼&1＼&0＼&68＼&68＼&控制＼&6＼&0＼&3＼&0＼&2＼&0＼&65＼&65＼&算法＼&26＼&3＼&5＼&0＼&18＼&0＼&85＼&82＼&接口＼&1＼&0＼&0＼&0＼&2＼&0＼&11＼&11＼&功能＼&5＼&0＼&1＼&0＼&3＼&0＼&26＼&23＼&總數(shù)＼&55＼&3＼&12＼&0＼&26＼&0＼&255＼&249＼&引發(fā)率＼&5.5%＼&0%＼&0%＼&97.6%＼&]

由表1所示，Ipbench中共注入348個(gè)故障，其中255個(gè)故障導(dǎo)致了程序崩潰，且249次崩潰是由未捕捉異常引起。該程序缺乏合理的異常處理結(jié)構(gòu)對各類異常進(jìn)行捕捉、處理，成為了程序崩潰的主要原因。

實(shí)驗(yàn)中差錯(cuò)得到修正后，程序仍能正常輸出的原因包括但不限于：1）差錯(cuò)相關(guān)的數(shù)據(jù)在被使用前重新得到初始化；2）差錯(cuò)激活情況下的程序執(zhí)行效果與無差錯(cuò)情況下的程序執(zhí)行效果相同；3）差錯(cuò)所引起的異常被捕捉后，程序異常處理例程重新提供正常服務(wù)。

對于第一章節(jié)中1）和2）所描述的“故障-差錯(cuò)-異?！眰鞑ミ^程而言，若排除差錯(cuò)被修正后得到的正常輸入數(shù)據(jù)，Ipbench中由差錯(cuò)引起異常的比例為97.6%。由于實(shí)驗(yàn)規(guī)模的限制，該數(shù)據(jù)并不能代表所有程序的異常引發(fā)率，但可表明程序中一定比例的差錯(cuò)能夠引起程序異常，且該引發(fā)率與程序異常處理結(jié)構(gòu)實(shí)現(xiàn)的不同而不同。對于3）中的軟件健壯性問題，實(shí)際上是通過接口故障引入的，該類故障所生成的差錯(cuò)具有不可忽視的異常引發(fā)率[4]。

4 結(jié)論

本文研究了軟件故障、差錯(cuò)、異常之間的傳播機(jī)理，并通過故障注入實(shí)驗(yàn)證明該機(jī)理分析結(jié)果的正確性和合理性。該研究也為具有異常處理機(jī)制的程序進(jìn)行錯(cuò)誤行為分析及其差錯(cuò)數(shù)據(jù)收集提供了新的途徑。

參考文獻(xiàn)：

[1] Duraes J A，Madeira H S.Emulation of software faults： a field data study and a practical approach[J].IEEE Transactions onSoftware Engineering， 2006， 32（11）： 849-867.

[2] Christmansson J，Chillarege R.Generation of an error set that emulates software faults based on field data[C].Proceedings of the26th IEEE Symposium on Fault Tolerant Computing. Sendai， 1996： 304-313.

[3] Shah H B，Gorg C，Harrold M J.Understanding exception handling： Viewpoints of novices and experts[J].IEEE Transactions on Software Engineering， 2010，36（2）： 150-161.

[4] Amiya K Maji，F(xiàn)ahad A Arshad，et al. An empirical study of the robustness of Inter-component Communication in Android[C].Proceed-ings ofthe 42rd IEEE/IFIP International Conference on Dependable Systems and Networks. Boston ，2012： 1-12.