軟體可靠性及其驗證

軟體可靠性及其驗證

國防科工委可靠性工程技術中心 何國偉
本期專題: 軟體的可靠性
目前,軟體在系統中所處的地位越來越重要。眾所周知,系統中的硬體有可靠性指標的要
求,並必須經過驗證。但如果系統中軟體沒有可靠性指標要求,或不要求驗證,那麼整個系統
的可靠性仍是沒有保證的。目前,由於軟體可靠性原因而造成的災難性事故時有發生。為此
,本期專題將集中介紹軟體可靠性的有關問題,包括如下內容:
1.軟體可靠性及其驗證
本文在回顧了軟體可靠性發展曆程的基礎上,介紹了一些重要的軟體可靠性指標及其驗
證方法,並結合我國軟體工業發展的實際,提出了我國應該如何合理地制定一些軟體可靠性指
標。
2.軟體容錯與軟體故障樹技術的結合使用
本文介紹了在軟體系統方案研究、設計及編碼、測試等各階段如何將軟體容錯技術與軟
件故障樹技術結合,開發出了高可靠性軟體系統。
3.軟體可靠性工程實踐
如何保證軟體的可靠性已成為一項重要的工程內容。本文介紹了一種在實際中實施軟體
可靠性工程的方法。
4.軟體可靠性測試
進行軟體可靠性測試的目的是正確估計軟體產品的可靠性。本文介紹了軟體可靠性測試
的基本概念、應注意的問題和具體的測試步驟。
5.航天控制軟體的可靠性工程管理
本文分析了目前航天控制軟體可靠性工程管理存在的問題,針對這些問題,提出了一些軟
件工程化管理、軟體預先分析及可靠性度量的設想,旨在促進航天控制軟體可靠性工程管理
的系統化、正常化。
本期專期責任編輯 劉學習
一、引言
當前,軟體的可靠性問題已經暴露得相當突出。歐洲空間局發射的阿麗亞娜5號火箭由於
軟體故障造成損失數億美元。國內也出現了由於軟體故障損失數以百萬計的事故。凡此種種
,已不勝枚舉。
作者曾與美國宇航局的友人就軟體可靠性交換過意見。根據美國宇航局的經驗,他們的
軟體可靠性大體上比硬體低一個數量級。而美國宇航局的軟體是嚴格按軟體工程組織的,承
擔軟體開發的單位都要經受美國SEI(軟體工程研究所)規定的五級標準考核。因此,我們的軟
件可靠性水平大體上也不會比硬體高,這是一種符合情理的估計。
現在愈來愈多的民用、軍用系統採用了愈來愈多的軟體。硬體有可靠性要求,並且要求
驗證,例如按我國軍標GJB899考核驗證硬體是否達到MTBF(平均無故障時間)的最低可接受值
。但是,國內對軟體基本上還沒有提出可靠性指標,也不要求驗證。這樣,由於軟體的可靠性
無法保證,因此即使硬體的可靠性達到了要求的指標,但整個系統的可靠性仍無法保證。這種
狀況顯然與對民用、軍用系統的需要是不適應的。對軟體不提可靠性指標,對提高軟體的可
靠性沒有動力;而對提出的指標不要求驗證,對軟體開發單位沒有壓力。因此,對軟體提可靠
性指標的關鍵不是提多少,不是模仿硬體可靠性那樣去分配到元器件,而首先是如何驗證。
美國國家標準ANSI/AIAA R—013 1992《推薦的軟體可靠性的實踐》指出"最合理的軟體
故障率的可驗證要求大約在10-4/h左右",亦即MTBF在1萬小時左右。我國的軟體開發水平低
於美國,因此軟體的MTBF宜定在1000小時到10000小時之間,這應該算是一個先進的指標。
軟體可靠性當前最重要的指標是MTBF指標。其它的指標還有待進一步探討,例如硬體有
MTTR(平均維修時間)指標。但對軟體而言,使用者一般不應自行修改軟體,在沒有嚴格配置管
理下的軟體修改很可能愈改愈糟。一般情況下,軟體出現故障後由原開發單位修改,還必需經
過大量的必要的迴歸測試後才能再交付使用,而這一段時間往往相當長。因此,如何確定MTT
R就是一個有待很好探討的問題。本篇談的可靠性指標暫且只局限於MTBF。
二、軟體的缺陷、故障、故障率及平均壽命
國內不少人對軟體可靠性的基本概念還是不太清楚。因此本文先澄清一些基本概念。
從提出軟體產品的任務開始到產品不能使用為止的時間叫軟體的"生存周期"(即"壽命周
期")。在軟體生存周期的各個階段,人的行動會使軟體在一定條件下不能或將不能完成規定
功能。例如:
·使用者提出的需求是不完整的。
·軟體生產單位誤解了使用者的需求。
·軟體生產單位沒有完全實現使用者需求。
·軟體生產過程的下一道工序沒有完全實現上一道工序的要求。
·適用的演算法或判別邏輯不正確或不完整。
·人為疏漏等。
上述種種人的行動使軟體存在出現錯誤的根源,這叫"缺陷"。
一個軟體可能存在若干個缺陷。但是軟體執行一次任務時並不總是用到所有的程式組成
部分,如果未用到有缺陷的部分程式,則軟體仍能正確完成任務;如果在執行一次任務時要用
到有缺陷的部分程式,則軟體或軟體的一部分輸出就與規定的不符,即出故障(Fault)。所以
出故障是缺陷所在的程式通路被敏化而在此特定條件下的暴露。
軟體的組成部分在執行任務中被用到的頻率是不盡相同的,有些部分被頻繁地用到,有些
部分則極少被用到,亦即不同缺陷引起故障的可能性是不盡相同的,並且可以有幾個數量級的
差異。
對於某一個軟體缺陷來說,軟體執行任務而出一次故障的平均時間叫這一缺陷的平均壽
命MTBF,記為θ。其倒數記為λ=1/θ,叫作這個缺陷的故障率。
美國的E.N.Adams曾在1984年的IBM研究開發雜誌上,對有代表性的9個IBM軟體產品的缺
陷作了統計。他將軟體缺陷分為八檔,每檔MTBF的代表值為(單位年):
1.58, 5, 15.8, 50, 158, 500, 1580, 5000
第i檔的MTBF代表值為θi,該檔的總缺陷數為di,於是軟體總缺陷為
@@16103000.GIF;公式1@@
第i檔的總缺陷數占軟體總缺陷數的百分比為 ri=di/d,第i檔缺陷的總故障率為λi,軟
件總故障率為。
@@16103001.GIF;公式2@@
第i檔缺陷的總故障率占軟體總故障率的百分 比為fi=λi/λ,如表1所示。
@@16103002.GIF;表1 Adams統計表@@
從統計表中可以得到一些重要概念:軟體缺陷的故障率可以相差3～4個數量級;故障率高
的大缺陷數少,故障率低的小缺陷數多;極少數故障率高的大缺陷(例如佔總缺陷數39%的1、
2、3檔缺陷)佔了總故障率的絕大部分(上述三檔佔總故障率的72.5%)。
因此,軟體的缺陷數與軟體的故障率無直接關係。
如果對使用者交付一個軟體,並說還有10個缺陷,那麼使用者是不放心的。因為如果還有十個
第一檔的缺陷,則可能一、二個月就會出故障。反之,如果是第8檔的平均5000年出一次故障
的缺陷,則有100個也可安心接受。
因此對使用者來說,他最關心的是:"不論你交付的軟體有多少個缺陷,它們總的MTBF或λ是
多少?"
三、軟體各種缺陷故障率的Pareto圖
設一個軟體的若干缺陷按其故障率的大小從大到小依次排列為:λ1≥λ2≥λ3≥……
從理論上來說,可以把諸λ排成Pareto圖,其示意1所示。
@@16103003.GIF;圖1 軟體缺陷故障率理論上的Pareto圖@@
對硬體來說,這種Pareto圖不僅理論上存在,而且還可以通過可靠性預計得到。每個電子
裝置群組成件的故障率可以通過GJB299-A(國產)及MIL-STD-217F(進口)查算出來。但對軟體來
說,缺陷的故障率是無從估算的。
如電視機有一個故障率的Pareto圖,其中顯像管的高頻頭故障率最高,但除了幾個故障率
高的組成部分外,其它如整合電路、電阻、電容元件等的故障率都很低。而別的電子產品卻
是另一種規律。不同的電子產品硬體的Pareto圖可能很不相似。硬體的Pareto圖沒有統一的
規律。
對硬體來說,客觀存在且可以預計的Pareto圖並不存在可以外推的規律。例如電視機有
五個較大故障率的故障,但從第六個起,故障率就大幅度下降。因此得到連續五個大故障並不
能外推出第六個故障是較大故障!
比起硬體設計來,可靠性設計技術遠遠不成熟的軟體,有什麼理由說有λi=Φβi-1等規
律存在呢?
@@16103004.GIF;公式3@@
客觀上軟體存在一個Pareto圖,但一個軟體一個規律,適合於這個軟體的規律不見得適合
於另一軟體。另外,適合於前幾個缺陷故障率的規律不見得能外推到以後的故障。
如果說軟體故障率存在一定規律,那就是:在t=0時,軟體的故障率是
@@16103005.GIF;公式4@@
到t=t1時,出現第一個故障,排除相應的缺陷後,故障率降為:
@@16103006.GIF;公式5@@
@@16103007.GIF;圖2 λ(t)-t圖@@
因此,λ(t)是一條階梯形下降的折線,2所示,這是一個普遍規律。
有的作者提出,在排除軟體缺陷的過程中,可能出現新的缺陷,甚至是故障率很大的缺陷
,於是λ(t)還可能反彈。因此假設了有一個反彈機率及反彈率的機率分布,致使λ(t)模型極
其複雜。然而,從工程實際看,在嚴格的組態管理下,引入新缺陷可以立即被判斷出來,不會出
現一個反彈。
四、故障率λ(t)的測試及估計問題
設軟體的故障率為λ,相應的平均壽命為θ,並設軟體於t=0時投入運行,到t=T時出現故
障,則T是指數分布的隨變數,它的累積分布函數為:
@@16103008.GIF;公式5@@
如果軟體投入運行,一出現故障就排除相應的缺陷再投入運行,則再投入運行時的故障率
已經下降。亦即相應於故障率λ,只有一個測試資料T。根據上述統計規律,可得:
T有80%的機率落在(0.105θ, 2.303θ)之間;
T有90%的機率落在(0.0513θ, 2.996θ)之間;
T有95%的機率落在(0.0253θ,3.689θ)之間。
由此可以看出,T值波動二、三十倍還算正常。這是因為T的標準差σ等於均值θ,亦即
波動遠遠超過真值。
如果軟體在運行過程中,一出故障就排除缺陷再投入運行,則λ(t)變化為:
λ(0)→λ(t1)→λ(t2)→……
但對每一個λ(ti)只有一個測試資料,而測試資料的誤差又有較大的波動,因此企圖從測
試資料估計出較精確的λ(t)規律是不可能的。
從上述統計分析看,對每一個λ(ti)而言,其測試值ti+1-ti是一個很粗糙的量值,有些作
者企圖用模糊數學來描述。即使要用模糊數學描述,其隸屬函數也不是一般的三角圖形函數
,更不是常態分佈函數,而是散布極寬的函數,用模糊數學處理是得不出多少有實用意義的成
果的。
五、軟體運行剖面及可靠性資料
軟體有種種可能的輸入,各種可能輸入的出現機率並不相同。因此軟體的可能輸入值要
與出現機率聯絡起來。例如一個生產控制軟體,正常情況下的出現機率較大,異常情況下的出
現機率一般較小。軟體的一組可能輸入構成輸入空間的一個點P。這些P點的全體為輸入空間
S。在S上,定義一個機率密度函數f(p)。
設G是S的一個子點集,則輸入焦點P落在子點集G內的機率為:
P = ∫g f(p)dp
{S,f(p)}叫軟體的"運行剖面"
軟體使用方必須明確軟體的運行剖面,這裡既包括軟體的正常情況下的輸入,也包括
可能的非正常輸入。軟體的需求包括在正常輸入下應該得到正常輸出,也包括在可能的非正
常輸入下應該有正確反應。例如空間衛星上用的電腦軟體,它的正常輸入是根據各種先前
的衛星狀態資訊、當前的感應器測得的資料、地面或宇航員傳來的指令和資訊,來控制衛星
。
但是由於宇航空間的重粒子轟擊,可能使電腦的儲存空間中的數位產生0與1的突變。這
是可能的不正常輸入,對此軟體需要作出既定的正確響應。
軟體的一個缺陷Di隻影響S中的一個點集Gi,當輸入焦點P∈Gi,則缺陷Di使軟體出故障,其
機率為
@@16103009.GIF;公式6@@
相應故障率為λi。設諸λi相應的故障域Gi是相互獨立的,則
@@16103010.GIF;公式7@@
λ(t)=Σλii(t)。
必須注意,軟體的可靠性是規定條件下的可靠性,即實際運行條件下完成任務的可能性。
如果不是實際運行條件,那就不反映真正的可靠性。
舉一個極端的例子,如果用一個運行正確的例子,反覆輸入幾千次,那永遠是正確的,但這
並不反映軟體有高可靠性。正因為如此,不少軟體在評鑑時,只用不多的幾個測試案例示範一
下就算通過,這說明不了多少可靠性。就算通過了一百個測試案例,也不能說明其可靠性是高
的。"只有在按運行剖面隨機輸入條件下,軟體的故障率才能正確反映軟體的可靠性"。
因此軟體的可靠性只可能在兩種情況下取得:軟體在實際運行下統計得到的故障率;軟體
在類比實際運行條件下的隨機輸入測試下統計得到的故障率。
由於不應把未經充分測試的軟體交付現場運行,因此軟體在交付前必須在類比實際運行
條件下用大量的隨機輸入焦點作測試案例,來考核軟體,統計其故障率,並以此作為可靠性評估
的基本資料。
按照軟體工程進行的軟體白盒子等測試的統計故障率也不能作為可靠性評估的依據。白
盒子測試等是提高軟體可靠性的重要手段之一。但白盒子測試不是按運行剖面隨機測試,從
而統計資料不反映可靠性。例如白盒子測試的語句覆蓋率達100%,都正確,但並不能說明軟體
的可靠性就很高了。有的較嚴格的白盒子測試要求分支覆蓋率為85～95%,程式路徑覆蓋率為
60～80%。即使這些控制的分支、程式路徑都正確,也不能保證已達到了很高的可靠性。
因為畢竟只覆蓋了一部份,也許在未覆蓋的部分仍存在著故障率很高的缺陷。軟體工程
中的種種測試是提高軟體可靠性所必需的,但其統計資料並不表示軟體的可靠性。
為很多軟體模型研究者引用的NTDS軟體資料是一個典型,它在開發階段有26個資料,在測
試階段有5個資料……。不少作者把這些資料作為可靠性評定用的資料。實際上,這是不正確
的。
六、軟體的可靠性驗證實驗
在按運行剖面隨機輸入的條件下,軟體的可靠性為指數分布。這樣軟體的可靠性驗證試
驗可以引用GJB899(或MIL-STD-781D)《可靠性評鑑與驗收實驗》。
軟體MTBF的目標值(Goal)是軟體期望達到的使用指標。
軟體MTBF的門限值(Threshold)是軟體必須達到的使用指標。
軟體MTBF的規定值(Specified Value)是軟體研製任務書或合約中期望達到的合約指標
。它是承製方進行軟體可靠性設計的依據。規定值依據目標值來確定。
軟體MTBF的最低可接受值(Minimum acceptable value)是軟體研製任務書或合約中規定
的必須達到的合約指標,它是進行驗證的依據。規定值依據目標值來確定。
MTBF的檢驗下限θ1是最低可接受的MTBF值。MTBF的檢驗上限θ0是參考規定值確定的。
鑒別比d=θ0/θ1。一般選d=1.5、2.0、3.0。
生產方風險α是MTBF的真值等於θ0時產品被判為不通過的機率,使用方風險β是MTBF的
真值等於θ1時,產品被判為通過的機率。一般選α、β的值為10%、20%,特殊情況下可取高
風險率30%。
實驗時間是θ1的倍數。
Ac為判決為通過的故障數,Re為判決為不通過的故障數。
根據鑒別比及α、β值,GJB899提供了如表2的定時實驗方案。
@@16103011.GIF;表2 GJB899提供的定時實驗方案@@
例如方案17的d=3.0,即θn=3θ1、α=20%、β=20%,實驗時間為4.3θ1,如果實驗期內出
現的故障數r≤2,則通過;r≥3,則不通過。
推薦的方案是19到21。當然也可選用適當的GJB899的序貫實驗方案。
即使軟體通過了驗證實驗,在實驗中暴露的故障,也必須找出引起故障的缺陷,加以排除
,進行迴歸測試,確認未引入新的缺陷後再交付使用。
採取定時實驗的原因是便於制訂實驗計劃。
實驗時間是任意若干台電腦軟體同時進行可靠性實驗的累計實驗時間。在上例中,如
θ1=1000h,則實驗時間為4300h,如取三台電腦同時隨機驗證,則花費1433h即可結束。
驗證實驗期間不排除缺陷的原因,是因為排除缺陷需要一整套嚴格的管理及技術過程,更
改後還需要進行迴歸測試,排除缺陷的周期一般都較長。
驗證實驗的通過說明已通過軟體MTBF的最低可接受值,並不說明已通過軟體MTBF的規定
值。
在接收後,還應繼續軟體的SRGT,並彙集交付使用後暴露的故障,繼續排除缺陷,使軟體可
靠性繼續增長,達到規定值。