軟體測試與可靠性評估方法研究

摘要：隨著科學技術的飛速發展，軟體的功能越來越強大，軟體的複雜性也越來越高，從而大大增加了軟體測試與可靠性評估的難度。為了保證一個軟體系統的品質，有必要針對軟體的測試與可靠性評估方法進行專門地研究。本文就是針對這一領域所做的一些研究。

　　一.軟體測試的定義

　　軟體測試（Software testing）是軟體生存期（Software life cycle）中的一個重要階段，是軟體品質保證的關鍵步驟。通俗地講，軟體測試就是在軟體投入運行前，對軟體需求分析、設計規格說明和編碼進行最終複審的活動。1983年IEEE提出的軟體工程術語中給軟體測試下的定義是：“使用人工或自動的手段來運行或測定某個軟體系統的過程，其目的在於檢驗它是否滿足規定的需求或弄清預期結果與實際結果之間的差別”。這個定義明確指出：軟體測試的目的是為了檢驗軟體系統是否滿足需求。

　　從使用者的角度來看，普遍希望通過軟體測試暴露軟體中隱藏的錯誤和缺陷，所以軟體測試應該是“為了發現錯誤而執行程式的過程”。或者說，軟體測試應該根據軟體開發各階段的規格說明和程式的內部結構而精心設計一批測試案例（即輸入資料及其預期的輸出結果），並利用這些測試案例去運行程式，以發現程式錯誤或缺陷。

　　二.軟體測試的生命週期

　　測試主要依據是被試系統的研製任務書和技術規格書，是對軟體整體功能和效能的綜合測試與評估。測試原理是軟體測試活動的理論基礎，測試方法是測試原理的實際應用和獲得測試資料的手段。基於軟體的共性，對於軟體的測試要遵循一般軟體的測試原理和方法。同時，針對軟體的特性，必須找到合適的測試方法。測試案例的合理性對於軟體的測試與評估具有關鍵作用，而如何使設計的用例合情、合理並且典型有效並不容易。所以應該與軟體的研製人員以及終端使用者一起，有針對性地研究實際作業環境並加以描述，形成合理的測試案例集。另一方面，軟體運行環境的複雜程度對軟體評估具有重要作用，所以應產生盡量逼真的運行背景以便於研究。軟體測試的周期1所示。

　　實踐證明，儘管人們在開發軟體的過程中使用了許多保證軟體品質的方法和技術，但開發出的軟體中還會隱藏許多錯誤和缺陷。這對於規模大、複雜性高的軟體更是如此。所以，嚴格的軟體測試對於保證軟體品質具有重要作用。

圖1 軟體測試的生命週期

　　軟體測試在軟體生存期中橫跨兩個階段。在軟體編碼階段，當編寫出一個模組後，通常要對它進行必要的測試（稱為單元測試），這時測試與編碼屬於同一個階段。在編碼階段結束後，對軟體系統還要進行各種綜合測試（整合測試與系統測試），這是一個獨立階段，即軟體測試階段。在這個測試階段又有兩種性質不同的測試：研製單位內部進行的整合測試和系統測試與使用者（或第三方）進行的驗收性測試。

　　在軟體測試生命週期內，錯誤在軟體開發的每個階段都可能被帶入。在軟體測試中，某些錯誤被發現、分類、隔離，最終被糾正。由於軟體不斷被修改，所以這個過程是一個反覆進行的過程。
三.測試方法和流程

　　軟體測試方法主要有黑箱測試方法與白箱測試兩類。黑箱測試又稱功能測試、資料驅動測試或基於規格說明的測試，是在完全不考慮程式內部結構和內部特性的情況下，檢查輸入與輸出之間關係是否符合要求。白箱測試又稱結構測試、邏輯驅動測試或基於程式的測試，是在已知程式內部結構的情況下設計測試案例的測試方法。顯然，白箱測試適合在單元測試中運用，而在獨立測試階段多採用黑箱測試方法。

　　測試案例（Test case）實際上是對軟體運行過程中所有可能存在的目標、運動、行動、環境和結果的描述，是對客觀世界的一種抽象。設計測試案例即設計針對特定功能或組合功能的測試方案，並編寫成文檔。測試案例應該體現軟體工程的思想和原則。測試案例的選擇既要有一般情況，也應有極限情況以及最大和最小的邊界值情況。因為測試的目的是暴露應用軟體中隱藏的缺陷，所以在設計選取測試案例和資料時要考慮那些易於發現缺陷的測試案例和資料，結合複雜的運行環境，在所有可能的輸入條件和輸出條件中確定測試資料，來檢查應用軟體是否都能產生正確的輸出。

