是最早的軟件可靠性模型之一-Read精編版

1、軟件可靠性問題的提出軟件可靠性問題的提出 20世紀中期是計算機硬件飛速發(fā)展的階段，但軟件世紀中期是計算機硬件飛速發(fā)展的階段，但軟件開發(fā)尚處于低級階段，軟件的重要性還不顯著。開發(fā)尚處于低級階段，軟件的重要性還不顯著。 隨著軟件的大量使用和軟件規(guī)模的迅速增長，軟件隨著軟件的大量使用和軟件規(guī)模的迅速增長，軟件可靠性低的問題日益顯著，并作為可靠性低的問題日益顯著，并作為“軟件危機軟件危機”的的主要問題之一于主要問題之一于1968年被提了出來。年被提了出來。 據了解，美國航天飛機上飛行軟件有據了解，美國航天飛機上飛行軟件有50多萬行源代多萬行源代碼；而碼；而F一一22戰(zhàn)斗機上的飛行軟件的源代碼數(shù)更是戰(zhàn)斗

2、機上的飛行軟件的源代碼數(shù)更是高達高達150多萬行。多萬行。 另據美國軍方的統(tǒng)計，美國軍方在武器裝備作戰(zhàn)使另據美國軍方的統(tǒng)計，美國軍方在武器裝備作戰(zhàn)使用中遇到的問題，用中遇到的問題，軟件問題約占到軟件問題約占到70左右左右。由于軟件故障造成的重大事故不乏其例由于軟件故障造成的重大事故不乏其例 美國空軍的范登堡中心在美國空軍的范登堡中心在60年代后期發(fā)生過多年代后期發(fā)生過多次次導彈試射失敗的事故，事后發(fā)現(xiàn)導彈試射失敗的事故，事后發(fā)現(xiàn)幾乎幾乎都是由都是由軟件錯誤造成的；軟件錯誤造成的； F一一18戰(zhàn)斗機在海灣戰(zhàn)爭中，戰(zhàn)斗機在海灣戰(zhàn)爭中，飛行控制軟件飛行控制軟件共共發(fā)生了發(fā)生了500多次多次故障；故障

3、； 我國某型號飛機首飛前我國某型號飛機首飛前航空電子系統(tǒng)航空電子系統(tǒng)在地面測在地面測試中測出的故障共試中測出的故障共800多個，其中軟件故障就多個，其中軟件故障就達達600多個，約占多個，約占75；由于軟件故障造成的重大事故不乏其例由于軟件故障造成的重大事故不乏其例 1990年年1月月15日，美國一日，美國一通信中轉系統(tǒng)通信中轉系統(tǒng)新投新投入使用的軟件發(fā)生了錯誤，導致主干線遠程入使用的軟件發(fā)生了錯誤，導致主干線遠程網網大規(guī)模崩潰大規(guī)模崩潰； 美國的美國的Therac-25放射性治療儀由于放射性治療儀由于軟件存軟件存在缺陷在缺陷導致幾個癌癥病人受到非常嚴重的過導致幾個癌癥病人受到非常嚴重的過量放

4、射性治療，其中量放射性治療，其中4個人因此死亡個人因此死亡； 2002年年11月月28日，歐洲的亞里安娜日，歐洲的亞里安娜5型火箭型火箭因因發(fā)動機控制系統(tǒng)軟件的錯誤發(fā)動機控制系統(tǒng)軟件的錯誤而而導致飛行試導致飛行試驗失敗。驗失敗。軟件可靠性的發(fā)展軟件可靠性的發(fā)展 在在2020世紀世紀5050年代末年代末6060年代初，計算機硬件從晶體年代初，計算機硬件從晶體管到集成電路，得到了飛速的發(fā)展管到集成電路，得到了飛速的發(fā)展. .而軟件開發(fā)仍而軟件開發(fā)仍處于很低級的階段，極大地依賴于開發(fā)人員的編處于很低級的階段，極大地依賴于開發(fā)人員的編程技巧，且主要關注的是軟件的功能。程技巧，且主要關注的是軟件的功能。

5、19681968年在年在西德召開的國際軟件工程會議上提出的西德召開的國際軟件工程會議上提出的“軟件危軟件危機機”的主要問題之一，就是軟件可靠性低，經常的主要問題之一，就是軟件可靠性低，經常出故障。從那時起，才開始認識到軟件可靠性的出故障。從那時起，才開始認識到軟件可靠性的重要性。據統(tǒng)計，計算機系統(tǒng)中，由于軟件錯誤重要性。據統(tǒng)計，計算機系統(tǒng)中，由于軟件錯誤引起的故障占所有故障的引起的故障占所有故障的65%65%。美國貝爾（。美國貝爾（BellBell）實驗室曾對一個實驗室曾對一個AT&TAT&T運行支持系統(tǒng)作了統(tǒng)計，發(fā)運行支持系統(tǒng)作了統(tǒng)計，發(fā)現(xiàn)現(xiàn)80%80%的故障與軟件有關。究其

6、原因是的故障與軟件有關。究其原因是軟件太復雜軟件太復雜了，一個小小的程序，其可能的路徑可以是天文了，一個小小的程序，其可能的路徑可以是天文數(shù)字，以致于在軟件開發(fā)過程中難以對其作窮盡數(shù)字，以致于在軟件開發(fā)過程中難以對其作窮盡的測試，或者說難于完全排除軟件缺陷。的測試，或者說難于完全排除軟件缺陷。調用路徑太多調用路徑太多 A c d e g l 20 次 f j k h i m B其中每個結點或圓圈代表一段其中每個結點或圓圈代表一段可能以轉移語句結束的順序執(zhí)可能以轉移語句結束的順序執(zhí)行語句，每條弧代表兩段程序行語句，每條弧代表兩段程序間的控制轉移。程序含有一個間的控制轉移。程序含有一個最少重復最少

7、重復20次的循環(huán)語句次的循環(huán)語句.由于由于有有5條貫穿循環(huán)體的路徑，即條貫穿循環(huán)體的路徑，即cdefhm；cdefim；cdegjm；cdegkm；cdlm，那么從，那么從 點點A到點到點B的所有獨立路徑數(shù)為的所有獨立路徑數(shù)為520 +519 +51，約為，約為1014 或或1016億。億。 （1 1）故障機理）故障機理 硬件產生故障的原因有四個方面：即設硬件產生故障的原因有四個方面：即設計問題、生產過程中的問題、超載及耗損。硬計問題、生產過程中的問題、超載及耗損。硬件故障主要是由于耗損（物理退化）所致的，件故障主要是由于耗損（物理退化）所致的，而軟件不存在物理退化現(xiàn)象。這就決定了軟件而軟件不

