軟件測試與質(zhì)量保證飛軟件測試從計(jì)算機(jī)誕生至今，計(jì)算機(jī)無疑成為當(dāng)代發(fā)展最為迅猛的科學(xué)技術(shù)。今天，計(jì)算機(jī)已滲透到人們生活的各個方面。工業(yè)農(nóng)業(yè)金融科教衛(wèi)生國防百姓生活軟件測試隨著對計(jì)算機(jī)需求和依賴的與日俱增其軟件開發(fā)成本以及由于軟件故障而造成的經(jīng)濟(jì)損失也正在增加軟件質(zhì)量問題已成為人們共同關(guān)注的焦點(diǎn)。計(jì)算機(jī)系統(tǒng)的規(guī)模和復(fù)雜性急劇增加軟件測試軟件開發(fā)商為了占有市場，把軟件質(zhì)量作為企業(yè)的重要目標(biāo)之一，以免在激烈的競爭中被淘汰出局。用戶為了保證自己業(yè)務(wù)的順利完成，當(dāng)然也希望選用優(yōu)質(zhì)的軟件。軟件測試一些關(guān)鍵應(yīng)用，如民航訂票系統(tǒng)、銀行結(jié)算系統(tǒng)、證券交易系統(tǒng)、自動飛行控制軟件、軍事防御、核電站安全控制系統(tǒng)對軟件質(zhì)量提出了更高的要求。軟件測試使用質(zhì)量欠佳的軟件，還可能造成災(zāi)難性的后果。2003年,軟件問題造成美國東北部及加拿大停電,導(dǎo)致5000萬人受影響,3人喪生,

各種損失估計(jì)約為60億美元2004年,北美銀行由于一個新安裝的軟件的缺陷,使得數(shù)以百萬計(jì)的客戶受到影響,該缺陷的修復(fù)花費(fèi)了整整兩個星期的時間,造成的損失以億元計(jì)2000年美國海軍飛機(jī)墜落,導(dǎo)致4人喪生(控制軟件問題)1997年韓國空難,導(dǎo)致225人喪生(雷達(dá)控制軟件問題)2003年4月,美國一個專門為學(xué)生提供貸款的公司由于軟件出錯,錯誤計(jì)算80萬宗學(xué)生貸款利率,導(dǎo)致了800萬美元的利率損失千年蟲問題Intel芯片浮點(diǎn)除法軟件故障等。因此，許多科學(xué)家在展望21世紀(jì)計(jì)算機(jī)科學(xué)發(fā)展方向和策略時，把軟件質(zhì)量放在優(yōu)先于提高軟件功能和性能的地位。軟件測試軟件測試是對軟件需求分析、設(shè)計(jì)規(guī)格說明和編碼的最終復(fù)審是軟件質(zhì)量保證的關(guān)鍵步驟是為了發(fā)現(xiàn)故障而執(zhí)行程序的過程。軟件測試隨著軟件系統(tǒng)規(guī)模和復(fù)雜性的增加，進(jìn)行專業(yè)化高效軟件測試的要求越來越嚴(yán)格，軟件測試職業(yè)的價值逐步得到了認(rèn)可，軟件測試從業(yè)人員急劇增加，軟件測試評測中心如雨后春筍般成長起來。軟件測試軟件測試無疑是面向未來信息化社會的熱門專業(yè)之一在未來3~5年內(nèi)，軟件測試技術(shù)將作為一門新興產(chǎn)業(yè)而快速發(fā)展起來。內(nèi)容提要：第一章

軟件測試概述第二章

軟件測試實(shí)質(zhì)第三章

軟件測試策略第四章

黑盒測試第五章

白盒測試第六章

集成測試與系統(tǒng)測試第七章

驗(yàn)證測試和確認(rèn)測試第八章

測試計(jì)劃與測試文檔第九章

面向?qū)ο蟮能浖y試第十章

軟件測試自動化和測試工具第十一章

軟件質(zhì)量保證第十二章

軟件測試職業(yè)指導(dǎo)第一章 軟件測試概述計(jì)算機(jī)系統(tǒng)的軟件可靠性問題軟件測試與軟件可靠性軟件測試的發(fā)展歷史、現(xiàn)狀和展望人們對計(jì)算機(jī)依賴的程度越高，對其可靠性的要求就越高。IEEE(Institute

ofElectricalandElectronicsEngineers，電氣與電子工程師學(xué)會)定義軟件可靠性為：系統(tǒng)在特定的環(huán)境下，在給定的時間內(nèi)，無故障地運(yùn)行的概率。

用來評價軟件按照用戶的要求和設(shè)計(jì)目標(biāo)，完成規(guī)定功能的能力，涉及軟件的性能、功能性、可用性、可服務(wù)性、可安裝性、可維護(hù)性以及文擋等多方面特性。軟件測試是保證軟件可靠性的一個關(guān)鍵因素。1.軟件測試的重要性計(jì)算機(jī)和程序是一對孿生兄弟,自從計(jì)算機(jī)誕生之日就必須要有程序在其上運(yùn)行,從而得到問題的正確解,必須對程序的功能性進(jìn)行測試.所以,軟件測試工作是在軟件工程誕生之前就客觀存在了,一直延用至今,且其測試的內(nèi)容和技術(shù)也有了較大的發(fā)展。無論從何種角度講，軟件測試都是軟件開發(fā)過程一個必不可少的活動，是對軟件需求分析、設(shè)計(jì)規(guī)約和編碼的最終復(fù)審；是軟件質(zhì)量保證的關(guān)鍵步驟。軟件測試是根據(jù)軟件開發(fā)各階段的規(guī)約和軟件的內(nèi)部結(jié)構(gòu)，精心設(shè)計(jì)一批測試用例（包括輸入數(shù)據(jù)及其預(yù)期的輸出結(jié)果），并利用這些測試用例去運(yùn)行程序，以發(fā)現(xiàn)軟件中不符合質(zhì)量特性要求（即缺陷或錯誤）的過程。目前，許多軟件開發(fā)機(jī)構(gòu)將研制力量的40%以上投入到軟件測試之中，體現(xiàn)了充分重視軟件質(zhì)量要求。可見軟件測試的重要性。軟件測試不等同于程序測試。軟件測試應(yīng)當(dāng)貫穿在軟件生存周期全過程。因此，需求描述、需求規(guī)約、設(shè)計(jì)規(guī)約、模塊設(shè)書以及程序等都應(yīng)成為軟件測試的對象。在進(jìn)行軟件產(chǎn)品或軟件系統(tǒng)開發(fā)時，主要有3類人員必須參與，他們是項(xiàng)目經(jīng)理、開發(fā)人員和測試人員。一般來說，大家都會十分重視開發(fā)工作，因此在一個項(xiàng)目組中，會有很多的開發(fā)人員，而測試人員比較少。經(jīng)過多次實(shí)踐后，才會增加測試人員，如微軟公司就是這種情況。目前軟件測試人員就比較多了，如Exchange

2000，項(xiàng)目經(jīng)理23人，開發(fā)人員140人，測試人員350人；再如Windows2000，項(xiàng)目經(jīng)理250人，開發(fā)人員1700人，測試人員3200人，可以看出測試人員和開發(fā)人員之比，竟達(dá)5：3。2.軟件測試的目的和原則基于不同的立場，存在著不同的測試目的。從用戶的角度看，一般希望通過軟件測試暴露軟件中隱藏的缺陷，以此來決定是否可以接受該軟件產(chǎn)品和軟件系統(tǒng)。從軟件開發(fā)者的角度看，希望通過測試說明軟件中不存在缺

陷，表明該軟件已正確地實(shí)現(xiàn)了用戶的要求，從而確立用戶對該軟件的質(zhì)量信任。從軟件管理者角度看，希望花費(fèi)有限的資源達(dá)到該軟件用戶的質(zhì)量要求，經(jīng)費(fèi)和進(jìn)度是其首要考慮的焦點(diǎn)。因此，就軟件測試的目的可提出如下的觀點(diǎn)：測試是程序的執(zhí)行過程，目的在于發(fā)現(xiàn)缺陷；一個好的測試用例在于能發(fā)現(xiàn)至今未發(fā)現(xiàn)的缺陷；一個成功的測試是發(fā)現(xiàn)了至今未發(fā)現(xiàn)的多個缺陷的測試。所以，測試的目的是以最少的資源和時間，找出軟件中隱藏的各種缺陷甚至錯誤。測試的成功與否就是以發(fā)現(xiàn)軟件中潛在的缺陷多少來衡量。根據(jù)這些測試目的和目標(biāo)，軟件測試應(yīng)該注意些什么呢？鄭人杰等人編著的《實(shí)用軟件工程》第2版（清華大學(xué)出版社，1999年）中有一段描述對此問題進(jìn)行了回答。應(yīng)當(dāng)把“盡早地和不斷地進(jìn)行軟件測試”作為軟件開發(fā)者的座右銘。由于原始問題的復(fù)雜性，軟件的復(fù)雜性和抽象性，軟件開發(fā)各個階段工作的多樣性，以及參加開發(fā)各種層次人員之間工作的配合關(guān)系等因素，使得開發(fā)的每個環(huán)節(jié)都可能產(chǎn)生錯誤。所以不應(yīng)把軟件測試僅僅看作是軟件開發(fā)的一個獨(dú)立階段，而應(yīng)當(dāng)把它貫穿到

軟件開發(fā)的各個階段中。堅(jiān)持在軟件開發(fā)的各個階段的技術(shù)評審，這樣才能在開發(fā)過程中盡早發(fā)現(xiàn)和預(yù)防錯誤，把出現(xiàn)的錯誤克服在早期，杜絕某些隱患，提高軟件質(zhì)量。測試用例應(yīng)由測試輸入數(shù)據(jù)和與之對應(yīng)的預(yù)期輸出結(jié)果這兩部分組成。

在做測試之前，應(yīng)當(dāng)根據(jù)測試的要求選擇在測試過程中使用的測試用例。測試用例主要用來檢驗(yàn)程序員編制的程序，因此不但需要測試的輸入數(shù)據(jù)，而且需要針對這些輸入數(shù)據(jù)的預(yù)期輸出結(jié)果。如果對測試輸入數(shù)據(jù)沒有給出預(yù)期的程序輸出結(jié)果，那么就缺少了檢驗(yàn)實(shí)測結(jié)果的基準(zhǔn)，就有可能把一個似是而非的錯誤結(jié)果當(dāng)成正確結(jié)果。程序員應(yīng)避免檢查自己的程序.測試工作需要嚴(yán)格的作風(fēng)，客觀的態(tài)度和冷靜的情緒。人們常常由于各種原因，具有一種不愿否定自己工作的心里，認(rèn)為揭露自己程序中的問題總不是一件愉快的事，這一心里狀態(tài)就成為測試自己程序的障礙。另外，程序員對規(guī)約理解錯誤而引入的錯誤更難發(fā)現(xiàn)。如果由別人來測試程序員編寫的程

