馬振宇,吳 緯,張 威,劉福勝,韓 坤
(1.裝甲兵工程學院 技術保障工程系, 北京 100072; 2.裝甲兵工程學院 信息工程系, 北京 100072;3.北京特種車輛研究所, 北京 100071)
當訂購方驗收生產方的軟件產品時,有時會出現經濟成本、人力成本、時間成本過高等情況,這就導致難以順利開展軟件可靠性驗證測試[1]的相關工作。在后續的驗收工作中,基于貝葉斯方法能夠有效地利用先驗信息,讓驗證測試時長明顯的縮短,進而保證了驗收工作的順利完成。因此這種驗證測試方法被使用的越來越廣泛。
目前專家學者們針對貝葉斯的軟件可靠性驗證測試方法進行了大量研究工作。吳玉美等使用貝葉斯方法驗證安全關鍵型軟件的可靠性[2,3];李秋英等同樣使用貝葉斯方法對高可靠性軟件進行驗證測試[4];劉解放等提出了基于多階段先驗信息的加權貝葉斯方法[5];張文杰等通過構造混合驗前分布,給出了貝葉斯混合驗前分布下的可靠性驗證測試方案[6];王學成等提出了基于減函數的先驗分布構造法進行測試驗證的方案[7];劉廣等做了進一步深入研究,提出了基于減函數的多層貝葉斯軟件可靠性驗證測試方法[8]。
這些方法都是基于比較理想、簡單的條件進行的。例如假設先驗分布函數中的待估參數量簡化為一個;多層貝葉斯的先驗分布函數選用均勻分布;先驗動態整合都是對無失效驗證測試考慮的,并沒有考慮失效數不為零的情況。前人的研究結果還存在片面性,不適用于普遍的驗證測試中。因此,本文在前人的研究基礎上做出了進一步研究。首先構造帶有單調減函數思想的待估雙參數的先驗分布函數,進而提出基于單調減函數的貝葉斯軟件可靠性驗證測試方案,與此同時給出待估參數的具體估計的方法。然后,針對實際測試過程中出現不同失效次數的情況,提出兩種先驗動態整合法。最后通過實驗分析,論證了驗證方案可以降低測試所需要的時間,以及先驗動態整合法的可行性。
在可靠性驗證測試[9,10]過程里,選取失效率λ作為可靠性指標,在以λ為條件的情況下,測試過程里出現的失效次數的條件分布密度函數為f(r|λ)。同時h(λ)為λ的先驗分布密度函數。那么失效次數和失效率的聯合分布密度函數就為
g(r,λ)=f(r|λ)h(λ)
(1)
通過式(1),進而得到關于失效次數r的邊緣分布,即

(2)
聯立式(1)和式(2),進一步推導出失效率的后驗分布密度函數,即
(3)
根據實際情況,設定可靠性驗證測試方案中的可靠性指標(λ0,r,c),其中失效的次數為r,失效率為λ0,置信度為c。求出滿足下式t的最小值,即可靠性驗證測試方案所需要的總的最短測試時長

(4)
為了構造帶有單調減函數的先驗分布函數[11],首先應對函數的核進行闡述說明。假設f(x)為隨機變量的分布密度函數,若f(x)=A′g(x),A′是一個與隨機變量毫無關系的多項式,g(x)是一個包含了全部隨機變量的多項式,那么g(x)就是f(x)函數的核,記作
f(x)∝g(x)
(5)
根據減函數的思想,再選取伽馬分布的隨機變量(失效率λ),構造出單調減函數的分布密度函數的核,即
h(λ)∝λa-1e-bλ
(6)
式中:a、b均為待估參數,00。
由上述函數的核的概念,可以得到λ先驗分布的密度函數,即
h(λ)=A′λa-1e-bλ
(7)
根據第一節的思想,貝葉斯軟件可靠性驗證測試方案選取的是滿足伽馬分布的失效率的先驗分布密度函數,為了便于計算,對h(λ)做出稍許改動,令A′=Aba-1,則基于減函數思想構造的先驗分布密度函數h(λ)被改為
h(λ)=A·(bλ)a-1e-bλ
(8)
再根據分布密度函數的性質,可以得到:

