軟件測試與質量保證飛軟件測試軟件測試從計算機誕生至今，計算機無疑成為當代發(fā)展最為迅猛的科學技術。今天，計算機已滲透到人們生活的各個方面。工工農金科教衛(wèi)生國業(yè)業(yè)融防百姓生活隨著對計算機需求和依賴的與日俱增計算機系統(tǒng)的規(guī)模和復雜性急劇增加計算機系統(tǒng)的規(guī)模和復雜性急劇增加其軟件開發(fā)成本以及由于軟件故障而造成的經濟損失也正在增加軟件質量問題已成為人們共同關注的焦點。軟件質量問題已成為人們共同關注的焦點。軟件開發(fā)商為了占有市場，把軟件質量作為企業(yè)的重要目標之一，以免在激烈的競爭中被淘汰出局。用戶為了保證自己業(yè)務的順利完成，當然也希望選用優(yōu)質的軟件。軟件測試一些關鍵應用，如民航訂票系統(tǒng)、銀行結算系統(tǒng)、證券交易系統(tǒng)、自動飛行控制軟件、軍事防御、核電站安全控制系統(tǒng)

對軟件質量提出了更高的要求。軟件測試使用質量欠佳的軟件，還可能造成災難性的后果。2003年,軟件問題造成美國東北部及加拿大停電,導致5000萬人受影響,3人喪生,各種損失估計約為60億美元2004年,北美銀行由于一個新安裝的軟件的缺陷,使得數(shù)以百萬計的客戶受到影響,該缺陷的修復花費了整整兩個星期的時間,造成的損失以億元計2000年美國海軍飛機墜落,導致4人喪生(控制軟件問題)1997年韓國空難,導致225人喪生(雷達控制軟件問題)2003年4月,美國一個專門為學生提供貸款的公司由于軟件出錯,錯誤計算80萬宗學生貸款利率,導致了800萬美元的利率損失千年蟲問題Intel芯片浮點除法軟件故障等。Intel芯片浮點除法軟件故障等。因此，許多科學家在展望21世紀計算機科學發(fā)展方向和策略時，把軟件質量放在優(yōu)先于提高軟件功能和性能的地位。軟件測試軟件測試軟件測試是對軟件需求分析、設計規(guī)格說明和編碼的最終復審是軟件質量保證的關鍵步驟是為了發(fā)現(xiàn)故障而執(zhí)行程序的過程。隨著軟件系統(tǒng)規(guī)模和復雜性的增加，進行專業(yè)化高效軟件測試的要求越來越嚴格，軟件測試職業(yè)的價值逐步得到了認可，軟件測試從業(yè)人員急劇增加，軟件測試評測中心如雨后春筍般成長起來。軟件測試評測中心如雨后春筍般成長起來。軟件測試無疑是面向未來信息化社會的熱門專業(yè)之一軟件測試無疑是面向未來信息化社會的熱門專業(yè)之一在未來3~5在未來3~5年內，軟件測試技術將作為一門新興產業(yè)而快速發(fā)展起來。內容提要：第一章軟件測試概述第二章軟件測試實質第三章軟件測試策略第四章黑盒測試第五章白盒測試第六章集成測試與系統(tǒng)測試第七章驗證測試和確認測試第八章測試計劃與測試文檔第九章面向對象的軟件測試第十章軟件測試自動化和測試工具第十一章軟件質量保證第十二章軟件測試職業(yè)指導第一章軟件測試概述計算機系統(tǒng)的軟件可靠性問題軟件測試與軟件可靠性軟件測試的發(fā)展歷史、現(xiàn)狀和展望人們對計算機依賴的程度越高，對其可靠性的要求就越高。IEEE(InstituteIEEE(InstituteofElectricalandElectronicsEngineers，電氣與電子工程師學會)定義軟件可靠性為：系統(tǒng)在特定的環(huán)境下，在給定的時間內，無故障地運行的概率。用來評價軟件按照用戶的要求和設計目標，完成規(guī)定功能的能力，涉及軟件的性能、功能性、可用性、可服務性、可安裝性、可維護性以及文擋等多方面特性。軟件測試是保證軟件可靠性的一個關鍵因素。1.1.軟件測試的重要性計算機和程序是一對孿生兄弟,自從計算機誕生之日就必須要有程序在其上運行,從而得到問題的正確解,必須對程序的功能性進行測試.所以,軟件測試工作是在軟件工程誕生之前就客觀存在了,一直延用至今,且其測試的內容和技術也有了較大的發(fā)展。無論從何種角度講，軟件測試都是軟件開發(fā)過程一個必不可少的活動，是對軟件需求分析、設計規(guī)約和編碼的最終復審；是軟件質量保證的關鍵步驟。軟件測試是根據(jù)軟件開發(fā)各階段的規(guī)約和軟件的內部結構，精心設計一批測試用例（包括輸入數(shù)據(jù)及其預期的輸出結果），并利用這些測試用例去運行程序，以發(fā)現(xiàn)軟件中不符合質量特性要求（即缺陷或錯誤）的過程。目前，許多軟件開發(fā)機構將研制力量的40%以上投入到軟件測試之中，體現(xiàn)了充分重視軟件質量要求。可見軟件測試的重要性。軟件測試不等同于程序測試。軟件測試應當貫穿在軟件生存周期全過程。因此，需求描述、需求規(guī)約、設計規(guī)約、模塊設書以及程序等都應成為軟件測試的對象。在進行軟件產品或軟件系統(tǒng)開發(fā)時，主要有3類人員必須參與，他們是項目經理、開發(fā)人員和測試人員。一般來說，大家都會十分重視開發(fā)工作，因此在一個項目組中，會有很多的開發(fā)人員，而測試人員比較少。經過多次實踐后，才會增加測試人員，如微軟公司就是這種情況。目前軟件測試人員就比較多了，如Exchange2000，項目經理23人，開發(fā)人員140人，測試人員350人；再如Windows2000，項目經理250人，開發(fā)人員1700人，測試人員3200人，可以看出測試人員和開發(fā)人員之比，竟達5：3。2.2.軟件測試的目的和原則基于不同的立場，存在著不同的測試目的。從用戶的角度看，一般希望通過軟件測試暴露軟件中隱藏的缺陷，以此來決定是否可以接受該軟件產品和軟件系統(tǒng)。從軟件開發(fā)者的角度看，希望通過測試說明軟件中不存在缺陷，表明該軟件已正確地實現(xiàn)了用戶的要求，從而確立用戶對該軟件的質量信任。從軟件管理者角度看，希望花費有限的資源達到該軟件用戶的質量要求，經費和進度是其首要考慮的焦點。因此，就軟件測試的目的可提出如下的觀點：測試是程序的執(zhí)行過程，目的在于發(fā)現(xiàn)缺陷；一個好的測試用例在于能發(fā)現(xiàn)至今未發(fā)現(xiàn)的缺陷；一個成功的測試是發(fā)現(xiàn)了至今未發(fā)現(xiàn)的多個缺陷的測試。所以，測試的目的是以最少的資源和時間，找出軟件中隱藏的各種缺陷甚至錯誤。測試的成功與否就是以發(fā)現(xiàn)軟件中潛在的缺陷多少來衡量。根據(jù)這些測試目的和目標，軟件測試應該注意些什么呢？鄭人杰等人編著的《實用軟件工程》第2版（清華大學出版社，1999年）中有一段描述對此問題進行了回答。應當把“盡早地和不斷地進行軟件測試”作為軟件開發(fā)者的座右銘。由于原始問題的復雜性，軟件的復雜性和抽象性，軟件開發(fā)各個階段工作的多樣性，以及參加開發(fā)各種層次人員之間工作的配合關系等因素，使得開發(fā)的每個環(huán)節(jié)都可能產生錯誤。所以不應把軟件測試僅僅看作是軟件開發(fā)的一個獨立階段，而應當把它貫穿到軟件開發(fā)的各個階段中。堅持在軟件開發(fā)的各個階段的技術評審，這樣才能在開發(fā)過程中盡早發(fā)現(xiàn)和預防錯誤，把出現(xiàn)的錯誤克服在早期，杜絕某些隱患，提高軟件質量。測試用例應由測試輸入數(shù)據(jù)和與之對應的預期輸出結果這兩部分組成。在做測試之前，應當根據(jù)測試的要求選擇在測試過程中使用的測試用例。測試用例主要用來檢驗程序員編制的程序，因此不但需要測試的輸入數(shù)據(jù)，而且需要針對這些輸入數(shù)據(jù)的預期輸出結果。如果對測試輸入數(shù)據(jù)沒有給出預期的程序輸出結果，那么就缺少了檢驗實測結果的基準，就有可能把一個似是而非的錯誤結果當成正確結果。程序員應避免檢查自己的程序.測試工作需要嚴格的作風，客觀的態(tài)度和冷靜的情緒。人們常常由于各種原因，具有一種不愿否定自己工作的心里，認為揭露自己程序中的問題總不是一件愉快的事，這一心里狀態(tài)就成為測試自己程序的障礙。另外，程序員對規(guī)約理解錯誤而引入的錯誤更難發(fā)現(xiàn)。如果由別人來測試程序員編寫的程序，可能會更客觀，更有效，并更容易取得成功。要注意的是，這點不能與程序的排錯（調試）相混淆。排錯由程序員自己來做可能更有效。在設計測試用例時，應當包括合理的輸入條件和不合理的輸入條件。合理的輸入條件是指能驗證程序正確的輸入條件，而不合理的輸入條件是指異常的、臨界的及可能引起問題變異的輸入條件。在測試程序時，人們常常傾向于過多地考慮合法的和期望的輸入條件，以檢查程序是否做了它應該做的事情，而忽視了不合法的和預想不到的輸入條件。事實上，軟件在投入運行之后，用戶的使用往往不遵循事先的約定，使用了一些意外的輸入，如用戶在鍵盤上按錯了鍵或輸入了非法的命令。如果開發(fā)的軟件遇到這種情況時不能作出適當?shù)姆磻?，給出相應的信息，那么就容易產生故障，輕則給出錯誤結果，重則導致軟件失效。因此，軟件系統(tǒng)處理非法命令的能力也必須在測試時受到檢驗。用不合理的輸入條件測試程序時，往往比用合理的輸入條件進行測試能發(fā)現(xiàn)更多的錯誤。充分注意測試中的群集現(xiàn)象。測試時不要以為找到了幾個錯誤問題就已解決，不須繼續(xù)測試了。經驗表明，測試后程序中殘存的錯誤數(shù)目與該程序中已發(fā)現(xiàn)的錯誤數(shù)目或檢錯率成正比。在所測程序段中，若發(fā)現(xiàn)錯誤數(shù)目多，則殘存錯誤數(shù)目也比較多。這種錯誤群集性現(xiàn)象，已為許多程序的測試實踐所證實。例如IBM公司的OS/370操作系統(tǒng)，47%的錯誤僅與該系統(tǒng)的4%的程序模塊有關。嚴格執(zhí)行測試計劃，排除測試的隨意性。測試計劃應包括：所測試軟件的功能，輸入和輸出，測試內容，各項測試的進度安排，資源要求，測試資料，測試工具，測試用例的選擇，測試的控制方式和過程，系統(tǒng)組裝方式，跟蹤規(guī)程，排錯規(guī)程，回歸測試的規(guī)定以及評價標準等。對于測試計劃，要明確規(guī)定，不要隨意解釋。應當對每一個測試結果做全面檢查這是一條最明顯的原則，但常常被忽視。有些錯誤的征兆在輸出實測結果時已經明顯地出現(xiàn)了，但是如果不仔細全面地檢查測試結果，就會使這些缺陷或錯誤被遺漏掉。所以必須對預期的輸出結果明確定義，對實測的結果仔細分析檢查，抓住癥候，暴露錯誤。妥善保存測試計劃，測試用例，出錯統(tǒng)計和最終分析報告，為維護提供方便。3.3.軟件測試與相關的幾個概念軟件測試不僅僅是軟件質量保證體系中的重要一環(huán),而且也是保證質量的重要技術手段。排錯（debugging）是查找、分析和糾正錯誤的過程。而測試（testing）是由人工或自動方法來執(zhí)行或評價軟件系統(tǒng)或軟件子系統(tǒng)的過程，以驗證是否滿足規(guī)定的需求，或識別出期望的結果和實際結果之間有無差別。因此，測試的任務是盡可能多地發(fā)現(xiàn)軟件中的缺陷和錯誤，而排錯的任務是進一步診斷和改正程序中潛在的缺陷和錯誤。一般來說，排錯有兩類活動：其一是確定程序中可疑缺陷或錯誤的確切性質和位置；其二，是對程序（設計、編碼）進行修改，從而排除這個潛在的缺陷或錯誤。驗證（verification）有3個含義：其一，確定軟件生存周期中的一個給定階段的產品是否達到前階段確立的需求的過程；其二，程序正確性的形式證明，即采用形式理論證明程序符合設計規(guī)約規(guī)定的過程；其三，評審、審查、測試、檢查、審計等各類活動，或對某些項處理、服務或文件等是否和規(guī)定的需求相一致進行判斷和提出報告。確認（validation）是在軟件開發(fā)過程結束時，對軟件進行評價，以確認它和軟件需求是否相一致的過程，其目的是想證實在一個給定的外部環(huán)境中軟件的正確性。確認一般包括需求規(guī)約的確認和程序的確認，而程序的確認又分為靜態(tài)確認和動態(tài)確認。靜態(tài)確認不在計算機上實際執(zhí)行程序，通過人工分析或程序正確性證明來證實程序的正確性。動態(tài)確認主要通過動態(tài)執(zhí)行程序作分析，或者測試程序來檢查其動態(tài)行為，以證實程序是否存在問題，這通常就叫確認測試。4.4.軟件測試方法分類軟件測試有各種分類方法，按照不同的分類原則有不同的分類結果。軟件測試的分類原則可以有一下幾種：按照軟件測試的動、靜態(tài)來分，有靜態(tài)測試和動態(tài)測試。在軟件開發(fā)過程中，每產生一個文檔，或每一個活動結束時產生的文檔，都必須對文檔進行測試，靜態(tài)測試通過了，則該過程或活動才結束，開發(fā)工作取得了進展，可以進入下一個階段或活動，對這種靜態(tài)測試也叫做評審。動態(tài)測試就是通過運行程序來檢驗程序的動態(tài)行為和運行結果的正確性。運行程序并非動態(tài)測試的目的，通過運行來檢驗程序是否正確才是動態(tài)測試的目的。動態(tài)測試必須具備測試用例，有時還需要具備驅動程序、樁模塊和測試監(jiān)視代碼。按照軟件層面來分，美國國家宇航局建議將軟件評審的內容分兩個層面來進行，即技術評審和管理評審。技術評審的任務：建立軟件配置管理基線；提出并解決技術問題，審查技術工作；評價項目的狀態(tài)，判明有關技術問題的近期、長期風險，并加以討論；在技術代表的權限內，達成已判明風險的轉移策略；標識呈交給管理人員討論的風險要素和有關問題；確保用戶和軟件開發(fā)技術人員之間的交流暢通。管理評審的任務：報告上級管理部門該項目的狀態(tài)、所采取的方針、所達成的技術協(xié)議，以及軟件產品進展的總體情況；解決技術評審不能解決的問題；就技術評審不能解決的近期、長期風險可達成的轉移戰(zhàn)略；鑒別并解決管理方面的問題以及技術評審沒有提出的風險；征得用戶的同意和各方認可以便及時完成。按照軟件開發(fā)過程的內、外進行分類①軟件開發(fā)過程中的測試。按軟件開發(fā)過程中所處的階段（或活動）及其作用來分，有單元測試、集成測試、系統(tǒng)測試、驗收測試。軟件開發(fā)過程中的測試，大部分是開發(fā)單位自行完成的。當然，也可交第三方軟件測試機構執(zhí)行，但往往是系統(tǒng)測試和驗收測試。有時，這種測試，因為不是由用戶進行的，又稱α測試。②軟件產品測試。其測試對象是產品化或正在產品化的軟件。這種測試的內容包含范圍很廣，通常由第三方軟件測試機構完成。通常的軟件產品測試：功能測試、性能測試、β測試（用戶測試）專門的軟件產品測試：可靠性測試、標準符合性測試、互操作性測試、安全性測試、強度測試。按照測試用例所依據(jù)的信息來源，測試方法可以分為以下幾種：①以程序為基礎的測試。通過對程序的分析形成測試用例，并以程序被執(zhí)行的程度來判斷測試是否充分，這就是“白盒法”。②以需求規(guī)約和需求描述為基礎的測試。通過分析軟件的需求描述和需求規(guī)約形成測試用例，并根據(jù)需求描述和需求規(guī)約所約定的功能和性能是否得到了充分的檢驗來判斷測試是否充分。這就是“黑盒法”。③程序和需求相結合的測試。綜合考慮需求和實現(xiàn)形成測試用例。④以接口為基礎的測試，僅僅依靠軟件與其運行環(huán)境之間的接口形成測試用例，隨機測試就是一種以接口為基礎的測試方法。按照判斷測試的充分性，測試方法可分為以下幾種。①結構性測試，旨在充分覆蓋程序結構，并以程序中的某類成分是否都已得到測試為依據(jù)，來判斷測試的充分性，如語句覆蓋是一種結構性測試。②排錯性測試，旨在排除程序中潛在缺陷的可能性，并根據(jù)測試用例集成排除軟件潛在缺陷可能性的能力判斷測試的充分性。③分域測試，通過對軟件的需求和實現(xiàn)進行分析，將軟件的輸入空間劃分成一系列子空間，然后在每一個子空間內選擇一個或多個測試數(shù)據(jù)。④功能測試，根據(jù)軟件所需的功能和所實現(xiàn)的功能，形成測試用例，分析測試的充分性。按照軟件測試的完整性，Shooman從程序結構和測試覆蓋程度分為如下幾種。①完全性和連續(xù)性測試：要求程序中的所有指令至少執(zhí)行一次（100%的語句覆蓋）②圖路徑測試：所有圖路徑至少執(zhí)行一次（100%的圖路徑覆蓋）③程序路徑測試：所有程序路徑至少執(zhí)行一次（100%的程序路徑覆蓋）④窮舉測試：對輸入?yún)?shù)的所有值執(zhí)行所有程序路徑，或對輸入?yún)?shù)的所有值和所有輸入序列，以及初始條件的所有組合，執(zhí)行所有程序路徑。5.5.軟件錯誤的分級在軟件產品開發(fā)中,不論哪一階段產生的缺陷和錯誤,其最后的表現(xiàn)就是:軟件產品達不到用戶的要求,由于存在軟件錯誤,使之不能有效地完成規(guī)定的任務.軟件測試的任務,就在于找出或發(fā)現(xiàn)軟件中存在的錯誤(假如錯誤存在的話).由于錯誤的性質不同,危害性也不同.軟件測試如果能發(fā)現(xiàn)軟件中危害性大的錯誤(如果存在的話),那么該軟件測試的價值就越高.一般將軟件錯誤分為5級。第1級錯誤：不能滿足軟件需求，基本功能未完全實現(xiàn)，危及人員或設備安全的錯誤。第2級錯誤：不利于完全滿足軟件需求或基本功能的實現(xiàn)，并且不存在可以變通的解決辦法（重新裝入或重新啟動該軟件不屬于變通解決辦法）。第3級錯誤：不利于完全滿足軟件需求或基本功能的實現(xiàn)，但卻存在合理的、可以變通的解決辦法（重新裝入或重新啟動該軟件不屬于變通解決辦法）。第4級錯誤：不影響完全滿足軟件需求或基本功能的實現(xiàn)，但有不便于操作員操作的錯誤。第5級錯誤：不屬于第1~4級錯誤的其他錯誤。第二章軟件測試實質軟件測試的基本概念軟件故障測試的復雜性與經濟性測試的充分性問題測試原則停止測試的標準這一定義非常明確地提出了軟件測試以發(fā)現(xiàn)故障為目的。針對測試人員，測試的最好定義是：測試是為了發(fā)現(xiàn)故障而執(zhí)行程序的過程。第二章軟件測試實質這一定義非常明確地提出了軟件測試以發(fā)現(xiàn)故障為目的。針對測試人員，測試的最好定義是：測試是為了發(fā)現(xiàn)故障而執(zhí)行程序的過程。軟件測試的基本概念軟件故障測試的復雜性與經濟性測試的充分性問題測試原則停止測試的標準這一定義非常明確地提出了軟件測試以檢驗軟件是否滿足需求為目標。IEEE這一定義非常明確地提出了軟件測試以檢驗軟件是否滿足需求為目標。IEEE提出的軟件工程標準術語中給軟件測試下的定義是：“使用人工或自動手段來運行或測定某個系統(tǒng)的過程，其目的在于檢驗它是否滿足規(guī)定的需求或是弄清預期結果與實際結果之間的差別”。是否滿足規(guī)定的需求是否有差別第二章軟件測試實質第二章軟件測試實質一般來說，“成功”表示達到了某種目的，而“失敗”則表示令人失望或事不如愿。但在測試中，由于查不出故障的測試浪費了大量的時間和人力，因此使用“成功”這個詞就顯得不夠恰當了。事實證明，發(fā)現(xiàn)故障是一個有價值的工作。發(fā)現(xiàn)故障的測試是成功的測試，發(fā)現(xiàn)故障的測試是成功的測試，而使程序產生正確結果的測試稱為失敗的測試。軟件測試主要涉及5方面的問題：誰來執(zhí)行測試?測試什么?什么時候測試?怎樣進行測試?測試完成的標準是什么?第二章第二章軟件測試實質故障(fault)、失效(failure)、軟件測試的基本概念軟件故障錯誤(error)、缺陷(defect)、隱錯(bug)、過失(mistake)、異常（anomaly），這些術語常用來描述軟件失敗時的現(xiàn)象。測試的復雜性與經濟性測試的充分性問題測試原則停止測試的標準我們采用我們采用IEEE制定的標準術語。錯誤(error人是會犯錯誤的。一個很接近的同義詞是過失（mistake）。過失是人犯下的，是人做的一件錯事或人為產生的一個不正確結果。故障(fault)——故障是錯誤的結果(可能導致失效)。更精確地說，故障是錯誤的表現(xiàn)。與故障很接近的一個同義詞是缺陷(defect)，失效(failure)——故障(例如崩潰)引起的結果(表現(xiàn))。所有的錯誤都是要付出代價的。統(tǒng)計資料表明，在軟件開發(fā)的不同階段進行改動需要付出的代價完全不同。后期改動的代價比前期進行相應修改要高出2~3個數(shù)量級。圖2-4軟件故障的修復費用第二章軟件測試實質第二章軟件測試實質軟件測試的基本概念軟件故障測試的復雜性與經濟性測試的充分性問題測試原則停止測試的標準窮舉測試工作量太大，實際上是行不通的，窮舉測試工作量太大，實際上是行不通的，這就注定了一切實際測試都是不徹底的。因此，軟件測試的一個基本問題是經濟學問題。軟件測試的總目標是充分利用有限的人力和物力資源，高效率、高質量地完成測試。軟件測試的基本概念軟件故障測試的復雜性與經濟性測試的充分性問題測試原則停止測試的標準

不充分的測試是愚蠢的，而過度的測試則是一種罪孽。停止測試的標準？停止測試的標準？軟件測試的基本概念軟件故障測試的復雜性與經濟性測試的充分性問題測試原則停止測試的標準

一些至關重要的測試原則或方針，可以視為軟件測試和軟件開發(fā)的“交通規(guī)則”或者“生活法則”。例如：例如：完全測試程序是不可能的軟件測試是有風險的存在的故障數(shù)量與發(fā)現(xiàn)的故障數(shù)成正比殺蟲劑現(xiàn)象應避免測試自己編寫的程序第三章軟件測試策略第三章軟件測試策略 軟件開發(fā)模型軟件測試過程黑盒測試與白盒測試靜態(tài)測試與動態(tài)測試驗證測試與確認測試軟件開發(fā)模型軟件測試過程黑盒測試與白盒測試靜態(tài)測試與動態(tài)測試驗證測試與確認測試

另一種常用的軟件開發(fā)模型是螺旋模型該模型加入了風險分析在內。瀑布模型多年來廣泛流行，它在支持結構化軟件開發(fā)、控制軟件開發(fā)的復雜性、促進軟件開發(fā)工程化等方面起著顯著作用。軟件開發(fā)模型是軟件開發(fā)過程、活動和任務的結構框架，軟件開發(fā)模型是軟件開發(fā)過程、活動和任務的結構框架，能夠清晰、直觀地表達軟件開發(fā)的全部過程，明確規(guī)定要完成的主要活動和任務，是軟件項目開發(fā)的基礎。 軟件開發(fā)模型軟件測試過程黑盒測試與白盒測試靜態(tài)測試與動態(tài)測試驗證測試與確認測試

軟件開發(fā)是一個自頂向下，逐步細化的過程。軟件測試則是依相反順序的自底向上，逐步集成的過程。低一級的測試為上一級的測試準備條件。軟件測試過程包括:測試資料的收集與整理；熟悉所要測試的軟件；測試方案的制定；測試計劃的編寫；測試實例的設計與編寫；測試準備工作；測試操作；軟件缺陷記錄及報告；修改充實測試實例及測試計劃書；測試自動化程序的編寫；修改、增加測試程序黑盒測試和白盒測試是兩類廣泛使用的軟件測試方法。第三章軟件測試策略黑盒測試和白盒測試是兩類廣泛使用的軟件測試方法。軟件開發(fā)模型軟件測試過程黑盒測試與白盒測試靜態(tài)測試與動態(tài)測試驗證測試與確認測試黑盒測試的基本觀點是黑盒測試的基本觀點是將被測程序看作一個打不開的黑盒，測試人員在完全不考慮程序內部結構和內部特性的情況下，只依靠被測程序輸入和輸出之間的關系，或程序的功能來設計測試用例。白盒測試將被測程序看作一個打開的盒子，白盒測試將被測程序看作一個打開的盒子，測試人員根據(jù)其內部構造設計測試用例。第三章靜態(tài)測試是指不利用計算機運行被測試的程序，通過其它手段達到檢測的目的,軟件開發(fā)模型軟件測試過程黑盒測試與白盒測試靜態(tài)測試與動態(tài)測試驗證測試與確認測試

是對被測程序進行特性分析的一些方法的總稱。動態(tài)測試則是指通常意義上的測試——通過運行和使用被測程序，驗表明，使用靜態(tài)測試可以發(fā)現(xiàn)大約30%驗表明，使用靜態(tài)測試可以發(fā)現(xiàn)大約30%到70%的邏輯設計和編碼錯誤。經第三章軟件測試策略軟件開發(fā)模型軟件測試過程黑盒測試與白盒測試靜態(tài)測試與動態(tài)測試驗證測試與確認測試

確認測試則通過運行代碼來完成,是在開發(fā)過程中或結束時，對系統(tǒng)或部件進行評估以確定其是否滿足需求規(guī)格的過程。驗證測試針對開發(fā)過程中的任何中間產品進行,是為確定驗證測試針對開發(fā)過程中的任何中間產品進行,是為確定某一開發(fā)階段的產品是否滿足在該階段開始時提出的要求而對系統(tǒng)或部件進行評估的過程。驗證驗證就是對諸如需求規(guī)格說明，設計規(guī)格說明和代碼之類的產品進行評估、審查和檢查的過程，屬于靜態(tài)測試。確認是“基于計算機的測試”過程，屬于動態(tài)測試。第四章黑盒測試第四章黑盒測試三個被測程序等價類劃分測試邊界值分析決策表測試其它黑盒測試方法三個被測程序等價類劃分測試邊界值分析決策表測試其它黑盒測試方法在第四章和第五章，我們將采用三個例子來說明各種單元測試方法。這三個例子分別是：在第四章和第五章，我們將采用三個例子來說明各種單元測試方法。這三個例子分別是：一個是三角形問題；一個是邏輯比較復雜的NextDate函數(shù)；一個是有代表性的雇傭金問題。這三個例子合在一起，足可以說明軟件測試人員在單元級別上可能會遇到的大多數(shù)問題。三個被測程序等價類劃分測試邊界值分析決策表測試其它黑盒測試方法等價類劃分把程序的輸入域劃分成若干個互不相交的一組子集，即等價類。等價類由等價關系決定，等價類劃分把程序的輸入域劃分成若干個互不相交的一組子集，即等價類。等價類由等價關系決定，因此等價類中的元素有一些共同的特點：如果用等價類中的一個元素作為測試數(shù)據(jù)進行測試不能發(fā)現(xiàn)程序中的故障，那么使用集合中的其它元素進行測試也不可能發(fā)現(xiàn)錯誤。也就是說，對揭露程序中的故障來說，等價類中的每個元素是等效的。例如，在三角形問題中，如果我們選擇三元組（5，5，5）作為測試用例的輸入，可以判定這是一個等邊三角形的測試用例。在程序測試中能暴露某個程序故障，那么以(6，6，6)或（100，100，100）作為測試數(shù)據(jù)也能發(fā)現(xiàn)這個故障。因此，這些測試用例是冗余的。在考慮等價類時，應注意區(qū)別兩種不同的情況：有效等價類：有效等價類是指對程序規(guī)格說明，是有意義的，合理的輸人數(shù)據(jù)所構成的集合。利用有效等價類，可以檢驗程序是否實現(xiàn)了規(guī)格說明預先規(guī)定的功能和性能。無效等價類：無效等價類是指對程序規(guī)格說明，是不合理或無意義的輸入數(shù)據(jù)所構成的集合。利用無效等價類，可以檢查程序功能和性能的實現(xiàn)是否有不符合規(guī)格說明要求的地方。 在設計測試用例時，應同時考慮有效等價類和無效等價類測試用例的設計。我們希望用最少的測試用例，覆蓋所有的有效等價類。但對每一個無效等價類，設計一個測試用例來覆蓋它。此外，在設計測試用例時，我們應意識到：預期結果也是測試用例的一個必要組成部分，對采用無效輸入的測試也是如此。人們從長期的測試工作經驗得知，大量的故障發(fā)生在輸入或輸出范圍的邊界上，而不是在輸入范圍的內部。第四章黑盒測試人們從長期的測試工作經驗得知，大量的故障發(fā)生在輸入或輸出范圍的邊界上，而不是在輸入范圍的內部。三個被測程序等價類劃分測試邊界值分析決策表測試其它黑盒測試方法我們知道：當滿足a+b>c、a十c>b及b+c>a才能構成三角形。但如果把三個不等式的任何一個大于號“>”錯寫成大于等于號“≥”，那就無法構成三角形了。使用邊界值分析方法設計測試用例，首先應確定邊界情況。使用邊界值分析方法設計測試用例，首先應確定邊界情況。輸入等價類與輸出等價類的邊界，就是應著重測試的邊界情況。通過使所有變量取正常值，只使一個變量分別取最小值、略高于最小值、略低于最大值和最大值，有兩輸入變量的程序F的邊界值析測試用例是：{<Xlnom，X2min>，<Xlnom，X2min+>，<Xlnom，X2nom>，<Xlnom，X2max>，<Xlnom，X2max->，<Xlmin，X2nom>，<Xlmin，X2min+>，<Xlmin，X2max>，<Xlmin，X2max+>}x2dca b x1圖4-5有兩個變量程序的邊界值分析測試用例次邊界條件：有些邊界在軟件內部，用戶幾乎看不到，但是軟件測試仍有必要對這些邊界條件進行檢查。如2的冪次方和ASCII碼就是這樣的兩個例子。例如，假設某種通訊協(xié)議支持256條命令，為了提高數(shù)據(jù)傳輸效率，通訊軟件總是將常用的信息壓縮到一個很小的單元中，必要時再擴展為大一些的單元。比如將常用的15條命令壓縮為一個半字節(jié)數(shù)據(jù)，在遇到第16到256之間的命令時，軟件轉而發(fā)送一個一字節(jié)的命令。用戶只知道可以執(zhí)行256條命令，并不知道軟件根據(jù)半字節(jié)/字節(jié)邊界執(zhí)行了不同的計算和操作。為了覆蓋任何可能的2的冪次方次邊界，還要考慮臨近半字節(jié)邊界14，15和16，以及臨近字節(jié)邊界254，255和256的測試用例。第四章黑盒測試三個被測程序等價類劃分測試邊界值分析決策表測試其它黑盒測試方法

決策表很適合于處理針對不同邏輯條件組合值，分別執(zhí)行不同的操作這類問題。c3:a,b,c構成一個三角形?c2:a=b?c3:a=c?c4:b=c?N－－－Yc3:a,b,c構成一個三角形?c2:a=b?c3:a=c?c4:b=c?N－－－YYYYYYYNYYNYYYNNYNYYYNYNYNNYYNNNa1:非三角形a2:一般三角形a3:等腰三角形a4:等邊三角形a5:不可能XXXXXXXXX條件樁部分列出了問題的所有條件動作樁則給出了問題規(guī)定的可能采取操作為了使用決策表設計測試用例，可以把條件解釋為輸入，把行動解釋為輸出。決策表最突出的優(yōu)點是，為了使用決策表設計測試用例，可以把條件解釋為輸入，把行動解釋為輸出。決策表最突出的優(yōu)點是，它能把復雜的問題按各種可能的情況一一列舉出來，簡明而易于理解，也可避免遺漏。因此利用決策表可以設計出完整的測試用例集合。因果圖方法適合于描述對于多種條件的組合，產生多個相應動作的測試方法，能夠幫助我們按一定步驟，高效率地選擇測試用例，以檢測程序輸入條件的各種組合情況。第四章黑盒測試因果圖方法適合于描述對于多種條件的組合，產生多個相應動作的測試方法，能夠幫助我們按一定步驟，高效率地選擇測試用例，以檢測程序輸入條件的各種組合情況。三個被測程序等價類劃分測試邊界值分析決策表測試其它黑盒測試方法因果圖方法最終生成的是判定表。因果圖方法最終生成的是判定表。分析程序規(guī)格說明的描述中，哪些是原因，哪些是結果。原因常常是輸入條件或是輸入條件的等價類，而結果則是輸出條件。找出原因與結果之間，原因與原因之間的對應關系，并將其表示成連接各個原因與各個結果的“因果圖”。把因果圖轉換成判定表。第四章黑盒測試三個被測程序等價類劃分測試邊界值分析決策表測試其它黑盒測試方法

特殊值測試：測試人員使用其領域知識、使用類似程序的測試經驗等信息開發(fā)測試用例時，常常使用特殊值測試。這種方法不使用測試策略，只根據(jù)“最佳工程判斷”來設計測試用例。因此，特殊值測試特別依賴測試人員的能力。故障猜測法故障猜測法人們靠經驗和直覺猜測程序中可能存在的各種軟件故障，從而有針對性地編寫檢查這些故障的測試用例。第??章白盒測試第??章白盒測試邏輯覆蓋路徑分析數(shù)據(jù)流測試符號測試域測試策略程序變異程序插裝邏輯覆蓋路徑分析數(shù)據(jù)流測試符號測試域測試策略程序變異程序插裝

邏輯覆蓋要求對被測程序的結構作到一定程度的覆蓋。由于覆蓋測試的目標不同，邏輯覆蓋又可分為：語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋及路徑覆蓋。得程每個判斷的每個條件的可能取值至少被執(zhí)一次支來看一段小程序:if(a>0andb!=a)c=b/a;elsec=a;為測試依據(jù),則可建立以下幾個測試實例: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í)行一次，同時每個判斷的所有可能判斷結果也至少被執(zhí)行一次。第??章白盒測試第??章白盒測試邏輯覆蓋路徑分析數(shù)據(jù)流測試符號測試域測試策略程序變異程序插裝

