星載軟件可靠性測試實踐

石 柱，鄭 重

(中國航天科技集團公司軟件評測中心，北京100048)

0 引言

為驗證星載軟件的可靠性，在軟件驗收之前，應進行軟件可靠性測試，以評估星載軟件的可靠性是否能滿足任務書規定的可靠性要求。軟件可靠性測試一般在軟件產品驗收階段進行，在軟件需求方參與的情況下實施，其目的是在給定的統計置信度下驗證軟件產品是否達到了規定的可靠性指標要求。在測試過程中，軟件版本是凍結的，即不會試圖通過定位錯誤后再排出錯誤來解決所發現的失效。通過軟件可靠性測試，得到一個二選一的結論，即軟件是否已經達到了規定的可靠性指標［1］。目前，特別在航天等對可靠性要求較高得領域，還缺乏開展可靠性測試和評估的實踐和經驗，亟待開展軟件可靠性測試方法的研究和實踐工作。本文在對軟件可靠性測試一般方法和過程研究的基礎上，針對某星載嵌入式軟件的特點，根據用戶需求，給出了開展軟件可靠性測試的過程、途徑和方法，并給出了對該軟件的可靠性評估結果，從而驗證了該過程和方法的可行性。

1 軟件可靠性測試方案

1.1 測試對象

本次測試對象是某星載嵌入式軟件，該軟件產品在設計上存在一些亟待解決的可靠性問題，例如，軟件不定期復位 (復位間隔幾周或幾個月)、計算精度下降等，這些問題嚴重影響了空間飛行器任務的順利執行。在對該型號軟件在軌失效情況進行可靠性評估后發現:該軟件不能滿足衛星總體對該軟件提出的可靠性要求 (平均無故障時間MTBF大于6個月，置信度大于0.6)，而且隨著該軟件關鍵等級的提高，以及新的應用需求，對該產品的可靠性提出了更高的要求。

在經過一系列可靠性分析和測試后，研制單位對該軟件進行了修改，即本次可靠性測試的軟件版本即為修改后的軟件版本。本次測試目的即是驗證修改后的軟件是否能滿足規定的可靠性指標要求。

1.2 測試過程

軟件可靠性測試是指為了保證和驗證軟件的可靠性要求而對軟件進行的測試，與一般軟件測試不同，軟件可靠性測試的主要目的不是發現所有的軟件錯誤和缺陷，而是通過獲取軟件失效數據進行分析，評估軟件當前的可靠性水平，預測未來可能達到的水平，從而驗證軟件可靠性的定量要求是否得到滿足［2］。

根據以上特點，參考以往經驗，此次軟件可靠性測試工作過程如圖1所示，主要包括7個工作環節。

圖1 軟件可靠性測試過程

(1)確定驗收準則

根據軟件的特點，以及用戶的要求制定出適合的驗收準則，以便能獲得可用來判別驗收通過與否所需的數據;

(2)定義失效

軟件失效的定義是面向用戶的，即用戶不期望發生的那些故障才可算作失效，因此，在進行測試之前，首先要明確定義測試中軟件發生哪些故障可以算作失效，以及失效的嚴重程度，便于數據的收集。

(3)構造使用剖面

所謂使用剖面是指:軟件各種使用情況及其發生概率的集合。在使用信息分析的基礎上，按照被測軟件的實際使用規律，構造軟件的使用剖面。

(4)生成測試用例

基于上述構造的軟件使用剖面，通過程序生成測試數據及自動測試驅動工程文件 (含多個腳本文件)，該工程文件相當于測試用例集，以驅動高動態仿真器對該軟件進行測試。

(5)準備測試環境

軟件可靠性測試對測試環境有苛刻的要求，要求測試環境與被測軟件的真實運行環境盡可能一致，并在測試期間不對軟件進行任何修改，以保證軟件失效率在此期間看成時恒定的。本次測試的環境由測試方和委托方合作開發專用的可靠性測試環境，包括測試設備、相關軟件及環境。

(6)執行測試并收集分析測試數據