序，可能會更客觀，更有效，并更容易取得成功。要注意的是，這點(diǎn)不能與程序的排錯（調(diào)試）相混淆。排錯由程序員自己來做可能更有效。在設(shè)計(jì)測試用例時，應(yīng)當(dāng)包括合理的輸入條件和不合理的輸入條件。合理的輸入條件是指能驗(yàn)證程序正確的輸入條件，而不合理的輸入條件是指異常的、臨界的及可能引起問題變異的輸入條件。在測試程序時，人們常常傾向于過多地考慮合法的和期望的輸入條件，以檢查程序是否做了它應(yīng)該做的事情，而忽視了不合法的和預(yù)想不到的輸入條件。事實(shí)上，軟件在投入運(yùn)行之后，用戶的使用往往不遵循事先的約定，使用了一些意外的輸入，如用戶在鍵盤上按錯了鍵或輸入了非法的命令。如果開發(fā)的軟件遇到這種情況時不能作出適當(dāng)?shù)姆磻?yīng)，給出相應(yīng)的信息，那么就容易產(chǎn)生故障，輕則給出錯誤結(jié)果，重則導(dǎo)致軟件失效。因此，軟件系統(tǒng)處理非法命令的能力也必須在測試時受到檢驗(yàn)。用不合理的輸入條件測試程序時，往往比用合理的輸入條件進(jìn)行測試能發(fā)現(xiàn)更多的錯誤。充分注意測試中的群集現(xiàn)象。測試時不要以為找到了幾個錯誤問題就已解決，不須繼續(xù)測試了。經(jīng)驗(yàn)表明，測試后程序中殘存的錯誤數(shù)目與該程序中已發(fā)現(xiàn)的錯誤數(shù)目或檢錯率成正比。在所測程序段中，若發(fā)現(xiàn)錯誤數(shù)目多，則殘存錯誤數(shù)目也比較多。這種錯誤群集性現(xiàn)象，已為許多程序的測試實(shí)踐所證實(shí)。例如IBM公司的OS/370操作系統(tǒng)，47%的錯誤僅與該系統(tǒng)的4%的程序模塊有關(guān)。嚴(yán)格執(zhí)行測試計(jì)劃，排除測試的隨意性。測試計(jì)劃應(yīng)包括：所測試軟件的功能，輸入和輸出，測試內(nèi)容，各項(xiàng)測試的進(jìn)度安排，資源要求，測試資料，測試工具，測試用例的選擇，測試的控制方式和過程，系統(tǒng)組裝方式，跟蹤規(guī)程，排錯規(guī)程，回歸測試的規(guī)定以及評價標(biāo)準(zhǔn)等。對于測試計(jì)劃，要明確規(guī)定，不要隨意解釋。應(yīng)當(dāng)對每一個測試結(jié)果做全面檢查這是一條最明顯的原則，但常常被忽視。有些錯誤的征兆在輸出實(shí)測結(jié)果時已經(jīng)明顯地出現(xiàn)了，但是如果不仔細(xì)全面地檢查測試結(jié)果，就會使這些缺陷或錯誤被遺漏掉。所以必須對預(yù)期的輸出結(jié)果明確定義，對實(shí)測的結(jié)果仔細(xì)分析檢查，抓住癥候，暴露錯誤。妥善保存測試計(jì)劃，測試用例，出錯統(tǒng)計(jì)和最終分析報告，為維護(hù)提供方便。3.軟件測試與相關(guān)的幾個概念軟件測試不僅僅是軟件質(zhì)量保證體系中的重要一環(huán),而且也是保證質(zhì)量的重要技術(shù)手段。排錯（debugging）是查找、分析和糾正錯誤的過程。而測試（testing）是由人工或自動方法來執(zhí)行或評價軟件系統(tǒng)或軟件子系統(tǒng)的過

程，以驗(yàn)證是否滿足規(guī)定的需求，或識別出期望的結(jié)果和實(shí)際結(jié)果之間有無差別。因此，測試的任務(wù)是盡可能多地發(fā)現(xiàn)軟件中的缺陷和錯誤，而排錯的任務(wù)是進(jìn)一步診斷和改正程序中潛在的缺陷和錯誤。一般來說，排錯有兩類活動：其一是確定程序中可疑缺陷或錯誤的確切性質(zhì)和位置；其二，是對程序（設(shè)計(jì)、編碼）進(jìn)行修改，從而排除這個潛在的缺陷或錯誤。驗(yàn)證（verification）有3個含義：其一，確定軟件生存周期中的一個給定階段的產(chǎn)品是否達(dá)到前階段確立的需求的過程；其二，程序正確性的形式證明，即采用形式理論證明程序符合設(shè)計(jì)規(guī)約規(guī)定的過程；其三，評審、審查、測試、檢查、審計(jì)等各類活動，或?qū)δ承╉?xiàng)處理、服務(wù)或文件等是否和規(guī)定的需求相一致進(jìn)行判斷和提出報告。確認(rèn)（validation）是在軟件開發(fā)過程結(jié)束時，對軟件進(jìn)行評價，以確認(rèn)它和軟件需求是否相一致的過程，其目的是想證實(shí)在一個給定的外部環(huán)境中軟件的正確性。確認(rèn)一般包括需求規(guī)約的確認(rèn)和程序的確認(rèn)，而程序的確認(rèn)又分為靜態(tài)確認(rèn)和動態(tài)確認(rèn)。靜態(tài)確認(rèn)不在計(jì)算機(jī)上實(shí)際執(zhí)行程序，通過人工分析或程序正確性證明來證實(shí)程序的正確性。動態(tài)確認(rèn)主要通過動態(tài)執(zhí)行程序作分析，或者測試程序來檢查其動態(tài)行為，以證實(shí)程序是否存在問題，這通常就叫確認(rèn)測試。4.軟件測試方法分類軟件測試有各種分類方法，按照不同的分類原則有不同的分類結(jié)果。軟件測試的分類原則可以有一下幾種：按照軟件測試的動、靜態(tài)來分，有靜態(tài)測試和動態(tài)測試。在軟件開發(fā)過程中，每產(chǎn)生一個文檔，或每一個活動結(jié)束時產(chǎn)生的文檔，都必須對文檔進(jìn)行測試，靜態(tài)測試通過了，則該過程或活動才結(jié)束，開發(fā)工作取得了進(jìn)展，可以進(jìn)入下一個階段或活動，對這種靜態(tài)測試也叫做評審。動態(tài)測試就是通過運(yùn)行程序來檢驗(yàn)程序的動態(tài)行為和運(yùn)行結(jié)果的正確性。運(yùn)行程序并非動態(tài)測試的目的，通過運(yùn)行來檢驗(yàn)程序是否正確才是動態(tài)測試的目的。動態(tài)測試必須具備測試用例，有時還需要具備驅(qū)動程序、樁模塊和測試監(jiān)視代碼。按照軟件層面來分，美國國家宇航局建議將軟件評審的內(nèi)容分兩個層面來進(jìn)行，即技術(shù)評審和管理評審。技術(shù)評審的任務(wù)：建立軟件配置管理基線；提出并解決技術(shù)問題，審查技術(shù)工作；評價項(xiàng)目的狀態(tài)，判明有關(guān)技術(shù)問題的近期、長期風(fēng)險，并加以討論；在技術(shù)代表的權(quán)限內(nèi)，達(dá)成已判明風(fēng)險的轉(zhuǎn)移策略；標(biāo)識呈交給管理人員討論的風(fēng)險要素和有關(guān)問題；確保用戶和軟件開發(fā)技術(shù)人員之間的交流暢通。管理評審的任務(wù)：報告上級管理部門該項(xiàng)目的狀態(tài)、所采取的方針、所達(dá)成的技術(shù)協(xié)議，以及軟件產(chǎn)品進(jìn)展的總體情況；解決技術(shù)評審不能解決的問題；就技術(shù)評審不能解決的近期、長期風(fēng)險可達(dá)成的轉(zhuǎn)移戰(zhàn)略；鑒別并解決管理方面的問題以及技術(shù)評審沒有提出的風(fēng)險；征得用戶的同意和各方認(rèn)可以便及時完成。按照軟件開發(fā)過程的內(nèi)、外進(jìn)行分類①軟件開發(fā)過程中的測試。按軟件開發(fā)過程中所處的階段（或活動）及其作用來分，有單元測試、集成測試、系統(tǒng)測試、驗(yàn)收測試。軟件開發(fā)過程中的測試，大部分是開發(fā)單位自行完成的。當(dāng)然，也可交第三方軟件測試機(jī)構(gòu)執(zhí)行，但往往是系統(tǒng)測試和驗(yàn)收測試。有時，這種測試，因?yàn)椴皇怯捎脩暨M(jìn)行的，又稱α測試。②軟件產(chǎn)品測試。其測試對象是產(chǎn)品化或正在產(chǎn)品化的軟件。這種測試的內(nèi)容包含范圍很廣，通常由第三方軟件測試機(jī)構(gòu)完成。通常的軟件產(chǎn)品測試：功能測試、性能測試、β測試（用戶測試）專門的軟件產(chǎn)品測試：可靠性測試、標(biāo)準(zhǔn)符合性測試、互操作性測試、安全性測試、強(qiáng)度測試。按照測試用例所依據(jù)的信息來源，測試方法可以分為以下幾種：①以程序?yàn)榛A(chǔ)的測試。通過對程序的分析形成測試用例，并以程序被執(zhí)行的程度來判斷測試是否充分，這就是“白盒法”。②以需求規(guī)約和需求描述為基礎(chǔ)的測試。通過分析軟件的需求描述和需求規(guī)約形成測試用例，并根據(jù)需求描述和需求規(guī)約所約定的功能和性能是否得到了充分的檢驗(yàn)來判斷測試是否充分。這就是“黑盒法”。③程序和需求相結(jié)合的測試。綜合考慮需求和實(shí)現(xiàn)形成測試用例。④以接口為基礎(chǔ)的測試，僅僅依靠軟件與其運(yùn)行環(huán)境之間的接口形成測試用例，隨機(jī)測試就是一種以接口為基礎(chǔ)的測試方法。按照判斷測試的充分性，測試方法可分為以下幾種。①結(jié)構(gòu)性測試，旨在充分覆蓋程序結(jié)構(gòu)，并以程序中的某類成分是否都已得到測試為依據(jù)，來判斷測試的充分性，如語句覆蓋是一種結(jié)構(gòu)性測試。②排錯性測試，旨在排除程序中潛在缺陷的可能性，并根據(jù)測試用例集成排除軟件潛在缺陷可能性的能力判斷測試的充分性。③分域測試，通過對軟件的需求和實(shí)現(xiàn)進(jìn)行分析，將軟件的輸入空間劃分成一系列子空間，然后在每一個子空間內(nèi)選擇一個或多個測試數(shù)據(jù)。④功能測試，根據(jù)軟件所需的功能和所實(shí)現(xiàn)的功能，形成測試用例，分析測試的充分性。按照軟件測試的完整性，Shooman從程序結(jié)構(gòu)和測試覆蓋程度分為如下幾種。①完全性和連續(xù)性測試：要求程序中的所有指令至少執(zhí)行一次（100%的語句覆蓋）②圖路徑測試：所有圖路徑至少執(zhí)行一次（100%的圖路徑覆蓋）③程序路徑測試：所有程序路徑至少執(zhí)行一次（100%的程序路徑覆蓋）④窮舉測試：對輸入?yún)?shù)的所有值執(zhí)行所有程序路徑，或?qū)斎雲(yún)?shù)的所有值和所有輸入序列，以及初始條件的所有組合，執(zhí)行所有程序路徑。5.軟件錯誤的分級在軟件產(chǎn)品開發(fā)中,不論哪一階段產(chǎn)生的缺陷和錯誤,其最后的表現(xiàn)就是:軟件產(chǎn)品達(dá)不到用戶的要求,由于存在軟件錯誤,使之不能有效地完成規(guī)定的任務(wù).軟件測試的任務(wù),就在于找出或發(fā)現(xiàn)軟件中存在的錯誤(假如錯誤存在的話).