　　軟體測試所得到的資料經過處理以後，可以用來作為評估軟體系統是否滿足使用者需求的依據。軟體測試階段的資訊流2所示：

 

圖2 軟體測試資訊流

　　四.軟體評估理論及其發展現狀

　　軟體的評估理論是進行評估的理論依據，評估方法是評估理論的實際應用和處理測試資料的方法。對於評估指標體系中的不同指標，應該根據測試資料的不同，選取相應的評估理論和方法。軟體評估（Software assessment）的實質是對軟體品質的度量與評價。

　　我們對軟體品質評估的定義是：“為了確定一特定的軟體模組、軟體包或軟體產品是否驗收合格或發布而把特定的評估準則應用到該軟體模組、軟體包或軟體產品上去的活動”。

　　可見，軟體評估的對象是“軟體模組、軟體包或軟體產品”，軟體評估的目的是“確定被評對象是否驗收合格或發布”。定義中提到的評估準則是“根據特定的軟體產品和品質需求，確定產品是否通過驗收或發布的一組成文的規則和條件的集合”。從廣泛意義上講，評估準則已經包括了評估方法和指標體系，即如何處理獲得的測試資料與如何應用評估準則到被評估軟體上。

　　軟體可靠性評估（Software reliability assessment）的完整含義是：根據軟體系統可靠性結構（單元與系統間可靠性關係）、壽命類型和各單元的可靠性實驗資訊，利用機率統計方法，評估出系統的可靠性特徵量。

　　目前，軟體可靠性工程是一門雖然得到普遍承認，但還處於不成熟的正在發展確立階段的新興工程學科。國外從60年代後期開始加強軟體可靠性的研究工作，經過20年左右的研究推出了各種可靠性模型和預測方法，於1990年前後形成較為系統的軟體可靠性工程體系。同時，從80年代中期開始，西方各主要工業強國均確立了專門的研究計劃和課題，如英國的AIVEY（軟體可靠性和度量標準）計劃、歐洲的ESPRIT（歐洲資訊技術研究與發展戰略）計劃、SPMMS（軟體生產和維護管理保障）課題、Eureka（尤裡卡）計劃等。每年，都有大量人力物力投入軟體可靠性研究項目，並取得一定成果。

　　國內對於軟體可靠性的研究工作起步較晚，在軟體可靠性量化理論、度量標準（指標體系）、建模技術、設計方法、測試技術等方面與國外差距較大。國內多數軟體的生產方式還處於電腦時代的早期階段，缺點很明顯，主要表現在：1、透明度差；2、軟體交付系統聯調前只靠自檢，品質得不到保證；3、使用者對交付的軟體可靠性缺乏信心。多數所謂的“軟體測試”僅僅對幾個預先指定的用例進行一下表演就算通過。目前還沒有像硬體那樣完善的檢驗體系，交付軟體的品質不高。典型統計表明，“開發階段平均每千行代碼有50-60個缺陷，交付後平均每千行代碼有15-18個缺陷”，有時會留下嚴重隱患。

　　目前，軟體可靠性管理方面還沒有建立起具有權威性的管理體系和規範。比如，如何描述軟體可靠性、如何測試、如何評估、如何設計、如何提高等。由於目前國內外對於軟體可靠性模型的研究多集中在軟體的研製階段，而很少有涉及測試與評估階段的可靠性模型，所以從事軟體可靠性測試與評估研究是一個有理論價值和實際意義、並且存在一定難度的課題。

　　隨著電腦軟體編製的正常化，必然要將軟體可靠性考核納入科學、規範的軌道。具體表現在：1、在軟體系統研製任務中，制定軟體可靠性量化指標，使軟體考核有明確的標準；2、建立完善的軟體測試、可靠性資訊收集系統，使在電腦軟體開發中通過科學的軟體測試不斷減少缺陷；3、通過研究軟體可靠性考核方法，制定相應的軟體考核規程、標準；4、開發軟體可靠性評估軟體，使軟體評鑑更加方便。

　　五.軟體可靠性評估的定義

　　可靠性（reliability）是產品在規定的條件下和規定的時間內完成規定功能的能力，它的機率度量稱為可靠度。

　　軟體可靠性（software reliability）是軟體系統的固有特性之一，它表明了一個軟體系統按照使用者的要求和設計的目標，執行其功能的正確程度。軟體可靠性與軟體缺陷有關，也與系統輸入和系統使用有關。理論上說，可靠的軟體系統應該是正確、完整、一致和健壯的。但是實際上任何軟體都不可能達到百分之百的正確，而且也無法精確度量。一般情況下，只能通過對軟體系統進行測試來度量其可靠性。