(9)
那么可以得到A=b/Γ(a),進而推導出λ先驗分布的密度函數,即
(10)

假設軟件在時間區間(0,t]中,出現的失效次數X=r的概率是λ的條件概率,并且失效次數服從λt的Poisson分布,即
(11)
聯立式(10)和式(11),得到X,λ的聯合分布函數,即

(12)
由上式,可以推導出X的邊緣分布函數,即
(13)
聯立式(12)和式(13),可以得到λ的后驗分布密度函數,即

(14)
構造的先驗分布密度函數h(λ)中待估參數a,b不再是一個定值,它是根據軟件可靠性測試階段得到的相關信息估計而得[12]。其值可以通過軟件可靠性測試持續的總時間t,以及在總時間里失效次數的期望和方差來確定參數的估計值。
假設軟件可靠性測試的總時間t足夠長,在把(0,t]分成m個時間間隔序列T1,T2,…,Tm。那么每一個時間間隔Ti內發生的失效次數為ki=t/Ti(i=1,2,…,m)。
p(r)對應的一階矩

(15)
p(r2)對應的二階矩

(16)
將E(r)、E(r2)記作w1、w2,即超參數a,b的估計值為
(17)
根據實際情況,設定軟件可靠性驗證測試方案中的可靠性指標(λ0,r,c),其中失效的次數為r,失效率為λ0,置信度為c。求出滿足式(18)的最小t值,也就是軟件可靠性驗證測試方案所需要的總的測試時長t

(18)
根據2.1節構造單調減函數的先驗分布密度函數的思想,構造出失效率的先驗分布密度函數。根據式(18),如果軟件在規定的可靠性驗證測試時間以內,實際出現總失效的次數不大于對應軟件可靠性驗證測試方案中失效數的最大值,那么軟件通過可靠性驗證測試的檢測。否則軟件可靠性并未達標,需要接著進行下一次軟件可靠性驗證測試。很顯然,前一次測試失敗的經歷一定會給下一次可靠性驗證測試提供歷史信息,所以我們首先需要把上一次測試失敗的結果信息融合到下一次的軟件可靠性驗證測試的先驗信息當中去,然后再進行下一次的可靠性驗證測試。
通常來說,對于安全關鍵型軟件、高可靠性軟件、航天類軟件等類型軟件,在進行軟件可靠性驗證測試時,應該發現一個導致失效出現的缺陷,就應該立即進行排錯處理,有利于提高軟件本身的可靠性。同時對于高可靠性的軟件來說,驗證測試條件比較嚴苛,一般選擇無失效測試方案。針對以上兩點,提出排錯條件下的先驗動態整合法。
(19)
那么可以依次類推,當出現第i-1次可靠性驗證測試未通過時,那么第i次驗證測試通過時對應的測試時長ti就應滿足下式中的t
(20)
通過上述分析,下面給出在排錯條件下的先驗動態整合法,具體過程如下:
(1)依據制定的基于單調減函數的貝葉斯軟件可靠性驗證測試方案,以及確定的方案的可靠性指標(λ0,r,c),利用式(18),計算出測試所要的時長t。
(2)通過對軟件進行實際的驗證測試,測試時長為t。如果ri≤r,則表明驗證通過,接收該軟件,測試結束。否則繼續進行(3)。
(3)設置測試人員所能接受的最長測試時長tmax,以及最大迭代次數I,以及初始迭代次數i=1。
類比于排錯先驗動態整合法,提出不考慮無失效的可靠性驗證測試,也就是說本方法針對的是在實際測試過程中至少出現一次失效的軟件,即r≠0。下面介紹在不排錯條件下的先驗動態整合法。
(1)依據制定的基于單調減函數的貝葉斯軟件可靠性驗證測試方案,以及確定的方案的可靠性指標(λ0,r,c),利用式(18),計算出測試所要的時長t。
(2)通過對軟件進行實際的驗證測試,測試時長為t。如果ri≤r,則表明驗證通過,接收該軟件,測試結束。否則繼續進行(3)。
(3)設置測試人員所能接受的最長測試時長tmax,以及最大迭代次數I,以及初始迭代次數i=1。