由于錯誤的性質(zhì)不同,危害性也不同.軟件測試如果能發(fā)現(xiàn)軟件中危害性大的錯誤(如果存在的話),那么該軟件測試的價值就越高.一般將軟件錯誤分為5級。第1級錯誤：不能滿足軟件需求，基本功能未完全實(shí)現(xiàn)，危及人員或設(shè)備安全的錯誤。第2級錯誤：不利于完全滿足軟件需求或基本功能的實(shí)現(xiàn)，并且不存在可以變通的解決辦法（重新裝入或重新啟動該軟件不屬于變通解決辦法）。第3級錯誤：不利于完全滿足軟件需求或基本功能的實(shí)現(xiàn)，但卻存在合理的、可以變通的解決辦法（重新裝入或重新啟動該軟件不屬于變通解決辦法）。第4級錯誤：不影響完全滿足軟件需求或基本功能的實(shí)現(xiàn)，但有不便于操作員操作的錯誤。第5級錯誤：不屬于第1~4級錯誤的其他錯誤。第二章 軟件測試實(shí)質(zhì)軟件測試的基本概念軟件故障測試的復(fù)雜性與經(jīng)濟(jì)性測試的充分性問題測試原則停止測試的標(biāo)準(zhǔn)第二章 軟件測試實(shí)質(zhì)軟件測試的基本概念軟件故障測試的復(fù)雜性與經(jīng)濟(jì)性測試的充分性問題測試原則停止測試的標(biāo)準(zhǔn)IEEE提出的軟件工程標(biāo)準(zhǔn)術(shù)語中給軟件測試下的定義是：“使用人工或自動手段來運(yùn)行或測定某個系統(tǒng)的過程，其目的在于檢驗(yàn)它是否滿足規(guī)定的需求或是弄清預(yù)期結(jié)果與實(shí)際結(jié)果之間的差別”。該定義包含了兩方面的含義：1）是否滿足規(guī)定的需求2）是否有差別這一定義非常明確地提出了軟件測試以檢驗(yàn)軟件是否滿足需求為目標(biāo)。針對測試人員，測試的最好定義是：測試是為了發(fā)現(xiàn)故障而執(zhí)行程序的過程。這一定義非常明確地提出了軟件測試以發(fā)現(xiàn)故障為目的。第二章 軟件測試實(shí)質(zhì)一般來說，“成功”表示達(dá)到了某種目的，而“失敗”則表示令人失望或事不如愿。但在測試中，由于查不出故障的測試?yán)速M(fèi)了大量的時間和人力，因此使用“成功”這個詞就顯得不夠恰當(dāng)了。事實(shí)證明，發(fā)現(xiàn)故障是一個有價值的工作。發(fā)現(xiàn)故障的測試是成功的測試，而使程序產(chǎn)生正確結(jié)果的測試稱為失敗的測試。第二章 軟件測試實(shí)質(zhì)軟件測試主要涉及5方面的問題：誰來執(zhí)行測試?測試什么?什么時候測試?怎樣進(jìn)行測試?測試完成的標(biāo)準(zhǔn)是什么?軟件測試的基本概念軟件故障測試的復(fù)雜性與經(jīng)濟(jì)性測試的充分性問題測試原則停止測試的標(biāo)準(zhǔn)第二章 軟件測試實(shí)質(zhì)故障(fault)、失效(failure)、錯誤(error)、缺陷(defect)、隱錯(bug)、過失(mistake)、異常（anomaly），這些術(shù)語常用來描述軟件失敗時的現(xiàn)象。我們采用IEEE制定的標(biāo)準(zhǔn)術(shù)語。錯誤(error)

—

—

人是會犯錯誤的。一個很接近的同義詞是過失（mistake）。過失是人犯下的，是人做的一件錯事或人為產(chǎn)生的一個不正確結(jié)果。故障(fault)——故障是錯誤的結(jié)果(可能導(dǎo)致失效)。更精確地說，故障是錯誤的表現(xiàn)。與故障很接近的一個同義詞是缺陷(defect)，失效(failure)——故障(例如崩潰)引起的結(jié)果(表現(xiàn))。所有的錯誤都是要付出代價的。統(tǒng)計(jì)資料表明，在軟件開發(fā)的不同階段進(jìn)行改動需要付出的代價完全不同。后期改動的代價比前期進(jìn)行相應(yīng)修改要高出2~3個數(shù)量級。圖2-4

軟件故障的修復(fù)費(fèi)用第二章 軟件測試實(shí)質(zhì)軟件測試的基本概念軟件故障測試的復(fù)雜性與經(jīng)濟(jì)性測試的充分性問題測試原則停止測試的標(biāo)準(zhǔn)窮舉測試工作量太大，實(shí)際上是行不通的，這就注定了一切實(shí)際測試都是不徹底的。因此，軟件測試的一個基本問題是經(jīng)濟(jì)學(xué)問題。

軟件測試的總目標(biāo)是充分利用有限的人力和物力資源，高效率、高質(zhì)量地完成測試。第二章 軟件測試實(shí)質(zhì)軟件測試的基本概念軟件故障測試的復(fù)雜性與經(jīng)濟(jì)性測試的充分性問題測試原則停止測試的標(biāo)準(zhǔn)不充分的測試是愚蠢的，而過度的測試則是一種罪孽。停止測試的標(biāo)準(zhǔn)？第二章 軟件測試實(shí)質(zhì)2.1

軟件測試的基本概念軟件故障測試的復(fù)雜性與經(jīng)濟(jì)性測試的充分性問題測試原則停止測試的標(biāo)準(zhǔn)例如：

完全測試程序是不可能的軟件測試是有風(fēng)險的存在的故障數(shù)量與發(fā)現(xiàn)的故障數(shù)成正比殺蟲劑現(xiàn)象應(yīng)避免測試自己編寫的程序一些至關(guān)重要的測試原則或方針，可以視為軟件測試和軟件開發(fā)的“交通規(guī)則”或者“生活法則”。第三章 軟件測試策略軟件開發(fā)模型軟件測試過程黑盒測試與白盒測試靜態(tài)測試與動態(tài)測試驗(yàn)證測試與確認(rèn)測試第三章 軟件測試策略軟件開發(fā)模型軟件測試過程黑盒測試與白盒測試靜態(tài)測試與動態(tài)測試驗(yàn)證測試與確認(rèn)測試軟件開發(fā)模型是軟件開發(fā)過程、活動和任務(wù)的結(jié)構(gòu)框架，能夠清晰、直觀地表達(dá)軟件開發(fā)的全部過程，明確規(guī)定要完成的主要活動和任務(wù)，是軟件項(xiàng)目開發(fā)的基礎(chǔ)。另一種常用的軟件開發(fā)模型是螺旋模型該模型加入了風(fēng)險分析在內(nèi)。瀑布模型多年來廣泛流行，它在支持結(jié)構(gòu)化軟件開發(fā)、控制軟件開發(fā)的復(fù)雜性、促進(jìn)軟件開發(fā)工程化等方面起著顯著作用。第三章 軟件測試策略軟件開發(fā)模型軟件測試過程黑盒測試與白盒測試靜態(tài)測試與動態(tài)測試驗(yàn)證測試與確認(rèn)測試軟件開發(fā)是一個自頂向下，逐步細(xì)化的過程。軟件測試則是依相反順序的自底向上，逐步集成的過程。低一級的測試為上一級的測試準(zhǔn)備條件。軟件測試過程包括:測試資料的收集與整理；熟悉所要測試的軟件；測試方案的制定；測試計(jì)劃的編寫；測試實(shí)例的設(shè)計(jì)與編寫；測試準(zhǔn)備工作；測試操作；軟件缺陷記錄及報告；修改充實(shí)測試實(shí)例及測試計(jì)劃書；測試自動化程序的編寫；修改、增加測試程序第三章 軟件測試策略軟件開發(fā)模型軟件測試過程黑盒測試與白盒測試靜態(tài)測試與動態(tài)測試驗(yàn)證測試與確認(rèn)測試黑盒測試和白盒測試是兩類廣泛使用的軟件測試方法。黑盒測試的基本觀點(diǎn)是將被測程序看作一個打不開的黑盒，測試人員在完全不考慮程序內(nèi)部結(jié)構(gòu)和內(nèi)部特性的情況下，只依靠被測程序輸入和輸出之間的關(guān)系，或程序的功能來設(shè)計(jì)測試用例。白盒測試將被測程序看作一個打開的盒子，測試人員根據(jù)其內(nèi)部構(gòu)造設(shè)計(jì)測試用例。第三章 軟件測試策略靜態(tài)測試是指不利用計(jì)算機(jī)運(yùn)行被測試軟件開發(fā)模型軟件測試過程黑盒測試與白盒測試靜態(tài)測試與動態(tài)測試驗(yàn)證測試與確認(rèn)測試的程序，通過其它手段達(dá)到檢測的目的,是對被測程序進(jìn)行特性分析的一些方法的總稱。動態(tài)測試則是指通常意義上的測試——通過運(yùn)行和使用被測程

