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