在上述工作準備就緒的情況下，執行可靠性測試，并通過可靠性測試平臺中的監測功能收集測試數據及發生的失效數據，測試人員分析發生的失效事件，并將有效的失效記錄下來。

(7)可靠性評價

根據測試期間發生的失效次數和時間，利用可靠性模型，評估軟件的可靠性指標是否達到預期的可靠性指標要求，得出拒絕或接受被測軟件的結論。

1.3 驗收準則的確定

本次可靠性測試采用無失效考核方案，即根據該軟件的可靠性定量指標——平均無失效運行前時間 (MTBF)，確定一個預定的可靠性測試連續無失效的累積時間 (設為T')，然后進行可靠性測試，若實際的累積連續無失效測試時間 (設為T)超過T'，即T＜T'，在給定的置信水平γ下認為達到了可靠性要求;如未達到要求，即T＜T'，則軟件需要修改，那么在修改后仍需重新按無失效考核方案進行測試。

在開展測試之前，應用兩種可靠性模型擬合 (指數分布模型、正態分布模型)對該軟件在軌失效數據進行擬合，通過擬合結果發現，其失效間隔并不是一個穩定、均勻的分布，所以造成方差過大，因此，正態分布模型擬合該軟件失效率是不適合的，盡管指數模型存在誤差，但是相比正態分布模型的結果，指數模型的誤差是可以接受的，因此，該軟件的失效率服從指數分布，在這種情況下，無失效考核時間與MTBF的時間比計算公式為

由置信度γ=0.6可以計算得到:無失效考核時間為MTBF的0.91629倍，由MTBF=0.5年得到，如果投入一臺被測件進行測試，其無失效執行測試時間為:0.5年×0.91629=0.458145年 (即168天)，即本次可靠性測試最少執行的時間是168天，在168天內如果沒有發生一次失效，則可認為該軟件達到了要求的可靠性水平［3］。

2 軟件可靠性測試方法

參照GJB899《可靠性鑒定與驗收試驗》和用戶需求，本次軟件可靠性測試的關鍵步驟擬采取以下方法和途徑:

2.1 定義失效

進行軟件可靠性測試，首先需要明確定義軟件失效，經與研制方的溝通，此次測試的失效定義為［4］:

(1)軟件復位:發生主動復位或被動復位;

(2)無定位數據:連續半小時不能提供有效導航定位數據，軟件也未復位。

2.2 構建測試環境

在測試過程中，投入一臺星載嵌入式設備作為被測件，該設備接收高動態仿真器信號 (以下稱動態機)，運行時間為168天;同時，又投入兩臺設備作為比對分析，其中包括一臺動態機，該設備與被測件運行相同的測試用例，另一臺接收靜態天線信號 (以下稱靜態機)，兩臺設備運行時間均為168天。測試中引入比對設備的目的是，當被測設備發生故障時，能正確定位故障原因是否是設備本身問題還是仿真器信號問題，且CPU時間與日歷時間一致。

為確保盡可能在真實環境進行可靠性測試，全面考核該軟件的所有對外接口及使用剖面，應保持被測軟件在整機環境中運行，即應保持該軟件與其他軟硬兼得正常數據交換和信號交換。通過高動態信號仿真器模擬接近真實運行狀態的信號，并可通過改變電文源碼、偽碼類型、傳播誤差等因素考核該軟件在各種信號輸入條件下的故障發生率。

星載嵌入式軟件可靠性試驗平臺包括運行平臺和監測平臺兩個部分，其中運行平臺設備主要包括受試設備 (包括監測數據采集模塊);監測平臺設備主要包括高動態仿真器、工控機、監測設備及監測軟件等。該試驗平臺的設備連接圖如圖2所示。該環境在運行正確和穩定的前提下，提供如下功能:

(1)記錄并輸出測試過程中該軟件發生復位的次數、時間和相關場景;

(2)記錄并輸出測試過程中發生連續半小時不能提供定位數據的次數、時間和相關場景。

圖2 可靠性測試平臺設備連接

2.3 構造使用剖面

軟件可靠性測試的過程必須以某種方式近似地反映軟件的真實運行情況，測試的基本過程要求首先確定一個以概率方式定量描述軟件系統使用過程的統計模型，然后由模型產生測試用例，以求能合理地反映軟件使用的統計規律。本次測試通過構造軟件的使用環境和使用剖面來刻畫軟件的使用情況，其中，使用剖面不僅包括對軟件操作和使用概率的描述，還包括可能的操作約束和序列信息。下面給出使用環境和使用剖面的構造過程［5-8］。

(1)使用環境的構造

使用環境的構建包括:導航星星座模型、大氣模型、載體模型、天線模型，其中:

1)導航星星座模型主要是對導航星星歷和歷書的變化的模擬;