討論路徑數(shù)目的計算方法，分析程序中到底有多少條路徑?有多少條線形獨立路徑數(shù)如果程序中出現(xiàn)了多個判斷和多個循環(huán)，可能的路徑數(shù)目將會急劇增長，以至實現(xiàn)路徑覆蓋不可能的。實際上我們可以做到的只是有選擇地測試程序中某些有代表的性路徑。獨立路徑選擇和路經覆蓋是兩種常用的路經覆蓋方法。獨立路徑是指從程序入口到出口的多次執(zhí)行中，每次至少有一個語句是新的，未被重復的。

限制循環(huán)的次數(shù)。我們只考慮循環(huán)執(zhí)行一次和零次兩種情況，這種簡化循環(huán)意義下的路徑覆蓋為Z路徑覆蓋。 邏輯覆蓋路徑分析數(shù)據(jù)流測試是指關注變量定義點和使用(或引用數(shù)據(jù)流測試是指關注變量定義點和使用(或引用)點的一種結構測試方式，符號測試域測試策略程序變異數(shù)據(jù)流測試是指在不運行被測程序的前提下，對變量的定義、引用進行分析，以檢測數(shù)據(jù)的賦值與引用之間是否出現(xiàn)了不合理的現(xiàn)象，如引用未賦值的變量，對以前未曾引用變量的再次賦值等數(shù)據(jù)流異常現(xiàn)象。數(shù)據(jù)流測試是指在不運行被測程序的前提下，對變量的定義、引用進行分析，以檢測數(shù)據(jù)的賦值與引用之間是否出現(xiàn)了不合理的現(xiàn)象，如引用未賦值的變量，對以前未曾引用變量的再次賦值等數(shù)據(jù)流異常現(xiàn)象。定義／使用測試是一種常用的數(shù)據(jù)流測試方法。定義/使用路徑，記做du-path如果對某個變量vV，存在一個定義、使用結點對，即DEF(v，m)和USE(v，n)，使得變量v在結點m處被定義，在結點n處被使用，則從m到n的結點序列稱為一條定義/使用路徑.定義明確路徑，記做dc-path如果對某個變量vV，存在一個定義、使用結點對，即DEF(v，m)和USE(v，n)，使得變量v在結點m處被定義，在結點n處被使用，并且從m到n的結點序列中沒有其他結點對變量v進行過定義，則從m到n的結點序列稱為一條定義明確路徑.定義定義/使用路徑和定義明確路徑描述了變量從被定義點到被引用點數(shù)據(jù)流向。不是定義明確的定義/使用路徑，很可能是潛在問題的所在。所以我們應特別關注這些定義/使用路徑。第??章白盒測試第??章白盒測試邏輯覆蓋路徑分析數(shù)據(jù)流測試符號測試域測試策略程序變異程序插裝

符號測試的基本思想是允許程序的輸入不僅可以是具體的數(shù)值數(shù)據(jù)，而且還可以包括符號值。符號測試方法在使用中會遇到一些問題，比如在遇到循環(huán)、過程調用、動態(tài)數(shù)據(jù)結構、數(shù)組和指針處理時，符號執(zhí)行實現(xiàn)困難。在執(zhí)行程序過程中以符號計算代替了普通執(zhí)行中的數(shù)值計算，在執(zhí)行程序過程中以符號計算代替了普通執(zhí)行中的數(shù)值計算，所得到的結果自然是符號公式或是符號謂詞。更明確地說，普通測試執(zhí)行的是算術運算，符號測試執(zhí)行則是代數(shù)運算。一次符號測試的結果代表了一大類普通測試的運行結果，實際上是證明了程序接受此類輸入，所得輸出是正確的，還是錯誤的。域測試的“域測試的“域”指的是程序的輸入空間。自然，每個被測程序都有一個輸入空間，而輸入空間又可以分為不同的子空間。子空間的劃分是由程序中分支語句中的謂詞決定的。路徑分析數(shù)據(jù)流測試符號測試域測試策略程序變異域測試策略在分析輸入域的基礎上，域測試策略在分析輸入域的基礎上，對每一子域的每一謂詞邊界，通過選取適當?shù)臏y試點，對謂詞邊界附近的處理進行檢測。邏輯覆蓋路徑分析數(shù)據(jù)流測試符號測試域測試策略程序變異程序插裝

