通過軟件測試提高軟件可靠性的方法分析

1、通過軟件測試提高軟件可靠性的方法分析0引言隨著計算機應(yīng)用范圍的日益廣泛，軟件系統(tǒng)作為計算機系統(tǒng)的神經(jīng)中樞，也早已延伸到了產(chǎn)品中的各個方面。為了能夠適應(yīng)各種復(fù)雜的背景環(huán)境和完成復(fù)雜的任務(wù)，近年來軟件系統(tǒng)的應(yīng)用規(guī)模、復(fù)雜度以及重要性程度均呈急劇上升趨勢。隨著軟件應(yīng)用范圍和規(guī)模的不斷擴大，軟件設(shè)計的復(fù)雜程度不斷提高，軟件開發(fā)中出現(xiàn)錯誤或缺陷的機會越來越多。同時，人們對軟件質(zhì)量的要求也越來越高，要保證產(chǎn)品的質(zhì)量并確保其有效性，提高軟件的質(zhì)量與可靠性是最關(guān)鍵的一個途徑，這已成為航空、航天等領(lǐng)域的共識。此時，作為軟件質(zhì)量保證手段之一的軟件測試越來越受到重視，對其要求也越來越高。因此，要根據(jù)軟件故障產(chǎn)生和發(fā)

2、展的規(guī)律，檢測出軟件存在的故障和可能存在的隱患，控制和減少軟件故障所造成的影響，構(gòu)建一個可以支撐高質(zhì)量、高可靠性軟件研制的技術(shù)保障體系，從而全面提高軟件系統(tǒng)在產(chǎn)品關(guān)鍵應(yīng)用中的可靠性和可用性。1工程實例1.1測試過程筆者所在院系的軟件產(chǎn)品通常要經(jīng)歷4個階段的開發(fā)研制，在軟件開發(fā)的每個階段，軟件內(nèi)部測試都要進行以下幾個方面的測試工作：靜態(tài)分析、代碼審查、單元測試、部件測試、配置項測試。（1）靜態(tài)分析。軟件靜態(tài)分析主要是通過專業(yè)軟件靜態(tài)分析工具對程序結(jié)構(gòu)、數(shù)據(jù)結(jié)構(gòu)、代碼品質(zhì)等在非運行狀態(tài)下進行分析，提取軟件大量的靜態(tài)內(nèi)部信息，為代碼審查及動態(tài)測試提供輔助參考信息，依據(jù)現(xiàn)有的度量模型定量評價軟件的內(nèi)在

3、質(zhì)量【1】。靜態(tài)分析中需關(guān)注的指標(biāo)有圈復(fù)雜度、基本復(fù)雜度、扇出數(shù)和模塊行數(shù)。（2）代碼審查。代碼審查主要是檢查代碼和設(shè)計的一致性；檢查代碼執(zhí)行標(biāo)準(zhǔn)的情況；檢查代碼的可讀性；檢查代碼邏輯表達的正確性和完整性；檢查代碼結(jié)構(gòu)的合理性等。（3）單元測試。單元測試的依據(jù)是軟件詳細(xì)設(shè)計說明文檔，單元測試對模塊內(nèi)所有的控制路徑設(shè)計測試用例，針對被測單元生成驅(qū)動模塊，將被測單元需調(diào)用的其它函數(shù)打樁，模擬實現(xiàn)被測單元的接口，執(zhí)行插樁后的測試用例，得到最終的測試結(jié)果。單元測試的目的是檢查每個軟件模塊能否正確地實現(xiàn)設(shè)計說明中的功能、性能、接口和其它設(shè)計約束等要求，并發(fā)現(xiàn)模塊內(nèi)可能存在的各種錯誤。（4）部件測試。部件

4、測試中，根據(jù)測試計劃和被測試軟件的設(shè)計文檔，采用自頂向下或自底向上的模式把各個模塊逐步裝配成所需的功能模塊并進行測試，部件測試對部件內(nèi)所有的接口設(shè)計測試用例，針對被測部件生成驅(qū)動，將被測部件需調(diào)用的函數(shù)真實調(diào)用，實現(xiàn)被測單元的真實接口，執(zhí)行測試用例，得到最終的測試結(jié)果。部件測試的目的是檢驗軟件單元和軟件部件之間的接口關(guān)系，并驗證軟件部件是否符合設(shè)計要求。（5）配置項測試。軟件配置項是為獨立的配置管理而設(shè)計的并且能滿足最終用戶功能的一組軟件。在這種測試中，首先根據(jù)測試計劃和被測試軟件的設(shè)計文檔，細(xì)化分解軟件需求，形成測試需求，然后再針對每一個測試需求，采用功能分解法、邊界值分析法、錯誤猜測法、程