(5)接著再進行時間為t*-t的可靠性驗證測試。如果在該時間段內,發生失效的次數不大于r*-ri,則表明驗證通過,接收該軟件,測試結束。否則繼續進行(6)。
(6)假設在t*-t時長里出現了k次失效,那么令ri+1=ri+k,t=t*,同時i=i+1,接著重復執行(4)。
根據上述兩種不同情況下的先驗動態整合方法,通過兩種方法的結合,得出融合兩種不同情況下的先驗動態整合法。其流程如圖1所示,其步驟大致如下:
(1)根據基于單調減函數的貝葉斯軟件可靠性驗證測試方案,結合式(18),算出測試時長。在測試過程中,如果r實≤r,那么軟件通過可靠性驗證測試的檢測。否則進行(2)。
(2)設置測試人員所能接受的最長測試時長tmax,以及最大迭代次數I,以及初始迭代次數i=1。
(3)根據測試的實際需求,確定可靠性驗證測試是否為無失效驗證測試。如果是無失效的驗證測試,那么就選用排錯條件下的先驗動態整合法,具體過程參照3.1節。否則進行(4)。
(4)在失效數不為零的情況下,可以選擇兩種方法的任意一種方法。如果選擇不排錯條件下的先驗動態整合法,那么具體步驟就參考3.2節。否則參照3.1節。

圖1 先驗動態整合方法的具體流程
本單位主要從提高軟件可靠性的角度對裝甲車輛的可靠性進行研究。由于時控軟件的高可靠性,不易出現故障,才能保證硬件裝備的正常使用,進而保障部隊的日常戰備需求。嵌入裝備的軟件都由本單位同一團隊研發,研發的軟件具有相同的性質,因而驗證測試結果也大致相同。對于時控軟件的可靠性要求在各類研發的嵌入式軟件中最為嚴格。綜上所述,本文選取時控軟件作為實驗分析的對象。實驗先驗數據選用來自特種車輛軟件測評中心對軟件進行可靠性增長過程中,得到的最后10組失效間隔數據作為歷史信息。選取t=100 000分鐘,從而得到該階段失效次數的經驗樣本值t/Ti,構成先驗信息數據,見表1。

表1 先驗信息數據
通過先驗信息數據,再結合式(17)可以計算得到失效率的先驗分布參數的估計值,a=1,b=1008,其值符合基于單調減函數的先驗分布函數的參數取值范圍,那么h(λ)=1008e-1008λ。在驗證測試方案,令置信度c為0.99,失效概率λ0為0.001,失效次數r從0到10。通過式(18)求得,在無先驗信息條件下以及帶有單調減函數思想的先驗信息條件下的軟件可靠性驗證測試所需要的總時長,結果見表2。

表2 基于不同驗前信息的驗證測試總時長
根據兩種先驗動態整合的方法,分別計算在失效數從0到3條件下,在可靠性驗證測試過程當中,實際出現失效的次數與驗證測試總時長之間的關系,具體結果見表3~表6。

表3 r=0時,測試總時長結果

表4 r=1時,測試總時長對比

表5 r=2時,測試總時長對比