程序變異是一種不同于黑盒測試和白盒測試的測試方法，它屬于錯誤驅動測試，適用于某類特定的程序故障。假設對程序P進行了微小改動而得到程序MP，則MP也是一個程序，稱為P的一個變異體(mutant)。顯而易見，如果程序P是正確的，MP也是一個幾乎正確的程序。如果P不正確，則P的某一個變異體MP可能是正確的。程序變異假定，被測程序由經驗豐富的程序人員編寫，這樣的程序即使不正確，程序變異假定，被測程序由經驗豐富的程序人員編寫，這樣的程序即使不正確，殘留在程序中的錯誤也不是那些重大錯誤，而是一些難以發(fā)現(xiàn)的小錯誤。和正確軟件相比，表現(xiàn)為一個符號或幾個符號的錯誤。程序變異的目標就是查出這些簡單的錯誤及其組合。 邏輯覆蓋路徑分析數(shù)據(jù)流測試符號測試域測試策略程序變異程序插裝程序插裝是一種借助于往被測程序中插入操作來實現(xiàn)測試目的方法，在軟件測試中有著廣泛的應用。第六章集成測試與系統(tǒng)測試第六章集成測試與系統(tǒng)測試 集成測試系統(tǒng)測試集成測試系統(tǒng)測試