序，發(fā)現(xiàn)軟件故障，以達(dá)到檢測的目的。經(jīng)驗(yàn)表明，使用靜態(tài)測試可以發(fā)現(xiàn)大約30%到70%的邏輯設(shè)計(jì)和編碼錯誤。第三章 軟件測試策略軟件開發(fā)模型軟件測試過程黑盒測試與白盒測試靜態(tài)測試與動態(tài)測試驗(yàn)證測試與確認(rèn)測試驗(yàn)證測試針對開發(fā)過程中的任何中間產(chǎn)品進(jìn)行,是為確定某一開發(fā)階段的產(chǎn)品是否滿足在該階段開始時提出的要求而對系統(tǒng)或部件進(jìn)行評估的過程。確認(rèn)測試則通過運(yùn)行代碼來完成,是在開發(fā)過程中或結(jié)束時，

對系統(tǒng)或部件進(jìn)行評估以確定其是否滿足需求規(guī)格的過程。驗(yàn)證就是對諸如需求規(guī)格說明，設(shè)計(jì)規(guī)格說明和代碼之類的產(chǎn)品進(jìn)行評估、審查和檢查的過程，屬于靜態(tài)測試。確認(rèn)是“基于計(jì)算機(jī)的測試”過程，屬于動態(tài)測試。第四章 黑盒測試三個被測程序等價類劃分測試邊界值分析決策表測試其它黑盒測試方法第四章 黑盒測試三個被測程序等價類劃分測試邊界值分析決策表測試其它黑盒測試方法在第四章和第五章，我們將采用三個例子來說明各種單元測試方法。這三個例子分別是：一個是三角形問題；一個是邏輯比較復(fù)雜的NextDate函數(shù)；一個是有代表性的雇傭金問題。這三個例子合在一起，足可以說明軟件測試人員在單元級別上可能會遇到的大多數(shù)問題。第四章 黑盒測試三個被測程序等價類劃分測試邊界值分析決策表測試其它黑盒測試方法等價類劃分把程序的輸入域劃分成若干個互不相交的一組子集，即等價類。等價類由等價關(guān)系決定，因此等價類中的元素有一些共同的特點(diǎn)：如果用等價類中的一個元素作為測試數(shù)據(jù)進(jìn)行測試不能發(fā)現(xiàn)程序中的故障，那么使用集合中的其它元素進(jìn)行測試也不可能發(fā)現(xiàn)錯誤。也就是說，對揭露程序中的故障來說，等價類中的每個元素是等效的。例如，在三角形問題中，如果我們選擇三元組（5，5，5）作為測試用例的輸入，可以判定這是一個等邊三角形的測試用例。在程序測試中能暴露某個程序故障，那么以(6，6，6)或（100，100，100）作為測試數(shù)據(jù)也能發(fā)現(xiàn)這個故障。因此，這些測試用例是冗余的。在考慮等價類時，應(yīng)注意區(qū)別兩種不同的情況：有效等價類：有效等價類是指對程序規(guī)格說明，是有意義的，合理的輸人數(shù)據(jù)所構(gòu)成的集合。利用有效等價類，可以檢驗(yàn)程序是否實(shí)現(xiàn)了規(guī)格說明預(yù)先規(guī)定的功能和性能。無效等價類：無效等價類是指對程序規(guī)格說明，是不合理或無意義的輸入數(shù)據(jù)所構(gòu)成的集合。利用無效等價類，可以檢查程序功能和性能的實(shí)現(xiàn)是否有不符合規(guī)格說明要求的地方。在設(shè)計(jì)測試用例時，應(yīng)同時考慮有效等價類和無效等價類測試用例的設(shè)計(jì)。我們希望用最少的測試用例，覆蓋所有的有效等價類。但對每一個無效等價類，設(shè)計(jì)一個測試用例來覆蓋它。此外，在設(shè)計(jì)測試用例時，我們應(yīng)意識到：

預(yù)期結(jié)果也是測試用例的一個必要組成部分，對采用無效輸入的測試也是如此。第四章 黑盒測試三個被測程序等價類劃分測試邊界值分析決策表測試其它黑盒測試方法人們從長期的測試工作經(jīng)驗(yàn)得知，大量的故障發(fā)生在輸入或輸出范圍的邊界上，而不是在輸入范圍的內(nèi)部。我們知道：當(dāng)滿足a+b>c、a十c>b及b+c>a才能構(gòu)成三角形。但如果把三個不等式的任何一個大于號“>”錯寫成大于等于號“≥”，那就無法構(gòu)成三角形了。使用邊界值分析方法設(shè)計(jì)測試用例，首先應(yīng)確定邊界情況。輸入等價類與輸出等價類的邊界，就是應(yīng)著重測試的邊界情況。通過使所有變量取正常值，只使一個變量分別取最小值、略高于最小值、略低于最大值和最大值，有兩輸入變量的程序F的邊界值析測試用例是：x1ab{<Xlnom，X2min>，<

Xlnom，X2min+>，<Xlnom，X2nom>，<Xlnom，X2max>，<Xlnom，X2max->，<Xlmin，X2nom>，<Xlmin，X2min+>，<Xlmin，X2max>，<Xlmin，X2max+>

}x2d圖4-5

有兩個變量程序的邊界值分析測試用例c次邊界條件：有些邊界在軟件內(nèi)部，用戶幾乎看不到，但是軟件測試仍有必要對這些邊界條件進(jìn)行檢查。如2的冪次方和ASCII碼就是這樣的兩個例子。例如，假設(shè)某種通訊協(xié)議支持256條命令，為了提高數(shù)據(jù)傳輸效率，通訊軟件總是將常用的信息壓縮到一個很小的單元中，必要時再擴(kuò)展為大一些的單元。比如將常用的15條命令壓縮為一個半字節(jié)數(shù)據(jù)，在遇到第16到256之間的命令時，軟件轉(zhuǎn)而發(fā)送一個一字節(jié)的命令。用戶只知道可以執(zhí)行256條命令，并不知道軟件根據(jù)半字節(jié)/字節(jié)邊界執(zhí)行了不同的計(jì)算和操作。為了覆蓋任何可能的2的冪次方次邊界，還要考慮臨近半字節(jié)邊界14，15和16，以及臨近字節(jié)邊界254，255和256的測試用例。第四章 黑盒測試三個被測程序等價類劃分測試邊界值分析決策表測試其它黑盒測試方法決策表很適合于處理針對不同邏輯條件組合值，分別執(zhí)行不同的操作這類問題。c3:

a,b,c

構(gòu)成一個三角形?

c2:

a=b?c3:

a=c?c4:

b=c?N－－－YYYYYYYNYYNYYYNNYNYYYNYNYNNYYNNNa1:

非三角形a2:

一般三角形a3:

等腰三角形a4:

等邊三角形a5:不可能XXXXXXXXX表4-10

三角問題的決策表?xiàng)l件樁部分列出了問題的所有條件為了使用決策表設(shè)計(jì)測試用例，可以把條件解釋為輸入，把行動解釋為輸出。決策表最突出的優(yōu)點(diǎn)是，它能把復(fù)雜的問題按各種可能的情況一一列舉出來，簡明而易于理解，也可避免遺漏。因此利用決策表可以設(shè)計(jì)出完整的測試用例集合。動作樁則給出了問題規(guī)定的可能采取操作第四章 黑盒測試三個被測程序等價類劃分測試邊界值分析決策表測試其它黑盒測試方法因果圖方法適合于描述對于多種條件的組合，產(chǎn)生多個相應(yīng)動作的測試方法，能夠幫助我們按一定步驟，高效率地選擇測試用例，以檢測程序輸入條件的各種組合情況。因果圖方法最終生成的是判定表。分析程序規(guī)格說明的描述中，哪些是原因，哪些是結(jié)果。原因常常是輸入條件或是輸入條件的等價類，而結(jié)果則是輸出條件。找出原因與結(jié)果之間，原因與原因之間的對應(yīng)關(guān)系，并將其表示成連接各個原因與各個結(jié)果的“因果圖”。把因果圖轉(zhuǎn)換成判定表。第四章 黑盒測試三個被測程序等價類劃分測試邊界值分析決策表測試其它黑盒測試方法特殊值測試：測試人員使用其領(lǐng)域知識、使用類似程序的測試經(jīng)驗(yàn)等信息開發(fā)測試用例時，常常使用特殊值測試。這種方法不使用測試策略，只根據(jù)“最佳工程判斷”來設(shè)計(jì)測試用例。因此，特殊值測試特別依賴測試人員的能力。故障猜測法人們靠經(jīng)驗(yàn)和直覺猜測程序中可能存在的各種軟件故障，從而有針對性地編寫檢查這些故障的測試用例。第??章 白盒測試邏輯覆蓋路徑分析數(shù)據(jù)流測試符號測試域測試策略程序變異程序插裝第??章 白盒測試5.1

邏輯覆蓋路徑分析數(shù)據(jù)流測試符號測試域測試策略程序變異程序插裝邏輯覆蓋要求對被測程序的結(jié)構(gòu)作到一定程度的覆蓋。由于覆蓋測試的目標(biāo)不同，邏輯覆蓋又可分為：

語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋及路徑覆蓋。使得程使序得中程序每中個每判個判斷的每個條件的可能取值至少被執(zhí)斷的取行真一分次。支我和們?nèi)砜匆欢涡〕绦?if

(a>0

and

b!=a)c=b/a;else

c=a;假分支以至此少條執(zhí)件行覆一蓋次為測試依據(jù),則可建立以下幾個測試實(shí)例:a>0,b!=a;a<0,b=a;a<0,b!=a;a<0,b=a;a=0,b!=a;a=0,

b=a使得判斷中每個條件的所有可能取值至少被執(zhí)行一次，同時每個判斷的所有可能判斷結(jié)果也至少被執(zhí)行一次。第??章 白盒測試邏輯覆蓋路徑分析數(shù)據(jù)流測試符號測試域測試策略程序變異程序插裝討論路徑數(shù)目的計(jì)算方法，分析程序中到底有多少條路徑?有多少條線形獨(dú)立路徑數(shù)如果程序中出現(xiàn)了多個判斷和多個循環(huán)，可能的路徑數(shù)目將會急劇增長，以至實(shí)現(xiàn)路徑覆蓋不可能的。

