定義
1983年美國IEEE計算機學會對“軟體可靠性”作出了明確定義，此後該定義被美國標準化研究所接受為國家標準，1989年中國也接受該定義為國家標準。該定義包括兩方面的含義：
（1）在規定的條件下，在規定的時間內，軟體不引起系統失效的機率；
（2）在規定的時間周期內，在所述條件下程式執行所要求的功能的能力；
其中的機率是系統輸入和系統使用的函式，也是軟體中存在的故障的函式，系統輸入將確定是否會遇到已存在的故障（如果故障存在的話）。
越難保證
用軟體系統規模越做越大越複雜，其可靠性越來越難保證。套用本身對系統運行的可靠性要求越來越高，在一些關鍵的套用領域，如航空、航天等，其可靠性要求尤為重要，在銀行等服務性行業，其軟體系統的可靠性也直接關係到自身的聲譽和生存發展競爭能力。 特別是軟體可靠性比硬體可靠性更難保證，會嚴重影響整個系統的可靠性。在許多項目開發過程中，對可靠性沒有提出明確的要求，開發商(部門)也不在可靠性方面花更多的精力，往往只注重速度、結果的正確性和用戶界面的友好性等，而忽略了可靠性。在投入使用後才發現大量可靠性問題，增加了維護困難和工作量，嚴重時只有束之高閣，無法投入實際使用。
與硬體
軟體可靠性1.最明顯的是硬體有老化損耗現象，硬體失效是物理故障，是器件物理變化的必然結果，有浴盆曲線現象；軟體不發生變化，沒有磨損現象，有陳舊落後的問題，沒有浴盆曲線現象。
2.硬體可靠性的決定因素是時間，受設計、生產、運用的所有過程影響，軟體可靠性的決定因素是與輸入數據有關的軟體差錯，是輸入數據和程式內部狀態的函式，更多地決定於人。
3.硬體的糾錯維護可通過修復或更換失效的系統重新恢復功能，軟體只有通過重設計。
4.對硬體可採用預防性維護技術預防故障，採用斷開失效部件的辦法診斷故障，而軟體則不能採用這些技術。
5.事先估計可靠性測試和可靠性的逐步增長等技術對軟體和硬體有不同的意義。
6.為提高硬體可靠性可採用冗餘技術，而同一軟體的冗餘不能提高可靠性。
7.硬體可靠性檢驗方法已建立，並已標準化且有一整套完整的理論，而軟體可靠性驗證方法仍未建立，更沒有完整的理論體系。
8.硬體可靠性已有成熟的產品市場，而軟體產品市場還很新。
9.軟體錯誤是永恆的，可重現的，而一些瞬間的硬體錯誤可能會被誤認為是軟體錯誤。
總的說來，軟體可靠性比硬體可靠性更難保證，即使是美國宇航局的軟體系統，其可靠性仍比硬體可靠性低一個數量級。
軟體差錯
軟體差錯是軟體開發各階段潛入的人為錯誤：
1.需求分析定義錯誤。如用戶提出的需求不完整，用戶需求的變更未及時消化，軟體開發者和用戶對需求的理解不同等等。
2.設計錯誤。如處理的結構和算法錯誤，缺乏對特殊情況和錯誤處理的考慮等。
4.測試錯誤。如數據準備錯誤，測試用例錯誤等。
5.文檔錯誤。如文檔不齊全，文檔相關內容不一致，文檔版本不一致，缺乏完整性等。
從上游到下游，錯誤的影響是發散的，所以要儘量把錯誤消除在開發前期階段。
錯誤引入軟體的方式可歸納為兩種特性：程式代碼特性，開發過程特性。
程式代碼一個最直觀的特性是長度，另外還有算法和語句結構等，程式代碼越長，結構越複雜，其可靠性越難保證。
開發過程特性包括採用的工程技術和使用的工具，也包括開發者個人的業務經歷水平等。
除了軟體可靠性外，影響可靠性的另一個重要因素是健壯性，對非法輸入的容錯能力。
所以提高可靠性從原理上看就是要減少錯誤和提高健壯性。
三個要素
1.規定的時間
軟體可靠性只是體現在其運行階段，所以將“運行時間”作為“規定的時間”的度量。“運行時間”包括軟體系統運行後工作與掛起(開啟但空閒)的累計時間。由於軟體運行的環境與程式路徑選取的隨機性，軟體的失效為隨機事件，所以運行時間屬於隨機變數。
2.規定的環境條件
環境條件指軟體的運行環境。它涉及軟體系統運行時所需的各種支持要素，如支持硬體、作業系統、其它支持軟體、輸入數據格式和範圍以及操作規程等。不同的環境條件下軟體的可靠性是不同的。具體地說，規定的環境條件主要是描述軟體系統運行時計算機的配置情況以及對輸入數據的要求，並假定其它一切因素都是理想的。有了明確規定的環境條件，還可以有效判斷軟體失效的責任在用戶方還是研製方。
3.規定的功能
軟體可靠性還與規定的任務和功能有關。由於要完成的任務不同，軟體的運行剖面會有所區別，則調用的子模組就不同(即程式路徑選擇不同)，其可靠性也就可能不同。所以要準確度量軟體系統的可靠性必須首先明確它的任務和功能。
可靠性測試
測試目的
軟體可靠性軟體可靠性測試的主要目的有:
(1)通過在有使用代表性的環境中執行軟體,以證實軟體需求是否正確實現。
(2)為進行軟體可靠性估計採集準確的數據。估計軟體可靠性一般可分為四個步驟,即數據採集、模型選擇、模型擬合以及軟體可靠性評估。可以認為,數據採集是整個軟體可靠性估計工作的基礎,數據的準確與否關係到軟體可靠性評估的準確度。
(3)通過軟體可靠性測試找出所有對軟體可靠性影響較大的錯誤。
測試特點
軟體可靠性測試不同於硬體可靠性測試,這主要是因為二者失效的原因不同。硬體失效一般是由於元器件的老化引起的,因此硬體可靠性測試強調隨機選取多個相同的產品,統計它們的正常運行時間。正常運行的平均時間越長,則硬體就越可靠。軟體失效是由設計缺陷造成的,軟體的輸入決定是否會遇到軟體內部存在的故障。因此,使用同樣一組輸入反覆測試軟體並記錄其失效數據是沒有意義的。在軟體沒有改動的情況下,這種數據只是首次記錄的不斷重複,不能用來估計軟體可靠性。軟體可靠性測試強調按實際使用的機率分布隨機選擇輸入,並強調測試需求的覆蓋面。軟體可靠性測試也不同於一般的軟體功能測試。相比之下,軟體可靠性測試更強調測試輸入與典型使用環境輸入統計特性的一致,強調對功能、輸入、數據域及其相關機率的先期識別。測試實例的採樣策略也不同,軟體可靠性測試必須按照使用的機率分布隨機地選擇測試實例,這樣才能得到比較準確的可靠性估計,也有利於找出對軟體可靠性影響較大的故障。
此外,軟體可靠性測試過程中還要求比較準確地記錄軟體的運行時間,它的輸入覆蓋一般也要大於普通軟體功能測試的要求。
對一些特殊的軟體,如容錯軟體、實時嵌入式軟體等,進行軟體可靠性測試時需要有多種測試環境。這是因為在使用環境下常常很難在軟體中植入錯誤,以進行針對性的測試。
測試效果
軟體可靠性測試是軟體可靠性保證過程中非常關鍵的一步。經過軟體可靠性測試的軟體並不能保證該軟體中殘存的錯誤數最小,但可以保證該軟體的可靠性達到較高的要求。從工程的角度來看,一個軟體的可靠性高不僅意味著該軟體的失效率低,而且意味著一旦該軟體失效,由此所造成的危害也小。一個大型的工程軟體沒有錯誤是不可能的,至少理論上還不能證
明一個大型的工程軟體能沒有錯誤。因此,保證軟體可靠性的關鍵不是確保軟體沒有錯誤,而是要確保軟體的關鍵部分沒有錯誤。更確切地說,是要確保軟體中沒有對可靠性影響較大的錯誤。這正是軟體可靠性測試的目的之一。軟體可靠性測試的側重點不同於一般的軟體功能測試,其測試實例設計的出發點是尋找對可靠性影響較大的故障。因此,要達到同樣的可靠性要求,可靠性測試比一般的功能測試更有效,所花的時間也更少。另外,軟體可靠性測試的環境是具有使用代表性的環境,這樣,所獲得的測試數據與軟體的實際運行數據比較接近,可用於軟體可靠性估計。
總之,軟體可靠性測試比一般的功能測試更加經濟和有效,它可以代替一般的功能測試,而一般的軟體功能測試卻不能代替軟體可靠性測試,而且一般功能測試所得到的測試數據也不宜用於軟體可靠性估計。
注意問題
軟體可靠性測試一般可分為四個階段:制定測試方案,制定測試計畫,進行測試並記錄測試結果,編寫測試報告。
制定測試方案時需要特別注意被測功能的識別和失效等級的定義。制定測試計畫時需設計測試實例,決定測試時要確定輸入順序,並確定程式輸出的預期結果,這時也需注意測試覆蓋問題。
1.功能識別
軟體可靠性測試的第一步就是進行功能識別,確定使用剖面。功能識別的目標是:識別所有被測功能以及執行這些功能所需的相關輸入,識別每一個使用需求及其相關輸入的機率分布。為達到第一個目標,需要分析軟體功能的所有集合,這些功能之間全部的約束條件,功能之間的獨立性、相互關係和相互影響,還需分析系統的不同運行模式、失效發生時系統重構策略等對軟體運行方式有較大影響的因素。第一個目標也是一般軟體功能測試需要達到的目標,但第二個目標則是軟體可靠性測試特彆強調的。為了得到能夠反映軟體使用的有代表性的機率分布,測試人員必須和系統工程師、系統運行分析員和顧客共同合作。需要指出的是,由於可靠性的要求,輸入數據的機率分布應包括合法數據的機率分布和非法數據的機率分布兩部分。有時為了更好地反映實際使用狀況,還需給出那些影響程式運行方式的條件,如硬體配置.負荷等的機率分布。
2.定義換效等級
定義失效等級主要是為了解決下面兩個問題:
對發生機率小但失效後危害嚴重的功能需求的識別。
對可不查找失效原因、並不做統計的功能需求的識別。
在制定測試計畫時,失效及其等級的定義應由測試人員、設計人員和用戶共同商定,達成協定。
3.可靠性測試覆蓋
可靠性測試必須保證輸入覆蓋和環境覆蓋,這是準確估計軟體可靠性的基礎。
輸入覆蓋包括下面幾個內容:
輸入域覆蓋,即所有被測輸入值域的發生機率之和必須大於軟體可靠度的要求。
重要輸入變數值的覆蓋。
相關輸入變數可能組合的覆蓋,以確保相關輸入變數的相互影響不會導致軟體失效。
設計輸入空間與實際輸入空間之間區域的覆蓋,即不合法輸入域的覆蓋。
各種使用功能的覆蓋。
環境覆蓋是指測試時必須覆蓋所有可能影響程式運行方式的條件。
測試步驟
軟體可靠性測試分為四個階段:
1.制訂測試方案
本階段的目標是識別軟體功能需求,觸發該功能的輸入和對應的數據域,確定相關的機率分布及需強化測試的功能。
以下是我們推薦的步驟。在一些特定的套用中,有的步驟並不是必須的。
(1)分析功能需求分析各種功能需求,識別觸發該功能的輸入及相關的數據域(包括合法
與不合法的兩部分)。分析時要注意下述問題:
該軟體是否存在不同的運行模式?如果存在,那么應列出所有的系統運行模式。
是否存在影響程式運行方式的外部條件?如果存在,那么有多少?它們的影響程度如何
各種功能需求之間是相互獨立的還是相關的?如果相關,是密切相關還是部分相關?如果兩種功能密切相關,那么可將兩種功能合併為一種功能。如果功能之間為部分相關,則需列出相應輸入變數的合法組合。
(2)定義失效等級
判斷是否存在出現危害度較大的1級和2級失效的可能性。如果這種可能性存在,則應進行故障樹分析,標識出所有可能造成嚴重失效的功能需求和其相關的輸入領域。
(3)確定機率分布
確定各種不同運行方式的發生機率,判斷是否需要對不同的運行方式進行分別測試。如果需要,則應給出各種運行方式下各數據域的機率分布;否則,給出各數據域的機率分布。
判斷是否需要強化測試某些功能。
(4)整理機率分布的信息將這些信息編碼送入資料庫。
2.制訂測試計畫
(1)根據前一階段整理的機率分布信息生成相對應的測試實例集,並計算出每一測試實例預期的軟體輸出結果。
本階段需要注意:在按機率分布隨機選擇生成測試實例的同時,要保證測試的覆蓋面。
(2)編寫測試計畫,確定測試順序,分配測試資源。由於本階段前一部分的工作需要考慮大量的信息和數據,因此需要一個軟體支持工具,建立資料庫,並產生測試實例。另外,有時預測軟體輸出結果也需要大量的計算,有些複雜的軟體甚至要用到仿真器模擬輸出結果。總之,具體實施與被測套用軟體的實際功能類型有關。
3.測試
本階段進行軟體測試。需注意的是被測軟體的測試環境(包括硬體配置和軟體支撐環境
)應和預期的實際使用環境儘可能一致,對某些環境要求比較嚴格的軟體(如嵌入式軟體)則應完全一致。測試時按測試計畫和順序對每一個測試實例進行測試,判斷軟體輸出是否符合預期結果。測試時應記錄測試結果、運行時間和判斷結果。如果軟體失效,那么還應記錄失效現象和時間,以備以後核對。
4.編寫測試報告
按軟體可靠性估計的要求整理測試記錄,並將結果寫成報告。
軟體可靠性測試的關鍵在於:
對需求、輸入、數據域的識別及相關機率分布的確定。
按照機率分布隨機生成測試實例,並確定測試順序。
據國外有關文獻報導,這種測試方法已成功套用於大量套用軟體的可靠性測試,包括一些商用軟體和航空、航天電子設備中嵌入式軟體的測試,其效果很好。因此,我們有必要投入一定的人力、物力,針對我們的實際需要,有目的地對各類套用軟體進行軟體可靠性測試,從實踐中逐步積累經驗。同時需要軟體開發方和使用方共同合作,進行軟體可靠性測試方法的研究和有關支持工具的開發,促進我國軟體可靠性水平的提高。
評測技術
軟體可靠性評測是指運用統計技術對軟體可靠性測試和系統運行期間採集的軟體失效數據進行處理並評估軟體可靠性的過程。軟體可靠性評測的主要目的是測量和驗證軟體的可靠性，當然實施軟體可靠性評測也是對軟體測試過程的一種完善，有助於軟體產品本身的可靠性增長。
軟體測試者可以使用很多方法進行軟體測試，如按行為或結構來劃分輸入域的劃分測試，純粹隨機選擇輸入的隨機測試，基於功能、路徑、數據流或控制流的覆蓋測試，等等。對於給定的軟體，每種測試方法都局限於暴露一定數量和一些類別的錯誤。通過這些測試能夠查找、定位、改正和消除某些錯誤，實現一定意義上的軟體可靠性增長。但是，由於它們都是面向錯誤的測試，測試所得到的結果數據不宜用於軟體可靠性評估。
軟體可靠性測試是指在軟體的預期使用環境中，為進行軟體可靠性評估而對軟體實施的一種測試。軟體可靠性測試應該是面向故障的測試，以用戶將要使用的方式來測試軟體，每一次測試代表用戶將要完成的一組操作，使測試成為最終產品使用的預演。這就使得所獲得的測試數據與軟體的實際運行數據比較接近，可用於軟體可靠性估計。
軟體可靠性評測由可靠性目標的確定、運行剖面的開發、測試的計畫與執行和測試結果的分析與反饋等四個主要的活動組成。
可靠性目標是指客戶對軟體性能滿意程度的期望。通常用可靠度、故障強度、MTTF等指標來描述，根據不同項目的不同需要而定。建立定量的可靠性指標需要對可靠性、交付時間和成本進行平衡。為了定義系統的可靠性指標,必須確定系統的運行模式，定義故障的嚴重性等級，確定故障強度目標。
為了對軟體可靠性進行良好的預計，必須在軟體的運行域上對其進行測試，首先定義一個相應的剖面來鏡像運行域，然後使用這個剖面驅動測試，這樣可以使測試真實的反映軟體的使用情況。由於可能的輸入幾乎是無限的，測試必須從中選擇出一些樣本，即測試用例，測試用例要能反映實際的使用情況，反映系統的運行剖面。將統計方法套用到運行剖面開發和測試用例生成，在運行剖面中的每個元素都被定量地賦予一個發生機率值和關鍵因子，然後根據這些因素分配測試資源、挑選和生成測試用例。在這種測試中,優先測試那些最重要或最頻繁使用的功能，釋放和緩解最高級別的風險，有助於儘早發現那些對可靠性有最大影響的故障，以保證軟體的按期交付。一個產品有可能需要開發多個運行剖面，這取決於它所包含的運行模式和關鍵操作，通常需要為關鍵操作單獨定義運行剖面。
在軟體的開發過程中使用軟體可靠性測試和利用軟體可靠性測試對最終產品進行評價，在測試計畫的制定上有所不同。用於設計過程的可靠性測試稱為可靠性增長測試，測試與故障的排除聯繫在一起，一般安排在開發過程的系統測試階段執行，將測試所確定的故障提交給開發者進行修改，建立軟體的一個新的版本，再進行下一次測試。在這種“測試—排錯—新版本”的疊代過程中，跟蹤故障強度的變化，確認測試是否可以終止及軟體是否可以發布。可靠性增長測試的測試腳本將執行多次。針對最終產品的可靠性測試稱為可靠性驗證測試，通過驗證測試可確定軟體產品當前的可靠性水平。就單個軟體版本而言，可靠性驗證測試的測試腳本將僅執行一次。軟體可靠性故障數據的收集是測試活動的一部分，在測試周期內，紀錄每個故障的資料，如與時間相關的故障頻度、類型、嚴重性和故障的根源等，並且應區分設計階段和最終產品的故障。
可靠性增長測試和可靠性驗證測試將從不同的角度理解故障數據。在可靠性增長測試中，測試以疊代的方式進行，根據測試期間跟蹤到的故障，使用基於軟體可靠性增長模型和統計推理的可靠性評估程式進行故障強度的估計，並用於跟蹤測試的進展情況。可靠性驗證測試是軟體系統提交前進行的最後測試。它是最終檢驗而不是調試。在驗證測試中,其目標是確定一個軟體組件或系統在風險限度內是被接受還是被拒絕。驗證測試使用可靠性示圖，故障被繪製在圖上。根據它落入的區域，來決定被測軟體是被接受還是被拒絕，或者繼續進行測試。可以根據不同的客戶風險(接受一個不良程式的風險)和供應商風險(拒絕一個好程式的風險)級別構造圖表。