一些模塊單獨能夠工作，并不能保證連接起來也能正常工作。程序在某些局部反映不出的問題，在全局上很可能暴露出來，影響功能的發(fā)揮。集成測試是將多個模塊組合在一起進行測試的過程。獨立地測試程序的每個模塊，然后再把它們組合成整個程序的集成測試方法。從主控模塊開始，集成測試

非增式測試增式測試

自頂向下測試自底向上測試

按照軟件的控制層次結構，逐步把各個模塊集成在一起。從最下層的模塊開始，按照程序的層次結構，逐漸形成完整的整體。把下一個待測試的模塊組合到已經測試過的那些模塊上去，再進行測試。從最下層的模塊開始，按照程序的層次結構，逐漸形成完整的整體。系統(tǒng)測試實際上是針對系統(tǒng)中各個組成部分進行的綜合性檢驗，很接近我們日常測試實踐。集成測試系統(tǒng)測試實際上是針對系統(tǒng)中各個組成部分進行的綜合性檢驗，很接近我們日常測試實踐。系統(tǒng)測試系統(tǒng)測試目標不是找出軟件故障，系統(tǒng)測試目標不是找出軟件故障，而是要證明系統(tǒng)的性能。比如，確定程序是否滿足性能需求；確定系統(tǒng)是否滿足可靠性要求等等。系統(tǒng)測試性能測試強度測試安全性測試恢復測試可靠性測試配置測試可用性測試兼容性測試