2)地球周圍的大氣層會影響信號的傳輸，引起測量誤差，因此應該對這些誤差進行修正。對于該衛星軟件而言，因其工作在對流層之外，所以電離層效應是其中最重要的定位誤差之一;

3)根據衛星的實際運行情況并通過以下設置來建立載體模型，包括:載體特性及動力學極限，載體軌道、載體指向;

4)根據衛星的實際運行情況并通過以下設置建立接收天線模型，包括:天線信號類型及通道分配、天線偏移量、接收天線模式;

(2)使用剖面的構造

在對軟件使用信息分析的基礎上，按照軟件的實際使用規律，構造該軟件的使用剖面，本次測試構造以下幾個該軟件的使用剖面，包括電文、信號功率、偽距隨機噪聲和載體動作，其中以電文剖面為例:

由于電文參數在實際運行中絕大多數情況下都較為穩定，但在某些情況下會出現異常，因此，電文剖面可根據電文參數正常和異常對電文進行劃分。

1)根據與開發方溝通，電文正常的概率為0.99，異常的概率為0.01，按照導航電文不健康類型、電文精度和其他極端情況，又可將電文的異常類型分為9類;

2)每次發生電文異常的星數是隨機的，即可能是一顆星，也可能是多顆星，對于單一導航星和所有導航星來說，電文的某一或全部的參數錯誤時隨機和均等的。

電文參數異常可以根據以上導航星數和異常類型的不同組合和概率來構造剖面，最終共生成289個剖面。

在測試用例設計中，電文正常范圍值由高動態仿真器來保證，對于異常值需要構造測試用例。根據導航星電文異常發生的概率和運行時間計算，需從288個異常剖面中隨機抽取20個電文異常操作，最后將20組異常數據隨機分配到168天的時間軸上。由于該軟件的一個軌道周期大約是2個小時，因此，設定每個異常持續2個小時，一臺仿真器需要構造10個不同的用例，即從288個電文異常剖面中抽取10個用例。

基于上述構造的該軟件使用剖面，每個剖面的動作序列都以仿真軟件可識別的工程腳本文件的形式加載到每個場景中，該工程文件可以驅動高動態仿真器對該軟件進行測試。

2.4 執行測試

按照方案的要求，本次測試共設計測試用例11個，其中動態軌道10個用例，靜態軌道1個用例。動態軌道用例在時間上是連續的，且順次執行，共運行168天;每個軌道的輸入域均按照前面構造的4個剖面中描述的輸入空間及概率進行抽取。所有動態測試用例運行同一軌道，該軌道是以某衛星軌道為基礎而設計的。

本次測試的終止條件是:在測試中，累積測試時間達到驗證測試計劃的時間，完成所有測試用例的執行，并且測試平臺完整記錄測試過程中的監測數據，表明被測軟件通過驗證測試，則終止可靠性驗證測試，若驗證測試過程中發生失效，并確認是被測軟件導致的，表明被測軟件未通過驗證測試，則終止測試［9，10］。

2.5 數據采集

在測試運行過程中，軟件未發生由于本身設計原因而導致的復位，即該軟件未發生定義的失效。根據可靠性測試理論，由于兩動態機是運行相同的測試用例，因此被測件的考核時間以其中最長的計算，而且以下運行或操作過程所耗費的時間也不能算作考核時間:

(1)星載設備換軌道過程中無高動態信號的時間，共計3小時;

(2)人為或外界意外因素導致被測件復位到重新接收高動態信號之間所耗費的時間，共計7小時;

通過以上分析和計算，最終被測件的無失效考核時間為168天。

3 測試結果分析

根據可靠性評估規程，以及無失效考核時間與MTBF的時間比計算公式

由置信度γ=0.6可以計算得到:MTBF=180(天)

因此，按照目前運行結果，MTBF為180天，達到了可靠性指標要求 (180天)。

以上過程、方法和結果適用于該軟件在該使用剖面下的運行情況。

4 結束語

本文針對某星載嵌入式軟件特點，結合一般軟件可靠性測試的過程，給出了開展該軟件可靠性測試的關鍵步驟的解決方法和途徑，包括失效的定義、測試環境的搭建、使用剖面的構造和數據的采集，最后通過測試結果的分析，給出了該軟件的可靠性評估結論。本次測試的實踐過程證明了該方法的實用性和可行性，為該軟件的評價和驗收工作提供了決策依據，同時在測試中發現了一些一般軟件測試無法發現的軟件錯誤，有利于該軟件可靠性的提高。

［1］Michael R Lyu.Software reliability engineering:A roadmap［C］//Proc of Future of Software Engineering，Minnesota，2007:153-170.

［2］IEEE Std 982.1-2005，IEEE standard dictionary of measures of the software aspects of dependability［S］.New York:IEEE Computer Society Press，2005.

［3］WU Yumei，RUAN Lian.Research on the acceleration principle of software reliability testing ［J］.Computer Applications，2006，26(6):1449-1451(in Chinese).［吳玉美，阮鐮.軟件可靠性測試的加速機理研究 ［J］.計算機應用，2006，26(6):1449-1451.］

［4］SHI Zhu，ZHENG Zhong.Case study on software reliability measurement［J］.Systems Engineering and Electronics，2011，33(1):239-242(in Chinese).［石柱，鄭重.軟件可靠性度量實例研究 ［J］.系統工程與電子技術，2011，33(1):239-242.］

［5］ZHANG Xu，SHI Zhu，WANG Kunsheng.A test case generation approach of software reliability based on usage profile［J］Computer Simulation，2009，26(12):82-85(in Chinese).［張旭，石柱，王崑聲.基于使用剖面的軟件可靠性測試用例生成方法 ［J］.計算機仿真，2009，26(12):82-85.］

［6］Vincent Almering，Michiel van Genuchten，Ger Cloudt，et al.U-sing software reliability growth models in practice［J］.IEEE Software，2007，24(6):82-88.

［7］FENG Erqiang，LIU Chang，ZHENG Jun.Analysis on principle of software reliability accelerated testing methods［J］.Computer Engineering and Design，2011，32(9):3087-3090(in Chinese).［封二強，劉暢，鄭軍.軟件可靠性測試加速方法分析 ［J］.計算機工程與設計，2011，32(9):3087-3090.］

［8］CAI Jianping.New explore on test method for software reliability［J］.Computer Engineering and Design，2009，30(20):84-87(in Chinese).［蔡建平.軟件可靠性測試方法新探 ［J］.計算機工程與設計，2009，30(20):84-87.］

［9］ZHANG Lei，ZHOU Jifeng，ZHANG Qiang.Study on a testing method of verifying software reliability［J］.Computer＆ Digital Engineering，2010，38(6):86-88(in Chinese).［張磊，周繼峰，張強.系統軟件可靠性驗證測試方法研究 ［J］.計算機與數字工程，2010，38(6):86-88.］

［10］CHEN Chunxiu，MA Li.Research of software reliability test technology ［J］.Computer Engineering and Design，2010，31(21):96-99(in Chinese).［陳春秀，馬力.軟件可靠性測試技術研究 ［J］.計算機工程與設計，2010，31(21):96-99.］