實(shí)際上我們可以做到的只是有選擇地測試程序中某些有代表的性路徑。獨(dú)立路徑選擇和Z路經(jīng)覆蓋是兩種常用的路經(jīng)覆蓋方法。獨(dú)立路徑是指從程序入口到出口的多次執(zhí)行中，每次至少有一個語句是新的，未被重復(fù)的。限制循環(huán)的次數(shù)。我們只考慮循環(huán)執(zhí)行一次和零次兩種情況，這種簡化循環(huán)意義下的路徑覆蓋為Z路徑覆蓋。第??章 白盒測試邏輯覆蓋路徑分析數(shù)據(jù)流測試*符號測試域測試策略程序變異程序插裝數(shù)據(jù)流測試是指關(guān)注變量定義點(diǎn)和使用(或引用)點(diǎn)的一種結(jié)構(gòu)測試方式，數(shù)據(jù)流測試是指在不運(yùn)行被測程序的前提下，對變量的定義、引用進(jìn)行分析，以檢測數(shù)據(jù)的賦值與引用之間是否出現(xiàn)了不合理的現(xiàn)象，如引用未賦值的變量，對以前未曾引用變量的再次賦值等數(shù)據(jù)流異?，F(xiàn)象。定義／使用測試是一種常用的數(shù)據(jù)流測試方法。定義/使用路徑，記做du-path如果對某個變量v

V，存在一個定義、使用結(jié)點(diǎn)對，即DEF(v，m)和USE(v，n)，使得變量v在結(jié)點(diǎn)m處被定義，在結(jié)點(diǎn)n處被使用，則從m到n的結(jié)點(diǎn)序列稱為一條定義/使用路徑.定義明確路徑，記做dc-path如果對某個變量v

V，存在一個定義、使用結(jié)點(diǎn)對，即DEF(v，m)和USE(v，n)，使得變量v在結(jié)點(diǎn)m處被定義，在結(jié)點(diǎn)n處被使用，并且從m到n的結(jié)點(diǎn)序列中沒有其他結(jié)點(diǎn)對變量v進(jìn)行過定義，則從m到n的結(jié)點(diǎn)序列稱為一條定義明確路徑.定義/使用路徑和定義明確路徑描述了變量從被定義點(diǎn)到被引用點(diǎn)數(shù)據(jù)流向。不是定義明確的定義/使用路徑，很可能是潛在問題的所在。所以我們應(yīng)特別關(guān)注這些定義/使用路徑。第??章 白盒測試邏輯覆蓋路徑分析數(shù)據(jù)流測試符號測試域測試策略程序變異程序插裝符號測試的基本思想是允許程序的輸入不僅可以是具體的數(shù)值數(shù)據(jù)，而且還可以包括符號值。在執(zhí)行程序過程中以符號計(jì)算代替了普通執(zhí)行中的數(shù)值計(jì)算，所得到的結(jié)果自然是符號公式或是符號謂詞。更明確地說，普通測試執(zhí)行的是算術(shù)運(yùn)算，符號測試執(zhí)行則是代數(shù)運(yùn)算。一次符號測試的結(jié)果代表了一大類普通測試的運(yùn)行結(jié)果，實(shí)際上是證明了程序接受此類輸入，所得輸出是正確的，還是錯誤的。符號測試方法在使用中會遇到一些問題，

比如在遇到循環(huán)、過程調(diào)用、動態(tài)數(shù)據(jù)結(jié)構(gòu)、數(shù)組和指針處理時，符號執(zhí)行實(shí)現(xiàn)困難。第??章 白盒測試邏輯覆蓋路徑分析數(shù)據(jù)流測試符號測試域測試策略程序變異程序插裝域測試的“域”指的是程序的輸入空間。自然，每個被測程序都有一個輸入空間，而輸入空間又可以分為不同的子空間。子空間的劃分是由程序中分支語句中的謂詞決定的。域測試策略在分析輸入域的基礎(chǔ)上，對每一子域的每一謂詞邊界，通過選取適當(dāng)?shù)臏y試點(diǎn)，對謂詞邊界附近的處理進(jìn)行檢測。第??章 白盒測試邏輯覆蓋路徑分析數(shù)據(jù)流測試符號測試域測試策略程序變異程序插裝程序變異是一種不同于黑盒測試和白盒測試的測試方法，它屬于錯誤驅(qū)動測試，適用于某類特定的程序故障。程序變異假定，被測程序由經(jīng)驗(yàn)豐富的程序人員編寫，這樣的程序即使不正確，殘留在程序中的錯誤也不是那些重大錯誤，而是一些難以發(fā)現(xiàn)的小錯誤。和正確軟件相比，表現(xiàn)為一個符號或幾個符號的錯誤。程序變異的目標(biāo)就是查出這些簡單的錯誤及其組合。假設(shè)對程序P進(jìn)行了微小改動而得到程序MP，則MP也是一個程序，稱為P的一個變異體(mutant)。顯而易見，如果程序P是正確的，MP也是一個幾乎正確的程序。如果P不正確，則P的某一個變異體MP可能是正確的。第??章 白盒測試邏輯覆蓋路徑分析數(shù)據(jù)流測試符號測試域測試策略程序變異程序插裝程序插裝是一種借助于往被測程序中插入操作來實(shí)現(xiàn)測試目的方法，在軟件測試中有著廣泛的應(yīng)用。第六章 集成測試與系統(tǒng)測試集成測試系統(tǒng)測試第六章 集成測試與系統(tǒng)測試集成測試系統(tǒng)測試一些模塊單獨(dú)能夠工作，并不能保證連接起來也能正常工作。集成測試非增式測試增式測試自頂向下測試自底向上測試程序在某些局部反映不出的問題，在全局上很可能暴露出來，影響功能的發(fā)揮。集成測試是將多個模塊組合在一起進(jìn)行測試的過程。獨(dú)立地測試程序的每個模塊，然后再把它們組合成整個程序的集成測試方法。把下一個待測試的模塊組合到已經(jīng)測試過的那些模塊上去，再進(jìn)行測試。從主控模塊開始，按照軟件的控制層次結(jié)構(gòu)，逐步把各個模塊集成在一起。從最下層的模塊開始，按照程序的層次結(jié)構(gòu)，逐漸形成完整的整體。第六章 集成測試與系統(tǒng)測試集成測試系統(tǒng)測試系統(tǒng)測試實(shí)際上是針對系統(tǒng)中各個組成部分進(jìn)行的綜合性檢驗(yàn)，很接近我們?nèi)粘y試實(shí)踐。系統(tǒng)測試目標(biāo)不是找出軟件故障，而是要證明系統(tǒng)的性能。比如，確定程序是否滿足性能需求；確定系統(tǒng)是否滿足可靠性要求等等。系統(tǒng)測試性能測試強(qiáng)度測試安全性測試恢復(fù)測試可靠性測試配置測試可用性測試兼容性測試文檔資料測試網(wǎng)站測試說明在一定工作負(fù)荷和格局分配條件下,響應(yīng)時間及處理速度等特性檢查系統(tǒng)能力的最高實(shí)際限度，即軟件在一些超負(fù)荷情況下的運(yùn)行情況。檢查系統(tǒng)對非法侵入的防范能力，驗(yàn)證安裝在系統(tǒng)內(nèi)的保護(hù)機(jī)構(gòu)是否確實(shí)能夠?qū)ο到y(tǒng)進(jìn)行保護(hù)?；謴?fù)測試的主要目的是檢查系統(tǒng)的容錯能力。檢測系統(tǒng)的平均無故障時間是否超過規(guī)定時限；因故障而停機(jī)的時間在一年中應(yīng)不超過多少時間。配置測試是用各種硬件和軟件平臺以及不同設(shè)置檢查軟件操作的過程，以保證測試的軟件可以使用盡量多樣化的硬件組合?？捎眯詼y試檢測用戶使用軟件是否滿意檢測軟件之間能否正確地交互和共享信息，軟件測試不限于僅測試軟件，保證文檔的正確性也是軟件測試的職責(zé)。第七章 驗(yàn)證測試和確認(rèn)測試驗(yàn)證的基本方法驗(yàn)證活動通用代碼審查單確認(rèn)測試第七章 驗(yàn)證測試和確認(rèn)測試驗(yàn)證的基本方法驗(yàn)證活動通用代碼審查單確認(rèn)測試驗(yàn)證是對軟件產(chǎn)品進(jìn)行人工檢查或評審。驗(yàn)證的基本方法有：軟件審查、走查、伙伴檢查等。軟件審查以會議的形式進(jìn)行

。軟件審查的目標(biāo)是：收集數(shù)據(jù)，發(fā)現(xiàn)軟件故障。交流，信息。走查的目標(biāo)是：熟悉材料、發(fā)現(xiàn)軟件故障。第七章 驗(yàn)證測試和確認(rèn)測試驗(yàn)證的基本方法驗(yàn)證活動通用代碼審查單確認(rèn)測試驗(yàn)證活動是測試生存周期中的一個階段，包括需求驗(yàn)證、功能設(shè)計(jì)驗(yàn)證、詳細(xì)設(shè)計(jì)驗(yàn)證和代碼驗(yàn)證。在每一類的驗(yàn)證活動中，都要考慮以下問題：使用的驗(yàn)證方法(審查、走查、伙伴檢查等)產(chǎn)品中要驗(yàn)證的和不要驗(yàn)證的范圍沒有驗(yàn)證的部分所承擔(dān)的風(fēng)險。需要優(yōu)先進(jìn)行驗(yàn)證的范圍資源、進(jìn)度、工具和責(zé)任等第七章 驗(yàn)證測試和確認(rèn)測試驗(yàn)證的基本方法驗(yàn)證活動通用代碼審查單確認(rèn)測試審查單是驗(yàn)證測試的重要工具。在通用代碼審查單的基礎(chǔ)上開發(fā)定制出適合某種目的或項(xiàng)目的審查單。第七章 驗(yàn)證測試和確認(rèn)測試驗(yàn)證的基本方法驗(yàn)證活動通用代碼審查單確認(rèn)測試確認(rèn)測試以需求規(guī)格說明中的規(guī)定作為檢驗(yàn)尺度，在開發(fā)過程中或結(jié)束時，對系統(tǒng)或組成部分進(jìn)行

評估。單元測試低層測試集成測試確認(rèn)測試高層測試可用性測試