說明在一定工作負荷和格局分配條件下,響應時間及處理速度等特性檢查系統(tǒng)能力的最高實際限度，即軟件在一些超負荷情況下的運行情況。檢查系統(tǒng)對非法侵入的防范能力，驗證安裝在系統(tǒng)內的保護機構是否確實能夠對系統(tǒng)進行保護?；謴蜏y試的主要目的是檢查系統(tǒng)的容錯能力。檢測系統(tǒng)的平均無故障時間是否超過規(guī)定時限；因故障而停機的時間在一年中應不超過多少時間。配置測試是用各種硬件和軟件平臺以及不同設置檢查軟件操作的過程，以保證測試的軟件可以使用盡量多樣化的硬件組合?？捎眯詼y試檢測用戶使用軟件是否滿意文檔資料測試網(wǎng)站測試

檢測軟件之間能否正確地交互和共享信息，軟件測試不限于僅測試軟件，保證文檔的正確性也是軟件測試的職責。第七章驗證測試和確認測試第七章驗證測試和確認測試驗證的基本方法驗證活動通用代碼審查單確認測試驗證的基本方法驗證活動通用代碼審查單確認測試

驗證是對軟件產品進行人工檢查或評審。驗證的基本方法有：軟件審查、走查、伙伴檢查等。軟件審查以會議的形式進行。軟件審查的目標是：收集數(shù)據(jù)，發(fā)現(xiàn)軟件故障。交流，信息。

走查的目標是：熟悉材料、發(fā)現(xiàn)軟件故障。驗證的基本方法驗證活動通用代碼審查單確認測試

驗證活動是測試生存周期中的一個階段，包括需求驗證、功能設計驗證、詳細設計驗證和代碼驗證。在每一類的驗證活動中，都要考慮以下問題：在每一類的驗證活動中，都要考慮以下問題：使用的驗證方法(審查、走查、伙伴檢查等)產品中要驗證的和不要驗證的范圍沒有驗證的部分所承擔的風險。需要優(yōu)先進行驗證的范圍資源、進度、工具和責任等驗證的基本方法驗證活動通用代碼審查單確認測試審查單是驗證測試的重要工具。審查單是驗證測試的重要工具。在通用代碼審查單的基礎上開發(fā)定制出適合某種目的或項目的審查單。驗證的基本方法驗證活動通用代碼審查單確認測試

確認測試以需求規(guī)格說明中的規(guī)定作為檢驗尺度，在開發(fā)過程中或結束時，對系統(tǒng)或組成部分進行評估。確認測試

低層測試高層測試

單元測試集成測試可用性測試功能測試系統(tǒng)測試 驗收測試 三種確認測試策略：基于需求的測試：基于需求的測試必須采用黑盒測試策略，在不知道內部設計規(guī)格說明或代碼的情況下對用戶需求進行測試?；诠δ艿臏y試：基于功能的測試應該采用黑盒策略?；诠δ艿臏y試常采用等價類劃分、邊界值分析和故障猜測等方法設計測試用例?；趦炔康臏y試：基于內部的測試只能采用白盒測試策略。一但采用白盒測試，便可通過一系列的技術確保系統(tǒng)的內部各部分獲得充分的測試并且達到足夠的邏輯覆蓋。第八章測試計劃與測試文檔第八章測試計劃與測試文檔測試計劃軟件測試文檔主測試計劃驗證測試計劃確認測試計劃測試評估用戶手冊IEEE/ANSI測試文檔概述軟件生存周期各階段的測試任務與可交付的文檔高效率的測試是經過計劃的。成功的測試需要有一定的方法，高效率的測試是經過計劃的。成功的測試需要有一定的方法，包括條例、結構、分析和度量。軟件測試文檔主測試計劃驗證測試計劃確認測試計劃測試評估用戶手冊IEEE/ANSI測試文檔概述軟件生存周期各階段的測試任務與可交付的文檔測試文檔的編制是測試工作規(guī)范化的一個重要組成部分。測試文檔的編制是測試工作規(guī)范化的一個重要組成部分。軟件測試文檔主測試計劃驗證測試計劃確認測試計劃測試評估用戶手冊IEEE/ANSI測試文檔概述軟件生存周期各階段的測試任務與可交付的文檔 包括以下幾個內容：測試計劃：該計劃描述測試活動的范圍、方法、資源和進度，其中規(guī)定了被測試的對象，被測試的特性、應完成的測試任務、人員職責及風險等。測試設計規(guī)格說明：該說明詳細描述測試方法，測試用例以及測試通過的準則等。測試用例規(guī)格說明：該說明描述測試用例涉及的輸入、輸出，對環(huán)境的要求，對測試規(guī)程的要求等。測試步驟規(guī)格說明：該說明規(guī)定了實施測試的具體步驟。測試日志：該日志是測試小組對測試過程所作的記錄。測試事件報告：該報告說明測試中發(fā)生的一些重要事件。測試總結報告：對測試活動所作的總結和結論。第八章測試計劃與測試文檔第八章測試計劃與測試文檔制定主測試計劃的目標是：規(guī)定測試活動的范圍、方法、資源和進度；明確正在測試的項目、要執(zhí)行的主要測試任務、每個任務的負責人，以及與計劃相關的風險。測試計劃制定主測試計劃的目標是：規(guī)定測試活動的范圍、方法、資源和進度；明確正在測試的項目、要執(zhí)行的主要測試任務、每個任務的負責人，以及與計劃相關的風險。軟件測試文檔主測試計劃驗證測試計劃確認測試計劃測試評估用戶手冊IEEE/ANSI測試文檔概述軟件生存周期各階段的測試任務與可交付的文檔 測試計劃軟件測試文檔主測試計劃驗證測試計劃確認測試計劃測試評估用戶手冊