8、存在物理退化現(xiàn)象。這就決定了軟件正確性與軟件可靠性密切相關，一個正確的軟正確性與軟件可靠性密切相關，一個正確的軟件任何時刻均可靠；然而一個正確的硬件元器件任何時刻均可靠；然而一個正確的硬件元器件或系統(tǒng)則可能在某個時刻故障。軟件沒有耗件或系統(tǒng)則可能在某個時刻故障。軟件沒有耗損問題并不等于沒有可靠性問題，因在開發(fā)過損問題并不等于沒有可靠性問題，因在開發(fā)過程中常有一些隨機因素，不可避免地會在軟件程中常有一些隨機因素，不可避免地會在軟件中留下缺陷，因而軟件也有可靠性問題。所以中留下缺陷，因而軟件也有可靠性問題。所以硬件的故障機理是耗損，而軟件的硬件的故障機理是耗損，而軟件的故障機理故障機理就就是是殘留

9、缺陷在一定環(huán)境下造成的軟件錯誤。殘留缺陷在一定環(huán)境下造成的軟件錯誤。軟件與硬件的不同軟件與硬件的不同（2）復雜性）復雜性 軟件內部邏輯高度復雜，而硬件內部邏軟件內部邏輯高度復雜，而硬件內部邏輯較為簡單，這就在很大程度上決定了設輯較為簡單，這就在很大程度上決定了設計錯誤是導致軟件故障的主要原因，而導計錯誤是導致軟件故障的主要原因，而導致硬件故障的可能性則很小。致硬件故障的可能性則很小。（3 3）唯一性）唯一性 軟件是唯一的，軟件拷貝不改變軟件軟件是唯一的，軟件拷貝不改變軟件本身，而任何兩個硬件不可能絕對相同。本身，而任何兩個硬件不可能絕對相同。 軟件可靠性的核心是軟件可靠性的核心是“思考思考”問

10、題，軟件中不可問題，軟件中不可能象硬件那樣分解成元部件，它只有語句。語能象硬件那樣分解成元部件，它只有語句。語言本身造成的軟件故障較少，且通過靜態(tài)測試言本身造成的軟件故障較少，且通過靜態(tài)測試( (目測或編譯目測或編譯) )可加修正。軟件錯誤來源主要是可加修正。軟件錯誤來源主要是軟件設計者的思維錯誤及軟件的復雜性，這是軟件設計者的思維錯誤及軟件的復雜性，這是難以控制的。故軟件可靠性的提高需從人的思難以控制的。故軟件可靠性的提高需從人的思維正確性和減少軟件的復雜性兩方面著手。這維正確性和減少軟件的復雜性兩方面著手。這正如我們用漢語寫文章，觀點有錯誤不能歸咎正如我們用漢語寫文章，觀點有錯誤不能歸咎于

11、語言本身不好，而應歸咎于人的思想于語言本身不好，而應歸咎于人的思想。 （4 4）可靠性的核心）可靠性的核心 由于軟件內部邏輯復雜，運行環(huán)境動態(tài)由于軟件內部邏輯復雜，運行環(huán)境動態(tài)變化，且不同的軟件差異可能很大，因而軟變化，且不同的軟件差異可能很大，因而軟件故障機理可能有不同的表現(xiàn)形式。譬如有件故障機理可能有不同的表現(xiàn)形式。譬如有的故障過程比較簡單，易于追蹤分析，而有的故障過程比較簡單，易于追蹤分析，而有的故障過程可能非常復雜，難于甚至不可能的故障過程可能非常復雜，難于甚至不可能加以詳盡描述和分析，尤其是運行于高度復加以詳盡描述和分析，尤其是運行于高度復雜實時環(huán)境中的大型軟件。但總的說來，軟雜實時

12、環(huán)境中的大型軟件。但總的說來，軟件故障機理可描述為：件故障機理可描述為：軟件缺陷軟件缺陷軟件錯誤軟件錯誤軟件故障。軟件故障。軟件故障軟件故障（1 1）軟件缺陷）軟件缺陷 軟件缺陷軟件缺陷(Default)(Default)：軟件開發(fā)中殘留的內在缺陷軟件開發(fā)中殘留的內在缺陷稱為軟件缺陷。稱為軟件缺陷。這些缺陷可以在軟件生存期的各這些缺陷可以在軟件生存期的各個階段被引入。在軟件開發(fā)的各階段，軟件始終個階段被引入。在軟件開發(fā)的各階段，軟件始終離不開人的參與，而人難免會犯錯誤，這樣就必離不開人的參與，而人難免會犯錯誤，這樣就必然給軟件留下不良的痕跡。例如一段程序進行某然給軟件留下不良的痕跡。例如一段程

13、序進行某些數(shù)據處理，若在處理過程中就產生軟件錯誤，些數(shù)據處理，若在處理過程中就產生軟件錯誤，則說明這段程序存在缺陷或缺少一個程序段。軟則說明這段程序存在缺陷或缺少一個程序段。軟件缺陷是一個靜止的現(xiàn)象，只在一定的輸入條件件缺陷是一個靜止的現(xiàn)象，只在一定的輸入條件下才能被激活導致軟件錯誤，而且軟件錯誤也不下才能被激活導致軟件錯誤，而且軟件錯誤也不一定導致軟件故障，比如容錯軟件中的錯誤就可一定導致軟件故障，比如容錯軟件中的錯誤就可以被檢測出來并可糾正或避免，而不導致故障。以被檢測出來并可糾正或避免，而不導致故障。（2 2）軟件錯誤）軟件錯誤 軟件錯誤軟件錯誤(Error)：軟件缺陷在一定條件下暴露并

14、軟件缺陷在一定條件下暴露并導致系統(tǒng)在運行中出現(xiàn)可感知的不正常、不正確、導致系統(tǒng)在運行中出現(xiàn)可感知的不正常、不正確、不按規(guī)范執(zhí)行的內部狀態(tài)，不按規(guī)范執(zhí)行的內部狀態(tài)，則認為軟件出現(xiàn)則認為軟件出現(xiàn)“錯錯誤誤”，簡稱出錯。所謂不正確的內部狀態(tài)，是指，簡稱出錯。所謂不正確的內部狀態(tài)，是指在此狀態(tài)下，當正常的算法繼續(xù)下去時，就會發(fā)在此狀態(tài)下，當正常的算法繼續(xù)下去時，就會發(fā)生軟件故障。軟件錯誤是由于軟件缺陷造成的。生軟件故障。軟件錯誤是由于軟件缺陷造成的。一個錯誤可能是多個故障源。例如，在求最大值一個錯誤可能是多個故障源。例如，在求最大值的程序中，設計人員由于疏忽將求得的平均值作的程序中，設計人員由于疏忽將

15、求得的平均值作為最大值，這就是一個軟件錯誤。為最大值，這就是一個軟件錯誤。（3 3）軟件故障）軟件故障 軟件故障軟件故障(Failure)：在對錯誤不作任何糾正在對錯誤不作任何糾正和恢復的情況下，導致系統(tǒng)的輸出不滿足和恢復的情況下，導致系統(tǒng)的輸出不滿足用戶提供的正式文件上指明的要求或雙方用戶提供的正式文件上指明的要求或雙方協(xié)議的條款，稱為軟件的一次故障協(xié)議的條款，稱為軟件的一次故障。軟件。軟件故障是由于軟存錯誤造成的一種外部表現(xiàn)，故障是由于軟存錯誤造成的一種外部表現(xiàn)，它是動態(tài)的、程序執(zhí)行過程中出現(xiàn)的行為它是動態(tài)的、程序執(zhí)行過程中出現(xiàn)的行為表現(xiàn)。（表現(xiàn)。（2 2）中的故障例子，由于沒有容錯）中的