功能測試系統(tǒng)測試驗(yàn)收測試三種確認(rèn)測試策略：基于需求的測試：基于需求的測試必須采用黑盒測試策略，在不知道內(nèi)部設(shè)計(jì)規(guī)格說明或代碼的情況下對用戶需求進(jìn)行測試?；诠δ艿臏y試：基于功能的測試應(yīng)該采用黑盒策略?；诠δ艿臏y試常采用等價類劃分、邊界值分析和故障猜測等方法設(shè)計(jì)測試用例。基于內(nèi)部的測試：基于內(nèi)部的測試只能采用白盒測試策略。一但采用白盒測試，便可通過一系列的技術(shù)確保系統(tǒng)的內(nèi)部各部分獲得充分的測試并且達(dá)到足夠的邏輯覆蓋。第八章 測試計(jì)劃與測試文檔測試計(jì)劃軟件測試文檔主測試計(jì)劃驗(yàn)證測試計(jì)劃確認(rèn)測試計(jì)劃測試評估用戶手冊IEEE/ANSI測試文檔概述軟件生存周期各階段的測試任務(wù)與可交付的文檔第八章 測試計(jì)劃與測試文檔測試計(jì)劃軟件測試文檔主測試計(jì)劃驗(yàn)證測試計(jì)劃確認(rèn)測試計(jì)劃測試評估用戶手冊IEEE/ANSI測試文檔概述軟件生存周期各階段的測試任務(wù)與可交付的文檔高效率的測試是經(jīng)過計(jì)劃的。成功的測試需要有一定的方法，

包括條例、結(jié)構(gòu)、分析和度量。第八章 測試計(jì)劃與測試文檔測試計(jì)劃軟件測試文檔主測試計(jì)劃驗(yàn)證測試計(jì)劃確認(rèn)測試計(jì)劃測試評估用戶手冊IEEE/ANSI測試文檔概述軟件生存周期各階段的測試任務(wù)與可交付的文檔測試文檔的編制是測試工作規(guī)范化的一個重要組成部分。包括以下幾個內(nèi)容：測試計(jì)劃：該計(jì)劃描述測試活動的范圍、方法、資源和進(jìn)度，其中規(guī)定了被測試的對象，被測試的特性、應(yīng)完成的測試任務(wù)、人員職責(zé)及風(fēng)險等。測試設(shè)計(jì)規(guī)格說明：該說明詳細(xì)描述測試方法，測試用例以及測試通過的準(zhǔn)則等。測試用例規(guī)格說明：該說明描述測試用例涉及的輸入、輸出，對環(huán)境的要求，對測試規(guī)程的要求等。測試步驟規(guī)格說明：該說明規(guī)定了實(shí)施測試的具體步驟。測試日志：該日志是測試小組對測試過程所作的記錄。測試事件報告：該報告說明測試中發(fā)生的一些重要事件。測試總結(jié)報告：對測試活動所作的總結(jié)和結(jié)論。第八章 測試計(jì)劃與測試文檔測試計(jì)劃軟件測試文檔主測試計(jì)劃驗(yàn)證測試計(jì)劃確認(rèn)測試計(jì)劃測試評估用戶手冊IEEE/ANSI測試文檔概述軟件生存周期各階段的測試任務(wù)與可交付的文檔制定主測試計(jì)劃的目標(biāo)是：規(guī)定測試活動的范圍、方法、資源和進(jìn)度；明確正在測試的項(xiàng)目、要執(zhí)行的主要測試任務(wù)、每個任務(wù)的負(fù)責(zé)人，以及與計(jì)劃相關(guān)的風(fēng)險。第八章 測試計(jì)劃與測試文檔8.1

測試計(jì)劃軟件測試文檔主測試計(jì)劃驗(yàn)證測試計(jì)劃確認(rèn)測試計(jì)劃測試評估用戶手冊IEEE/ANSI測試文檔概述軟件生存周期各階段的測試任務(wù)與可交付的文檔測試評估包括以下幾個方面：測試覆蓋評估軟件故障評估測試有效性評估第九章 面向?qū)ο蟮能浖y試面向?qū)ο蟮母拍蠲嫦驅(qū)ο蟮臏y試與傳統(tǒng)軟件測試的區(qū)別面向?qū)ο筌浖y試類測試面向?qū)ο蟮募蓽y試第九章 面向?qū)ο蟮能浖y試面向?qū)ο蟮母拍蠲嫦驅(qū)ο蟮臏y試與傳統(tǒng)軟件測試的區(qū)別面向?qū)ο筌浖y試類測試面向?qū)ο蟮募蓽y試從測試的角度來考慮對象、消息、接口、類、繼承、動態(tài)綁定等面向?qū)ο蟪绦蛟O(shè)計(jì)的基本概念。例如：操作和方法(或者成員函數(shù))，對于大多數(shù)程序員來說并沒有多大的區(qū)別，然而對于測試人員來說，區(qū)別是顯然的。因?yàn)闇y試一個操作的步驟在某種程度上與測試一個方法的步驟不同，前者是類聲明的一部分同時也是操縱對象的一種手段，后者則是實(shí)現(xiàn)某個操作的一些代碼。第九章 面向?qū)ο蟮能浖y試面向?qū)ο蟮母拍蠲嫦驅(qū)ο蟮臏y試與傳統(tǒng)軟件測試的區(qū)別面向?qū)ο筌浖y試類測試面向?qū)ο蟮募蓽y試面向?qū)ο筌浖赜械睦^承、封裝和動態(tài)綁定以及和傳統(tǒng)軟件之間的差異給面向?qū)ο蟮能浖y試提出了一系列新的問題。例如：在傳統(tǒng)的面向過程的程序中，對于函數(shù)y=Function(x);我們只需要考慮函數(shù)Function()的行為特征，而在面向?qū)ο蟮某绦蛑校覀儾坏貌煌瑫r考慮基類函數(shù)Base::Function()

和繼承類函數(shù)Derived::Function()的行為特征。第九章 面向?qū)ο蟮能浖y試面向?qū)ο蟮母拍蠲嫦驅(qū)ο蟮臏y試與傳統(tǒng)軟件測試的區(qū)別面向?qū)ο筌浖y試類測試面向?qū)ο蟮募蓽y試面向?qū)ο蟮能浖y試主要體現(xiàn)在面向?qū)ο髥卧獪y試和面向?qū)ο蠹蓽y試中。面向?qū)ο髥卧獪y試針對程序內(nèi)部具體單一的功能模塊進(jìn)行測試。面向?qū)ο蠹蓽y試則針對系統(tǒng)內(nèi)部的相互服務(wù)進(jìn)行測試，如成員函數(shù)間的相互作用，類間的消息傳遞等。第九章 面向?qū)ο蟮能浖y試面向?qū)ο蟮母拍蠲嫦驅(qū)ο蟮臏y試與傳統(tǒng)軟件測試的區(qū)別面向?qū)ο筌浖y試類測試面向?qū)ο蟮募蓽y試在測試類的功能實(shí)現(xiàn)時，應(yīng)該首先保證類成員函數(shù)的正確性。面向?qū)ο缶幊痰墓逃刑匦允沟脤Τ蓡T函數(shù)的測試，不完全等同于傳統(tǒng)的函數(shù)或過程測試。還需要考慮：１. 繼承的成員函數(shù)是否都不需要測試？對父類中已經(jīng)測試過的成員函數(shù)，兩種情況需要在子類中重新進(jìn)行測試：繼承的成員函數(shù)在子類中做了改動；成員函數(shù)調(diào)用了改動過的成員函數(shù)。2. 對父類的測試能否照搬到子類？第十章 軟件測試自動化和測試工具測試與測試自動化測試工具常用測試工具簡介測試自動化和測試工具的好處測試自動化和測試工具存在的問題第十章 軟件測試自動化和測試工具測試與測試自動化測試工具常用測試工具簡介測試自動化和測試工具的好處測試自動化和測試工具存在的問題測試自動化希望通過自動化測試工具或其他手段，按照測試工程師的預(yù)定計(jì)劃進(jìn)行自動的測試，目的是減輕手工測試的勞動量，從而達(dá)到提高軟件質(zhì)量的目的。測試自動化的目的在于發(fā)現(xiàn)老的軟件故障，而手工測試的目的在于發(fā)現(xiàn)新故障。第十章 軟件測試自動化和測試工具測試與測試自動化測試工具常用測試工具簡介測試自動化和測試工具的好處測試自動化和測試工具存在的問題白盒測試工具黑盒測試工具測試設(shè)計(jì)和開發(fā)工具測試執(zhí)行和評估工具測試管理工具測試工具的選擇第十章 軟件測試自動化和測試工具測試與測試自動化測試工具常用測試工具簡介測試自動化和測試工具的好處測試自動化和測試工具存在的問題Parasoft

C++

Test測試工具簡介白盒工具--NuMega

DecPartner

Studio黑盒測試工具—QACenter數(shù)據(jù)庫測試工具——TESTBytes

和ERwin

Examiner測試管理工具——TestDirector第十章 軟件測試自動化和測試工具測試與測試自動化測試工具常用測試工具簡介測試自動化和測試工具的好處測試自動化和測試工具存在的問題測試自動化和測試工具能夠通過較少的開銷可以獲得更徹底的測試，提高軟件產(chǎn)品的質(zhì)量。但使用自動測試時，也會遇到許多問題，因?yàn)楣ぞ弋吘故枪ぞ撸谔幚硪恍┮馔馐录r，畢竟不如人靈活。幾個較為典型的靜態(tài)測試工具QACQAC是英國

ProgrammingReseach

公司開發(fā)的針對C語言的軟件靜態(tài)分析工具，通過對C語言程序進(jìn)行分析找出語法使用中存在的問題，例如：危險的用法、過于復(fù)雜、不可移植、不易維護(hù)或者不符合本部門要求的編程規(guī)范等，它能夠?qū)@些編譯器和其他開發(fā)工具不會察覺的隱藏問題發(fā)出警告。使用QAC可以明顯地減少代碼審查的時間，還可加深程序員對C語言特性的理解。如果在早期的開發(fā)階段就注意到程序所存在的問題，代碼的質(zhì)量可以得到大幅度的提升，測試周期可以縮短。分析C源程序，報告超過1100種潛在的問題，涉及C語言用法、危險結(jié)構(gòu)、有關(guān)維護(hù)性和移植性的方面；可以分析許多編譯器中常見的C語言的擴(kuò)展結(jié)構(gòu)和非標(biāo)準(zhǔn)結(jié)構(gòu)；非常容易配置警告信息和報告；可計(jì)算44種業(yè)界接受的度量標(biāo)準(zhǔn)包括