　　這樣，給出如下定義：“軟體可靠性是軟體系統在規定的時間內及規定的環境條件下，完成規定功能的能力”。根據這個定義，軟體可靠性包含了以下三個要素：

　　1.規定的時間

　　軟體可靠性只是體現在其運行階段，所以將“已耗用時間”作為“規定的時間”的度量。“已耗用時間”包括軟體系統運行後工作與掛起（開啟但空閑）的累計時間。由於軟體啟動並執行環境與程式路徑選取的隨機性，軟體的失效為隨機事件，所以已耗用時間屬於隨機變數。

　　2.規定的環境條件

　　環境條件指軟體的運行環境。它涉及軟體系統運行時所需的各種支援要素，如支援硬體、作業系統、其它支援軟體、輸入資料格式和範圍以及操作規程等。不同的環境條件下軟體的可靠性是不同的。具體地說，規定的環境條件主要是描述軟體系統運行時電腦的配置情況以及對輸入資料的要求，並假定其它一切因素都是理想的。有了明確規定的環境條件，還可以有效判斷軟體失效的責任在使用者方還是研製方。

　　3.規定的功能

　　軟體可靠性還與規定的任務和功能有關。由於要完成的任務不同，軟體的運行剖面會有所區別，則調用的子模組就不同（即程式直接選取不同），其可靠性也就可能不同。所以要準確度量軟體系統的可靠性必須首先明確它的任務和功能。

　　在講到軟體可靠性評估的時候，我們不得不提到軟體可靠性模型。軟體可靠性模型（Software reliability model）是指為預計或估算軟體的可靠性所建立的可靠性框圖和數學模型。建立可靠性模型是為了將複雜系統的可靠性逐級分解為簡單系統的可靠性，以便於定量預計、分配、估算和評價複雜系統的可靠性。

　　六.軟體的缺陷和失效

　　缺陷（defect/fault）是指軟體的內在缺陷。在軟體生命週期的各個階段，特別是在早期設計和編碼階段，設計者和編程人員的行動（如需求不完整、理解有歧義、沒有完全實現需求或潛在需求、演算法邏輯錯、編程問題等）會使軟體在一定條件下不能或將不能完成規定功能，這樣就不可避免地存在“缺陷”。

　　軟體一旦有缺陷，它將潛伏在軟體中，直到它被發現和正確修改。反之，在一定的環境下，軟體一旦運行正確，它將繼續保持這種正確性，除非環境發生變化。此外，軟體中的缺陷不會為因使用而“損耗”。所以缺陷是“無損耗”地潛伏在軟體中。

　　如果軟體在運行時沒有用到有缺陷的部分，軟體就可以正常運行且正確工作；若用到了有缺陷的部分，則軟體的計算或判斷就會與規定的不符從而使軟體喪失執行要求的功能的能力。軟體不能完成規定功能即“失效”（failure）或“故障”。對於無容錯設計的軟體而言，局部失效則整個軟體失效。對於採取容錯設計的軟體，局部故障或失效並不一定導致整個軟體失效。

　　判斷軟體是否失效的判據有：系統死機、系統無法啟動、不能輸入輸出顯示記錄、計算資料有誤、決策不合理以及其它削弱或使軟體功能喪失的事件或狀態。

　七.軟體的可靠性測試過程

　　完整的測試過程包括測試前的檢查、設計測試案例、測試實施、可靠性資料收集和編寫測試報告5個步驟，下面逐一對這5個步驟進行說明。

　　1.測試前的檢查

　　在進行應用軟體的可靠性測試前有必要檢查軟體需求與研製任務書是否一致，檢查所交付程式和資料以及相應的軟體支援環境是否符合要求，檢查文檔與程式的一致性，檢查軟體研製過程中形成的文檔是否齊全、文檔的準確性和完整性以及是否通過了有關評審。

　　根據軟體行業的有關標準，我們知道，軟體研製過程中形成的文檔共有十六種：《系統和段設計檔案》、《軟體開發計劃》、《軟體需求規格說明》、《介面需求規格說明》、《介面設計文檔》、《軟體設計文檔》、《軟體產品規格說明》、《版本說明文檔》、《軟體測試計劃》、《軟體測試說明》、《軟體測試報告》、《電腦系統操作員手冊》、《軟體使用者手冊》、《軟體程式員手冊》、《韌體保障手冊》、《電腦資源綜合保障手冊》。