測試評估包括以下幾個方面：測試覆蓋評估軟件故障評估測試有效性評估IEEE/ANSI測試文檔概述軟件生存周期各階段的測試任務與可交付的文檔第九章面向對象的軟件測試第九章面向對象的軟件測試面向對象的概念面向對象的測試與傳統(tǒng)軟件測試的區(qū)別面向對象軟件測試類測試面向對象的集成測試面向對象的概念面向對象的測試與傳統(tǒng)軟件測試的區(qū)別面向對象軟件測試類測試面向對象的集成測試從從測試的角度來考慮對象、消息、接口、類、繼承、動態(tài)綁定等面向對象程序設計的基本概念。例如：操作和方法(或者成員函數(shù))，對于大多數(shù)程序員來說并沒有多大的區(qū)別，然而對于測試人員來說，區(qū)別是顯然的。因為測試一個操作的步驟在某種程度上與測試一個方法的步驟不同，前者是類聲明的一部分同時也是操縱對象的一種手段，后者則是實現(xiàn)某個操作的一些代碼。面向對象的概念面向對象的測試與傳統(tǒng)軟件測試的區(qū)別面向對象軟件測試類測試面向對象的集成測試面向對象軟件特有的繼承、封裝和動態(tài)綁定以及和傳統(tǒng)軟件之間的差異給面向對象的軟件測試提出了一系列新的問題。面向對象軟件特有的繼承、封裝和動態(tài)綁定以及和傳統(tǒng)軟件之間的差異給面向對象的軟件測試提出了一系列新的問題。例如：在傳統(tǒng)的面向過程的程序中，對于函數(shù)y=Function(x);我們只需要考慮函數(shù)Function()的行為特征，而在面向對象的程序中，我們不得不同時考慮基類函數(shù)Base::Function()和繼承類函數(shù)Derived::Function()的行為特征。面向對象的概念面向對象的測試與傳統(tǒng)軟件測試的區(qū)別面向對象軟件測試類測試面向對象的集成測試面向對象的軟件測試主要體現(xiàn)在面向對象單元測試和面向對象集成測試中。面向對象單元測試針對程序內部具體單一的功能模塊進行測試。面向對象的軟件測試主要體現(xiàn)在面向對象單元測試和面向對象集成測試中。面向對象單元測試針對程序內部具體單一的功能模塊進行測試。面向對象集成測試則針對系統(tǒng)內部的相互服務進行測試，如成員函數(shù)間的相互作用，類間的消息傳遞等。面向對象的概念面向對象的測試與傳統(tǒng)軟件測試的區(qū)別面向對象軟件測試類測試面向對象的集成測試

在測試類的功能實現(xiàn)時，應該首先保證類成員函數(shù)的正確性。面向對象編程的固有特性使得對成員函數(shù)的測試，不完全等同于傳統(tǒng)的函數(shù)或過程測試。還需要考慮：１.繼承的成員函數(shù)是否都不需要測試？對父類中已經測試過的成員函數(shù)，兩種情況需要在子類中重新進行測試：繼承的成員函數(shù)在子類中做了改動；成員函數(shù)調用了改動過的成員函數(shù)。2. 對父類的測試能否照搬到子類？第十章軟件測試自動化和測試工具第十章軟件測試自動化和測試工具測試與測試自動化測試工具常用測試工具簡介測試自動化和測試工具的好處測試自動化和測試工具存在的問題測試與測試自動化測試工具常用測試工具簡介測試自動化和測試工具的好處測試自動化和測試工具存在的問題測試自動化希望通過自動化測試工具或其他手段，測試自動化希望通過自動化測試工具或其他手段，按照測試工程師的預定計劃進行自動的測試，目的是減輕手工測試的勞動量，從而達到提高軟件質量的目的。測試自動化的目的在于發(fā)現(xiàn)老的軟件故障，而手工測試的目的在于發(fā)現(xiàn)新故障。測試與測試自動化測試工具常用測試工具簡介測試自動化和測試工具的好處測試自動化和測試工具存在的問題白盒測試工具白盒測試工具黑盒測試工具測試設計和開發(fā)工具測試執(zhí)行和評估工具測試管理工具測試工具的選擇測試與測試自動化測試工具常用測試工具簡介測試自動化和測試工具的好處測試自動化和測試工具存在的問題ParasoftParasoftC++Test測試工具簡介白盒工具--NuMegaDecPartnerStudio黑盒測試工具—QACenter數(shù)據(jù)庫測試工具——TESTBytes和ERwinExaminer測試管理工具——TestDirector測試與測試自動化測試工具常用測試工具簡介測試自動化和測試工具的好處測試自動化和測試工具存在的問題測試自動化和測試工具能夠通過較少的開銷可以獲得更徹底的測試，測試自動化和測試工具能夠通過較少的開銷可以獲得更徹底的測試，提高軟件產品的質量。但使用自動測試時，也會遇到許多問題，因為工具畢竟是工具，在處理一些意外事件時，畢竟不如人靈活。幾個較為典型的靜態(tài)測試工具幾個較為典型的靜態(tài)測試工具QAC