CyclomaticComplexity（圈復(fù)雜度），靜態(tài)路徑統(tǒng)計(jì)數(shù)和Myer’sinterval等，并且可以擴(kuò)展成為公司特定的度量標(biāo)準(zhǔn)；依據(jù)ISO標(biāo)準(zhǔn)產(chǎn)生報告；可以擴(kuò)展成為實(shí)施本公司特定需要的分析檢查；可進(jìn)行多種可視化的輸出，包括函數(shù)結(jié)構(gòu)圖、函數(shù)調(diào)用樹、外部引用、文件包括關(guān)系和軟件度量分析圖等；突出C和C++語言之間的移植性問題；在線HTML幫助連接警告消息，包括替代解決辦法；Windows和UNIX平臺提供易于使用的GUI，并且可以集成到常用開發(fā)環(huán)境（如VC++、Tornado等）。除了QAC外，Programming

Reseach公司還針對C++語言、Fortran語言等提供了相應(yīng)的軟件靜態(tài)分析工具QAC++和QA

Fortran等。McCabeMcCabe

IQ

是美國McCabe

&Association

公司的產(chǎn)品，McCabe

IQ

功能強(qiáng)大，包含McCabe

Test、McCabe

QA、McCabeReengineering

等多種功能組件。美國國防部、美國海軍武器系統(tǒng)和美國通用電子同時對McCabe軟件進(jìn)行了測試，證明McCabe

在軟件的質(zhì)量度量、預(yù)見軟件錯誤和規(guī)劃軟件測試方面對軟件人員會有非常好的幫助。McCabe

QA是一個用于軟件質(zhì)量度量的功能組件。通過它可以計(jì)算被測軟件的McCabe復(fù)雜度，并通過一個易理解的可視環(huán)境評估整個軟件的質(zhì)量，明確需要改進(jìn)質(zhì)量的區(qū)域。圖形化的顯示使得軟件QA人員和軟件開發(fā)人員有了交流的基礎(chǔ)。McCabe

QA產(chǎn)生程序級結(jié)構(gòu)圖（battle

maps）和單元級流程圖。程序級結(jié)構(gòu)圖（battle

maps）中的方盒代表模塊，不同顏色表示不同質(zhì)量量度。紅色模塊大于用戶定義的度極限，綠色小于度極

限，黃色大于基本度極限而小于第二度極限。這些可視顯示可以很容易地幫助用戶發(fā)現(xiàn)問題。用戶還可以利用McCabe

QA來追蹤軟件質(zhì)量的變化過程。用戶在軟件開發(fā)周期中抓拍軟件的特殊點(diǎn)，并且把每個抓拍的點(diǎn)儲存起來，這些信息用來繪出在開發(fā)周期中軟件質(zhì)量的變化趨勢。管理者可以觀察和追蹤軟件質(zhì)量的變化過程，監(jiān)督整個系統(tǒng)的復(fù)雜性和質(zhì)量。McCabe

Reengineering是一個軟件再工程（逆向工程）的功能組件。它支持各種軟件的再工程，包括對已有軟件系統(tǒng)的維護(hù)，改變軟件特性或移植到新的平臺或結(jié)構(gòu)中。利用此軟件可以幫助我們識別代碼中的冗余代碼，

進(jìn)行軟件維護(hù)和更改時的風(fēng)險（risk）分析。PolySpacePolySpace

C

Verifier

是法國PolySpace開發(fā)的一種比較有特色的靜態(tài)測試工具。它利用一種基于抽象解釋的靜態(tài)驗(yàn)證技術(shù)來靜態(tài)地發(fā)現(xiàn)被測軟件運(yùn)行時的錯誤（run-time

error）。它是一種非侵入式的和基于源程序代碼的靜態(tài)測試工具，可以無需修改和運(yùn)行被測試軟件就發(fā)現(xiàn)和檢查出那些在未來的運(yùn)行中可能出錯的代碼。利用PolySpaceVerifier可以在代碼審查和靜態(tài)測試階段確定被測軟件的運(yùn)行錯誤，并用不同的顏色將所有可能導(dǎo)致運(yùn)行錯誤的軟件代碼標(biāo)出來。PolySpace

Verifier可以自動檢查下面的錯誤：企圖讀未初始化的變量；多線程應(yīng)用中未保護(hù)數(shù)據(jù)的訪問沖突；對空指針和越界指針的引用；對超界數(shù)組的訪問；非法類型轉(zhuǎn)換（long

toshort,float

to

integer）;非法的算術(shù)運(yùn)算（如除零錯誤，負(fù)數(shù)開方）；整數(shù)和浮點(diǎn)數(shù)的上溢出/下溢出；不可達(dá)代碼。幾個較為典型的動態(tài)測試工具ASMTesterASMTester是一個支持匯編語言軟件的單元測試工具。該工具為軟件開發(fā)和軟件測試人員提供了一個方便、有效的手段，在不需要任何目的機(jī)、硬件仿真器或數(shù)據(jù)發(fā)生器的前提下，高效率、低成本地完成對8031/51、8086/88、8096/98、TMSC3x、TMSC6x、1750A等匯編語言軟件的單元測試工作。該工具為用戶進(jìn)行單元測試提供以下功能：被測模塊和測試用例的管理與維護(hù)提供每個被測單元（模塊）動態(tài)測試覆蓋率指標(biāo)提供每個被測單元動態(tài)測試時的性能指標(biāo)變量追蹤測試結(jié)果的自動比對功能完善的嵌入式硬件環(huán)境模擬機(jī)制自動產(chǎn)生單元測試結(jié)果記錄單并可打印CantataCantata/

Cantata++是英國IPL公司開發(fā)的一個面向源代碼的測試分析工具，可以支持對軟件的靜態(tài)分析和動態(tài)測試。在動態(tài)測試方面，該工具為測試的說明、執(zhí)行、歸檔、重用和重復(fù)動態(tài)測試提供一個形式上的框架。它具有以下特點(diǎn)：可以根據(jù)用戶定義的Test

Case

Definition

自動生成測試腳本；自動生成樁模塊模擬被測模塊的函數(shù)調(diào)用。用戶可以傳遞參數(shù)給樁模塊，并設(shè)置樁模塊的返回參數(shù)；通過對測試執(zhí)行過程的監(jiān)視，得到測試覆蓋信息（包括語句、分支、條件、分支/條件、條件組合等不同級別的覆蓋信息）和程序執(zhí)行時間分布情況的信息；Cantata支持C語言，Cantata++支持C++語言。LoadRunnerLoadRunner是美國Mercury

Interactive公司開發(fā)的一種預(yù)測系統(tǒng)行為和性能的負(fù)載測試工具。通過以模擬上千萬用戶，實(shí)施并發(fā)負(fù)載及實(shí)時性能監(jiān)測的方式來確認(rèn)和查找問題，LoadRunner能夠?qū)φ麄€企業(yè)網(wǎng)絡(luò)結(jié)構(gòu)進(jìn)行測試。通過使用LoadRunner，企業(yè)能最大限度地縮短測試時間，優(yōu)化性能和加速應(yīng)用系統(tǒng)的發(fā)布周期。CodeTESTCodeTEST是美國AMC公司采用專利插樁技術(shù)開發(fā)出的專為嵌入式軟

件開發(fā)與測試人員使用的性能分析與測試工具。作為專為嵌入式系統(tǒng)

軟件測試而設(shè)計(jì)的工具套件，CodeTEST廣泛應(yīng)用于嵌入式軟件的在

線動態(tài)測試。CodeTEST采用硬件輔助軟件的系統(tǒng)構(gòu)架和源代碼插樁

技術(shù)，用適配器或探針，直接連接到被測試系統(tǒng)，從目標(biāo)板總線獲取

信號，為跟蹤嵌入式應(yīng)用程序、分析軟件性能、統(tǒng)計(jì)軟件的測試覆蓋

率以及監(jiān)測內(nèi)存的動態(tài)分配等提供了一個實(shí)時在線的高效率解決方案。TestbedTestbed是英國LDRA公司的產(chǎn)品，其動態(tài)測試功能通過Tbrun模塊實(shí)現(xiàn)。Tbrun具有自動生成測試腳本與打樁處理的功能，測試腳本編譯后與被測軟件連接在一起，從而產(chǎn)生一可執(zhí)行程序運(yùn)行于目標(biāo)系統(tǒng)或主機(jī)系統(tǒng)，并產(chǎn)生測試結(jié)果文件。第十一章 軟件質(zhì)量保證軟件質(zhì)量保證軟件測試管理技術(shù)測試的組織方式軟件過程成熟度CMM11.4

ISO

9000第十一章 軟件質(zhì)量保證軟件質(zhì)量保證軟件測試管理技術(shù)測試的組織方式軟件過程成熟度CMM11.4

ISO

9000軟件質(zhì)量保證的主要職責(zé)是檢查和評價當(dāng)前軟件開發(fā)過程，并設(shè)法達(dá)到防止軟件故障出現(xiàn)的目標(biāo)。第十一章 軟件質(zhì)量保證軟件質(zhì)量保證軟件測試管理技術(shù)測試的組織方式軟件過程成熟度CMM11.4

ISO

9000建立軟件測試管理體系的主要目的是確保軟件測試在軟件質(zhì)量保證中發(fā)揮應(yīng)有的關(guān)鍵作用。第十一章 軟件質(zhì)量保證軟件質(zhì)量保證軟件測試管理技術(shù)測試的組織方式軟件過程成熟度CMM11.4

ISO

9000軟件能力成熟度CMM現(xiàn)已成為一個行業(yè)標(biāo)準(zhǔn)模型，用來定義和評價軟件公司開發(fā)過程的成熟度，為提高軟件質(zhì)量提供指導(dǎo)。第十一章 軟件質(zhì)量保證軟件質(zhì)量保證軟件測試管理技術(shù)測試的組織方式軟件過程成熟度CMM11.4

ISO

9000ISO

9000定義了一套關(guān)于質(zhì)量管理和質(zhì)量保證的標(biāo)準(zhǔn)，

有助于公司一致地交付符合客戶質(zhì)量要求的產(chǎn)品或服務(wù)。軟件質(zhì)量我們先來看軟件質(zhì)量的定義：反映軟件系統(tǒng)或軟件產(chǎn)品滿足明

確或隱含需求的能力有關(guān)的特性總和。其含義有四：其一，能

滿足給定需要的性質(zhì)和特性的全體；其二，具有所期望的各種

屬性的組合程度；其三，顧客和用戶覺得能滿足其綜合期望的

程度；其四，確定軟件在使用中將滿足顧客預(yù)期要求的程度。

