第一章 緒 論
1．1 軟件生存期
同其它任何事物一樣，計算機軟件從它的發(fā)生、發(fā)展到達成熟階段，以至老化和衰亡，是一個(gè)歷史發(fā)展的過(guò)程，這個(gè)過(guò)程稱(chēng)為軟件的生存期（Life Cycle），包括下列六個(gè)步驟：
（1）計劃（Planning）：確定軟件開(kāi)發(fā)的總目標；給出軟件的功能、性能、可靠性以及接口等方面的設想；研究完成該軟件任務(wù)的可行性，探討問(wèn)題解決的方案；對可供開(kāi)發(fā)使用的資源（軟件、硬件、人力）、成本、可取得的效益和開(kāi)發(fā)的進(jìn)度等做出估計；制定完成開(kāi)發(fā)任務(wù)的實(shí)施計劃。
（2）需求分析（Requirement Analysis）：由軟件人員和用戶(hù)共同對待開(kāi)發(fā)的軟件進(jìn)行詳細的定義和確切的描述，其結果是給出軟件需求說(shuō)明書(shū)（SRS：Software Requirement Specification）。
（3）設計（Designing）：軟件的設計分為兩部分。一是概要設計（Preliminary Design），是指根據軟件的需求說(shuō)明書(shū)，軟件設計人員應把需求說(shuō)明書(shū)中各項需求轉化為相應的體系結構，在結構中的每一組成部分是功能明確的模塊，每個(gè)模塊都能體現相應的需求。二是詳細設計（Detail Design），是指對概要設計中給出的各個(gè)模塊所要完成的工作進(jìn)行具體的描述，為后來(lái)的編程打下基礎。軟件設計的結果是給出設計說(shuō)明書(shū)。
（4）編碼（Coding）：利用某種計算機語(yǔ)言，把設計說(shuō)明書(shū)中規定的內容轉化為計算機可以接受的程序的過(guò)程稱(chēng)為編碼。編碼應以設計相一致，且結構清晰、易讀、易修改。
（5）測試（Testing）：根據軟件的需求說(shuō)明書(shū)、設計說(shuō)明書(shū)和源代碼，檢驗軟件開(kāi)發(fā)工作的成果是否符合要求的過(guò)程稱(chēng)為軟件測試。軟件測試是發(fā)現軟件錯誤、提高軟件可靠性與保證軟件質(zhì)量的重要手段。
（6）運行與維護（Running and Maintaining）：對已交付用戶(hù)的軟件投入正式使用后便進(jìn)入運行階段，這個(gè)階段可能持續若干年。在運行過(guò)程中，可能有多種原因需要對它進(jìn)行修改，包括運行中發(fā)現了軟件錯誤需要修正；為適應變化了的軟硬件環(huán)境，而需要做相應的變更；為進(jìn)一步增強軟件的功能，或提高其性能，而使它進(jìn)一步的完善和擴充等。
上述六步表明了一個(gè)軟件從其醞釀開(kāi)始，直至使用相當長(cháng)的時(shí)間后，被新的軟件代替而退役的整個(gè)過(guò)程。按此順序逐步轉變的過(guò)程可用一個(gè)軟件生存期的瀑布模型加以形象化描述。如圖1.1所示。圖中自上而下的箭頭代表了問(wèn)題的一個(gè)求解過(guò)程，而自下而上的箭頭代表了在實(shí)際項目的研制中，為確保軟件質(zhì)量，每一步驟完成后都要進(jìn)行復查，如發(fā)現了問(wèn)題，就要及時(shí)解決，以免問(wèn)題積壓到最后造成更大的困難。運行與維護的箭頭表示在運行中可能需要多次維護。另外圖中還指明了六個(gè)步驟劃分的三個(gè)階段，軟件定義階段、軟件開(kāi)發(fā)階段和軟件維護階段。
值得注意的是，上述軟件維護工作不可簡(jiǎn)單地看待僅僅是修改程序。在運行過(guò)程中若有必要修改，得提出充分的修改理由，經(jīng)過(guò)審核，才能確定下來(lái)。接著(zhù)需要經(jīng)歷制定修改計劃、確定新的需求、修改軟件設計、修改編碼、進(jìn)行測試以及重新投入運行等一系列步驟，這正是上述開(kāi)發(fā)一個(gè)新軟件的步驟。若是運行中多次提出修改，則將經(jīng)歷多次這些步驟?？捎脠D1.2來(lái)表示這一過(guò)程，并稱(chēng)為軟件的生存周期，也簡(jiǎn)稱(chēng)為軟件的生存期。
1．2
軟件危機
計算機系統工程分為硬件和軟件兩大范疇。計算機硬件的工程技術(shù)在過(guò)去的50多年中已經(jīng)達到了相當成熟的狀態(tài)。硬件設計技術(shù)和制造技術(shù)發(fā)展非常迅速，其自動(dòng)化已經(jīng)達到相當高的水平，硬件的可靠性已是一種現實(shí)的要求，而不在是一種愿望。
而在軟件工程技術(shù)方面的情況則不同，軟件是最難設計、最少可能成功、最容易出錯、也最難管理的系統部分。據報道，在上世紀的最后十年里，計算機軟件已成為系統癱瘓的主要原因。隨著(zhù)以計算機為基礎的系統在數量、復雜程度和應用方面的激增，對軟件的需要卻在不斷增加，因此促使供求矛盾日趨激化，這就是人們常說(shuō)的軟件危機。軟件危機的來(lái)源主要表現以下幾個(gè)方面：
（1）缺乏軟件開(kāi)發(fā)的經(jīng)驗：由于缺乏大型軟件開(kāi)發(fā)的經(jīng)驗和軟件開(kāi)發(fā)數據的積累，使得開(kāi)發(fā)工作的計劃很難制定。主觀(guān)盲目地制定計劃，執行起來(lái)和實(shí)際情況有很大差距，使得經(jīng)費常常突破預算、工期一拖再拖，軟件的投資者和用戶(hù)對開(kāi)發(fā)工作從不滿(mǎn)意發(fā)展到不信任。
（2）需求不明確：作為軟件設計依據的軟件需求，在開(kāi)發(fā)的初期提得不夠明確，或者未能做出確切的表達。開(kāi)發(fā)工作開(kāi)始后，軟件人員又未能和用戶(hù)及時(shí)的交換意見(jiàn)，使得一些問(wèn)題得不到及時(shí)解決而隱藏起來(lái)，造成開(kāi)發(fā)后期矛盾的集中暴露。導致對多個(gè)錯綜復雜的問(wèn)題既難于分析，又難于解決。
（3）缺少開(kāi)發(fā)規范：開(kāi)發(fā)過(guò)程中沒(méi)有統一遵循的、公認的方法論或開(kāi)發(fā)規范，參加工作的人員之間的配合不夠嚴密，約定不夠明確。加之不重視文字資料，使得開(kāi)發(fā)文檔很不完整。發(fā)現了問(wèn)題，未能從根本上去找原因，只是修修補補。顯然，這樣開(kāi)發(fā)出來(lái)的軟件無(wú)法維護。
（4）軟件的復雜性：軟件的規模一般都比較龐大，大型軟件有時(shí)會(huì )超過(guò)1億行源代碼。加之人們傳統上的誤區，往往是硬件難以實(shí)現的部分改用軟件來(lái)完成，這使得軟件既龐大，復雜性又高，甚至有時(shí)人的大腦已無(wú)法理解、無(wú)法駕馭人類(lèi)本身所創(chuàng )造出來(lái)的復雜邏輯系統，投入使用后往往錯誤百出。
（5）缺乏有效的測試手段：軟件的復雜性和軟件測試的復雜性，使得難以研制有效的軟件測試工具，導致測試效率不高、自動(dòng)化程度低，測試花費時(shí)間多、測試成本高，這使得軟件開(kāi)發(fā)者只要求測試人員對軟件做簡(jiǎn)單的測試，這無(wú)法保證軟件的質(zhì)量。
軟件危機的事例是很多的。最著(zhù)名的是上世紀六十年代，美國IBM公司開(kāi)發(fā)的IBM360操作系統，這一項目在開(kāi)發(fā)期共花費了5000萬(wàn)美元，總共投入的工作量是5000人年，共寫(xiě)出了100萬(wàn)行源程序。由于它太龐大，OS360變得相當不可靠，平均每次修改后的新版本都大約存在1000個(gè)左右的錯誤，而且有理由認為這是一個(gè)常數。另外，美國空軍的范登堡中心在上世紀六十年代后期發(fā)生過(guò)多次導彈試射失敗的事故，事后檢查幾乎都是由于軟件有錯誤而造成的。
與軟件危機有關(guān)的許多問(wèn)題都起源于軟件本身的特點(diǎn)、軟件開(kāi)發(fā)人員的弱點(diǎn)、以及人們對軟件開(kāi)發(fā)實(shí)質(zhì)的種種不切實(shí)際的誤解，計算機軟件已經(jīng)成為以計算機為基礎的系統發(fā)展的重要瓶徑?？茖W(xué)上的危機和其它領(lǐng)域的危機一樣，解決危機的過(guò)程往往孕育著(zhù)一種科學(xué)理論的誕生。自上世紀七十年代以來(lái)，科學(xué)家們一直在試圖解決軟件危機問(wèn)題，雖然目前尚不能說(shuō)軟件的危機已經(jīng)過(guò)去，但二十年來(lái)，軟件技術(shù)的迅速發(fā)展，包括面向對象的技術(shù)、基于知識的軟件開(kāi)發(fā)環(huán)境、先進(jìn)的軟件測試工具等，為保證大型軟件的研制提供了重要的基礎。正是這些先進(jìn)的技術(shù)，目前上億行源代碼的軟件比比皆是。
1．3 軟件質(zhì)量
質(zhì)量這一概念有許多不同的定義。在《詞?！分?，就把質(zhì)量一詞解析為“產(chǎn)品或工作的優(yōu)劣程度”。國際標準化組織（ISO）把質(zhì)量定義為“與一個(gè)產(chǎn)品或服務(wù)是否能夠滿(mǎn)足其指定的或蘊涵的需求有關(guān)的性質(zhì)與特征的總合”。同其它產(chǎn)品一樣，軟件的質(zhì)量也不是絕對的，在不同的情況下，對不同的人來(lái)說(shuō)，軟件質(zhì)量的含義是不同的。
1． 軟件質(zhì)量要素
軟件產(chǎn)品的質(zhì)量是由許多軟件性質(zhì)構成的，這些性質(zhì)常稱(chēng)為軟件質(zhì)量要素。一般來(lái)講，軟件的質(zhì)量因素有下列11個(gè)。
（1）易使用性：是指軟件易于使用的程度。
（2）完整性：保護軟件不被未經(jīng)同意的存儲和使用的能力。
（3）效率：指軟件對計算機資源的使用效率，包括運算時(shí)間效率和存儲空間效率。
（4）可靠性：不失敗的能力。
（5）正確性：程序完成其規約的程度。
（6）易維護性：在程序的操作環(huán)境中，確定軟件故障的位置并糾正故障的難易程度。
（7）靈活性：當軟件操作環(huán)境變化時(shí)，對軟件作相應修改的難易程度。
（8）易測試性：對軟件測試以保證其無(wú)錯誤和滿(mǎn)足其規約的難易程度。
（9）易移植性：將一個(gè)程序從一個(gè)運行環(huán)境移植到另一個(gè)運行環(huán)境的難易程度。
（10）易復用性：復用一個(gè)軟件或其部分的難易程度。
（11）互用性：將一個(gè)軟件系統和其它軟件系統組合在一起的難易程度。
2．軟件質(zhì)量要素的衡量標準
軟件每個(gè)質(zhì)量要素又包含一系列的衡量標準，具體為：
（1）易使用性：包括易操作性、培訓、易交流性、輸入和輸出量、輸入輸出速度。
（2）完整性：包括存儲控制、存儲審查。
（3）效率：包括運行效率、存儲效率。
（4）可靠性：容錯性、一致性、準確性、簡(jiǎn)潔性。
（5）正確性：包括易追溯性、一致性、完備性。
（6）易維護性：一致性、簡(jiǎn)潔性、簡(jiǎn)明性、模塊性、自我描述性。
（7）靈活性：模塊性、一般性、易擴展性、自我描述性。
（8）易測試性：簡(jiǎn)潔性、模塊性、檢視、自我描述性。
（9）易移植性：模塊性、自我描述性、硬件獨立性、軟件獨立性。
（10）易復用性：通用性、模塊性、自我描述性、硬件獨立性、軟件獨立性。
（11）互用性：模塊性、通訊共同性、數據共同性。
每個(gè)衡量標準的定義為：
（1）易追溯性：指在特定的軟件開(kāi)發(fā)與操作環(huán)境中，能夠從軟件的需求尋找出其相應的實(shí)現的能力與性質(zhì)。
（2）完備性：指軟件實(shí)現了其全部所需功能的性質(zhì)。
（3）一致性：指在軟件的設計與實(shí)現中采用統一的技術(shù)與術(shù)語(yǔ)的性質(zhì)。
（4）準確性：指軟件的輸出與計算中的精度滿(mǎn)足其需求的性質(zhì)。
（5）容錯性：指在非正常條件下，仍然能夠操作軟件的性質(zhì)。
（6）簡(jiǎn)潔性：指軟件以最容易理解的方式實(shí)現其功能的性質(zhì)。
（7）模塊性：指用一系列在很大程度上相互獨立的模塊來(lái)構成軟件的性質(zhì)。
（8）一般性：指軟件所提供的功能具有應用范圍廣的性質(zhì)。
（9）易擴展性：指易于對軟件存儲空間和計算功能進(jìn)行擴充的性質(zhì)。
（10）檢視：指軟件所提供的用于測量使用情況和識別錯誤的屬性。
（11）自我描述性：指軟件中包含它對功能的實(shí)現的解析性信息的屬性。
（12）運行效率：指軟件使用最少的處理時(shí)間的性質(zhì)。
（13）存儲效率：指軟件在操作中對存儲空間的需求最少的性質(zhì)。
（14）存儲控制：指反映對軟件及其數據的存儲進(jìn)行控制的能力的性質(zhì)。
（15）存儲審查：指對軟件及其數據的存儲進(jìn)行審查、記錄能力的性質(zhì)。
（16）易操作性：指決定軟件的操作與操作過(guò)程的復雜程度與難易程度的性質(zhì)。
（17）培訓：指支持從初步熟悉到熟練操作軟件的過(guò)度的性質(zhì)。
（18）易交流性：指軟件的輸入與輸出能夠被人們理解的程度的性質(zhì)。
（19）軟件獨立性：指決定對軟件環(huán)境中的其它軟件的依賴(lài)程度的性質(zhì)。
（20）硬件獨立性：指決定軟件對硬件環(huán)境的依賴(lài)程度的性質(zhì)。
（21）通訊共同性：指軟件使用標準的通訊協(xié)議與界面的性質(zhì)。
（22）數據共同性：指軟件使用標準的數據表示格式的性質(zhì)。
（23）簡(jiǎn)明性：軟件的實(shí)現使用最少代碼的性質(zhì)。
每一個(gè)軟件質(zhì)量衡量標準又可以有多個(gè)不同的度量。軟件質(zhì)量度量有的作用于軟件的代碼，有的作用于軟件開(kāi)發(fā)過(guò)程中產(chǎn)生的中間結果和文檔。
1．4 軟件可靠性
1．硬件可靠性
所謂系統的可靠性，是指“一個(gè)系統在一定的環(huán)境下，在所給定的時(shí)間內能按預定的要求完成一定功能的概率”。
設一個(gè)具有N個(gè)元件的系統，經(jīng)運行t時(shí)間后，有F(t)個(gè)元件失效，其余S(t)個(gè)元件仍然保持完好，則分別定義元件的可靠度R(t)和不可靠度Q(t)為：
定義元件的失效率Z(t)為單位時(shí)間內失效的元件數與非失效的元件數之比。
根據理論研究和大量統計得出，在正常的工作條件下，元件的失效變化趨勢如圖1.3所示。這就是硬件系統可靠性分析中著(zhù)名的盆式曲線(xiàn)（Bathtub curve）。它表明系統在使用的開(kāi)始階段，其失效率是比較高的，但隨著(zhù)故障的排除，其失效率將穩定在一個(gè)基本上保持不變的常數，這個(gè)時(shí)期稱(chēng)為正常的使用期。由于受到周?chē)h(huán)境、元件老化等因數的影響，在使用一定的時(shí)間后，系統的故障率開(kāi)始上升，而且越來(lái)越高，直至系統被淘汰。
在正常的使用期，系統的失效率可以近似為一個(gè)常數l，則：
解這個(gè)方程，并考慮到R(0)=1，有：
硬件可靠性理論中的一個(gè)重要參數是系統的平均故障間隔時(shí)間MTBF（Mean Time Between Failures）和平均故障時(shí)間MTTF（Mean Time To Failures）。MTBF是指可修復故障的系統，而MTTF是指不可修復故障的系統。如果忽略這一點(diǎn)，MTBF和MTTF是混用的。因此，根據定義：
上述公式是硬件可靠性的基本理論，也是一套非常成熟的理論。
經(jīng)過(guò)幾十年的發(fā)展，硬件可靠性不但在理論上成熟的，而且在工程上也有許多提高可靠性的方法和工具。目前，一般出廠(chǎng)的硬件產(chǎn)品都有可靠性指標，如風(fēng)險函數和MTBF等。
2．軟件可靠性
軟件的可靠性定義為：在給定的時(shí)間內，特定環(huán)境下軟件正確運行的概率。正如前節所述，軟件可靠性是軟件質(zhì)量的要素之一。對用戶(hù)而言，同其它軟件質(zhì)量要素相比，軟件可靠性是最重要的要素。
從其定義可以看出，軟件可靠性涉及三個(gè)概念：給定的時(shí)間、特定的環(huán)境、正確運行的概率。
對給定的時(shí)間，是指由于軟件的可靠性是隨時(shí)間而變化的，根據軟件可靠性的理論，軟件每排除一個(gè)故障，其可靠性就提高一步。因此，在談?wù)撥浖煽啃缘臅r(shí)候，一定要指明是什么時(shí)間的可靠性。
特定的環(huán)境是軟件可靠性的一個(gè)重要的因素，它包括硬件環(huán)境、軟件支撐環(huán)境和其它為保證軟件正常運行所需要的環(huán)境。在評估軟件可靠性時(shí)，一般要假設環(huán)境是正確無(wú)誤的。
正確運行的概率情況比較復雜，軟件運行包括選擇輸入數據和啟動(dòng)程序執行。但問(wèn)題是如何選擇輸入數據才能真實(shí)的反應軟件的可靠性？如何根據錯誤發(fā)生的時(shí)間來(lái)評估軟件可靠性？軟件可靠性的變化規律是什么？等等，類(lèi)似的問(wèn)題在軟件可靠性理論的研究中都沒(méi)有很好的解決。雖然如此，在過(guò)去的三十余年里，科學(xué)家在這個(gè)方面做了大量的研究，目前比較著(zhù)名的有四十余種軟件可靠性模型，由于工程數據的來(lái)源以及對軟件可靠性認識上的不同，這些模型存在較大的差異。一個(gè)新的軟件究竟用那種可靠性模型去評估更好，目前尚無(wú)定論。只能根據工程背景和個(gè)人的喜好去判斷。
拋開(kāi)尋求統一的軟件可靠性模型，近幾年來(lái)，許多科學(xué)家試圖從工程的角度研究軟件可靠性的部分內容，主要是軟件的平均無(wú)故障時(shí)間MTBF、軟件的故障率l等，這些參數對用戶(hù)來(lái)說(shuō)恐怕是更重要的。目前的許多軍用軟件、關(guān)系到國計民生的一些重要軟件都有相應的可靠性參數評估，也是軟件生產(chǎn)應達到的目標。
根據軟件可靠性的理論，一個(gè)軟件在交付之后，軟件的可靠性就是確定的，只不過(guò)人們現在還沒(méi)有很好的辦法去認識它。拋開(kāi)其它因素不談，唯一能影響軟件可靠性的是殘留在軟件中錯誤數目。隨著(zhù)軟件在測試過(guò)程中或在使用過(guò)程中，軟件錯誤的不斷發(fā)現與排除，殘留在軟件中的錯誤會(huì )逐步減少，軟件的故障率會(huì )逐步降低，因此，軟件的故障率曲線(xiàn)應該類(lèi)似于圖1.4所示的曲線(xiàn)。這是軟件可靠性建模的基本思想。
1．5 軟件錯誤
1． 軟件錯誤的概念
定義1.1：錯誤（Error）：是指人們期望的和系統實(shí)際具有的狀態(tài)或行為之間的偏差。
軟件錯誤包括由系統分析或者程序設計而產(chǎn)生的全部錯誤。軟件錯誤存在于軟件生存期的各個(gè)階段，凡是和預期的狀態(tài)或行為不相符合的統稱(chēng)為軟件錯誤。例如，制定的計劃和實(shí)際不相符合的、需求說(shuō)明書(shū)有問(wèn)題的、設計說(shuō)明書(shū)有問(wèn)題的、程序編碼有問(wèn)題的、測試有問(wèn)題的、運行結果不正確的、維護有問(wèn)題的等等，都是軟件錯誤。
定義1.2：失效（Failure）：是指在軟件運行期間出現的錯誤。它是因軟件中存在的錯誤引起的、并在執行期間動(dòng)態(tài)表現出來(lái)的和實(shí)際不同的狀態(tài)和行為。
從這里可以看出，失敗只是錯誤的一部分。
定義1.3：故障（Fault）：是指軟件中的物理缺陷。
故障也是錯誤的一部分，故障是指軟件中實(shí)實(shí)在在存在的錯誤。故障可能引起軟件的失效，也可能不引起軟件的失效，人們總是通過(guò)修改軟件中的故障來(lái)提高軟件的可靠性。
定義1.4：缺陷（Defect，Bug）：凡是沒(méi)有按照要求所進(jìn)行的工作統稱(chēng)為缺陷。
缺陷泛指系統中的一切錯誤。顯然，缺陷是比錯誤范圍更大的概念，缺陷除了包括錯誤所具有的全部屬性外，像程序的多余物、難以理解的程序、難以修改的程序，文檔不完全等，雖然這些可能并不能使軟件失敗，但是缺陷。通過(guò)修改軟件中的缺陷來(lái)提高軟件的質(zhì)量。
從定義可以看出，上述四個(gè)概念是彼此相關(guān)的，有些文獻中也經(jīng)常是混用的。實(shí)際使用時(shí)應區分它們之間的層次和范圍。
2.軟件的缺陷數目與缺陷密度
軟件的缺陷數目是指軟件中所存在的所有缺陷的總和。而軟件的缺陷密度是指每單位代碼中的缺陷數目，這里，單位代碼一般是KLOC或KSLOC（千行源代碼），表示為缺陷數目/KLOC，或者缺陷數目/KSLOC。
軟件工程師在工作中一般會(huì )引入大量的缺陷。統計表明，有經(jīng)驗的軟件工程師的缺陷引入率一般是50~250個(gè)缺陷/KLOC，平均的缺陷引入率在100個(gè)缺陷/KLOC以上。即使軟件工程師學(xué)過(guò)軟件缺陷管理之后，平均的缺陷引入率也在50個(gè)缺陷/KLOC，也就是說(shuō)，每20行代碼中就有一個(gè)缺陷。再者從理論上看，人的認識能力是有限的，根據Hatton模型，對一般的軟件，軟件的缺陷數目可用下面的公式表示：
這里W是軟件的復雜度，一般用源代碼數目來(lái)表示。
從工程實(shí)踐來(lái)看，目前世界上先進(jìn)的軟件開(kāi)發(fā)組織所生產(chǎn)的軟件，其缺陷密度可以達到2個(gè)缺陷/KLOC，一般的軟件開(kāi)發(fā)組織所生產(chǎn)的軟件其缺陷密度可以達到4~40個(gè)缺陷/KLOC。據統計，在美國，安全第一的軟件開(kāi)發(fā)的代價(jià)是每行程序需花費500$。NASA所生產(chǎn)的軟件其故障密度可以達到0.1個(gè)缺陷/KLOC，但其代價(jià)是每行源代碼高達1000$。
軟件的缺陷數目或者缺陷密度可以通過(guò)測試或者其它方法來(lái)計算。而殘留在軟件中缺陷數目或者缺陷密度只能通過(guò)評估來(lái)得到，例如根據測試的程度、或者根據軟件可靠性模型等可以預測軟件中殘留的缺陷數目。
在安全第一或者一些重要的軟件驗收中，軟件的缺陷數目或者缺陷密度是軟件能否通過(guò)驗收的重要標準。
3．軟件錯誤的分類(lèi)方法
軟件的錯誤是非常復雜的，凡是人們能夠想到的軟件錯誤都是可能發(fā)生的。到目前為止，人們對軟件錯誤的認識尚停留在表面上，其內在規律有待進(jìn)一步研究。這也是目前軟件測試技術(shù)發(fā)展比較緩慢的原因之一。雖然如此，人們還是可以根據軟件錯誤的表現將其進(jìn)行分類(lèi)，常見(jiàn)的分類(lèi)方法有：
（1）根據錯誤的征兆進(jìn)行分類(lèi)：這種分類(lèi)方法是根據系統的輸入和系統對輸入的反應結果進(jìn)行的分類(lèi)。如表1.1所示。這種分類(lèi)方法的好處是可以提高人們認識錯誤的嚴重程度，以便防范于未然。
表1.1 根據錯誤的征兆進(jìn)行的分類(lèi)
輸入
系統反應
錯誤輸入
正確輸入
對輸入的拒絕
正確
第I類(lèi)型的錯誤（嚴重）
得出錯誤的結果
第II類(lèi)型的錯誤（嚴重）
第III類(lèi)型的錯誤（嚴重）
系統崩潰
第IV類(lèi)型的錯誤（嚴重）
第V類(lèi)型的錯誤（嚴重）
（2）根據錯誤的起因進(jìn)行的分類(lèi)：計算機系統中的每一個(gè)錯誤，究其原因，大都可以歸結為下列三種情況之一，硬件或軟件中的設計錯誤、由于環(huán)境或部件的老化引起的硬件惡化、錯誤的輸入數據。顯然，在軟件生存期的不同階段，每類(lèi)錯誤的分布是不一樣的，因此，這種分類(lèi)方法的好處，一是了解錯誤在不同時(shí)期的分布規律。例如，在系統運行的早期所發(fā)生的錯誤，很有可能是設計錯誤或數據錯誤所引起的，在運行相當長(cháng)的時(shí)間后所發(fā)生的錯誤可能是由于數據錯誤引起的，而在運行相當長(cháng)的時(shí)間后，就有可能是硬件惡化引起的，這為判斷軟件錯誤的類(lèi)型并盡快修復提供依據。二是根據這種分類(lèi)，可以知道那些錯誤是可以排除的，而那些錯誤又必須通過(guò)是更換設備才能解決的。
（3）根據錯誤發(fā)生的持續時(shí)間來(lái)分類(lèi)：一般可將其分為永久性錯誤和瞬時(shí)錯誤。永久性錯誤是指經(jīng)常發(fā)生的錯誤，這類(lèi)錯誤是不可怕的，因為它容易被排除。而瞬時(shí)錯誤恰恰相反，由于是偶爾出現，難以掌握其規律，故很難將其排除。
（4）根據錯誤的嚴重程度進(jìn)行分類(lèi)：不同的錯誤所產(chǎn)生的后果是不一樣的。較少的錯誤例如數據格式不對，并不會(huì )產(chǎn)生什么后果，而有些錯誤，例如飛機導航軟件出錯，可能導致機毀人忘的嚴重后果。一般來(lái)講，根據錯誤的嚴重程度可以分為：較少錯誤、中等錯誤、較嚴重錯誤、嚴重錯誤、非常嚴重錯誤和最嚴重錯誤。這里的分類(lèi)，是根據錯誤引起后果的程度來(lái)分的，而不是根據錯誤對應故障的復雜性來(lái)分類(lèi)的，有時(shí)一個(gè)較少的故障，例如，程序語(yǔ)句漏掉一個(gè)標點(diǎn)符號等，都可能產(chǎn)生嚴重的后果。
（5）根據開(kāi)發(fā)階段進(jìn)行分類(lèi)：在軟件生存期的每個(gè)階段都可能存在錯誤，即計劃錯誤、需求分析錯誤、設計錯誤、編碼錯誤、測試錯誤、運行與維護錯誤。由于生存期的每一個(gè)階段又是下一個(gè)階段的先導，也就是說(shuō)，前一個(gè)階段正確的設計是保證下一個(gè)階段設計正確的必要條件。因此，要求一旦發(fā)現某個(gè)階段存在錯誤，就要盡快將其排除。否則，越往后，排除故障的代價(jià)就越大，從這種意義上講，這種分類(lèi)法是必要的。
4．軟件錯誤的分類(lèi)
雖然上述給出了軟件錯誤的五類(lèi)分類(lèi)方法，但前四種的分類(lèi)方法只能給人們一個(gè)感性的認識，對排除故障并沒(méi)有很大的幫助。
（1）根據軟件開(kāi)發(fā)階段的分類(lèi)：根據軟件開(kāi)發(fā)階段的分類(lèi)方法針對性比較強，便于人們認識錯誤和糾正錯誤。表1.2給出了一種基于開(kāi)發(fā)階段的分類(lèi)方法，表中給出的錯誤數據比例是根據含有6877000個(gè)語(yǔ)句的源程序的錯誤（共16029個(gè)錯誤）進(jìn)行統計的結果。
表1.2：基于開(kāi)發(fā)階段的分類(lèi)方法
錯誤類(lèi)型
描述
錯誤個(gè)數
百分比
軟件需求錯誤
包括軟件需求制定得不合理或不正確；需求不完全；含有邏輯錯誤；需求分析的文檔有誤。
1317
8.2%
功能和性能錯誤
包括功能和性能規定得有錯誤，或是遺漏了某些功能；為用戶(hù)提供的信息有錯誤，或信息不確切；對意外的異常情況處理有誤等。
2624
16.1%
結構錯誤
包括程序控制流或控制順序有誤；處理過(guò)程有誤等。
4082
25.2%
數據錯誤
包括數據定義或數據結構有誤；數據存儲或數據操作有誤等。
3638
22.4%
實(shí)現和編碼錯誤
包括編碼錯或按鍵錯；違背編碼風(fēng)格或是編碼標準錯誤；文檔有誤等。
1601
9.9%
集成錯誤
包括軟件內部和外部接口有誤；各相關(guān)部分在時(shí)間配合、數據吞吐量等方面不協(xié)調等。
1455
9.0%
系統結構錯誤
操作系統調用錯或使用錯、恢復錯誤、診斷錯誤、分割及覆蓋錯誤、引用環(huán)境錯誤等。
282
1.7%
測試定義與測試執行錯誤
包括測試設計錯誤、測試執行錯誤、測試文檔錯誤、測試用例不充分等。
447
2.8%
其它類(lèi)型錯誤
763
4.7%
（2）基于引起錯誤復雜度的分類(lèi)：如表1.3所示。
表1.3：基于引起錯誤復雜度的分類(lèi)
錯誤類(lèi)型
描述
文檔
注釋、消息。
語(yǔ)法
拼寫(xiě)、標點(diǎn)符號、打字、指令格式。
聯(lián)編打包
變更管理、庫、版本控制。
賦值
說(shuō)明、重名、作用域、限制。
接口
過(guò)程調用與引用、輸入/輸出、用戶(hù)格式。
檢查
出錯信息、不合適的檢查。
數據
結構、內容。
函數
邏輯、指針、循環(huán)、遞歸、計算、函數缺陷。
系統
配置、記時(shí)、內存。
環(huán)境
設計、編譯、測試、其它系統支持問(wèn)題。
5．軟件錯誤的危害
（1）軟件錯誤可能造成的危害：近年來(lái)，隨著(zhù)計算機應用領(lǐng)域的迅速擴大，計算機軟、硬件新技術(shù)的不斷涌現，人們對軟件的質(zhì)量提出了新的更高的要求。目前，計算機已廣泛地應用于航天、航空、工業(yè)控制、交通、銀行、金融、醫療等領(lǐng)域。在這樣的應用領(lǐng)域中，軟件質(zhì)量往往關(guān)系到人民生命財產(chǎn)和生態(tài)環(huán)境的安危。一旦軟件發(fā)生故障，就可能造成人的生命和財產(chǎn)的巨大損失和生態(tài)環(huán)境的破壞。例如：
· 國際上，計算機已普遍用于核電站的控制與安全保護，一旦軟件發(fā)生故障，將會(huì )造成人員傷亡和環(huán)境污染。
· 在倫敦希思羅國際機場(chǎng)，平均每三分鐘就有一架飛機起落，如果調度飛機場(chǎng)著(zhù)陸次序的軟件發(fā)生故障，將會(huì )造成飛機相撞的災難。
· 波音747等大型客機都使用計算機自動(dòng)導航系統，如果它發(fā)生故障，將會(huì )造成機毀人忘的事故。
· 在西方國家，鐵路信號系統已計算機化。英國已計劃在不久的將來(lái)實(shí)現鐵路信號和扳道的全部自動(dòng)化。鐵路交通的安全性將進(jìn)一步依賴(lài)計算機系統的正常運行。
· 在巴黎地鐵系統中，由于使用計算機進(jìn)行有效的調度和安全控制，火車(chē)的行駛速度得以加快，火車(chē)之間的間隔得以縮短。
· 現代通信技術(shù)和網(wǎng)絡(luò )技術(shù)的發(fā)展，使得人們相互之間的信息交換達到完全自動(dòng)化，如果主控計算機出現故障，則它所控制的用戶(hù)對外的信息交流將被中斷，所造成的損失是難以估量的。
· 一旦銀行系統的計算機出現故障，將會(huì )造成混亂。這也是目前銀行系統尚需人工備份資料的重要原因。
以上類(lèi)似的例子很多，難以枚舉。隨著(zhù)計算機科學(xué)、信息科學(xué)和其它自然科學(xué)的發(fā)展，我們有理由相信，人們將會(huì )越來(lái)越依靠計算機，計算機將是人類(lèi)生活的重要組成部分，到那時(shí)，計算機的錯誤將不在僅僅是一個(gè)技術(shù)問(wèn)題，而將完全變成一個(gè)普遍的社會(huì )問(wèn)題。
（2）軟件錯誤已經(jīng)造成的危害：軟件的錯誤給人類(lèi)生活已經(jīng)造成的危害的事例是很多的，這里僅舉幾個(gè)例子。
· 歐洲航空航天局發(fā)射的啊里亞那火箭，由于軟件的錯誤而使發(fā)射失敗，所攜帶的衛星報廢，損失巨大。
· 中國的´´衛星，也是由于軟件的錯誤，在運行不到一年后就失去作用。根據事后的分析表明，僅僅是由于一個(gè)非常簡(jiǎn)單的軟件錯誤而使耗資巨大的衛星報廢，多么可失！
· 由于控制放射性治療設備的軟件錯誤，在加拿大已經(jīng)造成了多起癌癥病人因受到過(guò)量放射性輻射而死亡的事故。
· 在英國，由于放射性治療設備中計算輻射量的軟件錯誤，發(fā)生了癌癥病人因放射性輻射太低而得不到適當治療的事故。
· 在倫敦，救護車(chē)調度軟件剛剛投入使用幾小時(shí)就發(fā)生故障，造成急診病人延誤達十幾小時(shí)。
· 飛機自動(dòng)控制軟件的錯誤造成了飛機在特技飛行表演時(shí)墜毀。
· 自動(dòng)行李處理系統的小小軟件錯誤使丹佛國際機場(chǎng)飛機受阻，到達的行李空等九個(gè)月。
類(lèi)似的例子也很多。當我們每天依靠計算機進(jìn)行工作時(shí)，一旦計算機發(fā)生錯誤，給我們造成的危害是苦不堪言，可能我們幾個(gè)月甚至幾年的勞動(dòng)會(huì )付諸東流。表1.4給出了部分計算機系統實(shí)效源的統計數據。
表1.4計算機系統實(shí)效源的統計數據
系統
數據發(fā)表年份
硬件(%)
軟件(%)
維護(%)
操作(%)
環(huán)境(%)
AT&T ESS
1978
20
15
—
65
—
Tandem
1985
18
26
25
17
14
Bellcore
1986
26
30
—
44
—
Tandem
1987
19
43
13
13
12
可見(jiàn)，軟件故障正逐漸成為導致計算機系統失效的主要因素。
1．6 軟件測試概論
1． 軟件測試的概念
由于軟件及軟件錯誤的復雜性，長(cháng)期以來(lái)，人們對軟件測試的認識一直是模糊的。許多科學(xué)家從不同的角度給出了軟件測試的不同定義，但總體來(lái)看，都是不全面的。Myers認為：“程序測試是為了發(fā)現錯誤而執行程序的過(guò)程”，該定義明確給出了軟件測試就是為了發(fā)現軟件中的錯誤，這一概念目前被人們所公認。但該定義認為軟件測試僅僅是程序編碼的測試，這顯然是不全面的，在某種意義上說(shuō)是有害的，因為許多軟件錯誤并不是編碼上的錯誤，而人們往往會(huì )忽略這一點(diǎn)。
1983年IEEE給出的定義是：“使用人工或自動(dòng)手段來(lái)運行或測定某個(gè)系統的過(guò)程，其目的在于檢驗它是否滿(mǎn)足規定的需求或是弄清楚預期結果與實(shí)際結果之間的差別”。應該說(shuō)該定義是比較全面的。應該說(shuō)，上述兩個(gè)定義都是以檢驗軟件是否存在錯誤為目的，也可以說(shuō)是一種正確性測試。但也有人不同意這種觀(guān)點(diǎn)，認為軟件測試還應包括可靠性測試、健壯性測試、性能測試、效率測試等。作者認為，軟件的測試是和軟件的需求是密切相關(guān)的，對一般的民用軟件，正確性測試是能夠滿(mǎn)足要求的。而對某些關(guān)鍵性軟件，如導航控制軟件、核電站控制軟件等則必須進(jìn)行后幾種測試。但要指出的是，進(jìn)行后幾種測試，僅僅編寫(xiě)一個(gè)軟件測試程序是不夠的，往往研制必須的硬件環(huán)境，其代價(jià)往往是很大的。因此，本文我們所論述的測試一般都是指面向軟件正確性的測試。
2． 如何認識軟件錯誤
目前，影響軟件測試技術(shù)發(fā)展的一個(gè)重要因素就是人們對軟件測試在認識上存在的誤區。誤區之一是設計者、程序員對自己所做的工作特別有信心，不愿意讓別人來(lái)挑自己的毛病。誤區之二是既然軟件測試不能證明軟件是正確的，何必又需要測試呢？誤區之三是由于軟件測試是一種輔助性的工作，既費力又難以出成績(jì)。很多人不愿意做這個(gè)工作。因此，解決人們認識上的問(wèn)題是非常有必要的。
（1）軟件能否徹底的測試：回答是不能。例如，一元二次方程ax2+bx+c=0求根的程序，該程序的3個(gè)輸入a、b、c是實(shí)數，假設計算機有32位（假設8位階碼），每個(gè)數據的數據個(gè)數至少為1030，則總的數據個(gè)數要大于1090。要徹底測試一個(gè)軟件，就要每個(gè)數據都至少運行一次，這是目前所有計算機都不可能做到的。上述還僅僅考慮了輸入的一部分，在使用中，用戶(hù)有意或無(wú)意的可能輸入其它數據，例如字符等?？紤]到這些因素，要徹底測試一個(gè)軟件是不可能的。
軟件不能被徹底的測試并不否定軟件測試的作用。正如一個(gè)再好的醫生也不可能檢查出病人的所有毛病一樣，據此就否定醫生的作用是錯誤的。早在1972年，Dijkstra曾說(shuō)過(guò)一句名言：“軟件測試只能表明錯誤的存在，而不能表明錯誤不存在”。
（2）早期的錯誤是否應在早期排除：回答是肯定的。軟件的錯誤存在于軟件生存期的各個(gè)階段，在每一階段發(fā)現的錯誤都應在此階段將其排除掉，否則，越往后，排除講越困難。有人作過(guò)統計，在后一個(gè)階段排除前一個(gè)階段的錯誤，其費用將提高10倍。經(jīng)過(guò)近些年來(lái)軟件工程技術(shù)的實(shí)踐，人們對這個(gè)問(wèn)題已不在有什么懷疑。但存在的問(wèn)題是：不是人們發(fā)現了早期的錯誤不排除，而是沒(méi)人去發(fā)現早期的錯誤，這種情形很普遍，是軟件設計的災難，必須引起足夠的重視。
（3）能否用驗證技術(shù)代替軟件測試：回答是不能。程序驗證是采用形式化的方法來(lái)檢驗軟件是否正確，從理論上看，該方法對檢驗軟件的錯誤是完備的。但實(shí)際上，程序驗證技術(shù)有很大的局限性，實(shí)踐表明，該方法只能對一些小的例子是有效的，大中型軟件正確性驗證無(wú)論從方法上還是從驗證效率上，都是不實(shí)際的。此外，經(jīng)過(guò)程序驗證的軟件，需求分析錯誤、接口錯誤等也檢驗不出來(lái)。
3． 軟件測試的費用
統計表明，軟件測試與維護的費用要占到整個(gè)軟件開(kāi)發(fā)費用的50%以上。圖1.5給出了估計修復軟件缺陷費用的現行行業(yè)標準（資料來(lái)源：B.Bohem,Software Engineeering,IEEE Transactions on Computer,1976.12）。表明缺陷發(fā)現的越晚，費用將如何驚人的增長(cháng)。
4．
軟件測試的意義
（1）減少軟件的缺陷數目或者降低軟件的缺陷密度：通過(guò)測試可以發(fā)現軟件中存在的缺陷，通過(guò)完全的修改這些缺陷，可以減少軟件中缺陷的總數目或者降低其缺陷密度。
（2）提高軟件的可靠性：軟件的缺陷數目是影響軟件可靠性的主要因素，通過(guò)測試減少軟件的缺陷數目可以達到提高軟件可靠性的目的。
（3）評估軟件的性能指標：通過(guò)軟件測試，根據所發(fā)現的缺陷數目和發(fā)現缺陷的時(shí)間，可以評估軟件的可靠性等指標。即使軟件測試沒(méi)有發(fā)現缺陷，也同樣可以達到這個(gè)目的。
（4）增加用戶(hù)對軟件的信心。軟件通過(guò)了何種測試對用戶(hù)來(lái)說(shuō)是非常重要的，嚴格的軟件測試可以大大用戶(hù)對該軟件的信心。
1．7 軟件測試方法
軟件的錯誤存在于軟件生存期的各個(gè)階段，不同階段的錯誤性質(zhì)是不同的，不同的錯誤對應了不同的測試方法。本章所論述的靜態(tài)測試方法、動(dòng)態(tài)測試方法、黑盒測試方法和白盒測試方法就是根據上述問(wèn)題而發(fā)展起來(lái)的。有些方法是通用的，例如靜態(tài)測試技術(shù)，在軟件生存期各個(gè)階段的錯誤檢測中都可以使用，而有些方法只是對某個(gè)階段才能使用，例如，動(dòng)態(tài)測試技術(shù)，只有當程序出來(lái)以后才能進(jìn)行動(dòng)態(tài)測試。不同的測試方法對各個(gè)階段錯誤檢測的效率也是不同的，有些時(shí)候，在同一階段，當各種方法組合使用時(shí)，錯誤檢測的效果會(huì )更好。此外，對程序測試而言，分步測試更有利于盡快的發(fā)現錯誤，減少測試的開(kāi)銷(xiāo)。
1．靜態(tài)測試方法
（1）測試方法：在軟件開(kāi)發(fā)過(guò)程中，每產(chǎn)生一個(gè)文檔，都必須對它進(jìn)行測試，以確定它的質(zhì)量是否滿(mǎn)足要求。靜態(tài)測試的基本特征是在對軟件進(jìn)行分析、檢查和測試時(shí)不實(shí)際運行被測試的程序。它可以對各種文檔進(jìn)行測試，是軟件開(kāi)發(fā)中十分有效的質(zhì)量控制方法之一。在軟件開(kāi)發(fā)過(guò)程中的早期階段，由于可運行的代碼尚未產(chǎn)生，不可能進(jìn)行動(dòng)態(tài)測試，而這些階段的中間產(chǎn)品的質(zhì)量直接關(guān)系到軟件開(kāi)發(fā)的成敗與開(kāi)銷(xiāo)的大小，因此，在這些階段，靜態(tài)測試的作用尤為重要。目前，比較常用的靜態(tài)測試方法有：Yourdon的結構化走通法和Fagan檢查法。
1） 結構化走通法。結構化走通是由一組人員對一個(gè)文檔從多種不同的角度進(jìn)行檢查，以盡可能多地發(fā)現其中的錯誤。它以該文檔的產(chǎn)生者為中心，由產(chǎn)生者向參加審閱的其他人員報告其文檔。所發(fā)現的錯誤或懷疑是錯誤的問(wèn)題則由召集人記錄在案。審閱的中心問(wèn)題是發(fā)現錯誤，而不是糾正錯誤。在結構化走通的審閱過(guò)后，由文檔的產(chǎn)生者將記錄在案的錯誤糾正。
Yourdon指出，結構化走通的審閱過(guò)程應該由如下人員組成：
· 報告者：該文檔的擁有者和文檔的產(chǎn)生者；
· 召集人：組織并主持審閱；
· 秘書(shū)：負責事先將文檔散發(fā)給有關(guān)人員，記錄審閱過(guò)程和結果，并將記錄遞交給報告者；
· 維護者：將負責維護該文檔的人員的代表；
· 標準檢查員：負責對照該文檔所適用的標準進(jìn)行檢查的人員；
· 用戶(hù)代表：負責從其使用者的觀(guān)點(diǎn)檢查該文檔；
· 其他人員：任何對該文檔的檢查能夠有所貢獻的人員。
2）Fagan檢查。Fagan檢查是由IBM發(fā)展起來(lái)的，其總的原理和Yourdon的結構化走通非常類(lèi)似。但是Fagan檢查是將審閱放在一個(gè)質(zhì)量計劃、度量和控制的更廣泛的環(huán)境下，使之具有雙重目的：一是發(fā)現產(chǎn)品的錯誤；二是通過(guò)對錯誤的分析、統計，提供今后對所發(fā)現的同類(lèi)錯誤進(jìn)行控制的數據。Fagan檢查強調的是對錯誤進(jìn)行分類(lèi)和統計，從而發(fā)現共同的錯誤類(lèi)型和將來(lái)避免這類(lèi)錯誤的方法。簡(jiǎn)言之，Fagan檢查強調對開(kāi)發(fā)過(guò)程的反饋和從錯誤中吸取教訓。
（2）測試內容。靜態(tài)測試測試的范圍和內容很多。從范圍上講，凡是能形成文檔的設計都應該進(jìn)行測試。這包括需求定義文檔的靜態(tài)測試、概要設計文檔的靜態(tài)測試、詳細設計文檔的靜態(tài)測試、編碼文檔的靜態(tài)測試、測試文檔的靜態(tài)測試等。從內容上看，針對不同的文檔，雖測試的內容不盡相同，但都是按照軟件質(zhì)量的要求，即第一章給出的軟件質(zhì)量的11個(gè)要素進(jìn)行測試。下面以源代碼的靜態(tài)測試為例說(shuō)明靜態(tài)測試所包括的內容。
1）完備性測試。檢查代碼是否完全、準確地實(shí)現了設計規約中所規定的內容；代碼是否滿(mǎn)足設計要求；代碼是否創(chuàng )建了所需的數據庫或其它初始化數據；是否有未引用的或未定義的變量、常量或數據類(lèi)型。
2）一致性測試。檢查代碼在邏輯上與設計規約是否一致；是否自始自終使用了相同的格式、調用約定、結構等。
3）正確性測試。代碼是否符合標準；變量的定義和使用是否都正確；注釋是否正確；子程序調用的參數個(gè)數是否正確等。
4）易修改性測試。檢查代碼是否避免了直接使用地址，而采用標號或符號常量；代碼是否由單入口、單出口的子程序構成；是否有交叉引用數據等。
5）可測試性測試。檢查程序中是否有遞歸；是否包含了無(wú)窮循環(huán)等。
6）健壯性測試。檢查代碼是否防止可以發(fā)現的運行時(shí)刻的錯誤，如：下標變量越界、除數為0、棧溢出等。
7）結構化測試。檢查程序的每一個(gè)功能是否都可以作為一塊代碼而識別出；循環(huán)是否只有一個(gè)入口等。
8）易追溯性測試。檢查是否有一個(gè)交叉引用表，通過(guò)它可以便捷地從代碼找到相應的設計；是否有修改歷史記錄，它記錄對代碼的所有修改歷史和修改原因。
9）易理解性測試。檢查注釋是否簡(jiǎn)潔、充分；是否有不必要的復雜代碼等。
10）可驗證性測試。檢查實(shí)現是否避免了使用測試難度大的技術(shù)和方法等。
（3）方法評述：靜態(tài)測試主要靠人來(lái)完成的。雖然近些年來(lái)，從需求分析開(kāi)始的軟件生存期的各個(gè)階段，開(kāi)發(fā)了不少的工具，但短期內難以實(shí)現其設計的自動(dòng)化和測試的自動(dòng)化。因此，靜態(tài)測試錯誤發(fā)現的多少完全依賴(lài)于測試的組織和測試者的水平，實(shí)踐也表明在這個(gè)方面有許多成功的范例，例如中國的某個(gè)有數萬(wàn)行航天類(lèi)控制軟件，通過(guò)靜態(tài)測試發(fā)現了其中的3000多個(gè)缺陷。但從目前靜態(tài)測試的效果來(lái)看尚存在如下的一些問(wèn)題。
1）認識不足。特別是決策者的認識不足。但這種情況正在改變。
2）測試的問(wèn)題太多，不知從何處下手。解決這個(gè)問(wèn)題的辦法是可以對靜態(tài)測試的范圍和內容進(jìn)行分門(mén)別類(lèi)的測試，效果可能會(huì )更好。
3）自動(dòng)化或半自動(dòng)化的測試工具是必須的。有了這個(gè)工具，可以大大提高測試者的興趣和發(fā)現錯誤的能力。但目前基本上是空白。
4）開(kāi)發(fā)的軟件缺少靜態(tài)測試所必須的文檔。這個(gè)在一些地方還十分突出，但這種情況正在好轉。
2． 動(dòng)態(tài)測試方法
靜態(tài)測試只能定性的分析軟件的質(zhì)量，而不能定量。從這種意義上講，靜態(tài)測試是有很大的局限性，但這并不否定靜態(tài)測試的重要性，因為，就發(fā)現一個(gè)錯誤而言，動(dòng)態(tài)測試的花費要大得多。
所謂動(dòng)態(tài)測試，就是通過(guò)運行軟件來(lái)檢驗軟件的動(dòng)態(tài)行為和運行結果的正確性。因此，動(dòng)態(tài)測試只存在于軟件生存期的編碼階段之后。動(dòng)態(tài)測試包括兩個(gè)基本要素：一是被測程序，二是用于運行軟件的數據，稱(chēng)為測試數據，程序一次運行所需要的測試數據稱(chēng)為測試用例，所以測試數據是測試用例的集合。
動(dòng)態(tài)測試的流程如圖1.6所示。因此，一個(gè)成熟的動(dòng)態(tài)測試軟件必須回答下列問(wèn)題：
1） 如何選擇或產(chǎn)生測試用例？
2） 如何組織軟件的測試運行？
3） 如何考察和記錄軟件動(dòng)態(tài)運行的行為？
4） 如何判斷軟件動(dòng)態(tài)行為的正確性？
5） 測試過(guò)程如何結束？
6） 如何通過(guò)軟件測試的結果分析軟件的某些性質(zhì)，如軟件的可靠性等？
動(dòng)態(tài)測試近三十年來(lái)，由于有其比較強的錯誤檢測能力，受到人們的普遍重視，產(chǎn)生了許多測試方法。這些方法可以從兩個(gè)角度對其進(jìn)行分類(lèi)。
（1）按照產(chǎn)生測試數據以及判斷測試充分性的方法：可以分為如下四類(lèi)：
1）結構性測試。結構性測試旨在充分地覆蓋軟件的結構，并以軟件中的某些元素是否都已得到測試為準則來(lái)判斷軟件測試的充分性。本書(shū)將在第四章做詳細介紹。
2）排錯性測試。排錯性測試旨在排除軟件中包含某類(lèi)錯誤的可能性，并根據一個(gè)測試數據集排除軟件錯誤可能性的能力來(lái)度量其測試的充分性。
3）分域測試。分域測試方法通過(guò)對軟件的實(shí)現或/和軟件需求進(jìn)行分析，將軟件的輸入空間劃分成一系列子空間，然后在每一個(gè)子空間內選擇一個(gè)或多個(gè)測試用例。
4）功能測試。功能測試是根據軟件所需的功能或/和所實(shí)現的功能選擇測試數據，分析測試的充分性。
（2）按照產(chǎn)生測試數據所根據的信息來(lái)源：可以分為下列四類(lèi)：
1）以程序為基礎的測試。它通過(guò)對程序的分析來(lái)產(chǎn)生測試數據，它還以程序被執行的程度來(lái)判斷測試是否充分。
2）以需求和功能的規約為基礎的測試。它通過(guò)分析軟件的需求和功能規約來(lái)產(chǎn)生測試數據，并根據軟件需求和功能規約中所規定的功能和性能是否都得到了充分的檢驗來(lái)判斷測試是否充分。
3）程序和需求相結合的測試。它綜合考慮軟件的需求和實(shí)現來(lái)產(chǎn)生測試數據，判斷測試的充分性，這是目前最常用的方法，可以擬補（1）和（2）單個(gè)方法的不足。
4）以界面為基礎的測試。以界面為基礎的測試僅僅依靠軟件與其運行環(huán)境之間的界面來(lái)產(chǎn)生測試數據，并以界面和界面內所包含的功能是否都得到測試來(lái)判斷測試的充分性。這是面向對象技術(shù)常用的測試方法。
3．黑盒測試方法
黑盒測試又稱(chēng)功能測試、數據驅動(dòng)測試和基于規格說(shuō)明的測試。用這種方法進(jìn)行程序測試時(shí)，被測程序被當作一個(gè)打不開(kāi)的黑盒，測試者是在完全不知道程序內部結構的情況下進(jìn)行的，而只需知道程序的輸入和輸出之間的關(guān)系亦可。因此，黑盒測試是基于用戶(hù)的測試。測試者正是依靠這個(gè)關(guān)系來(lái)產(chǎn)生測試用例，并判斷運行結果的正確性。進(jìn)行黑盒測試必須要弄清楚下列幾個(gè)問(wèn)題：
（1）軟件的功能到底有多少？這是進(jìn)行黑盒測試所必須的，否則，測試是不可能充分的。
（2）測試的層次是什么？也就是說(shuō)，測試要在哪個(gè)層次上進(jìn)行。因為，在軟件的總體功能之下可能有若干個(gè)層次的功能，在需求分析層描述的功能一般比較粗，在這個(gè)層次上進(jìn)行測試可能會(huì )漏掉一些細節。而在代碼層則一般比較細，但在這個(gè)層次上進(jìn)行測試可能會(huì )忽視各個(gè)功能之間存在的相互作用和相互依賴(lài)的關(guān)系。因此測試人員需要考慮并兼顧各個(gè)層次的功能。也正是由于這個(gè)原因，使得黑盒測試的影響大大降低。
黑盒測試是必要的，有時(shí)也是必須的。所謂是必須的，是作為測試者而言，并不總能得到程序的源代碼，而往往只有程序的說(shuō)明書(shū)和執行代碼，在此情況下，唯一的測試方法就必須采用黑盒測試技術(shù)。所謂必要的，是相對白盒測試而言的，主要表現如下幾個(gè)方面：
（1）白盒測試并不是最后的測試手段，因為白盒測試驗證不了諸如軟件可靠性等參數，而這恰恰是黑盒測試所要做的工作。
（2）黑盒測試不能對程序的特定部位進(jìn)行測試，因而無(wú)法對程序進(jìn)行排錯。而這恰恰是白盒測試可以做到的。
對一般的測試軟件系統，采用黑盒測試和白盒測試相結合的測試方法，往往會(huì )取得更好的測試效果。
4．白盒測試方法
白盒測試又稱(chēng)結構測試、邏輯驅動(dòng)測試或基于程序的測試。用這種方法進(jìn)行程序測試時(shí)，測試者可以看到被測程序，并利用其分析程序的內部構造。因此，白盒測試是基于程序的測試。白盒測試是根據被測程序的內部結構設計測試用例的一類(lèi)測試。它要求對被測程序的結構特性做到一定程度的覆蓋，因此，白盒測試也稱(chēng)為基于覆蓋的測試技術(shù)。到目前為止，已經(jīng)提出了幾十種覆蓋技術(shù)，我們將在第四章做詳細論述。但必須說(shuō)明無(wú)論那種白盒測試的覆蓋技術(shù)，即使達到100%的覆蓋率，也不能保障把所有的錯誤都檢測出來(lái)。對于某些在規格說(shuō)明書(shū)中規定的，但在實(shí)現中被漏掉的功能，無(wú)論那一種測試也檢測不出來(lái)的。因此，提高結構測試的覆蓋率只能增強人們對被測軟件的信心。
動(dòng)態(tài)測試和靜態(tài)測試是一種分類(lèi)方法，黑盒測試與白盒測試又是另外的一種分類(lèi)方法。二者是有許多交叉的。動(dòng)態(tài)測試含有黑盒測試與白盒測試，靜態(tài)測試一般只含有白盒測試。黑盒測試一般都是動(dòng)態(tài)測試，而白盒測試一般都包含動(dòng)態(tài)測試和靜態(tài)測試。
5．其它測試方法
（1）可靠性測試與排錯性測試：可靠性測試是以驗證或評估軟件的可靠性為目的，并不關(guān)心測試過(guò)程中所發(fā)現的錯誤。正如前邊所述，軟件錯誤是不可能完全避免的，軟件存在的錯誤并不影響軟件的交付，用戶(hù)所關(guān)心的是軟件的可靠性究竟是多少。排錯性測試則恰恰相反，該測試是以排除軟件錯誤為目的的，一旦測試發(fā)現錯誤，就立刻予以排除。一般而言，排錯性測試用于軟件測試的早期階段，并以白盒測試為主要測試手段。而可靠性測試用于軟件測試的末尾階段，一般以黑盒測試為主要測試手段。
（3）人工測試與自動(dòng)測試：顧名思義，人工測試是采用人工的手段對軟件實(shí)施的測試，它是相對自動(dòng)測試而言的。和靜態(tài)測試不同，人工測試貫穿于軟件生存期的各個(gè)階段，并通過(guò)人工運行和審查會(huì )的形式對軟件實(shí)施的測試。人工測試中，主要是測試人員根據一些成熟的軟件設計規則對軟件的正確性等進(jìn)行審查，檢驗所進(jìn)行的設計是否能滿(mǎn)足需要。實(shí)踐表明，人工測試是非常有效但往往被忽略。統計表明，人工測試能發(fā)現30%~70%的錯誤，IBM公司的代碼審查會(huì )的查錯率更高，竟能查出全部錯誤的80%。軟件測試還有其它更多的測試方法，在后面的幾章中將有詳細的敘述。
1．8 軟件測試步驟
圖1.7給出了軟件的生存期和軟件測試之間的關(guān)系。也可以用圖1.8來(lái)描述，即軟件測試的V模型。軟件測試是要分步進(jìn)行的，為什么呢？打一個(gè)比方，對一個(gè)1000行的程序搜索一個(gè)錯誤和10個(gè)100行的程序搜索一個(gè)錯誤其代價(jià)是不一樣的。從軟件測試的角度來(lái)看，分步測試的原因有三個(gè)：一是和上述例子類(lèi)似，即把大問(wèn)題劃成小問(wèn)題，這更有利于問(wèn)題的求解。二是軟件則不同的層次上，其錯誤的類(lèi)型是不一樣的，其測試的側重點(diǎn)和測試方法是不同的。其三是在級別高的層次上檢測低級層次上的錯誤其花費要大幅度的增長(cháng)，圖有人做過(guò)統計，在下面的給出的四個(gè)測試層次上，即單元測試、集成測試、確認測試和系統測試，層次每增加一
級，測試一個(gè)錯誤的代價(jià)就要提高10倍以上，圖1.5也充分的說(shuō)明了這一點(diǎn)?？梢杂脠D1.9來(lái)表示各個(gè)測試步驟之間的關(guān)系。
（1）單元測試：?jiǎn)卧獪y試是對軟件中的基本組成單位進(jìn)行測試，如一個(gè)模塊、一個(gè)過(guò)程、一個(gè)函數或一個(gè)類(lèi)，等等。單元測試是軟件測試最基本的組成部分，也是最重要的部分之一。其目的是檢驗軟件基本組成單位的正確性。一個(gè)軟件單元的正確性是相對該單元的規約而言的，因此，單元測試是以被測單位的規約為基準。單元測試要注意如下的問(wèn)題：
1）單元的大小要適宜。一般是以程序中給出的模塊為準，但有時(shí)一個(gè)模塊可能太大，有時(shí)也可能太少，這二者都會(huì )對單元測試的效果產(chǎn)生不利的影響。一般來(lái)講，一個(gè)單元模塊在幾十行到幾百行源代碼為宜。
2）單元測試一般要給出驅動(dòng)模塊和樁模塊。一般來(lái)講，一個(gè)單元是不能獨立運行的，因此，要設計一些模塊，使之能驅動(dòng)被測模塊的執行，這種模塊稱(chēng)之為驅動(dòng)模塊。另外，一個(gè)被測模塊還可能調用其它的模塊，而在測試一個(gè)單元時(shí)，一般是不考慮其它模塊的測試的，因此設計一類(lèi)模塊稱(chēng)之為樁模塊，用于模擬運行被測模塊時(shí)調用的其它模塊。
（2）集成測試：集成測試是在軟件系統集成過(guò)程中所進(jìn)行的測試，其主要目的是檢查軟件單位之間接口的正確性。它根據集成測試計劃，一邊將模塊或其它軟件單位組合成越來(lái)越大的系統，一邊運行該系統，以分析所組成的系統是否正確，各組成部分是否合拍。集成測試的策略主要有自頂向下和自底向上兩種。
1）自頂向下的集成測試策略從軟件的主控模塊入手，將其直接調用的模塊首先與其集成。并將該子系統所調用的過(guò)程和所使用的數據用一些簡(jiǎn)單的代碼——即樁模塊代替，在樁模塊的幫助下，可以運行并測試這一子系統，直至測試結果滿(mǎn)足要求為止。然后，將這一子系統所調用的模塊與該子系統集成，并重復上述過(guò)程，直到測試完畢。
2）自底向上的集成測試策略則相反，從軟件中不調用任何其它單元的模塊入手，把直接調用該模塊的程序與其集成在一起，在驅動(dòng)模塊的幫助下，完成該子系統的測試。然后，再把調用該子系統的模塊和該子系統集成，并重復上述過(guò)程，直到測試完畢。
這兩種方法各有優(yōu)缺點(diǎn)，在實(shí)踐中，可將兩種方法相結合。
（3）系統測試：系統測試是對已經(jīng)集成好的軟件系統進(jìn)行徹底的測試，以檢驗軟件系統的正確性和性能（如運算的精度、系統的反應時(shí)間）等是否滿(mǎn)足其規約所指定的要求。系統測試在許多情況下是比較復雜的，僅僅編制一個(gè)測試程序是不夠的，往往伴隨著(zhù)要建立一個(gè)軟硬結合的測試系統。
（4）驗收測試：驗收測試旨在向軟件的購買(mǎi)者展示該軟件系統滿(mǎn)足其用戶(hù)的要求。它的測試數據通常是系統測試數據的子集。所不同的是，驗收測試常常需要用戶(hù)的代表在場(chǎng)，甚至在軟件安裝的現場(chǎng)。這是投入使用前的最后測試。
（5）回歸測試：回歸測試是在軟件維護階段，對軟件修改之后進(jìn)行的測試。其目的是檢驗對軟件進(jìn)行的修改是否正確。這里，修改的正確性有兩重含義：一是指所作的修改達到了預期的目的，如錯誤得到改正，能夠適應新的運行環(huán)境。二是指不影響軟件的其它功能的正確性。
回歸測試通常包括重新運行系統測試中的部分測試數據。因此，需要搞清楚哪些測試數據是與被修改的代碼有關(guān)。在軟件開(kāi)發(fā)過(guò)程中，保留測試數據與程序代碼之間的關(guān)系對回歸測試具有很大的幫助?；貧w測試還往往需要使用針對所修改的代碼的測試數據。這樣的測試數據可以根據單元測試、集成測試和系統測試的方法產(chǎn)生。
1．9 軟件測試與軟件可靠性
從理論上看，軟件的可靠性只和存在于軟件中的故障有關(guān)。假設軟件S中有n個(gè)故障f1,f2,…,fn，直觀(guān)上，軟件S的可靠性R可以表示為RS= RS（f1,f2,…,fn）。假設D是S的定義域，f(D)是D中每個(gè)點(diǎn)取值的概率，{D，f(D)}是S的運行剖面，在{D，f(D)}下，假設每個(gè)故障被檢測的概率為qi=P(fi)，這里，所謂的檢測概率是指一次性檢測該故障的概率，或者說(shuō)，一次運行產(chǎn)生錯誤的概率。若S中存在n個(gè)故障，則：
定理1：若n個(gè)故障f1，f2，…，fn是相互獨立的，則：
實(shí)際上l即是在存在n個(gè)故障的前提下，軟件S的風(fēng)險函數。
根據軟件可靠性理論，軟件S初始的故障數目可以假設為一個(gè)常數n。隨著(zhù)測試的進(jìn)行，存在于軟件S的故障不斷的被排除（假設是完全排除，即不引入新的故障），存在于軟件中的故障會(huì )越來(lái)越少。由于每排除一個(gè)故障后，剩余的存在于S中故障集合是排除前存在于S中故障集合的子集，因此不難證明：
定理2：設F1和F2是軟件S兩個(gè)故障集合，若F1ÍF2，則l(F1)£ l(F2)；若F1ÌF2，則l(F1)< l(F2)。
可以看出，隨著(zhù)測試的進(jìn)行，故障被檢測并被排除，軟件的風(fēng)險函數越來(lái)越少，其可靠性會(huì )越來(lái)越高。因此，軟件測試是發(fā)現軟件故障，提高軟件可靠性的重要手段。
【例1.1】 假設軟件中有5個(gè)錯誤，每個(gè)錯誤被檢測的概率分別為：q1=10-6，q2=10-7，q3=10-8，q4=10-9，q5=10-10，時(shí)間單位是秒。假設錯誤的檢測與排除是按照從檢測概率大的到檢測概率小的依次進(jìn)行，因此，其對應的風(fēng)險函數和平均無(wú)故障時(shí)間分別為：
（1） 初始狀態(tài)：l1=1.11´10-6，MTBF=31.25(天)（每天按8小時(shí)計算）
（2） 排除第一個(gè)故障后：l2=1.11´10-7，MTBF=312.5(天)
（3） 排除第二個(gè)故障后：l3=1.11´10-8，MTBF=3128.1(天)
（4） 排除第三個(gè)故障后：l4=1.11´10-9，MTBF=31565.7(天)
（5） 排除第四個(gè)故障后：l5=10-10，MTBF=347222.2(天)
1．10 影響軟件測試效率的因素
同其它任何一個(gè)產(chǎn)品相比，軟件的測試是更為復雜的，這主要是因為到目前為止，人們對軟件的錯誤發(fā)生的規律認識的還不是很清楚，軟件測試也缺少有效的工具。影響軟件測試的效率的因素是很多的，除了測試方法之外，主要因素還有人為因素、軟件類(lèi)型、錯誤類(lèi)型、測試充分度等。下面對這些因素進(jìn)行一些分析。
1.人為因素
在軟件測試缺少自動(dòng)化程度高的測試工具的前提下，軟件測試的許多工作是由人來(lái)完成的。因此，人的因素是影響測試效率的重要方面。Basili和Selby的實(shí)驗數據清楚地揭示出了人為因素的作用。表1.3揭示了不同水平層次的測試人員在發(fā)現軟件錯誤的數量和測試效率的差異。這里，階段1、2和3分別對應單元測試、集成測試和系統測試。
表1.3 人為因素對測試效率的影響
測試者水平層次
階段
初級
中級
高級
平均值
標準差
平均值
標準差
平均值
標準差
發(fā)現錯誤的個(gè)數
1
3.88
1.89
4.07
1.69
2
3.04
2.07
3.83
1.64
3
3.90
1.83
4.18
1.99
5.00
1.53
發(fā)現錯誤的效率
1
1.36
0.97
2.22
1.66
2
1.00
0.85
0.96
0.74
3
2.14
2.48
2.53
2.48
2.36
1.61
2.軟件類(lèi)型
軟件類(lèi)型也是影響測試效率的一個(gè)重要因素，表1.4是Basili和Selby的實(shí)驗數據。P1~P4代表了4個(gè)不同的程序。
表1.4 軟件類(lèi)型對測試效率的影響
程 序
階段
P1
P2
P3
P4
平均值
標準差
平均值
標準差
平均值
標準差
平均值
標準差
發(fā)現錯誤的個(gè)數
1
4.07
1.62
3.48
1.45
4.28
2.25
2
3.23
2.20
3.31
1.97
3.31
1.84
3
4.19
1.73
5.22
1.75
3.41
1.66
發(fā)現錯誤的效率
1
1.60
1.39
1.19
0.83
2.09
1.42
2
0.98
0.67
0.71
0.71
1.05
1.04
3
2.15
1.10
3.70
3.26
1.14
0.79
3.錯誤類(lèi)型
各種不同的測試方法檢測不同錯誤類(lèi)型的能力也是不同的。錯誤的分類(lèi)方法目前有許多種，前邊已經(jīng)給出了比較詳細的分類(lèi)方法，為分析方便，下列分類(lèi)是其中的一種簡(jiǎn)單的分類(lèi)方法。
（1）初始化錯誤：初始化代碼中的錯誤；
（2）控制錯誤：控制轉移的條件或轉移地址錯誤；
（3）數據錯誤：包括程序中的常數、數據庫中的數據錯誤等；
（4）計算錯誤：計算代碼錯誤
（5）集成錯誤：各模塊之間、軟件與環(huán)境之間的錯誤
（6）容貌錯誤：人機界面、打印格式等錯誤。
圖1.10中是根據是Basili和Selby的實(shí)驗數據整理的。
4.測試充分度
測試充分度是反映了在給定的測試方法下軟件被測試的程度。設M是給定的測試方法，在M下，軟件S應被測試的元素的集合是T，而實(shí)際上被測試元素的集合為U，則U/T即是測試充分度。Frankl和Weiss發(fā)現，只有當測試的充分度接近100%時(shí)，才能使測試發(fā)現錯誤的能力得到發(fā)揮。如圖1.11所示。
1．11 軟件測試工具
軟件測試工具是提高軟件測試效率的重要手段，是軟件理論和技術(shù)發(fā)展的重要標志。也是軟件測試技術(shù)從實(shí)驗室走向產(chǎn)業(yè)的重要標志。軟件測試工具是伴隨軟件測試技術(shù)的發(fā)展而發(fā)展的。目前，應用比較廣泛的軟件測試工具有下列幾種類(lèi)型：
（1）測試設計工具：測試設計工具有助于準備測試輸入或測試數據。測試設計工具包括邏輯設計工具和物理設計工具。邏輯設計工具涉及到說(shuō)明、接口或代碼邏輯，有時(shí)也叫做測試用例生成器。物理設計工具操作已有的數據或產(chǎn)生測試數據。如可以隨機從數據庫中抽取記錄的工具就是物理設計工具。從說(shuō)明中獲取測試數據的工具就是邏輯設計工具。
（2）測試管理工具：測試管理工具是指幫助完成測試計劃，跟蹤測試運行結果等的工具。這類(lèi)工具還包括有助于需求、設計、編碼測試及缺陷跟蹤的工具。其代表工具有MI公司的Test Director， Rational公司的Test Manager， Compureware公司的TrackRecord等。
（3）靜態(tài)分析工具：靜態(tài)分析工具直接對代碼進(jìn)行分析，不需要運行代碼，也不需要對代碼編譯鏈接，生成可執行文件。靜態(tài)分析工具一般是對代碼進(jìn)行語(yǔ)法掃描，找出不符合編碼規范的地方，根據某種質(zhì)量模型評價(jià)代碼的質(zhì)量，生成系統的調用關(guān)系圖等。靜態(tài)分析工具的代表有Telelogic公司的Logiscope軟件，PR公司的PRQA軟件，Reasoning公司的Illuma軟件。
（4）動(dòng)態(tài)分析工具：動(dòng)態(tài)分析工具與靜態(tài)分析工具不同，動(dòng)態(tài)測試工具的一般采用“插樁”的方式，向代碼生成的可執行文件中插入一些監測代碼，用來(lái)統計程序運行時(shí)的數據。其與靜態(tài)分析工具最大的不同就是動(dòng)態(tài)分析工具要求被測系統實(shí)際運行。其代表有Compuware公司的DevPartner軟件、Rational公司的Purify系列產(chǎn)品。
（5）覆蓋測試工具：覆蓋工具評估通過(guò)一系列的測試，測試軟件被測試執行的程度。覆蓋工具大量的用于單元測試中。例如，對于安全性要求高或與安全有關(guān)的系統，則要求的覆蓋程度也較高。覆蓋工具還可以度量設計層次結構，如調用樹(shù)結構的覆蓋率。如Telelogic公司的TestChecker測試軟件。
（6）負載和性能測試工具：性能測試工具檢測每個(gè)事件所需要的時(shí)間。例如，性能測試工具可以測定典型或負載條件下的響應時(shí)間。負載測試可以產(chǎn)生系統流量。例如產(chǎn)生許多代表典型情況或最大情況下的事物。這種類(lèi)型的測試工具用于容量和壓力測試。專(zhuān)用于性能測試的工具有Radview公司的WebLoad、，icrosoft公司的WebStress，MI公司的LoadRunner等工具。
（7）GUI測試驅動(dòng)和捕獲/回放工具：這類(lèi)測試工具可使測試自動(dòng)執行，然后將測試輸出結果與期望輸出進(jìn)行比較。此類(lèi)測試工具可在任何層次中執行測試：?jiǎn)卧獪y試、集成測試、系統測試或驗收測試。捕獲回放工具是目前使用的測試工具中最流行的一種。其代表有Rational公司的TeamTest、Robot，Compuware公司的QACenter，MI公司的WinRunner等。
（8）基于故障的測試工具：首先給出軟件的故障模型，在此故障模型下，給出基于該故障模型的軟件測試工具。這是目前一種有很好發(fā)展前景的軟件測試工具。隨著(zhù)人們對軟件故障認識的不斷深入，軟件的故障模型也會(huì )越來(lái)越完備，并更加符合實(shí)際?；诠收系能浖y試工具有三個(gè)需要研究的問(wèn)題：一是故障模型的準確程度，二是測試的準確程度，三是測試的自動(dòng)化程度。目前比較典型的是Rational公司的C++測試產(chǎn)品C—Inspector。
1．12 軟件測試技術(shù)的發(fā)展現狀
軟件測試技術(shù)是和程序聯(lián)系在一起的，自從有了程序，也就有了軟件測試。只不過(guò)是早期人們沒(méi)有認識到這個(gè)問(wèn)題罷了。
早在二十世紀五十年代，英國著(zhù)名的計算機科學(xué)家圖靈就曾給出了程序測試的原始定義：測試是正確性確認的實(shí)驗方法的一種極端形式。但在這個(gè)時(shí)期，程序一般是比較簡(jiǎn)單的，控制類(lèi)程序和計算類(lèi)程序是主要的，程序的規模一般在幾百~幾千行源代碼。程序設計者、編程人員和程序測試者一般都是一個(gè)人，測試者可以簡(jiǎn)單的根據程序的功能對程序進(jìn)行測試，并簡(jiǎn)單的根據結果的正確性來(lái)決定程序是否有錯誤。由于程序規模小，一般程序的正確性也不存在大的什么問(wèn)題。
五十年代以后，隨著(zhù)高級語(yǔ)言的誕生和廣泛應用，軟件的規模急劇增大，就計算機科學(xué)本身來(lái)說(shuō)，操作系統軟件、編譯軟件等一般都在數萬(wàn)行源代碼，而且由于這種軟件一般都是計算機系統運行的核心，其正確性和可靠性的要求都比較高，傳統程序設計的思想和軟件不可靠性的矛盾日趨突出。于七十年代誕生的軟件工程技術(shù)是軟件發(fā)展的里程碑，它在某種程度上緩解了這個(gè)矛盾，但沒(méi)有從根本上解決問(wèn)題。
七十年代中期以后，是軟件測試技術(shù)發(fā)展的最活躍的時(shí)期。Brooks總結了開(kāi)發(fā)IBM OS/360操作系統中的經(jīng)驗，在著(zhù)名的《神秘的人—月》一書(shū)中闡明了軟件測試在研制大系統中的重要意義。1975年，美國黃榮昌教授在論文中討論了測試準則、測試過(guò)程、路徑謂詞、測試數據及其生成問(wèn)題，首次全面系統地論述了軟件測試的有關(guān)問(wèn)題。Hetzel在1975年整理出版了《Program Test Methods》一書(shū)，書(shū)中縱覽了測試方法及各種自動(dòng)測試工具，這是專(zhuān)題論述軟件測試的第一本著(zhù)作。Goodenough和Gerhart首次提出了軟件測試的理論，從而把軟件測試這一實(shí)踐性很強的學(xué)科提高到理論的高度，被認為是測試技術(shù)發(fā)展過(guò)程中具有開(kāi)創(chuàng )性的工作。此后不久，著(zhù)名測試專(zhuān)家Howden指出了上述理論的缺陷，并進(jìn)行了新的開(kāi)創(chuàng )性工作。以后，Weyuker，Ostrand，Geller和Gerhart等進(jìn)一步總結原有的測試理論并進(jìn)一步加以完善，使軟件測試成為有理論指導的實(shí)踐性學(xué)科。
在軟件測試理論迅速發(fā)展的同時(shí)，各種軟件測試方法也應運而生。黃榮昌提出了程序插裝測試技術(shù)；Howden在路徑分析的基礎上，提出了系統功能測試和代數測試的概念；Howden、Clarke和Darringer等人提出了符號測試方法，并建立了DISSET符號測試系統；Demillo提出了程序變異測試方法；Osterweil和Fosdick提出了數據流測試方法；White和Cohen提出了域測試方法；Richardson和Clarke提出了劃分測試方法?？傊?，七十年代至八十年代，是軟件測試技術(shù)迅速發(fā)展的時(shí)期，數十種軟件測試方法被提出，軟件測試技術(shù)已迅速發(fā)展成為一個(gè)獨立的學(xué)科。
但總體來(lái)看，七十年代至八十年代，軟件測試技術(shù)的研究主要是在理論上。實(shí)用的軟件測試系統并不多見(jiàn)，少數的測試系統由于測試效率不高，也難以進(jìn)入市場(chǎng)。
進(jìn)入二十世紀九十年代，隨著(zhù)計算機技術(shù)的日趨普及，軟件的應用范圍逐步擴大，一些關(guān)系到國際民生的行業(yè)、關(guān)系到國家安全的重要部門(mén)已變得越來(lái)越依賴(lài)軟件。軟件的規模在大幅度的擴大，軟件的復雜性在大幅度的提高，由于軟件測試技術(shù)的發(fā)展遠遠落后于軟件技術(shù)的發(fā)展，軟件不可靠性的矛盾變得更加突出。因此，進(jìn)入九十年代，軟件的質(zhì)量與可靠性已引起了政府和社會(huì )的廣泛重視，各種實(shí)用的軟件測試系統不斷涌現，軟件測試產(chǎn)品也逐步的進(jìn)入市場(chǎng)，專(zhuān)門(mén)從事軟件測試的公司也相繼出現，這為保證軟件的質(zhì)量與可靠性奠定了重要基礎。進(jìn)入2000年以來(lái)，我國軟件測試技術(shù)發(fā)展極為迅速，全國目前大約有100余家軟件評測中心，軟件測試的從業(yè)人員有數千人，2003年軟件測試的產(chǎn)值達到了數億人民幣。
在軟件測試技術(shù)的學(xué)術(shù)領(lǐng)域，1982年，在美國北卡羅來(lái)納大學(xué)召開(kāi)了首屆軟件測試的正式學(xué)術(shù)會(huì )議，之后，該學(xué)術(shù)會(huì )議每?jì)赡暾匍_(kāi)一次，此外，國際上還有軟件可靠性會(huì )議，從會(huì )議的規模和論文的數量與質(zhì)量上看，從事軟件測試技術(shù)的人員在大幅度的增加。我國目前雖然沒(méi)有專(zhuān)門(mén)的軟件測試的學(xué)術(shù)組織，但目前在容錯計算專(zhuān)業(yè)委員會(huì )的學(xué)術(shù)會(huì )議上、全國測試學(xué)術(shù)會(huì )議上都能受到大量的軟件測試技術(shù)的學(xué)術(shù)論文。2004年8月，在青海省西寧市召開(kāi)了全國首屆軟件測試技術(shù)研討會(huì ),2007年，將在昆明召開(kāi)第二屆全國軟件測試技術(shù)研討會(huì )。
可以預測，在未來(lái)的時(shí)間里，軟件測試技術(shù)與行業(yè)將會(huì )得到更快的發(fā)展，主要可能的表現包括：軟件測試理論更加完善，測試效率更加提高；更實(shí)用的軟件測試系統將會(huì )大量出現；更多的專(zhuān)門(mén)從事軟件測試與可靠性評估的公司將會(huì )誕生。