5、序插樁法、等價類劃分法等方法逐一設(shè)計測試用例，最后在實際測試環(huán)境中運行測試用例并取得測試結(jié)果，并將實際結(jié)果與預(yù)期結(jié)果進行比較分析，根據(jù)一致性原則判定測試用例是否通過。軟件配置項測試的目的是檢驗軟件配置項與軟件需求規(guī)格說明的一致性。1.2問題現(xiàn)象某產(chǎn)品軟件到了后期階段仍在進行頻繁更改，通過對其分析，得出軟件復(fù)雜度高是其存在的主要問題。GJB/Z 102-97軟件可靠性和安全性設(shè)計準(zhǔn)則中對軟件編程要求做了如下規(guī)定：（1）除中斷情形外，模塊應(yīng)使用單入口和單出口的控制結(jié)構(gòu)。（2）在設(shè)計軟件時，將模塊在邏輯上構(gòu)成分層次的結(jié)構(gòu)，在不同的層次上可有不同的扇入扇出數(shù)。模塊的實際結(jié)構(gòu)形態(tài)應(yīng)滿足下述準(zhǔn)則：模塊的扇

6、出一般應(yīng)控制在7以下；為避免某些程序代碼的重復(fù)，可適當(dāng)增加模塊的扇入；應(yīng)使高層模塊有較高的扇出，低層模塊有較高的扇入。（3）軟件單元的圈復(fù)雜度（即McCabe 指數(shù)）應(yīng)小于10。（4）對于用高級語言實現(xiàn)的軟件單元，每個軟件單元的源代碼最多不應(yīng)超過200行，一般不超過60行。據(jù)統(tǒng)計，某產(chǎn)品軟件某版本總模塊數(shù)251個，行數(shù)超標(biāo)的模塊數(shù)有11個，基本復(fù)雜度超標(biāo)的模塊數(shù)有15個，圈復(fù)雜度超標(biāo)的模塊數(shù)有87個，占到了總模塊數(shù)的34.7%，最高的圈復(fù)雜度達到了89，超出了規(guī)定值的8倍，軟件中頻繁更改的模塊大多是復(fù)雜度比較高的模塊。1.3問題分析在軟件經(jīng)過幾個階段的測試之后，所發(fā)現(xiàn)的軟件錯誤和缺陷均已得到了

7、更正，但靜態(tài)分析結(jié)果中的軟件圈復(fù)雜度、基本復(fù)雜度等指標(biāo)超高的現(xiàn)象一直沒有被重視，到了后期軟件越來越復(fù)雜導(dǎo)致軟件潛在風(fēng)險發(fā)生。軟件復(fù)雜度是衡量軟件質(zhì)量的一個因素，圈復(fù)雜度大說明程序代碼質(zhì)量低且難于測試和維護。經(jīng)驗表明，程序的可能錯誤和高的圈復(fù)雜度有著很大關(guān)系，基本復(fù)雜度高意味著程序模塊的結(jié)構(gòu)不夠良好;，難以理解和模塊化，軟件質(zhì)量的可維護性低。從圖1和圖2中可以看出，復(fù)雜度越高，內(nèi)部結(jié)構(gòu)越復(fù)雜，其潛在的出錯可能性也就越大。2測試指導(dǎo)設(shè)計2.1軟件質(zhì)量的pareto原理pareto原理【2】 指出，20%的軟件模塊包含了軟件中80%的缺陷，20%的軟件改進，需花費80%的適應(yīng)性維護費用。通過軟件測試

8、問題分析可以看出，少部分的高復(fù)雜度模塊引起了大部分的軟件錯誤，且經(jīng)常出錯的模塊改錯后還會經(jīng)常出錯。復(fù)雜度超標(biāo)問題修正越晚，修正的難度越大，并且會出現(xiàn)修改了一個錯誤，卻引出了更多錯誤的情況，或是修改了有缺陷的代碼，卻又導(dǎo)致先前正確的功能模塊出現(xiàn)錯誤等。因此，必須在發(fā)現(xiàn)軟件復(fù)雜度超標(biāo)的早期階段就及時進行修正。2.2降低軟件圈復(fù)雜度2.2.1圈復(fù)雜度定義在軟件測試的概念里，圈復(fù)雜度用來衡量一個模塊判定結(jié)構(gòu)的復(fù)雜程度，數(shù)量上表現(xiàn)為獨立線性路徑條數(shù)，即合理的預(yù)防錯誤所需測試的最少路徑條數(shù)。1976年Thomas McCabe提出了圈復(fù)雜度（Cyclomatic Complexity）的概念，依據(jù)圈復(fù)雜度