16、故障例子，由于沒有容錯措施，即沒有限制和排除軟件故障的措施，措施，即沒有限制和排除軟件故障的措施，最終將得到不可接受的結果（平均值），最終將得到不可接受的結果（平均值），產生軟件故障。產生軟件故障。 激活軟件 輸入域 缺陷的數(shù)據 軟件缺陷 軟件 不可接受的結果 （軟件故障） 輸出域軟件故障的特點軟件故障的特點影響軟件可靠性的因素影響軟件可靠性的因素u運行環(huán)境運行環(huán)境( (剖面剖面) )。同一軟件在不同運行剖面下，其可靠性同一軟件在不同運行剖面下，其可靠性行為可能極不相同。由于軟件故障是軟件缺陷在一定輸入行為可能極不相同。由于軟件故障是軟件缺陷在一定輸入情況下被激活的結果，假設軟件輸入域劃分為兩

17、個部分：情況下被激活的結果，假設軟件輸入域劃分為兩個部分：G G和和F F：運行剖面不包含：運行剖面不包含F(xiàn) F中的輸入，則軟件不會出現(xiàn)故障，中的輸入，則軟件不會出現(xiàn)故障，其可靠性恒為其可靠性恒為l l。反之，如果運行剖面不包含。反之，如果運行剖面不包含G G中的輸入，中的輸入，則每一輸入情況下均出現(xiàn)故障，如果沒有容錯措施則則每一輸入情況下均出現(xiàn)故障，如果沒有容錯措施則R=0R=0。u軟件規(guī)模。軟件規(guī)模。隨著軟件規(guī)模的增大，軟件可靠性問題愈顯突隨著軟件規(guī)模的增大，軟件可靠性問題愈顯突出。在我們考慮軟件可靠性問題時，軟件一般是指中型以出。在我們考慮軟件可靠性問題時，軟件一般是指中型以上軟件上軟件

18、(4000-5000(4000-5000條以上語句條以上語句) )，這時可靠性問題難以對付。，這時可靠性問題難以對付。軟件工程實踐的一個側面可以反映這一點，即單元測試一軟件工程實踐的一個側面可以反映這一點，即單元測試一般由編程人員本人進行，而綜合測試則需獨立的測試人員。般由編程人員本人進行，而綜合測試則需獨立的測試人員。軟件可靠性增長模型也主要應用于綜合測試階段。軟件可靠性增長模型也主要應用于綜合測試階段。u軟件內部結構。軟件內部結構。軟件內部結構一般比較復雜，且動態(tài)變化，軟件內部結構一般比較復雜，且動態(tài)變化，對可靠性的影響也不甚清楚。但總的說來，結構越復雜，對可靠性的影響也不甚清楚。但總的說

19、來，結構越復雜，軟件復雜度越高，內含缺陷數(shù)越大，因而軟件可靠度越低。軟件復雜度越高，內含缺陷數(shù)越大，因而軟件可靠度越低。u軟件可靠性設計技術。軟件可靠性設計技術。關于軟件可靠性設計技術的外延并關于軟件可靠性設計技術的外延并不明確，但一般是指軟件設計階段中采用的用以保證和提不明確，但一般是指軟件設計階段中采用的用以保證和提高軟件可靠性為主要目標的軟件技術。高軟件可靠性為主要目標的軟件技術。u軟件可靠性測試軟件可靠性測試。研究表明，軟件測試方法與資源投入對。研究表明，軟件測試方法與資源投入對軟件可靠性有不可忽視的影響。軟件可靠性有不可忽視的影響。u軟件可靠性管理軟件可靠性管理。軟件可靠性管理旨在系

20、統(tǒng)管理軟件生存。軟件可靠性管理旨在系統(tǒng)管理軟件生存期各階段的可靠性活動，使之系統(tǒng)化、規(guī)范化、一體化，期各階段的可靠性活動，使之系統(tǒng)化、規(guī)范化、一體化，這樣就可以避免許多人為錯誤，以提高軟件可靠性。這樣就可以避免許多人為錯誤，以提高軟件可靠性。u軟件開發(fā)人員能力和經驗軟件開發(fā)人員能力和經驗。顯然，軟件開發(fā)人員。顯然，軟件開發(fā)人員( (包括測包括測試人員試人員) )的能力愈強，經驗愈豐富，所犯錯誤便可能愈少，的能力愈強，經驗愈豐富，所犯錯誤便可能愈少，所得軟件產品質量愈高，相應的可靠性也愈高。所得軟件產品質量愈高，相應的可靠性也愈高。u軟件開發(fā)方法軟件開發(fā)方法。軟件工程表明，開發(fā)方法對軟件可靠性有

21、。軟件工程表明，開發(fā)方法對軟件可靠性有顯著影響。與非結構化方法比較，結構化方法可以明顯減顯著影響。與非結構化方法比較，結構化方法可以明顯減少軟件缺陷數(shù)。少軟件缺陷數(shù)。u軟件開發(fā)環(huán)境軟件開發(fā)環(huán)境。研究表明，程序語言對軟件可靠性有影響。研究表明，程序語言對軟件可靠性有影響。譬如，結構化語言譬如，結構化語言AdaAda優(yōu)于優(yōu)于FortranFortran語言，而軟件測試工具語言，而軟件測試工具優(yōu)劣則影響測試效果。優(yōu)劣則影響測試效果。軟件可靠性定義軟件可靠性定義 （1 1）沿用硬件可靠性的定義沿用硬件可靠性的定義，即軟件可靠性，即軟件可靠性是指軟件在所規(guī)定的環(huán)境條件下、規(guī)定的時間內，是指軟件在所規(guī)定的

22、環(huán)境條件下、規(guī)定的時間內，一直能按要求和規(guī)格說明正確地完成任務的性質。一直能按要求和規(guī)格說明正確地完成任務的性質。這一性質的概率這一性質的概率( (定量定量) )描述也稱為可靠度，可用描述也稱為可靠度，可用可靠度函數(shù)表示?？梢娺@是一種面向時間的定義可靠度函數(shù)表示?？梢娺@是一種面向時間的定義方法，它沒有考慮故障的原因、軟件產品故障的方法，它沒有考慮故障的原因、軟件產品故障的特點及軟件產品的特殊性。特點及軟件產品的特殊性。 （2 2）軟件可靠性定義為：軟件可靠性定義為：假定輸入和硬件都假定輸入和硬件都沒有錯誤，對于一組輸入數(shù)據，軟件能正常運行沒有錯誤，對于一組輸入數(shù)據，軟件能正常運行不發(fā)生錯誤的概