表6 r=3時,測試總時長對比
根據表2,可以得到以下2個相關結論:
(1)首先隨著失效次數的不斷增加,無論是有無先驗信息,測試時長肯定會增加。其次可以發現,隨著每次失效次數的遞增,測試時長的增幅卻在降低。例如在無先驗信息的測試方案中,最失效次數從0增加到1時,測試時長的增幅為44.2%。而失效次數從9增加到10時,測試時長的增幅為5.3%;在基于單調減函數的貝葉斯測試方案中,失效次數從0增加到1時,測試時長的增幅為56.6%。而失效次數從9增加到10時,測試時長的增幅為7.7%。
(2)明顯可以看出,在基于單調減函數的貝葉斯驗證測試方案中,測試時長明顯小于無先驗信息測試方案的測試時長。當失效數為0時,本文提出的測試方案的測試時長比起無先驗信息的測試時長縮短了28.1%,當失效數為10時,本文提出的測試方案的測試時長比起無先驗信息的測試時長縮短了5.3%。
隨著失效次數的增加,兩種方案所需要的測試時長越來越接近,這就說明對軟件進行可靠性驗證測試時,如果軟件本身可靠性不高,就會很容易出現失效,當在驗證測試方案中,符合通過接收軟件條件所對應的失效次數過大時,無論使用何種測試方案,都會給測試員帶來巨大的工作量以及耗費大量的時間,甚至無法對該軟件完成可靠性驗證測試工作。
根據表3至表6,可以得到以下3個相關結論:
(1)針對測試方案中不同的失效次數,當驗證測試過程中實際出現的累積失效次數在個位數時,無排錯的先驗動態整合法的測試時長不大于排錯的先驗動態整合法的測試時間。例如,當r=1,實際累積失效次數為2次時,無排錯的先驗動態整合法的測試時長比排錯的先驗動態整合法的測試時間縮短了1639分鐘。而當r=1,實際累積失效次數為5次時,無排錯的先驗動態整合法的測試時長與排錯的先驗動態整合法的測試時間一樣長。
當驗證測試過程中實際出現的累積失效次數偏大時,排錯的先驗動態整合法的測試時間比無排錯的先驗動態整合法的測試時長要短,隨著實際累積失效次數的不斷增加,排錯的先驗動態整合法的測試時間會明顯的小于無排錯的先驗動態整合法的測試時長。例如,當r=3,實際累積失效次數為7次時,排錯的先驗動態整合法的測試時長比無排錯的先驗動態整合法的測試時間縮短了2784分鐘。這就說明,當軟件累積失效次數不斷增加時,如果對缺陷不進行改正,那么隨著測試的進行,無排錯的先驗動態整合法就會浪費大量測試時間,甚至會出現測試時長超過測試人員的可控范圍,根本無法完成對軟件的可靠性驗證測試。所以為了避免這類事情的發生,一般在測試過程中都會對出現的失效實時進行修正,然后再進行下一次的軟件可靠性驗證測試。

(3)基于不排錯條件的先驗動態整合法時,因為所有驗證測試結果類似,所以本文選取測試方案中失效次數為2的情況進行分析。當軟件執行首次的可靠性驗證測試時,測試時長為7392分鐘,如果軟件在此期間出現的失效次數不大于2,那么軟件可靠性指標達標,接收該軟件。如果在測試結束時,出現了r1=4次失效(r1>r),那么說明驗收失敗,可靠性并未達標。此時不需進行排錯處理,接著進行第二次驗證測試。第二次驗證測試時長為t=t*-t=10 590-7932-3198分鐘。同樣,如果在首測過程中,出現r1=5次失效,那么此時可靠性指標并未達標。那么第二次測試時長就為t=t*-t=13 555-7392=6163分鐘。同樣可以得到首次驗證測試結束后,實際出現的累計失效次數多少會對第二次驗證測試的持續時長有著直接影響。如果再接著進行第二次驗證測試時,又出現r2>r的情況,那么說明驗收依舊失敗,可靠性并未達標。則需要對該軟件進行第三次的可靠性驗證測試,第三次測試時長就為該次測試時長減去上一次測試時長。所以在進行下一次可靠性驗證測試的過程中,需要對前面的全部驗證測試結果(累積失效次數)進行整合分析。對于后面測試結果的分析依次類推。
本文首先介紹了基于貝葉斯方案的可靠性驗證測試方案。然后提出帶有單調減函數思想的先驗分布函數,確立了基于單調減函數的先驗分布以及對應的后驗分布。接著給出該先驗分布中參數的估計方法。以此為基礎,提出了基于單調減函數的貝葉斯軟件可靠性驗證測試方案。最后提出了兩種先驗動態整合法。其中一種為排錯的先驗動態整合法,其主要整合的測試時長的先驗信息;另一是不排錯的先驗動態整合法,主要是整合失效次數的先驗信息。
通過案例分析,該方案比起無先驗信息的測試方案,在保證驗證結果置信度不變的基礎之上,能夠顯著地降低了可靠性驗證測試所需要的測試時長。同時對于先驗動態的整合分析,使得在軟件可靠性驗證測試過程中,充分考慮了被測軟件的實時動態先驗信息,有效地降低了可靠性驗證測試的時長。
當然,基于單調減函數的貝葉斯軟件可靠性驗證測試方案仍需要投入到今后大量的驗證測試實驗中去檢驗,以此來不斷完善該方法,以便后續更高效的應用到軟件可靠性驗證測試中。