簡言之，軟件質(zhì)量是軟件一些特性的組合，它依賴軟件的本身。對于軟件質(zhì)量有多種不同的視面。用戶主要感興趣的是如何使用軟件、軟件性能和使用軟件的效用，特別是在指定的使用環(huán)境（context）下獲得與有效性、生產(chǎn)率、安全性和滿意度有關(guān)的規(guī)定目標(biāo)的能力，即使用質(zhì)量。開發(fā)者負(fù)責(zé)生產(chǎn)出滿足質(zhì)量要求的軟件，所以他們對中間制品和最終產(chǎn)品的質(zhì)量都感興

趣，當(dāng)然開發(fā)者視面也要體現(xiàn)軟件維護(hù)者所需要的質(zhì)量特性。對于管理者也許更注重總的質(zhì)量而不是某一特性，必須服從管理準(zhǔn)則，如在進(jìn)度拖延或成本超支與質(zhì)量提高之間進(jìn)行權(quán)衡，以達(dá)到用有限的人力、成本和時間使軟件質(zhì)量達(dá)到優(yōu)化的目的。保證軟件質(zhì)量基本上可用兩種途徑來實(shí)現(xiàn)，一種是保證生存周期過程，另一種是評價軟件最終產(chǎn)品的質(zhì)量。這兩種途徑都很重要，且都要求有一系統(tǒng)來管理質(zhì)量，該系統(tǒng)應(yīng)確定管理對質(zhì)量的保證，指明其策略以及恰當(dāng)?shù)脑敿?xì)執(zhí)行步驟。前者是采用ISO 9001質(zhì)量體系設(shè)計(jì)、開發(fā)、生產(chǎn)、安裝和服務(wù)的質(zhì)量保證模式，或者CMM能力成熟度模型，或者ISO 15504軟件過程評估（也稱為SPICE，即軟件過程改進(jìn)和能力確定）等方法來取得滿足質(zhì)量要求的軟件。后者是把軟件產(chǎn)品評價看作軟件生存周期的一個過程，目標(biāo)就是讓軟件產(chǎn)品在指定的使用環(huán)境下具有所需的效用，可以通過測量內(nèi)部屬性，也可以通過測量外部屬性，或者通過測量使用質(zhì)量屬性來評價。軟件質(zhì)量管理目前能被大家接受和公認(rèn)的是基于軟件生存周期過程的質(zhì)量管理，包括ISO

9001、CMM、ISO

15504等都是屬于這種類型，如能力成熟度模型（CMM）較全面地描述和分析軟件機(jī)構(gòu)的軟件過程能力的發(fā)展程度，建立了一個描述軟件機(jī)構(gòu)的軟件過程成熟度的分級標(biāo)準(zhǔn)和框架。軟件過程能力是描述遵循一個軟件過程而得到期望結(jié)果的程度，軟件過程成熟度是指一個具體的軟件過程被明確定義、管理、控制其實(shí)效的程度。利用能力成熟度模型，軟件機(jī)構(gòu)可以評估自己當(dāng)前的過程成熟度，并通過提出更嚴(yán)格的軟件質(zhì)量標(biāo)準(zhǔn)和過程改進(jìn)，來選擇自己的改進(jìn)策略，以達(dá)到更高一級的成熟程度。軟件產(chǎn)品評價需要策劃和管理，從而也是管理職能中的一個部分。軟件質(zhì)量模型一個框架，它規(guī)定了內(nèi)部和外部質(zhì)量的質(zhì)量模型與使用質(zhì)量的質(zhì)量模型，以及它們在軟件生存周期中的關(guān)系。內(nèi)部和外部質(zhì)量的質(zhì)量模型將軟件質(zhì)量屬性分類為6個特性，即功能性、可靠性、易用性、效率、易維護(hù)性和易移植性，并進(jìn)一步細(xì)分為27個子特性，從而構(gòu)成一個有層次的樹狀結(jié)構(gòu)，結(jié)構(gòu)的最高層由質(zhì)量特性組成，最低層則由軟件質(zhì)量屬性組成。使用質(zhì)量的質(zhì)量模型將軟件質(zhì)量屬性分類為4個特性，即有效性、生產(chǎn)率、安全性和滿意度。軟件質(zhì)量特性功能性：在指定條件下使用時，軟件產(chǎn)品提供滿足明確和隱含需求功能的能力；可靠性：在指定條件下使用時，軟件產(chǎn)品維持規(guī)定的性能級別的能力；易用性：在指定條件下使用時，軟件產(chǎn)品被理解、學(xué)習(xí)、使用及其吸引用戶的能力；效率：在規(guī)定條件下，相對于所用資源的數(shù)量，軟件產(chǎn)品可提供適當(dāng)性能的能力；易維護(hù)性：軟件產(chǎn)品可被修改的能力，修改可能包括修正、改進(jìn)或者適應(yīng)環(huán)境、需求和功能規(guī)約的變化；易移植性：軟件產(chǎn)品從一種環(huán)境遷移到另一種環(huán)境的能力；有效性：軟件產(chǎn)品在指定使用環(huán)境下，使用戶準(zhǔn)確、完整地獲得規(guī)定目標(biāo)的能力；生產(chǎn)率：軟件產(chǎn)品在指定使用環(huán)境下，使用戶花費(fèi)合適的與有效性相關(guān)的資源數(shù)量的能力；安全性：軟件產(chǎn)品在指定使用環(huán)境下，獲得可接受的損害人類、商務(wù)、軟件、財(cái)產(chǎn)或環(huán)境風(fēng)險級別的能力；滿意度：軟件產(chǎn)品在指定使用環(huán)境下，使用戶滿意的能力。軟件質(zhì)量評價過程３種評價過程：其一：開發(fā)者用的過程，計(jì)劃開發(fā)新產(chǎn)品或增強(qiáng)現(xiàn)有產(chǎn)品時為了預(yù)測最終產(chǎn)品質(zhì)量指標(biāo)；其二，需求方用的過程，計(jì)劃獲取或復(fù)用某個已有產(chǎn)品時，為了決定接受產(chǎn)品或者從眾多可選產(chǎn)品選擇某個產(chǎn)品；其三，評價者用的過程，應(yīng)開發(fā)者、需方或其他機(jī)構(gòu)的請求，對產(chǎn)品進(jìn)行獨(dú)立評估，它們通常是第三方機(jī)構(gòu)。不論哪一種評價過程，都是首先要確立評價需求，然后是規(guī)定評價、設(shè)計(jì)評價和執(zhí)行評價等活動。確立評價需求應(yīng)確立評價目

的，確定產(chǎn)品類型（中間制品、最終產(chǎn)品），規(guī)定質(zhì)量模型；規(guī)定評價包括選擇度量、建立度量評定等級、確立評估準(zhǔn)則；設(shè)計(jì)評價包括制定評價計(jì)劃；執(zhí)行評價包括進(jìn)行度量、與評估準(zhǔn)則相比較，評價結(jié)果。早在20世紀(jì)60年代末，已經(jīng)有人討論大型軟件開發(fā)項(xiàng)目的組織管理問題。隨著軟件工程在實(shí)踐過程中發(fā)生的問題，

人們認(rèn)識到軟件產(chǎn)品和軟件項(xiàng)目的開發(fā)，不完全取決于軟件開發(fā)方法。與程序的復(fù)雜性和系統(tǒng)的復(fù)雜性相比，前者已得到較大的緩解，更重要的是后者。如進(jìn)度推遲、經(jīng)費(fèi)超支、質(zhì)量差、軟件人員不稱職，均與管理有關(guān)。自20世紀(jì)80年代初，軟件界就關(guān)注“軟件過程”。20世紀(jì)80年代中期，IBM在Watts

S.Humphrey的指導(dǎo)下，Ron

Radice等人將成熟度框架首次應(yīng)用于軟件過程，

并由Humphrey于1986年將此成熟度框架帶到卡內(nèi)基·梅隆大學(xué)的軟件工程研究所（CMU/SEI）。應(yīng)美國聯(lián)邦政府要求，為其提供一個評價軟件開發(fā)商能力的方法，1986年11月，CMU/SEI在MITRE公司的幫助下開始設(shè)計(jì)過程成熟度框架，以此幫助軟件機(jī)構(gòu)改進(jìn)他們的軟件過程。1987年9月，CMU/SEI發(fā)表了一個簡短的軟件過程成熟度框架。其后在Humphrey的《管理軟件過程》一書中進(jìn)行擴(kuò)充。書中提出了軟件過程評估和軟件能力評估，和成熟度問卷，用于評估軟件過程成熟度。基于這些設(shè)想，由Jim

Withey,

MarkPaulk和Cynthia

Wise

在1990

年提出了最早的草案。1991年8月Mary

Beth

Chrissis

和Bill

Curtis

幫助Mark

Paulk校訂，推出了CMM（成熟度模型）1.1版。CMU/SEI原先計(jì)劃在1997年下半年推出2.0版，1998年推出2.1版。但由于種種原因，未能按計(jì)劃推出2.0版。由于美國聯(lián)邦政府的大力推行，CMM模型得到了廣泛應(yīng)用，CMU/SEI于2001年公布了通過CMM評估的軟件機(jī)構(gòu)共有964家，并對其作了統(tǒng)計(jì)分析。目前CMM本身還在向縱深發(fā)展，CMM家族有：軟件能力成熟度模型（SW-CMM）軟件獲取能力成熟度模型（SA-CMM）人員能力成熟度模型（People-CMM）

系統(tǒng)工程能力成熟度模型（SE-CMM）集成產(chǎn)品開發(fā)能力成熟度模型（IPD-CMM）個體軟件工程（PSP）群組軟件工程（TSP）另外，國際標(biāo)準(zhǔn)化組織為組織軟件過程評價標(biāo)準(zhǔn)的制訂，成立了“軟

件過程改進(jìn)和能力確定（SoftwareProcessImprovementand

Capability

Determine,

SPICD）”項(xiàng)目，ISO/IEC

JTCI的SC

7分技術(shù)委員會于1996年9月正式公布了工作草案，代號為15504，即ISO/IEC

TR

15504InformationTechnology

–Software

ProcessAssessment。CMM的廣泛采納和成功推廣，推動了軟件及其他學(xué)科的類似模型的開發(fā)，從而模型繁衍，導(dǎo)致了過程改善目標(biāo)和技術(shù)的沖突。要求的培訓(xùn)工作有了相當(dāng)大的增長，部分實(shí)踐人員在應(yīng)用各種不同的模型來實(shí)現(xiàn)特定的需要時產(chǎn)生了混淆。針對這種情況，美國聯(lián)邦政府、產(chǎn)業(yè)界和CMU/SEI于1998年啟動了“能力成熟度模型