23、率。這是一種面向數(shù)據的定義方不發(fā)生錯誤的概率。這是一種面向數(shù)據的定義方法。法。建議推薦建議推薦軟件可靠性技術軟件可靠性技術|軟件避錯技術軟件避錯技術|軟件容錯技術軟件容錯技術|軟件測試技術軟件測試技術|軟件預計技術軟件預計技術軟件避錯技術軟件避錯技術u軟件設計技術軟件設計技術（1 1） 自頂向下設計自頂向下設計(TDDTop-Down Design(TDDTop-Down Design) )是把系統(tǒng)功是把系統(tǒng)功能最抽象描述作為最高層次，并從它出發(fā)，把系統(tǒng)分成能最抽象描述作為最高層次，并從它出發(fā)，把系統(tǒng)分成分級的分系統(tǒng)，稱為層分級的分系統(tǒng)，稱為層(Levels)(Levels)。（2 2）數(shù)據結

24、構設計法數(shù)據結構設計法。主要注意力集中在信息結構和信息。主要注意力集中在信息結構和信息流動上，而不是過于集中在所要完成的功能上。如定義流動上，而不是過于集中在所要完成的功能上。如定義數(shù)據結構、標識數(shù)據流、定義能使數(shù)據流動的操作等。數(shù)據結構、標識數(shù)據流、定義能使數(shù)據流動的操作等。為了防止數(shù)據沖突，須引進中間文件，來實現(xiàn)輸入數(shù)據為了防止數(shù)據沖突，須引進中間文件，來實現(xiàn)輸入數(shù)據與輸出數(shù)據的結構轉換處理。與輸出數(shù)據的結構轉換處理。（3 3）高級軟件）高級軟件(HOSHigher Order Software)(HOSHigher Order Software)方法論。這方法論。這是一種詳細說明和開發(fā)可

25、靠軟件系統(tǒng)的方法論，是完全是一種詳細說明和開發(fā)可靠軟件系統(tǒng)的方法論，是完全面向系統(tǒng)而不是面向傳統(tǒng)軟件的。高級軟件的基本出發(fā)面向系統(tǒng)而不是面向傳統(tǒng)軟件的。高級軟件的基本出發(fā)點是把一個給定的系統(tǒng)看成一個點是把一個給定的系統(tǒng)看成一個“軟件軟件”，并可用數(shù)學，并可用數(shù)學模型模型( (即函數(shù)即函數(shù)) )來描述。來描述。19741974年年NASANASA將高級軟件首次在宇將高級軟件首次在宇宙飛船模型軟件開發(fā)中應用，現(xiàn)已用于開發(fā)宇宙飛船的宙飛船模型軟件開發(fā)中應用，現(xiàn)已用于開發(fā)宇宙飛船的飛行軟件中。飛行軟件中。u軟件實現(xiàn)技術軟件實現(xiàn)技術（1 1）自頂向下）自頂向下 (Top-Down Programming

26、(Top-Down Programming，TDP)TDP)和由底向上程和由底向上程序設計序設計(BottomUp Programming(BottomUp Programming，BUP)BUP)方法。方法。（2 2）模塊程序設計）模塊程序設計(MPModular Programming)(MPModular Programming)的思想是把整的思想是把整個軟件系統(tǒng)分解成為一系列獨立的代碼段來實現(xiàn)軟件的。每個軟件系統(tǒng)分解成為一系列獨立的代碼段來實現(xiàn)軟件的。每段就叫一個模塊，它常常是一個小型的、面向功能性的子程段就叫一個模塊，它常常是一個小型的、面向功能性的子程序或函數(shù)，每個模塊用來表示與某

27、個功能有關的一個或多個序或函數(shù)，每個模塊用來表示與某個功能有關的一個或多個任務，模塊之間的數(shù)據通信靠接口來完成。模塊之間有一定任務，模塊之間的數(shù)據通信靠接口來完成。模塊之間有一定的獨立性，可由不同的程序員編程來加快實現(xiàn)的進程。的獨立性，可由不同的程序員編程來加快實現(xiàn)的進程。（3 3）逐步求精程序設計）逐步求精程序設計 (SWRPStep Wise Refinement (SWRPStep Wise Refinement Programming)Programming)的基本思想是：對于一個復雜的問題，先解決的基本思想是：對于一個復雜的問題，先解決容易部分容易部分( (給出較粗的框圖給出較粗的框

28、圖) )，接著對剩下的問題再作更細的，接著對剩下的問題再作更細的分解，如此反復，直到所有問題都解決為止。分解，如此反復，直到所有問題都解決為止。（4 4）結構化程序設計）結構化程序設計(SPStructure Programming)(SPStructure Programming)概念是強概念是強調從程序結構和風格上來研究程序設計。結構化程序設計嚴調從程序結構和風格上來研究程序設計。結構化程序設計嚴格說不是一種程序設計的方法，而是編程的一個標準或風格。格說不是一種程序設計的方法，而是編程的一個標準或風格。軟件避錯技術的應用軟件避錯技術的應用 在在“美洲豹美洲豹”(Jaguar)飛機的數(shù)字式電

29、傳飛機的數(shù)字式電傳飛行控制系統(tǒng)的飛控軟件中飛行控制系統(tǒng)的飛控軟件中 系統(tǒng)啟動 監(jiān)控器復位 子系統(tǒng) 1 模塊 1 駐 模塊 2 留 子系統(tǒng) 2 模塊 3 程 序 子系統(tǒng) 7 模塊 6 結束軟件容錯技術軟件容錯技術uN文本技術文本技術 表 決 程 序 被激活 比 激 比 激 比 激 較 活 較 活 較 活非激活狀態(tài) 等待狀態(tài) 向 命 向 命 向 命 量 令 量 令 量 令 滿足 到下 終止 一個 被 檢測點 1 檢測點 1 檢測點 1 條件 交叉 啟 文 文 文 檢測點 動 本 本 本 1 2 N 運行狀態(tài) 檢測點 k 檢測點 k 檢測點 kN文本特點文本特點 獨立設計；獨立設計； 盡量采用不同的

30、算法和數(shù)據結構；盡量采用不同的算法和數(shù)據結構； 不同的語言；不同的語言； 不同的程序員來編寫。不同的程序員來編寫。 每個文本程序中設置一個或多個交叉每個文本程序中設置一個或多個交叉檢測點，每當文本執(zhí)行到一個交叉檢測點檢測點，每當文本執(zhí)行到一個交叉檢測點時便產生一個比較向量，并將比較向量交時便產生一個比較向量，并將比較向量交給表決程序，自己則進入等待狀態(tài)，等待給表決程序，自己則進入等待狀態(tài)，等待來自表決驅動的指令。來自表決驅動的指令。比較向量比較向量 比較向量比較向量，用于比較的目的。，用于比較的目的。 比較狀態(tài)標志比較狀態(tài)標志，用來指示在產生比，用來指示在產生比較向量的過程中是否發(fā)生了特殊事較

