2011年軟考系統架構設計師學習筆記第十三章
系統的可靠性
13.1 軟件可靠性
目前，硬件可靠性測試技術和評估手段日趨成熟，已經得到了業界的認可。
軟件可靠性模型的研究多集中在開發階段、測試階段、評估階段的可靠性模型。
13.1.1 軟件可靠性的定義
可靠性(Reliability)是指產品在規定的條件下和規定的時間內完成規定功能的能力。
按照產品可靠性的形成，分為固有可靠性、使用可靠性。
固有可靠性是通過設計、制造賦予產品的可靠性。
使用可靠性既受設計、制造的影響，又受使用條件的影響。
軟件與硬件從可靠性角度來看，主要有4個不同點：
1、復雜性，軟件內部的邏輯高度復雜，硬件則相對簡單。
2、物理退化，一個正確的軟件任何時刻均可靠，一個正確的硬件、元器件、系統則可能在某個時刻失效。
3、唯一性，軟件是唯一的，軟件復制不改變軟件本身，硬件不可能完全相同，概率方法在硬件可靠性領域取得巨大成功。
4、版本更新快，軟件版本更新較快，也給軟件可靠性評估帶來較大的難度。
1983年，美國IEEE 對“軟件可靠性”做出了更明確的定義。
1989年，我國國家標準 GB/T-11457也采用了這個定義。
定義：在規定的條件下，在規定的時間內，軟件不引起系統失效的概率。
依然沿用了“產品可靠性”的定義。
1、規定的時間
由于軟件運行的環境與程序路徑選取的隨機性，軟件的失效為隨機事件，所以運行時間屬于隨機變量。
2、規定的條件
不同的環境條件下的可靠性是不同的，計算機的配置情況、對輸入的要求。
有了明確規定的環境條件，還可以有效地判斷軟件失效的責任在用戶方還是開發放。
3、所要求的功能
軟件可靠性還與規定的任務和功能有關。
要準確度量軟件系統的可靠性，必須先明確它的任務和功能。
4、“軟件可靠性”定義具有如下特點：
1. 用內在的“缺陷” 和 外在的“失效”關系來描述可靠性。
2. 定義使人們對軟件可靠性進行量化評估成為可能。
3. 用概率的方法描述可靠性是比較科學的。
13.1.2 軟件可靠性的定量描述
軟件的可靠性可以基于 使用條件、規定時間、系統輸入、系統使用、軟件缺陷 等變量構建的數學表達式。
1、規定時間：自然時間、運行時間、執行時間。
使用執行時間來度量軟件的可靠性最為準確。
2、失效率：把軟件從運行開始，到某一時刻t 為止，出現失效的概率用 F(t)表示。
F(0)=0，即軟件運行初始時刻失效概率為0。
F(t)在時間域(0,+無窮大)上是單調遞增的。
F(+無窮大)=1，即失效概率在運行時間不斷增長時 趨向于1，這也意味著任何軟件都存在缺陷。
3、可靠度：在規定的條件下，規定的時間內 不發生失效的概率。
4、失效強度(Failure Intensity)單位時間 軟件系統出現失效的概率。
5、失效率(Failure Rate)又稱 風險函數(Hazard Function)，也可以稱為條件失效強度。
就是當軟件在 0～t 時刻內 沒有發生失效的條件下，t 時刻軟件系統的失效強度。
公式略。
6、可靠度與失效率之間的換算。
7、平均失效時間(Mean Time to Failure，MTTF)就是軟件運行后，到下一次出現失效的平均時間。更直觀地表明一個軟件的可靠度。
需要對 軟件可靠度 這個反映軟件可靠性的肚量指標作下列補充說明：
1. 需指明它與其他軟件的界限。
2. 軟件失效必須明確定義。
3. 必須假設硬件無故障(失效)和軟件有關變量輸入正確。
5. 必須指明時間基準：自然時間(日歷時間)、運行時間、執行時間(CPU 時間)、其他時間基準。
6. 通常以概率度量，也可以模糊數學中的可能性加以度量。
7. 在時間域上進行，是一種動態度量，也可以是在數據域上，表示成功執行一個回合的概率。
軟件回合是軟件運行最小的、不可分的執行單位。
8. 有時將軟件運行環境簡單地理解為軟件運行剖面(Operational Profile)。
運行剖面定義了關于軟件可靠性描述中的“規定條件”，測試環境、測試數據 等一系列問題。
13.1.3 可靠性目標
使用 失效強度 表示軟件缺陷對軟件運行的影響程度。
不僅取決于軟件失效發生的概率，還和軟件失效的嚴重程度有很大關系。引出另外一個概念——失效嚴重程度類(Failure Severity Class)。
失效嚴重程度類 就是對用戶具有相同程度影響的失效集合。
對失效嚴重程度的分級 可以按照不同的標準進行，對成本影響、對系統能力的影響 等。
對成本的影響可能包括失效引起的額外運行成本、修復和恢復成本、現有潛在的業務機會的損失等。
對系統能力的影響常常表現為 關鍵數據的損失、系統異常退出、系統崩潰、導致用戶操作無效等。
可靠性目標是指客戶對軟件性能滿意程度的期望。通常用 可靠度、故障強度、平均失效時間(MTTF)等指標來描述。
建立定量的可靠性指標需要對可靠性、交付時間、成本進行平衡。
13.1.4 可靠性測試的意義
1、軟件失效可能造成災難性的后果。
2、軟件的失效在整個計算機系統失效中的比例較高。
80%和軟件有關。
結構太復雜了，一個較簡單的程序，其所有路徑數量可能是一個天文數字。
3、相比硬件可靠性技術，軟件可靠性技術很不成熟。
4、軟件可靠性問題是造成費用增長的主要原因之一。
5、系統對于軟件的依賴性越來越強。
13.1.5 廣義的可靠性測試與俠義的可靠性測試
廣義的軟件可靠性測試是指為了最終評價軟件系統的可靠性而運用建模、統計、試驗、分析、和評價等一系列手段對軟件系統實施的一種測試。
俠義的軟件可靠性測試是指為了獲取可靠性數據，按預先確定的測試用例，在軟件的預期使用環境中，對軟件實施的一種測試。
也叫“軟件可靠性試驗(Software Reliability Test)”，它是面向缺陷的測試，以用戶將要使用的方式來測試軟件，所獲得的測試數據與軟件的實際運行數據比較接近。
可靠性測試是對軟件產品的可靠性進行調查、分析、評價的一種手段。
對檢測出來的失效的分布、原因、后果 進行分析，并給出糾正建議。
總的來說，可靠性測試的目的可歸納為以下三個方面：
1、發現軟件系統在 需求、設計、編碼、測試、實施 等方面的 各種缺陷。
2、為軟件的使用、維護提供可靠性數據。
3、確認軟件是否達到可靠性的定量要求。
13.2 軟件可靠性建模
13.2.1 影響軟件可靠性的因素
軟件可靠性模型(Software Reliability Model)是指 為預計或估算軟件的可靠性所建立的可靠性框圖和數學模型。
模型將復雜系統的可靠性逐級分解為簡單系統的可靠性，以便 定量預計、分配、估算、評價復雜系統的可靠性。
影響軟件可靠性的主要因素：缺陷的引入、發現、清除。
缺陷的引入主要取決于軟件產品的特征和軟件的開發過程特性。
缺陷的發現依靠運行剖面。
缺陷的清除依賴于失效的發現、修復活動、可靠性方面的投入。
影響軟件可靠性的主要因素如下：
1、運行剖面(環境)。
2、軟件規模。
3、軟件內部結構。
4、軟件的開發方法和開發環境。
5、軟件的可靠性投入。人力、資金、資源、時間 等。
早期重視軟件可靠性并采取措施開發出來的軟件，可靠性有明顯的提高。
13.2.2 軟件可靠性建模方法
可靠性模型通常由以下幾部分組成：
1、模型假設。模型是實際情況的簡化或規范化，總要包含若干假設。
2、性能度量。軟件可靠性模型的輸出量就是性能度量。
3、參數估計方法。
4、數據要求。
絕大多數模型包含三個共同假設：
1、代表性假設。選取代表軟件實際的運行剖面。
2、獨立性假設。假設認為軟件失效是獨立發生于不同時刻。
3、相同性假設。認為所有軟件失效的后果(等級)相同，即建模過程只考慮軟件失效的具體發生時刻，不區分軟件的失效嚴重等級。
如果在進行預測時發現引入了新的錯誤，或修復行為使新的故障不斷發生，就應該停止預測。否則，這樣的變化會因為增加問題的復雜程度而使模型的適用性降低。
好的軟件可靠性模型應該具有如下重要特性：
1、基于可靠性的假設。
2、簡單。
3、計算一些有用的量。
4、給出未來失效行為的好的映射。
5、可廣泛使用。
13.2.3 軟件的可靠性模型分類
可靠性模型大致可分為如下10類：
1、種子方法模型。
利用捕獲一再捕獲抽樣技術估計程序中的錯誤數，在程序中預先有意“播種”一些設定錯誤的“種子”，然后根據測試出的原始錯誤和發現的誘導錯誤比例，估計程序中殘留的錯誤數。
優點是簡單易行，缺點是誘導錯誤的“種子”與實際的原始錯誤之間的類比性估量困難。
2、失效率類模型。
3、曲線擬合類模型。
用回歸分析的方法研究軟件 復雜性、缺陷數、失效率、失效間隔時間，包括參數方法和非參數方法兩種。
4、可靠性增長模型。
5、程序結構分析模型。
通過對每一個節點可靠性、節點間轉換的可靠性和網絡在節點間的轉換概率，得出該持續程序的整體可靠性。
6、輸入域分類模型。
7、執行路徑分析方法模型。
8、非其次泊松過程模型。
NHPP，以軟件測試過程中單位時間的失效次數為獨立泊松隨機變量，來預測今后軟件的某使用時間點的積累失效次數。
9、馬兒可夫過程模型。
10、貝葉斯模型。
利用失效率的試驗前分布和當前的測試失效信息，來評估軟件的可靠性。
當軟件可靠性工程師對軟件的開發過程有充分的了解，軟件的繼承性比較好時具有良效果的可靠性分析模型。
時間域。
失效數類：失效數是有限的還是無限的。
失效數分布。
有限類：用時間表示的失效強度的函數形式。
無限類：用經驗期望失效數表示的失效強度的函數形式。
13.2.4 軟件可靠性模型舉例
1、模型假設
JM 模型的基本假設如下：
1. 初始錯誤個數為一個未知的常數。
2. 發現錯誤立即被完全排除，并且不引入新的錯誤，排除時間忽略不記，因此每次排錯后就要減 1。
3. 失效率剩余的錯誤個數成正比。
2、函數表達式。
軟件可靠性模型并不成熟，定量分析方法和數學模型要在實踐中不斷加以驗證和修正。
不同類型的軟件，應用方式也有很大區別。
13.2.5 軟件可靠性測試概述
可靠性測試 由可靠性目標的確定、運行剖面的開發、測試用例的設計、測試實施、測試結果的分析 等主要活動組成。
軟件可靠性測試 還必須考慮對軟件開發進度和成本的影響，最好是在受控的自動測試環境下，由專業測試機構完成。
13.2.6 定義軟件運行剖面
弧 用來連接狀態并表示由各種激勵導致的轉換，將轉換概率分配給每個弧。
每類用戶都可能以不同的方式使用系統。
兩種類型分層形式：用戶級分層、用法級分層。
用法級分層依賴于在測試狀態下系統能做什么。
用戶級分層考慮各種類型的用戶，以及他們如何使用系統。
這些概率估計主要是基于如下幾個方面：
1、從現有系統收集到的數據。
2、與用戶的交談或對用戶進行觀察獲得的信息。
3、原型使用與測試分析的結果。
4、相關領域專家的意見。
13.2.7 可靠性測試的實施
有必要檢查軟件需求與文檔是否一致，檢查軟件開發過程中形成的文檔的準確性、完整性、一致性。
可靠性測試依賴于軟件的可測試性。
為了獲得更多的可靠數據，應該使用多態計算機同時運行軟件，以增加累計時間。
用時間定義的軟件可靠性數據分為4類：
1、失效時間數據。
2、失效間隔時間數據。
3、分組時間內的失效數據。
4、分組時間的累計失效數。
這 4類數據可以相互轉化。
測試過程中必須真實地進行記錄，每個測試記錄必須包含如下信息：
1、測試時間。
2、含有測試用例的測試說明或標識。
3、所有與測試有關的測試結果，包括失效數據。
4、測試人員。
測試活動結束后要編寫《軟件可靠性測試報告》具備如下內容：
1、軟件產品標識。
2、測試環境配置(硬件和軟件)。
3、測試依據。
4、測試結果。
5、測試問題。
6、測試時間。
13.3 軟件可靠性評價
13.3.1 軟件可靠性評價概述
估計軟件當前的可靠性，以確認是否可以終止測試并發布軟件，還可以預計軟件要達到相應的可靠性水平所需要的時間和工作量，確認軟件的執行與需求的一致性。
13.3.2 怎樣選擇可靠性模型
可以從以下幾個方面進行比較和選擇：
1、模型假設的適用性。
2、預測的能力與質量。
3、模型輸出值能否滿足可靠性評價需求。
最重要的幾個需要精確估計的可靠性定量指標包括如下內容：
1. 當前的可靠度。
2. 平均失效時間。
3. 故障密度。
4. 期望達到規定可靠性目標的日期。
5. 達到規定的可靠性目標的成本要求。
4、模型使用的簡便性
簡便性一般包含如下三層含義：
1. 模型需要的數據 易于收集，成本不能超過可靠性計劃的預算。
2. 模型應該簡單易懂，測試人員不會花費太多的時間去研究專業的數學理論。
3. 模型應該便于使用。
13.3.3 可靠性數據的收集
面向缺陷的可靠性測試 產生的測試數據經過分析后，可以得到非常有價值的可靠性數據，這部分數據取決于定義的運行剖面和選取的測試用例集。
可靠性數據的收集工作是貫穿整個軟件生命周期的。
可行的一些辦法如下：
1、及早確定所采用的可靠性模型。
2、指定可實施性較強的可靠性數據收集計劃，指定專人負責，按照統一的規范收集記錄可靠性數據。
3、重視軟件測試特別是可靠性測試產生的測試數據的整理和分析。
4、充分利用數據庫來完成可靠性數據的存儲和統計分析。
13.3.4 軟件可靠性的評估和預測
1、判斷是否達到了可靠性目標。
2、如未能達到，要再投入多少時間、多少人力、多少資金。
3、在軟件系統投入實際運行 若干時間后，能否達到交付或部分交付用戶使用的可靠性水平。
沒有失效就無法估計可靠性。
要在模型之外運行一些統計技術和手段對可靠性數據進行分析，作為可靠性模型的補充、完善、修正。
輔助方法如下：
1、失效數據的圖形分析方法。
1. 積累失效個數圖形。
2. 單位時間段內的失效數的圖形。
3. 失效間隔時間圖形。
2、試探性數據分析技術(Exploratory Data Analysis，EDA)對可靠性分析有用的信息如下：
1. 循環相關。
2. 短期內失效數的急劇上升。
3. 失效數集中的時間段。
13.4 軟件的可靠性設計與管理
13.4.1 軟件可靠性設計
實踐證明，保障軟件可靠性,最有效、最經濟、最重要的手段是 在軟件設計階段采取措施進行可靠性控制。
1、軟件可靠性設計是軟件設計的一部分，必須在軟件的總體設計框架中使用，并且不能與其他設計原則相沖突。
2、軟件可靠性設計在滿足提高軟件質量要求的前提下，以提高和保障軟件可靠性為最終目標。
3、軟件可靠性設計應確定軟件的可靠性目標，不能無限擴大化，排在功能度、用戶需求、開發費用之后考慮。
容錯設計、檢錯設計、降低復雜度設計 等技術。
1、容錯設計技術
1. 恢復塊設計，一旦文本出現故障，用備份文本加以替換。
2. N版本程序設計，對于相同初始條件和相同輸入的操作結果，實行多數表決，防止其中某一軟件模塊/版本的故障提供錯誤的服務。
必須注意以下兩方面：
使軟件的需求說明具有完整性和精確性。
設計全過程的不相關性。
3. 冗余設計
在相同的運行環境中，一套軟件出故障的地方，另外一套也一定會出現故障。
在一套完整的軟件系統之外，設計一種不同路徑、不同算法或不同實現方法的模塊或系統作為備份。
費用可能接近單個版本軟件開發費用的兩倍，還有可能導致軟件運行時所花費的存儲空間、內存消耗、運行時間有所增加，需要在可靠性要求和額外付出代價之間做出折中。
2、檢錯技術
檢錯技術實現的代價一般低于容錯技術和冗余技術，但它有一個明顯的缺點，就是不能自動解決故障。
著重考慮幾個要素：檢測對象、檢測延時、實現方式、處理方式。
3、降低復雜度設計
模塊復雜性主要包含模塊內部數據流向和程序長度兩個方面，結構復雜性用不同模塊之間的關聯程度表示。
軟件復雜性是產生軟件缺陷的重要根源。
在設計師就應該考慮降低軟件的復雜性，是提高軟件可靠性的有效方法。
在保證實現軟件功能的基礎上，簡化軟件結構，縮短程序代碼長度，優化軟件數據流向，降低軟件復雜度，從而提高軟件可靠性。
13.4.2 軟件可靠性管理
為了進一步提高軟件可靠性，又提出軟件可靠性管理的概念，把軟件可靠性活動貫穿于軟件開發的全過程。
各個階段的可靠性活動的目標、計劃、進度、任務、修正措施等。
由于軟件之間的差異較大，下面的每項活動并不是每一個軟件系統的可靠性管理的必須內容，也不是軟件可靠性管理的全部內容。
【編輯推薦】