QACProgrammingReseach公司開發(fā)的針對C語言的軟件靜態(tài)分析工具，通過對C語言程序進行分析找出語法使用中存在的問題，例如：危險的用法、過于復雜、不可移植、不易維護或者不符合本部門要求的編程規(guī)范等，它能夠對這些編譯器和其他開發(fā)工具不會察覺的隱藏問題發(fā)出警告。使用QAC可以明顯地減少代碼審查的時間，還可加深程序員對C語言特性的理解。如果在早期的開發(fā)階段就注意到程序所存在的問題，代碼的質量可以得到大幅度的提升，測試周期可以縮短。分析C源程序，報告超過1100種潛在的問題，涉及C語言用法、危險結構、有關維護性和移植性的方面；可以分析許多編譯器中常見的C語言的擴展結構和非標準結構；非常容易配置警告信息和報告；可計算44種業(yè)界接受的度量標準包括CyclomaticComplexity（圈復雜度），靜態(tài)路徑統(tǒng)計數(shù)和Myer’sinterval等，并且可以擴展成為公司特定的度量標準；依據(jù)ISO標準產生報告；可以擴展成為實施本公司特定需要的分析檢查；可進行多種可視化的輸出，包括函數(shù)結構圖、函數(shù)調用樹、外部引用、文件包括關系和軟件度量分析圖等；突出C和C++語言之間的移植性問題；在線HTML幫助連接警告消息，包括替代解決辦法；Windows和UNIX平臺提供易于使用的GUI，并且可以集成到常用開發(fā)環(huán)境（如VC++、Tornado等）。除了QAC外，ProgrammingReseach公司還針對C++語言、Fortran語言等提供了相應的軟件靜態(tài)分析工具QAC++和QAFortran等。McCabeMcCabeIQ是美國McCabe&Association公司的產品，McCabeIQ功能強大，包含McCabeTest、McCabeQA、McCabeReengineering等多種功能組件。美國國防部、美國海軍武器系統(tǒng)和美國通用電子同時對McCabe軟件進行了測試，證明McCabe在軟件的質量度量、預見軟件錯誤和規(guī)劃軟件測試方面對軟件人員會有非常好的幫助。McCabeQA是一個用于軟件質量度量的功能組件。通過它可以計算被測軟件的McCabe復雜度，并通過一個易理解的可視環(huán)境評估整個軟件的質量，明確需要改進質量的區(qū)域。圖形化的顯示使得軟件QA人員和軟件開發(fā)人員有了交流的基礎。McCabeQA產生程序級結構圖（battlemaps）和單元級流程圖。程序級結構圖（battlemaps）中的方盒代表模塊，不同顏色表示不同質量量度。紅色模塊大于用戶定義的度極限，綠色小于度極限，黃色大于基本度極限而小于第二度極限。這些可視顯示可以很容易地幫助用戶發(fā)現(xiàn)問題。用戶還可以利用McCabeQA來追蹤軟件質量的變化過程。用戶在軟件開發(fā)周期中抓拍軟件的特殊點，并且把每個抓拍的點儲存起來，這些信息用來繪出在開發(fā)周期中軟件質量的變化趨勢。管理者可以觀察和追蹤軟件質量的變化過程，監(jiān)督整個系統(tǒng)的復雜性和質量。McCabeReengineering是一個軟件再工程（逆向工程）的功能組件。它支持各種軟件的再工程，包括對已有軟件系統(tǒng)的維護，改變軟件特性或移植到新的平臺或結構中。利用此軟件可以幫助我們識別代碼中的冗余代碼，進行軟件維護和更改時的風險（risk）分析。PolySpacePolySpaceCVerifier是法國PolySpace開發(fā)的一種比較有特色的靜態(tài)測試工具。它利用一種基于抽象解釋的靜態(tài)驗證技術來靜態(tài)地發(fā)現(xiàn)被測軟件運行時的錯誤（run-timeerror）。它是一種非侵入式的和基于源程序代碼的靜態(tài)測試工具，可以無需修改和運行被測試軟件就發(fā)現(xiàn)和檢查出那些在未來的運行中可能出錯的代碼。利用PolySpaceVerifier可以在代碼審查和靜態(tài)測試階段確定被測軟件的運行錯誤，并用不同的顏色將所有可能導致運行錯誤的軟件代碼標出來。PolySpaceVerifier可以自動檢查下面的錯誤：企圖讀未初始化的變量；多線程應用中未保護數(shù)據(jù)的訪問沖突；對空指針和越界指針的引用；對超界數(shù)組的訪問；非法類型轉換（longtoshort,floattointeger）;非法的算術運算（如除零錯誤，負數(shù)開方）；整數(shù)和浮點數(shù)的上溢出/下溢出；不可達代碼。幾個較為典型的動態(tài)測試工具幾個較為典型的動態(tài)測試工具ASMTester ASMTester是一個支持匯編語言軟件的單元測試工具。該工具為軟件開發(fā)和軟件測試人員提供了一個方便、有效的手段，在不需要任何目的機、硬件仿真器或數(shù)據(jù)發(fā)生器的前提下，高效率、低成本地完成對8031/51、8086/88、8096/98、TMSC3x、TMSC6x、1750A等匯編語言軟件的單元測試工作。該工具為用戶進行單元測試提供以下功能：被測模塊和測試用例的管理與維護提供每個被測單元（模塊）動態(tài)測試覆蓋率指標提供每個被測單元動態(tài)測試時的性能指標變量追蹤測試結果的自動比對功能完善的嵌入式硬件環(huán)境模擬機制自動產生單元測試結果記錄單并可打印CantataCantata/Cantata++是英國IPL公司開發(fā)的一個面向源代碼的測試分析工具，可以支持對軟件的靜態(tài)分析和動態(tài)測試。在動態(tài)測試方面，該工具為測試的說明、執(zhí)行、歸檔、重用和重復動態(tài)測試提供一個形式上的框架。它具有以下特點：可以根據(jù)用戶定義的TestCaseDefinition自動生成測試腳本；自動生成樁模塊模擬被測模塊的函數(shù)調用。用戶可以傳遞參數(shù)給樁模塊，并設置樁模塊的返回參數(shù)；通過對測試執(zhí)行過程的監(jiān)視，得到測試覆蓋信息（包括語句、分支、條件、分支/條件、條件組合等不同級別的覆蓋信息）和程序執(zhí)行時間分布情況的信息；Cantata支持C語言，Cantata++支持C++語言。LoadRunnerLoadRunner是美國MercuryInteractive公司開發(fā)的一種預測系統(tǒng)行為和性能的負載測試工具。通過以模擬上千萬用戶，實施并發(fā)負載及實時性能監(jiān)測的方式來確認和查找問題，LoadRunner能夠對整個企業(yè)網(wǎng)絡結構進行測試。通過使用LoadRunner，企業(yè)能最大限度地縮短測試時間，優(yōu)化性能和加速應用系統(tǒng)的發(fā)布周期。CodeTESTCodeTEST是美國AMC公司采用專利插樁技術開發(fā)出的專為嵌入式軟件開發(fā)與測試人員使用的性能分析與測試工具。作為專為嵌入式系統(tǒng)軟件測試而設計的工具套件，CodeTEST廣泛應用于嵌入式軟件的在線動態(tài)測試。CodeTEST采用硬件輔助軟件的系統(tǒng)構架和源代碼插樁技術，用適配器或探針，直接連接到被測試系統(tǒng)，從目標板總線獲取信號，為跟蹤嵌入式應用程序、分析軟件性能、統(tǒng)計軟件的測試覆蓋率以及監(jiān)測內存的動態(tài)分配等提供了一個實時在線的高效率解決方案。TestbedTestbed是英國LDRA公司的產品，其動態(tài)測試功能通過Tbrun模塊實現(xiàn)。Tbrun具有自動生成測試腳本與打樁處理的功能，測試腳本編譯后與被測軟件連接在一起，從而產生一可執(zhí)行程序運行于目標系統(tǒng)或主機系統(tǒng)，并產生測試結果文件。第十一章軟件質量保證第十一章軟件質量保證軟件質量保證軟件測試管理技術測試的組織方式軟件過程成熟度CMM11.4ISO9000軟件質量保證軟件測試管理技術測試的組織方式軟件過程成熟度CMM11.4ISO9000軟件質量保證的主要職責是檢查和評價當前軟件開發(fā)過程，軟件質量保證的主要職責是檢查和評價當前軟件開發(fā)過程，并設法達到防止軟件故障出現(xiàn)的目標。軟件質量保證軟件測試管理技術測試的組織方式軟件過程成熟度CMM11.4ISO9000建立軟件測試管理體系的主要目的是建立軟件測試管理體系的主要目的是確保軟件測試在軟件質量保證中發(fā)揮應有的關鍵作用。軟件質量保證軟件測試管理技術測試的組織方式軟件過程成熟度CMM11.4ISO9000軟件能力成熟度軟件能力成熟度CMM現(xiàn)已成為一個行業(yè)標準模型，用來定義和評價軟件公司開發(fā)過程的成熟度，為提高軟件質量提供指導。軟件質量保證軟件測試管理技術測試的組織方式軟件過程成熟度CMM11.4ISO9000ISOISO9000定義了一套關于質量管理和質量保證的標準，有助于公司一致地交付符合客戶質量要求的產品或服務。軟件質量軟件質量我們先來看軟件質量的定義：反映軟件系統(tǒng)或軟件產品滿足明確或隱含需求的能力有關的特性總和。其含義有四：其一，能滿足給定需要的性質和特性的全體；其二，具有所期望的各種屬性的組合程度；其三，顧客和用戶覺得能滿足其綜合期望的程度；其四，確定軟件在使用中將滿足顧客預期要求的程度。簡言之，軟件質量是軟件一些特性的組合，它依賴軟件的本身。對于軟件質量有多種不同的視面。用戶主要感興趣的是如何使用軟件、軟件性能和使用軟件的效用，特別是在指定的使用環(huán)境（context）下獲得與有效性、生產率、安全性和滿意度有關的規(guī)定目標的能力，即使用質量。開發(fā)者負責生產出滿足質量要求的軟件，所以他們對中間制品和最終產品的質量都感興趣，當然開發(fā)者視面也要體現(xiàn)軟件維護者所需要的質量特性。對于管理者也許更注重總的質量而不是某一特性，必須服從管理準則，如在進度拖延或成本超支與質量提高之間進行權衡，以達到用有限的人力、成本和時間使軟件質量達到優(yōu)化的目的。 保證軟件質量基本上可用兩種途徑來實現(xiàn)，一種是保證生存周期過程，另一種是評價軟件最終產品的質量。這兩種途徑都很重要，且都要求有一系統(tǒng)來管理質量，該系統(tǒng)應確定管理對質量的保證，指明其策略以及恰當?shù)脑敿殘?zhí)行步驟。前者是采用ISO 9001質量體系設計、開發(fā)、生產、安裝和服務的質量保證模式，或者CMM能力成熟度模型，或者ISO 15504軟件過程評估（也稱為SPICE，即軟件過程改進和能力確定）等方法來取得滿足質量要求的軟件。后者是把軟件產品評價看作軟件生存周期的一個過程，目標就是讓軟件產品在指定的使用環(huán)境下具有所需的效用，可以通過測量內部屬性，也可以通過測量外部屬性，或者通過測量使用質量屬性來評價。軟件質量管理目前能被大家接受和公認的是基于軟件生存周期過程的質量管理，包括ISO9001、CMM、ISO15504等都是屬于這種類型，如能力成熟度模型（CMM）較全面地描述和分析軟件機構的軟件過程能力的發(fā)展程度，建立了一個描述軟件機構的軟件過程成熟度的分級標準和框架。軟件過程能力是描述遵循一個軟件過程而得到期望結果的程度，軟件過程成熟度是指一個具體的軟件過程被明確定義、管理、控制其實效的程度。利用能力成熟度模型，軟件機構可以評估自己當前的過程成熟度，并通過提出更嚴格的軟件質量標準和過程改進，來選擇自己的改進策略，以達到更高一級的成熟程度。軟件產品評價需要策劃和管理，從而也是管理職能中的一個部分。軟件質量模型軟件質量模型一個框架，它規(guī)定了內部和外部質量的質量模型與使用質量的質量模型，以及它們在軟件生存周期中的關系。內部和外部質量的質量模型將軟件質量屬性分類為6個特性，即功能性、可靠性、易用性、效率、易維護性和易移植性，并進一步細分為27個子特性，從而構成一個有層次的樹狀結構，結構的最高層由質量特性組成，最低層則由軟件質量屬性組成。使用質量的質量模型將軟件質量屬性分類為4個特性，即有效性、生產率、安全性和滿意度。軟件質量特性軟件質量特性功能性：在指定條件下使用時，軟件產品提供滿足明確和隱含需求功能的能力；可靠性：在指定條件下使用時，軟件產品維持規(guī)定的性能級別的能力；易用性：在指定條件下使用時，軟件產品被理解、學習、使用及其吸引用戶的能力；效率：在規(guī)定條件下，相對于所用資源的數(shù)量，軟件產品可提供適當性能的能力；易維護性：軟件產品可被修改的能力，修改可能包括修正、改進或者適應環(huán)境、需求和功能規(guī)約的變化；易移植性：軟件產品從一種環(huán)境遷移到另一種環(huán)境的能力；有效性：軟件產品在指定使用環(huán)境下，使用戶準確、完整地獲得規(guī)定目標的能力；生產率：軟件產品在指定使用環(huán)境下，使用戶花費合適的與有效性相關的資源數(shù)量的能力；安全性：軟件產品在指定使用環(huán)境下，獲得可接受的損害人類、商務、軟件、財產或環(huán)境風險級別的能力；滿意度：軟件產品在指定使用環(huán)境下，使用戶滿意的能力。軟件質量評價過程軟件質量評價過程３種評價過程：其一：開發(fā)者用的過程，計劃開發(fā)新產品或增強現(xiàn)有產品時為了預測最終產品質量指標；其二，需求方用的過程，計劃獲取或復用某個已有產品時，為了決定接受產品或者從眾多可選產品選擇某個產品；其三，評價者用的過程，應開發(fā)者、需方或其他機構的請求，對產品進行獨立評估，它們通常是第三方機構。不論哪一種評價過程，都是首先要確立評價需求，然后是規(guī)定評價、設計評價和執(zhí)行評價等活動。確立評價需求應確立評價目的，確定產品類型（中間制品、最終產品），規(guī)定質量模型；規(guī)定評價包括選擇度量、建立度量評定等級、確立評估準則；設計評價包括制定評價計劃；執(zhí)行評價包括進行度量、與評估準則相比較，評價結果。早在20世紀60年代末，已經有人討論大型軟件開發(fā)項目的組織管理問題。隨著軟件工程在實踐過程中發(fā)生的問題，人們認識到軟件產品和軟件項目的開發(fā)，不完全取決于軟件開發(fā)方法。與程序的復雜性和系統(tǒng)的復雜性相比，前者已得到較大的緩解，更重要的是后者。如進度推遲、經費超支、質量差、軟件人員不稱職，均與管理有關。自20世紀80年代初，軟件界就關注“軟件過程”。20世紀80年代中期，IBM在WattsS.Humphrey的指導下，RonRadice等人將成熟度框架首次應用于軟件過程，并由Humphrey于1986年將此成熟度框架帶到卡內基·梅隆大學的軟件工程研究所（CMU/SEI）。應美國聯(lián)邦政府要求，為其提供一個評價軟件開發(fā)商能力的方法，1986年11月，CMU/SEI在MITRE公司的幫助下開始設計過程成熟度框架，以此幫助軟件機構改進他們的軟件過程。1987年9月，CMU/SEI發(fā)表了一個簡短的軟件過程成熟度框架。其后在Humphrey的《管理軟件過程》一書中進行擴充。書中提出了軟件過程評估和軟件能力評估，和成熟度問卷，用于評估軟件過程成熟度?；谶@些設想，由JimWithey,MarkPaulk和CynthiaWise在1990年提出了最早的草案。1991年8月MaryBethChrissis和BillCurtis幫助MarkPaulk校訂，推出了CMM（成熟度模型）1.1版。CMU/SEI原先計劃在1997年下半年推出2.0版，1998年推出2.1版。但由于種種原因，未能按計劃推出2.0版。由于美國聯(lián)邦政府的大力推行，CMM模型得到了廣泛應用，CMU/SEI于2001年公布了通過CMM評估的軟件機構共有964家，并對其作了統(tǒng)計分析。目前CMM本身還在向縱深發(fā)展，CMM家族有：軟件能力成熟度模型（SW-CMM）軟件獲取能力成熟度模型（SA-CMM）人員能力成熟度模型（People-CMM）系統(tǒng)工程能力成熟度模型（SE-CMM）集成產品開發(fā)能力成熟度模型（IPD-CMM）個體軟件工程（PSP）群組軟件工程（TSP）另外，國際標準化組織為組織軟件過程評價標準的制訂，成立了“軟件過程改進和能力確定（SoftwareProcessImprovementandCapabilityDetermine,SPICD）”項目，ISO/IECJTCI的SC7分技術委員會于1996年9月正式公布了工作草案，代號為15504，即ISO/IECTR15504InformationTechnology–SoftwareProcessAssessment。CMM的廣泛采納和成功推廣，推動了軟件及其他學科的類似模型的開發(fā)，從而模型繁衍，導致了過程改善目標和技術的沖突。要求的培訓工作有了相當大的增長，部分實踐人員在應用各種不同的模型來實現(xiàn)特定的需要時產生了混淆。針對這種情況，美國聯(lián)邦政府、產業(yè)界和CMU/SEI于1998年啟動了“能力成熟度模型集成（CapabilityMaturityModelIntegration,CMMI）”項目，于2000年第四季度發(fā)布了第一個正式的CMMI，最近的修改是2002年6月10日。CMMI包括了大量的工程改善和過程改善的信息，提供了單一的集成化框架來改善跨越幾個學科的機構的工程過程，從而提高機構過程改善的質量和有效性。相信CMMI將會逐步替代CMM。另外我國也非常重視CMM的研究和應用，目前已經參照CMM1.1版制定國家軍標“軍用軟件成熟度模型”，以及參照CMMI制定行業(yè)標準“ST/T11234軟件過程能力評估模型”和“ST/T11235軟件能力成熟度模型”。軟件質量評價簡介軟件質量評價簡介ISO和IEC（國際電工委員會）是世界性的標準化專門機構。在信息技術領域，ISO和IEC建立一個聯(lián)合的技術委員會，即ISO/IECJTC1。發(fā)布一項國際標準，至少需要有75%的參與表決的國家成員體投票贊成，可見其權威性。一般而言，對軟件的質量進行評價要從模型的生成、計分統(tǒng)計及結果分析，到結果報告生成軟件自動化，要符合軟件質量評價國際標準和國家標準，應較全面地考慮影響軟件質量的諸多因素，如各種軟件質量特性、評價準則和度量、質量加權系數(shù)采用的方法等，能較系統(tǒng)、科學地反映軟件的質量。我國執(zhí)行的《GB/T16260-1996其使用指南》國家標準（等同于ISO/IEC91261991），定義了評價軟件質量的功能性、可靠性、易用性、效率、維護性、可移植性6個特性和在此之下的21個子特性。有關概念 保證軟件產品質量一般可以通過兩種途徑實現(xiàn)，一是保證軟件開發(fā)過程的質量，另外就是評價最終軟件產品的質量，這兩種途徑都非常重要。為了滿足軟件質量要求而進行的軟件產品評價是軟件開發(fā)生存周期中的一個過程。軟件質量可以通過測量內部屬性、外部屬性和使用質量的屬性來評價。目標就是使軟件在指定的使用條件下具有所需的效用內部質量：是基于內部觀點的軟件產品特性的總體。內部質量是針對內部質量需求所被測量和評價的質量。軟件產品質量的細節(jié)可以在代碼實現(xiàn)、評審和測試期間被改進，但是由內部質量表示的軟件產品質量的基本性質不會改變，除非進行重新設計。外部質量：是基于外部觀點的軟件產品特性的總體。即當軟件執(zhí)行時，典型的是使用外部度量在模擬環(huán)境中用模擬數(shù)據(jù)測試時所被測量和評價的質量。在測試期間，大多數(shù)錯誤都應該可以被發(fā)現(xiàn)和消除。然而，在測試后仍會存在一些錯誤。由于難以校正軟件的體系結構或軟件其他的基礎設計，基礎設計在整個測試中通常保持不變。使用質量：軟件產品對指定用戶在特定的使用條件下獲得與有效性、生產率、安全性和滿意度相關的規(guī)定目標的能力。它是基于用戶觀點的用于指定的使用環(huán)境和條件時的質量。它測量用戶在特定環(huán)境中能達到其目標的程度，而不是測量軟件自身的性質。用戶的質量要求包括指定的使用條件下對使用質量的需求。當使用軟件產品質量特性和子特性來說明外部質量和內部質量的時候，可以使用這些被確定的要求。過程質量有助于提高產品質量，而產品質量又有助于提高使用質量。因此，評估和改進一個過程是提高軟件產品質量的一種手段，而評價和改進軟件產品質量則又是提高使用質量的一種手段。同樣，評價使用質量可以為改進產品提供反饋，而評價產品則可以為改進過程提供反饋。合適的軟件內部屬性是獲得所需外部特性的先決條件，而適當?shù)耐獠刻匦詣t是獲得使用質量的先決條件。內部質量、外部質量和使用質量的觀點在軟件生存周期中是變化的。例如，在生存周期開始階段作為質量需求而規(guī)定的質量大多數(shù)是從外部和用戶的角度出發(fā)的，它與像設計質量這樣的中間產品質量不同，后者大多是從內部和開發(fā)者的角度來看問題的。軟件質量保證措施軟件質量保證(SoftwareQualityAssurance，通?？s寫為SQA)的措施主要有，基于非執(zhí)行的測試(也稱為復審)、基于執(zhí)行的測試和程序正確性證明。技術復審的必要性正式技術復審的明顯優(yōu)點是，能夠較早地發(fā)現(xiàn)錯誤，防止錯誤被傳播到軟件過程的后續(xù)階段。正式技術復審實際上是一類復審方法，包括走查(Walk