31、向量的過程中是否發(fā)生了特殊事件，譬如監(jiān)測到例外條件，遇到文件，譬如監(jiān)測到例外條件，遇到文本結尾等。本結尾等。表決程序表決程序 激活各文本使之投入運行；激活各文本使之投入運行； 接受來自各文本的比較向量；接受來自各文本的比較向量； 實現(xiàn)各文本同步；實現(xiàn)各文本同步； 比較各文本的比較向量；比較各文本的比較向量； 處理比較結果。處理比較結果。 恢復塊技術恢復塊技術 狀態(tài)保護 狀態(tài)恢復 運行 備份塊替代 有 接收測試 有無備份 通過 無 狀態(tài)釋放 錯誤處理 軟件容錯技術的應用軟件容錯技術的應用F8縱向數(shù)字縱向數(shù)字飛行控制系統(tǒng)飛行控制系統(tǒng)在各余度硬件在各余度硬件通道中采用了通道中采用了非相似軟件，非相似

32、軟件，即即“恢復塊恢復塊”，也就是也就是F8DFBW駐留駐留備份軟件備份軟件(Resident Backup Software簡稱簡稱REBUS) 軟件測試技術軟件測試技術u定義：定義： 軟件測試是為了發(fā)現(xiàn)錯誤而執(zhí)行軟軟件測試是為了發(fā)現(xiàn)錯誤而執(zhí)行軟件的過程。或者說軟件測試是根據軟件的過程。或者說軟件測試是根據軟件開發(fā)各階段的說明和程序內部結構，件開發(fā)各階段的說明和程序內部結構，精心設計的測試用例精心設計的測試用例( (測試用例測試用例) ) 而執(zhí)而執(zhí)行軟件及發(fā)現(xiàn)錯誤的過程。行軟件及發(fā)現(xiàn)錯誤的過程。u軟件測試的原則軟件測試的原則（1 1）好的測試用例能使從程序中查出以）好的測試用例能使從程序中查

33、出以前未發(fā)現(xiàn)的錯誤的可能性增大。前未發(fā)現(xiàn)的錯誤的可能性增大。 （2 2）能查出先前未發(fā)現(xiàn)的錯誤的測試是）能查出先前未發(fā)現(xiàn)的錯誤的測試是成功的測試。成功的測試。（3 3）盡量避免程序員及程序設計機構測）盡量避免程序員及程序設計機構測試自己的程序，因為軟件測試中人的試自己的程序，因為軟件測試中人的心理狀態(tài)是重要的問題之一。心理狀態(tài)是重要的問題之一。軟件測試的一般步驟軟件測試的一般步驟軟件測試方法軟件測試方法（1 1）靜態(tài)測試。）靜態(tài)測試。不執(zhí)行程序而只是檢查源程序的結不執(zhí)行程序而只是檢查源程序的結構、文法和過程間的接口是否有錯的測試稱為靜構、文法和過程間的接口是否有錯的測試稱為靜態(tài)測試。程序編譯是

34、靜態(tài)測試的一種方法，還有態(tài)測試。程序編譯是靜態(tài)測試的一種方法，還有許多其它測試工具如審查會等人工測試法。許多其它測試工具如審查會等人工測試法。 （2 2）動態(tài)測試。）動態(tài)測試。使程序在某種控制環(huán)境中運行，使程序在某種控制環(huán)境中運行，在完成所要求的功能的同時，檢查是否存在不必在完成所要求的功能的同時，檢查是否存在不必要的功能的測試稱為動態(tài)測試。動態(tài)測試對要求、要的功能的測試稱為動態(tài)測試。動態(tài)測試對要求、數(shù)據、結果和內部程序工作狀態(tài)四部份的對應關數(shù)據、結果和內部程序工作狀態(tài)四部份的對應關系進行準確選擇和測定。動態(tài)測試也稱程序測試，系進行準確選擇和測定。動態(tài)測試也稱程序測試，是通過測試用例執(zhí)行程序發(fā)

35、現(xiàn)錯誤的過程。是通過測試用例執(zhí)行程序發(fā)現(xiàn)錯誤的過程。測試策略測試策略u“黑盒黑盒”測試法測試法 黑盒測試又稱數(shù)據驅動黑盒測試又稱數(shù)據驅動( (輸入輸出驅動輸入輸出驅動) )測試方案。在應用這種方案時，測試者把測試方案。在應用這種方案時，測試者把程序看成一個黑盒，即完全不考慮程序內程序看成一個黑盒，即完全不考慮程序內部結構和內部特性，僅按軟件說明書來測部結構和內部特性，僅按軟件說明書來測試程序所有可能的輸入情況。如果將所有試程序所有可能的輸入情況。如果將所有輸入情況都測試一遍這將是一個天文數(shù)字。輸入情況都測試一遍這將是一個天文數(shù)字。u“白盒白盒”測試法測試法 白盒測試法又稱邏輯驅動測試。它允許人

36、白盒測試法又稱邏輯驅動測試。它允許人們檢查程序的內部結構。使用這一方案時，們檢查程序的內部結構。使用這一方案時，測試者從檢查程序的邏輯著手，按程序結測試者從檢查程序的邏輯著手，按程序結構測試，即測試程序的每一條路徑而不考構測試，即測試程序的每一條路徑而不考慮軟件說明書的要求。顯然，獨立路徑也慮軟件說明書的要求。顯然，獨立路徑也是一個天文數(shù)字。是一個天文數(shù)字。 雖然以上兩種極端方案都不可行，但它雖然以上兩種極端方案都不可行，但它卻給測試提供了考慮問題的方向。即應該卻給測試提供了考慮問題的方向。即應該把程序外部功能和內部結構結合起來，形把程序外部功能和內部結構結合起來，形成新的測試方案。成新的測試

37、方案。測試用例設計測試用例設計（1 1）等價劃分。）等價劃分。把輸入域作等價劃分，使把輸入域作等價劃分，使所設計的測試用例具有代表性，即一個測所設計的測試用例具有代表性，即一個測試用例可以代表與其等價的其它測試用例。試用例可以代表與其等價的其它測試用例。（2 2）邊值分析）邊值分析。邊值分析不是簡單地等價。邊值分析不是簡單地等價類中找一個測試用例，而需經邊值分析，類中找一個測試用例，而需經邊值分析，并且不僅分析輸入的邊值還分析輸出的邊并且不僅分析輸入的邊值還分析輸出的邊值。值。黑盒方法黑盒方法等價劃分，邊值分析，因果圖，猜測錯誤等價劃分，邊值分析，因果圖，猜測錯誤白盒方法白盒方法語句覆蓋，判定