9、定義了軟件的復(fù)雜性。1977年Halstead提出了軟件科學(xué)復(fù)雜度度量。文獻【3】通過實驗證實了嵌入式軟件錯誤的位置與軟件的復(fù)雜度緊密相關(guān)，并且建立了動態(tài)復(fù)雜度模型，提出通過軟件復(fù)雜度度量可以識別程序中哪些代碼存在錯誤傾向。研究表明，軟件的缺陷不是隨機地分布在軟件中，軟件缺陷的存在與軟件獨特的、可度量的特性有關(guān)【4】。2.2.2復(fù)雜度計算方法C語言常用的軟件模塊邏輯結(jié)構(gòu)（結(jié)構(gòu)流圖）有如下幾種，如圖3所示。2.2.3降低圈復(fù)雜度由圈復(fù)雜度計算方法可以看出，在圈復(fù)雜度超過標(biāo)準(zhǔn)需要降低的情況下，可以將復(fù)雜的判斷條件提前計算，保證出現(xiàn)在if語句中的判斷條件的單一性。或是將重復(fù)代碼或相似代碼提取為一個新

10、的函數(shù)，將過長的函數(shù)按功能拆分成小的函數(shù)。2.3降低軟件基本復(fù)雜度2.3.1基本復(fù)雜度定義基本復(fù)雜度ev（G）為軟件通過結(jié)構(gòu)化（用單一結(jié)點替換控制流圖中的基本邏輯結(jié)構(gòu)）流程簡化后，再計算出的圈復(fù)雜度?；緩?fù)雜度計算方法為先畫出結(jié)構(gòu)流圖，然后將其中的基本結(jié)構(gòu)替換為一個結(jié)點，全部基本結(jié)構(gòu)替換完畢后計算基本復(fù)雜度。結(jié)構(gòu)流圖的簡化過程如圖9所示。2.3.2降低基本復(fù)雜度只要語句中運用的為正常;的編程語句使程序結(jié)構(gòu)保持單入口、單出口，無goto、break等異常跳轉(zhuǎn)語句，那么基本復(fù)雜度應(yīng)該都為1。如果程序中出現(xiàn)了非結(jié)構(gòu)化的語句，比如多入口、多出口等，則會導(dǎo)致最終結(jié)構(gòu)化完成后的基本復(fù)雜度不為1，如圖10所

11、示的幾種結(jié)構(gòu)。由以上分析可知，只要在編程中應(yīng)用正常的基本結(jié)構(gòu)（主要特點為單入口、單出口），減少break、goto等非正常出口、入口語句，就可以控制基本復(fù)雜度。2.4降低軟件扇出數(shù)一個過程/函數(shù)調(diào)用其它過程/函數(shù)的個數(shù)，稱為該模塊的扇出。扇出過小會增加程序結(jié)構(gòu)深度，過大會增加程序結(jié)構(gòu)寬度，并且導(dǎo)致過程或函數(shù)復(fù)雜性高。所以扇出最好為3或4個，最高不超過7個。一個過程/函數(shù)被其它過程/函數(shù)調(diào)用的個數(shù)，稱為該模塊的扇入。扇入越大表明模塊通用性越好，但扇入過大則程序的聚合性會變差。如果發(fā)現(xiàn)某個模塊的扇入、扇出過大，可考慮重新分解調(diào)整。靜態(tài)分析的復(fù)雜度結(jié)果可以預(yù)測軟件潛在錯誤的比率，可以指出過于復(fù)雜需要

12、分解的模塊，可以預(yù)測維護代碼和分接代碼所需的工作量，還可以揭示代碼的質(zhì)量。這些結(jié)果除了可以指導(dǎo)測試過程外，還可以用于指導(dǎo)軟件開發(fā)，使軟件復(fù)雜度從早期階段就得到控制，避免軟件中的錯誤傾向。在后續(xù)其它產(chǎn)品的軟件開發(fā)和測試過程中，靜態(tài)分析結(jié)果指導(dǎo)設(shè)計得到了很好的效果。3結(jié)語本文通過軟件測試問題分析研究了通過測試結(jié)果指導(dǎo)軟件設(shè)計的方法，以提高軟件的質(zhì)量和可靠性。軟件靜態(tài)分析可以度量軟件的基本質(zhì)量屬性，但目前其中的復(fù)雜度信息往往得不到設(shè)計人員的重視。某產(chǎn)品軟件測試實踐結(jié)果表明，靜態(tài)分析的結(jié)果能從軟件內(nèi)部結(jié)構(gòu)信息層面幫助設(shè)計人員開展代碼優(yōu)化工作，在軟件早期階段有意識地對復(fù)雜度等質(zhì)量指標(biāo)進行限制，后期就能避免軟件復(fù)雜度過高帶來的風(fēng)險，從而提高軟件的質(zhì)量和可靠性。參考文獻：【1】尹平，許聚常，張慧穎.軟件測試與軟件質(zhì)量評價.北京：國防工業(yè)出版社，2008.【2】SCHULMEYER G G.軟件質(zhì)量保證.北京： 機械工業(yè)出版社，2003.【3】JOHN C，MUNSON.Software faults，software failures and software reliability mod