　　應該注意：這裡的《軟體測試計劃》、《軟體測試說明》和《軟體測試報告》是指研製方在研製過程中進行測試所形成的測試文檔。原則上若軟體規模不太大，某些文檔可以合并。

　　這些檢查雖然增加了工作量，但對於在測試早期發現錯誤和提高軟體的品質是非常必要的。

　　2.設計測試案例

　　設計測試案例就是針對特定功能或組合功能設計測試方案，並編寫成文檔。測試案例的選擇既要有一般情況，也應有極限情況以及最大和最小的邊界值情況。因為測試的目的是暴露應用軟體中隱藏的缺陷，所以在設計選取測試案例和資料時要考慮那些易於發現缺陷的測試案例和資料，結合複雜的運行環境，在所有可能的輸入條件和輸出條件中確定測試資料，來檢查應用軟體是否都能產生正確的輸出。

　　一個典型的測試案例應該包括下列詳細資料：

　　　a.測試目標；

　　　b.待測試的功能；

　　　c.測試環境及條件；

　　　d.測試日期；

　　　e.測試輸入；

　　　f.測試步驟；

　　　g.預期的輸出；

　　　h.評價輸出結果的準則。

　　所有的測試案例應該經過專家評審才可以使用。

　　設計與選取測試案例集的第一步是對測試案例進行描述，這種描述是否權威、完整、可理解與正常化，則決定了該測試案例能否或多大程度上可以被操作人員、軟體研製人員和實驗評鑑人員所理解接受。所以，正常化的測試案例描述在軟體測試與評估中具有重要的作用。

　　3.測試實施

　　做好上述準備工作後，就可以實施測試了。研製方交付的任何軟體文檔中與可靠性品質特性有關的部分，包括產品說明書、使用者文檔、程式以及資料都應當按照需求說明和品質需求進行測試。在項目合約、需求說明書和使用者文檔中規定的所有配置情況下，程式和資料都必須進行測試。

　　在測試中，可以考慮進行“強化輸入”，即輸入比正常輸入更惡劣（合理程度的惡劣）的輸入。如果軟體在強化輸入下可靠，只能說明比正規輸入下可靠得多。

　　為了獲得更多的可靠性資料，應該採用多台電腦同時運行軟體，以增加累計已耗用時間。

　　4.可靠性資料收集

　　軟體可靠性資料是可靠性評估的基礎。應該建立軟體錯誤報表、分析與矯正措施系統。按照相關標準的要求，制定和實施軟體錯誤報表和可靠性資料收集、儲存、分析和處理的規程，完整、準確地記錄軟體測試階段的軟體錯誤報表和收集可靠性資料。

　　用時間定義的軟體可靠性資料可以分為四類：1、失效時間資料，記錄發生一次失效所累積經曆的時間；2、失效間隔時間資料，記錄本次失效與上一次失效間的間隔時間；3、分組資料，記錄某個時間區內發生了多少次失效；4、分組時間內的累積失效數，記錄某個區間內的累積失效數。這四類資料可以互相轉化。
每個測試記錄必須包含充分的資訊，包括：

　　a.測試時間；

　　b.含有測試案例的測試計劃或測試說明；

　　c.所有與測試有關的測試結果，包括所有測試時發生的故障；

　　d.參與測試的個人身份。

　　5.編寫測試報告

　　測試活動結束後必須編寫《軟體可靠性測試報告》，對測試項及測試結果在測試報告中加以總結歸納。編寫時可以參考GJB 438A-97中提供的《軟體測試報告》格式，並應根據情況進行剪裁。測試報告應具備下列內容：

　　a.產品標識；

　　b.使用的配置（硬體和軟體）；

　　c.使用的文檔；

　　d.產品說明、使用者文檔、程式和資料的測試結果；

　　e.與需求不相符的項的列表；

　　f.測試的最終日期。

　　這種正常化的過程管理控制有利於獲得真實有效資料，為最終得到客觀的評估結果奠定基礎。

　　八.結束語

　　本文針對軟體的測試與可靠性評估方法進行了專門地研究。當然，最好的軟體可靠性評估方法是完全用現場實驗的方法。評估軟體的可靠性受到許多客觀條件限制，其中最大的限制就是可靠性資訊不足。所以應該利用構成軟體的各個模組的曆史可靠性實驗資訊統計評估全系統的可靠性。這需要：收集到足夠的軟體以及各個模組的曆史可靠性實驗資訊；各個模組與軟體的可靠性關係明確；各模組壽命類型已知；以及軟體研製部門的配合（因為軟體曆史資訊資料主要由研製方掌握）。