38、覆蓋，條件覆蓋，判定語句覆蓋，判定覆蓋，條件覆蓋，判定/ /條件覆蓋，多重條件覆蓋條件覆蓋，多重條件覆蓋 （3 3）因果圖。）因果圖。因果圖是一種用于設計測試因果圖是一種用于設計測試用例的圖形工具，它對用自然語言書寫的用例的圖形工具，它對用自然語言書寫的需求或設計規(guī)范的內容進行分析，找出輸需求或設計規(guī)范的內容進行分析，找出輸入入( (因因) )與輸出與輸出( (果果) )及其間的邏輯關系，并及其間的邏輯關系，并由圖的形式表示出來。通過布爾邏輯吸收、由圖的形式表示出來。通過布爾邏輯吸收、合并，刪去低效率的測試用例，最后將因合并，刪去低效率的測試用例，最后將因果圖轉換成判定表，將判定表中的每一列果

39、圖轉換成判定表，將判定表中的每一列轉換成高效率的測試用例。轉換成高效率的測試用例。IBMIBM公司有幾個公司有幾個這樣的程序專利。這樣的程序專利。（4 4）猜測錯誤。）猜測錯誤。憑直覺和經驗列出可能憑直覺和經驗列出可能有的錯誤和易錯情況表，并寫出測試有的錯誤和易錯情況表，并寫出測試用例。用例。（5 5）語句覆蓋。）語句覆蓋。選擇足夠的測試用例使選擇足夠的測試用例使程序中的每條語句至少被執(zhí)行一次。程序中的每條語句至少被執(zhí)行一次。這是一個必要但不充分的準則。這是一個必要但不充分的準則。（6 6）判定覆蓋。）判定覆蓋。要求程序中的每一個分要求程序中的每一個分支語句至少都通過一次，即每一條判支語句至少

40、都通過一次，即每一條判定語句的真值執(zhí)行一次，假值也執(zhí)行定語句的真值執(zhí)行一次，假值也執(zhí)行一次。它較語句覆鍵的邏輯覆蓋好些，一次。它較語句覆鍵的邏輯覆蓋好些，但同樣是不充分的。但同樣是不充分的。（7 7）條件覆蓋。）條件覆蓋。執(zhí)行所設計的測試用例，使得判執(zhí)行所設計的測試用例，使得判定中的每個條件都獲得各種可能的結果。它較判定中的每個條件都獲得各種可能的結果。它較判定覆蓋準則要好，但不能替代它。定覆蓋準則要好，但不能替代它。（8 8）判定條件覆蓋。）判定條件覆蓋。要求設計足夠的測試用例，要求設計足夠的測試用例，使得每個判定中每個條件的所有可能結果至少出使得每個判定中每個條件的所有可能結果至少出現(xiàn)一次

41、，每個判定本身所有可能也至少出現(xiàn)一次，現(xiàn)一次，每個判定本身所有可能也至少出現(xiàn)一次，同時程序的每個入口點至少要進入一次。同時程序的每個入口點至少要進入一次。（9 9）多重條件覆蓋。）多重條件覆蓋。執(zhí)行所設計的調試情況，使執(zhí)行所設計的調試情況，使得每個判定中條件結果的所有可能組合至少出現(xiàn)得每個判定中條件結果的所有可能組合至少出現(xiàn)一次，程序所有入口都至少進入一次，顯然這是一次，程序所有入口都至少進入一次，顯然這是一種最強的邏輯覆蓋準則。一種最強的邏輯覆蓋準則。路徑覆蓋路徑覆蓋測試方法測試方法u模塊獨立測試模塊獨立測試 模塊獨立測試或程序單元測試是指測試程序模塊獨立測試或程序單元測試是指測試程序中的單

42、個子程序或過程的測試中的單個子程序或過程的測試( (以下簡稱模塊測以下簡稱模塊測試試) )。 模塊測試的目的是對模塊的功能與模塊的性模塊測試的目的是對模塊的功能與模塊的性能規(guī)范或接口規(guī)范進行比較，以揭示模塊與規(guī)范能規(guī)范或接口規(guī)范進行比較，以揭示模塊與規(guī)范的矛盾。模塊測試主要是采用白盒測試方法。利的矛盾。模塊測試主要是采用白盒測試方法。利用一種或多種白盒測試法對模塊的邏輯結構進行用一種或多種白盒測試法對模塊的邏輯結構進行分析，得到一些測試用例，然后根據模塊規(guī)范再分析，得到一些測試用例，然后根據模塊規(guī)范再用黑盒方法對原有的測試用例加以補充。用黑盒方法對原有的測試用例加以補充。u綜合測試綜合測試 綜

43、合測試是測試程序模塊間接口的過程，綜合測試是測試程序模塊間接口的過程，以發(fā)現(xiàn)模塊間相互作用出現(xiàn)的問題。綜合以發(fā)現(xiàn)模塊間相互作用出現(xiàn)的問題。綜合測試模塊組裝方法有自頂向下、自底向上測試模塊組裝方法有自頂向下、自底向上及混合測試等方法。及混合測試等方法。 面向對象的軟件測試面向對象的軟件測試 傳統(tǒng)的軟件測試以結構化軟件開發(fā)為主，傳統(tǒng)的軟件測試以結構化軟件開發(fā)為主，在理論和方法上已經取得豐碩成果，但自在理論和方法上已經取得豐碩成果，但自2020世紀世紀80 80 年代中后期以來，面向對象軟件年代中后期以來，面向對象軟件開發(fā)技術迅速發(fā)展開發(fā)技術迅速發(fā)展. . 盡管面向對象技術的基本思想保證了軟件盡管面

44、向對象技術的基本思想保證了軟件有更高的質量，但因為無論采用什么樣的有更高的質量，但因為無論采用什么樣的編程技術，編程人員的錯誤都是不可避免編程技術，編程人員的錯誤都是不可避免的，而由于面向對象技術開發(fā)的軟件代碼的，而由于面向對象技術開發(fā)的軟件代碼重用率高，更需要嚴格測試，以避免錯誤重用率高，更需要嚴格測試，以避免錯誤的繁衍。的繁衍。面向對象軟件語言特征對測試影響面向對象軟件語言特征對測試影響l 封裝性對測試的影響封裝性對測試的影響l 繼承性對測試的影響繼承性對測試的影響l 多態(tài)和動態(tài)綁定對測試的影響多態(tài)和動態(tài)綁定對測試的影響UML（Unified Modeling Language）已成）已成

45、為面向對象分析與設計的標準建模語言。為面向對象分析與設計的標準建模語言。軟件建模的區(qū)別軟件建模的區(qū)別 傳統(tǒng)軟件開發(fā)所采傳統(tǒng)軟件開發(fā)所采用的是從過程的角用的是從過程的角度即結構化方法來度即結構化方法來建立模型，它采用建立模型，它采用了模塊分解和功能了模塊分解和功能抽象的手段，開發(fā)抽象的手段，開發(fā)人員把精力集中在人員把精力集中在控制流程和算法上?？刂屏鞒毯退惴ㄉ?。 面向對象軟件開發(fā)面向對象軟件開發(fā)利用對象、屬性和利用對象、屬性和操作作為主要的建操作作為主要的建模成分對問題進行模成分對問題進行建模。它從需求分建模。它從需求分析入手，開發(fā)人員析入手，開發(fā)人員可以把精力集中在可以把精力集中在所研究的問題

46、域上所研究的問題域上 其軟件模型其軟件模型的改變的改變軟件測試層次軟件測試層次傳統(tǒng)軟件測試層次傳統(tǒng)軟件測試層次面向對象軟件測試層次面向對象軟件測試層次單元測試單元測試類測試類測試集成測試集成測試類簇類簇( (交互交互) )測試測試系統(tǒng)測試系統(tǒng)測試系統(tǒng)測試系統(tǒng)測試類測試與傳統(tǒng)的單元測試區(qū)別類測試與傳統(tǒng)的單元測試區(qū)別輸入數(shù)據輸入數(shù)據處理處理輸出數(shù)據輸出數(shù)據傳統(tǒng)測試模傳統(tǒng)測試模型型輸入數(shù)據輸入數(shù)據處理處理輸出數(shù)據輸出數(shù)據類的測試模類的測試模型型初始狀態(tài)初始狀態(tài)結束狀態(tài)結束狀態(tài)類測試的執(zhí)行順序類測試的執(zhí)行順序類簇測試類簇測試類簇測試又稱為類的交互測試，它主要考類簇測試又稱為類的交互測試，它主要考察一組

47、協(xié)同操作的類之間的相互作用。察一組協(xié)同操作的類之間的相互作用。系統(tǒng)測試是檢驗系統(tǒng)是否符合要求系統(tǒng)測試是檢驗系統(tǒng)是否符合要求系統(tǒng)測試系統(tǒng)測試面向對象軟件的系統(tǒng)測試與傳統(tǒng)的系統(tǒng)面向對象軟件的系統(tǒng)測試與傳統(tǒng)的系統(tǒng)測試沒有太大的區(qū)別，僅僅是測試用例測試沒有太大的區(qū)別，僅僅是測試用例的形式不同有所而已。的形式不同有所而已。 實例模型測試實例模型測試-撞球游戲撞球游戲 在軟件開發(fā)的前期，我們可以對軟件進行在軟件開發(fā)的前期，我們可以對軟件進行建模，這使得我們可以在編寫具體代碼之前建模，這使得我們可以在編寫具體代碼之前先對軟件的模型進行測試。對分析和設計模先對軟件的模型進行測試。對分析和設計模型進行測試的好處

48、在于：型進行測試的好處在于：v測試用例可以更早地確定。測試用例可以更早地確定。v漏洞可在開發(fā)過程中早期檢測出來，從而節(jié)漏洞可在開發(fā)過程中早期檢測出來，從而節(jié)省了時間、金錢和精力。省了時間、金錢和精力。v對代碼測試有指導意義，使之有的放矢對代碼測試有指導意義，使之有的放矢撞球游戲的模型測試撞球游戲的模型測試模型測試過程模型測試過程v用例建模用例建模v類建模類建模v動態(tài)和交互分析動態(tài)和交互分析用例建模用例建模 通過通過UML的用例圖（的用例圖（use-case diagram）和各種情景來進行用例建模。和各種情景來進行用例建模。用例模型審查標準用例模型審查標準標準標準對需求的說明對需求的說明完整性

49、完整性 使用用例描述了一個合格產品所需的所有使用用例描述了一個合格產品所需的所有功能。功能。正確性正確性 每個用例都要精確地描述了一個需求每個用例都要精確地描述了一個需求一致性一致性 需求之間沒有相互矛盾的地方需求之間沒有相互矛盾的地方類建模類建模用用UML類圖（類圖（class diagram）進行類建模。）進行類建模。 Ballxp類是游戲的核心類，游戲中的數(shù)據運算、類是游戲的核心類，游戲中的數(shù)據運算、情形判定和圖形繪制都是通過它來完成的。情形判定和圖形繪制都是通過它來完成的。 比如為了實現(xiàn)游戲的基本功能，比如為了實現(xiàn)游戲的基本功能，BallxpBallxp類類中必須包含有小球、磚塊和木棍

50、的狀態(tài)信中必須包含有小球、磚塊和木棍的狀態(tài)信息，必須有數(shù)據更新、畫球、畫磚、畫木息，必須有數(shù)據更新、畫球、畫磚、畫木棍的功能。為了響應游戲者的鼠標移動，棍的功能。為了響應游戲者的鼠標移動，又要添加接受鼠標信息的接口函數(shù)。為了又要添加接受鼠標信息的接口函數(shù)。為了應對小球在不同區(qū)域的碰撞，還要對當前應對小球在不同區(qū)域的碰撞，還要對當前的小球位置進行識別。的小球位置進行識別。動態(tài)和交互分析動態(tài)和交互分析 UML中可用狀態(tài)圖和順序圖來表述，它可中可用狀態(tài)圖和順序圖來表述，它可以方便我們分析軟件實際運行時的動態(tài)過以方便我們分析軟件實際運行時的動態(tài)過程。程。撞球游戲的順序圖撞球游戲的順序圖 通過上面的一系

51、列模型和分析，我們可以通過上面的一系列模型和分析，我們可以審查軟件在設計上的疏漏。審查軟件在設計上的疏漏。 要盡量在編碼開始前對設計充分檢查，否要盡量在編碼開始前對設計充分檢查，否則，在后期修復錯誤的代價將相當大。這則，在后期修復錯誤的代價將相當大。這是模型測試的意義所在。是模型測試的意義所在。軟件可靠性預計軟件可靠性預計 軟件可靠性預計：軟件可靠性預計：由模塊可靠性由模塊可靠性軟件系軟件系統(tǒng)的可靠性統(tǒng)的可靠性 軟件可靠性預計的三個要素：軟件可靠性預計的三個要素：模型、數(shù)據模型、數(shù)據和和參數(shù)估計參數(shù)估計 軟件可靠性預計和可靠性測試的關系：軟件可靠性預計和可靠性測試的關系： 軟件可靠性測試為可靠

52、性預計提供數(shù)據軟件可靠性測試為可靠性預計提供數(shù)據 軟件可靠性預計給出什么時候停止測試軟件可靠性預計給出什么時候停止測試軟件可靠性模型概述軟件可靠性模型概述 正因為軟件可靠性有著舉足輕重的影響，在軟件開正因為軟件可靠性有著舉足輕重的影響，在軟件開發(fā)階段結束之前需要估計和預測軟件可靠性。發(fā)階段結束之前需要估計和預測軟件可靠性。 軟件可靠性模型是分析和評估軟件可靠性的基礎。軟件可靠性模型是分析和評估軟件可靠性的基礎。 軟件可靠性模型的目的軟件可靠性模型的目的是使用某種隨機過程將軟件是使用某種隨機過程將軟件可靠性或其相關量表示成時間和軟件產品特性或者可靠性或其相關量表示成時間和軟件產品特性或者開發(fā)過程

53、的函數(shù)。開發(fā)過程的函數(shù)。 軟件可靠性建模的基本思路軟件可靠性建模的基本思路是用過去的失效數(shù)據建是用過去的失效數(shù)據建立可靠性模型，然后用所建立起來的模型估計現(xiàn)在立可靠性模型，然后用所建立起來的模型估計現(xiàn)在的軟件可靠性和預測將來的軟件可靠性。的軟件可靠性和預測將來的軟件可靠性。 對于軟件的模塊、子系統(tǒng)、系統(tǒng)都可以應用軟件可對于軟件的模塊、子系統(tǒng)、系統(tǒng)都可以應用軟件可靠性模型。靠性模型。 最早的模型是最早的模型是H.K.Weiss于于1956年提出來的一系年提出來的一系列公式，但由于它們過于復雜而對后來的建模列公式，但由于它們過于復雜而對后來的建模幾乎沒有影響；幾乎沒有影響； 最早的建?；顒涌勺匪莸?/p>

54、最早的建?；顒涌勺匪莸?967年年Hudson的工的工作，他當時以隨機生滅過程描述軟件缺陷的引作，他當時以隨機生滅過程描述軟件缺陷的引入和剔除過程；入和剔除過程； 進入進入20世紀世紀70年代后年代后，Jelinski、Moranda、Halstead、Littlewood、Verrall、Musa等軟件可等軟件可靠性建模的先驅們從不同的角度基于不同的假靠性建模的先驅們從不同的角度基于不同的假設各自發(fā)表了大量的模型，并就各自模型的優(yōu)設各自發(fā)表了大量的模型，并就各自模型的優(yōu)越性進行了長時間的爭論。越性進行了長時間的爭論。 之后，在先驅者的工作成果基礎上，經過更之后，在先驅者的工作成果基礎上，經過

55、更多軟件可靠性工作者多軟件可靠性工作者30余年來的努力，軟件余年來的努力，軟件可靠性模型到目前為止已經出現(xiàn)上百種；可靠性模型到目前為止已經出現(xiàn)上百種； 現(xiàn)有的模型幾乎將目前數(shù)理統(tǒng)計中常用的隨現(xiàn)有的模型幾乎將目前數(shù)理統(tǒng)計中常用的隨機分布都用到了；機分布都用到了； 最為常見且比較具有代表意義的模型不下最為常見且比較具有代表意義的模型不下20個，對軟件可靠性的度量、評估和預測起到個，對軟件可靠性的度量、評估和預測起到了積極的作用；了積極的作用； 與此同時，軟件可靠性工作者不斷引入各種與此同時，軟件可靠性工作者不斷引入各種先進的思想，力圖克服各種假設對模型使用先進的思想，力圖克服各種假設對模型使用造成

56、的障礙。造成的障礙。軟件可靠性模型分類軟件可靠性模型分類 軟件可靠性模型主要分為軟件可靠性模型主要分為經驗模型和解析經驗模型和解析模型，普遍使用的是解析模型。模型，普遍使用的是解析模型。 根據不同的準則，可對解析模型再作分類：根據不同的準則，可對解析模型再作分類： （1 1）根據建模對象的不同分類，如面向數(shù)）根據建模對象的不同分類，如面向數(shù)據、面向錯誤數(shù)和面向時間的模型；據、面向錯誤數(shù)和面向時間的模型； （2 2）根據模型假設的不同分類；）根據模型假設的不同分類； （3 3）根據模型適用階段的不同分類，如適）根據模型適用階段的不同分類，如適用于測試階段的增長模型和適用于確認階段用于測試階段的增

57、長模型和適用于確認階段的確認模型；的確認模型； （4 4）根據模型使用的數(shù)學工具不同分類，）根據模型使用的數(shù)學工具不同分類，分為統(tǒng)計模型和概率模型。分為統(tǒng)計模型和概率模型。模型具體類型模型具體類型 根據作為建模對象的數(shù)據或信息是否與時間根據作為建模對象的數(shù)據或信息是否與時間相關，軟件可靠性模型可分為相關，軟件可靠性模型可分為靜態(tài)模型和動靜態(tài)模型和動態(tài)模型。態(tài)模型。 靜態(tài)模型靜態(tài)模型可進一步分為：缺陷播種模型、基可進一步分為：缺陷播種模型、基于數(shù)據域模型和經驗模型。于數(shù)據域模型和經驗模型。 動態(tài)模型可動態(tài)模型可進一步分為微觀模型和宏觀模型，進一步分為微觀模型和宏觀模型，前者考慮軟件內部的特征量如

58、語句數(shù)，一定前者考慮軟件內部的特征量如語句數(shù)，一定程度上視軟件為白箱；后者不考慮軟件內部程度上視軟件為白箱；后者不考慮軟件內部結構或特征量，視軟件為黑箱。結構或特征量，視軟件為黑箱。軟件可靠性模型軟件可靠性模型模型模型動動 態(tài)態(tài)靜靜 態(tài)態(tài)宏宏 觀觀微觀微觀模型模型缺陷播種缺陷播種模型模型數(shù)數(shù) 據據 域域模型模型經經 驗驗模模 型型故障時間故障時間故障計數(shù)故障計數(shù)Jelinski-MorandaSchick-WolvertonMoranda幾何幾何Musa執(zhí)行時間執(zhí)行時間Littlewood-VerrallGoel-Okumoto NHPPMoranda 幾何幾何PossionShooman超幾

59、何超幾何NeisonHalstead表中表示隸屬關系JelinskiMoranda（JM）模型）模型 假設：假設：（1 1）軟件最初的錯誤數(shù)）軟件最初的錯誤數(shù)N N為常值，用表示在第為常值，用表示在第(i-1)(i-1)個錯誤被改正后，軟件投入運行至第次個錯誤被改正后，軟件投入運行至第次i i故障發(fā)生故障發(fā)生前這個階段的時間，且故障間隔時間是統(tǒng)計獨立的。前這個階段的時間，且故障間隔時間是統(tǒng)計獨立的。（2 2）在兩個相繼故障構成的時間間隔內，軟件的故）在兩個相繼故障構成的時間間隔內，軟件的故障率為常數(shù)，其大小正比于軟件中的殘存錯誤數(shù)。障率為常數(shù)，其大小正比于軟件中的殘存錯誤數(shù)。 （3 3）每個軟

60、件錯誤一經發(fā)現(xiàn)，立即被修正，且不考）每個軟件錯誤一經發(fā)現(xiàn)，立即被修正，且不考慮修改錯誤的時間，也不產生新的錯誤。慮修改錯誤的時間，也不產生新的錯誤。（4 4）每次故障后總有并僅有一個錯誤被排除，因此）每次故障后總有并僅有一個錯誤被排除，因此系統(tǒng)的故障率是階梯式下降的。系統(tǒng)的故障率是階梯式下降的。 按上述假設得出的軟件系統(tǒng)故障的密度函數(shù)為：按上述假設得出的軟件系統(tǒng)故障的密度函數(shù)為： 故障率為：故障率為： 可靠度為：可靠度為： 參數(shù)估計參數(shù)估計 建立極大似然方程（第七章）：建立極大似然方程（第七章）：運用極大似然方法：運用極大似然方法：), 2 , 1 (,)(Nietfiitii1iNitiNietR1)(ninix