軟件測試生命周期概述

1、軟件測試生命周期概述軟件測試基礎(chǔ)Software Testing Foundation主要參考書籍：軟件測試基礎(chǔ)教程(德)Andreas Spillner等著，人民郵電出版社 2009軟件測試（美）Ron Patter著，機(jī)械工業(yè)出版社出版2本章主要內(nèi)容軟件開發(fā)與軟件測試1.1 軟件生命周期1.2 軟件開發(fā)模型1.3 軟件測試過程模型單元測試集成測試系統(tǒng)測試驗收測試31.1 軟件生命周期軟件生命周期指從提出軟件產(chǎn)品開始，直到該軟件產(chǎn)品被淘汰的全過程。概括地說，軟件生命周期由軟件定義、軟件開發(fā)和運(yùn)行維護(hù)三個時期組成，每個時期又可進(jìn)一步劃分成若干個階段。問題定義可行性研究需求分析概要設(shè)計詳細(xì)設(shè)計編

2、碼和單元測試綜合測試軟件維護(hù)軟件生命周期的基本任務(wù) 軟件定義時期軟件開發(fā)時期運(yùn)行維護(hù)時期問題定義階段該階段的關(guān)鍵任務(wù)是要明確：要解決的問題是什么？可性行研究階段該階段的關(guān)鍵任務(wù)是要明確：做不做用最小的代價在盡可能短的時間內(nèi)從經(jīng)濟(jì)、技術(shù)、社會因素等方面論證解決方案的可行性需求分析階段該階段的關(guān)鍵任務(wù)是要明確：做什么對目標(biāo)系統(tǒng)提出完整、準(zhǔn)確、清晰、具體的要求用正式的文檔準(zhǔn)確地記錄對目標(biāo)系統(tǒng)的需求，形成軟件需求規(guī)格說明書(SRS)注意點概要設(shè)計(總體設(shè)計)階段該階段的關(guān)鍵任務(wù)是要明確：怎么做定義系統(tǒng)的總體結(jié)構(gòu)及接口之間的關(guān)系完成系統(tǒng)的概要設(shè)計說明書及集成測試計劃 詳細(xì)設(shè)計階段該階段的關(guān)鍵任務(wù)是要明確

3、： 具體做法設(shè)計出程序的詳細(xì)規(guī)格說明，即詳細(xì)地設(shè)計每個模塊，確定實現(xiàn)模塊功能所需要的算法和數(shù)據(jù)結(jié)構(gòu)完成詳細(xì)設(shè)計說明書和單元測試計劃編碼和單元測試階段該階段的關(guān)鍵任務(wù)是編碼和單元測試編寫出正確的、易理解的、易維護(hù)的程序模塊；仔細(xì)測試編寫出的每一個模塊提交通過了單元測試的各功能模塊及單元測試結(jié)果綜合測試階段 該階段的關(guān)鍵任務(wù)是通過各種類型的測試（及調(diào)試）使軟件達(dá)到預(yù)定的要求集成測試：根據(jù)設(shè)計的軟件結(jié)構(gòu)，把經(jīng)過單元測試檢驗的模塊按某種策略裝配起來，在裝配過程中對程序進(jìn)行必要的測試。系統(tǒng)測試：檢驗開發(fā)的系統(tǒng)能否與系統(tǒng)的其它部分協(xié)調(diào)工作。驗收測試：按照規(guī)格說明書的規(guī)定，由用戶對目標(biāo)系統(tǒng)進(jìn)行驗收。將所有測

4、試相關(guān)資料文檔化并納入配置管理軟件維護(hù)階段該階段的關(guān)鍵任務(wù)是通過各種必要的維護(hù)活動使系統(tǒng)持久地滿足用戶的要求。改正性維護(hù)：診斷和改正在使用過程中發(fā)現(xiàn)的軟件錯誤適應(yīng)性維護(hù)：修改軟件以適應(yīng)環(huán)境的變化完善性維護(hù)：根據(jù)用戶的要求改進(jìn)或擴(kuò)充軟件使它更完善預(yù)防性維護(hù)：修改軟件為將來的維護(hù)活動預(yù)先做準(zhǔn)備1. 2 軟件開發(fā)模型軟件測試不是獨立存在的，測試活動和軟件開發(fā)活動密切相關(guān)不同軟件開發(fā)的過程會常用不同的模型了解軟件開發(fā)周期模型是為了更好地將各種不同的軟件測試技術(shù)應(yīng)用與軟件開發(fā)過程中。141.2 軟件開發(fā)周期模型幾種常見的模型：瀑布模式（Waterfall）快速原型模型（Prototype）螺旋模式（Sp

5、iral）迭代-增量模型1516Waterfall ModelDefinitionFeasibility StudyRequirements AnalysisSystem DesignProgram DesignCoding & Module TestingIntegration & System TestingDefinitionDevelopmentDelivery & MaintenanceSupportSystem Lifecycle瀑布模型系統(tǒng)構(gòu)建集中在開發(fā)階段的最后完成，因此，在這段時間，對測試人員的需求量也很大，時間很集中。迭代-增量模型17Incremental Modelca

6、lendar timeanalysisdesigncodetestSystem/informationengineeringincrement 1delivery of1st incrementanalysisdesigncodetestincrement 2delivery of2nd incrementanalysisdesigncodetestanalysisdesigncodetestincrement 3increment 4delivery of3rd incrementdelivery of4th increment特點：每次提交的都是一個滿足用戶需求子集的可運(yùn)行的產(chǎn)品迭代-增量

7、模型特點使用增量模型開發(fā)軟件時，把軟件產(chǎn)品作為一系列的增量構(gòu)件來設(shè)計、編碼、集成和測試。每個構(gòu)件由多個相互作用的模塊構(gòu)成，并且能夠完成特定的功能。使用增量模型時，第一個增量構(gòu)件往往實現(xiàn)軟件的基本需求，提供最核心的功能。18迭代-增量模型中的測試迭代-增量模型的例子有原型法、RAD（快速應(yīng)用開發(fā)）、RUP（Rational統(tǒng)一過程）、敏捷開發(fā)模型等。采用迭代模型開發(fā)的軟件系統(tǒng)需要進(jìn)行不同級別的測試，每個新的增量都是在上一個增量的基礎(chǔ)上添加新的功能，形成一個新的子系統(tǒng)。隨著迭代的增加，回歸測試在增量中的作用就越發(fā)重要，對每個增量都要進(jìn)行驗證和確認(rèn)。19螺旋模型20特點：風(fēng)險驅(qū)動；主要適用于內(nèi)部開發(fā)

8、的大規(guī)模軟件項目。弱點：開發(fā)任務(wù)要有豐富的風(fēng)險評估經(jīng)驗和這方面的專門知識螺旋模型螺旋模型特點軟件開發(fā)幾乎總要冒一定風(fēng)險，因此，在軟件開發(fā)過程中必須及時識別和分析風(fēng)險，并且采取適當(dāng)措施以消除或減少風(fēng)險的危害。螺旋模型的基本思想是，使用原型及其他方法來盡量降低風(fēng)險。理解這種模型的一個簡便方法，是把它看作在每個階段之前都增加了風(fēng)險分析過程的快速原型模型，21增量模型和螺旋模型而言，他們都具備以下特點：系統(tǒng)的構(gòu)建較早，可以較早進(jìn)入測試，隨后的每個增量中對新的功能進(jìn)行測試，并進(jìn)行回歸測試。22快速原型模型23PART ONE The ProcessPrototyping Modellistentocus

9、tomerbuild/revisemock-upcustomertest-drivesmock-up快速原型模型特點快速原型的本質(zhì)是“快速”。開發(fā)人員應(yīng)該盡可能快地建造出原型系統(tǒng)，以加速軟件開發(fā)過程，節(jié)約軟件開發(fā)成本?？焖僭湍Ｐ涂捎糜讷@取用戶的真正需求。對快速原型模型，可了解用戶是如何使用原型的，將使用情況定義為對客戶很重要的場景，然后使用這些場景作為系統(tǒng)測試用例24過程模型的選擇首先，了解每一種過程模型的特點和適用性。其次，根據(jù)軟件項目的特點選擇合適的過程模型。不同的軟件開發(fā)生命周期需要采用不同的方式來測試了解軟件開發(fā)周期模型是為了更好地將各種不同的軟件測試技術(shù)應(yīng)用與軟件開發(fā)過程中。251

10、.3 軟件測試過程模型常用測試過程模型：V模型W模型H模型軟件測試過程軟件開發(fā)是一個自頂向下逐步細(xì)化的過程。軟件測試則是依相反順序的自底向上逐步集成的過程。低一級的測試為上一級的測試準(zhǔn)備條件。27單元測試單元測試單元測試單元測試模塊模塊模塊模塊集成測試已測模塊系統(tǒng)測試驗收測試1.3 軟件測試過程模型 - V模型需求分析概要設(shè)計詳細(xì)設(shè)計編碼單元測試集成測試系統(tǒng)測試根據(jù)詳細(xì)設(shè)計說明書檢驗每個單元模塊是否符合預(yù)期要求根據(jù)概要設(shè)計說明書檢驗各模塊是否正確地集成將系統(tǒng)作為一個整體檢驗在預(yù)定環(huán)境中能否正常有效工作開發(fā)過程測試過程1.3 軟件測試過程模型 - W模型1、形象地說明測試與開發(fā)的并行關(guān)系，體現(xiàn)了

11、測試貫穿整個開發(fā)過程的思想；2、測試的對象不僅僅是程序，還包括需求和設(shè)計階段形成的各種文檔1.3 軟件測試過程模型 - H模型測試就緒點測試準(zhǔn)備測試執(zhí)行測試流程其它開發(fā)流程軟件測試可分為以下四個級別：組件測試集成測試系統(tǒng)測試驗收測試單元測試是軟件開發(fā)過程中最低級別的測試活動，是其它級別測試工作展開的基礎(chǔ)2. 單元測試31單元測試單元測試單元測試單元測試模塊模塊模塊模塊集成測試已測模塊系統(tǒng)測試驗收測試2. 單元測試單元測試也稱作模塊測試、組件測試、程序測試或類測試。單元測試是對單個軟件組件的測試單個軟件組件可以是模塊、單元、程序或函數(shù)，在面向?qū)ο缶幊讨?，也稱作類。單元測試的目的是要檢測程序模塊中

12、有無故障存在322.1 單元測試的任務(wù)（1）模塊接口測試（2）模塊局部數(shù)據(jù)結(jié)構(gòu)測試（3）模塊邊界條件測試（4）覆蓋測試（5）出錯處理檢測33(1) 模塊接口測試 模塊接口測試是單元測試的基礎(chǔ)。只有在數(shù)據(jù)能正確流入、流出模塊的前提下，其他測試才有意義。34測試接口正確與否應(yīng)該考慮下列因素：1 輸入的實際參數(shù)與形式參數(shù)的個數(shù)是否相同；2 輸入的實際參數(shù)與形式參數(shù)的屬性是否匹配；3 輸入的實際參數(shù)與形式參數(shù)的量綱是否一致；4 調(diào)用其他模塊時所給實際參數(shù)的個數(shù)是否與被調(diào)模塊的形參個數(shù)相同；5 調(diào)用其他模塊時所給實際參數(shù)的屬性是否與被調(diào)模塊的形參屬性匹配；6調(diào)用其他模塊時所給實際參數(shù)的量綱是否與被調(diào)模塊

13、的形參量綱一致；7 調(diào)用預(yù)定義函數(shù)時所用參數(shù)的個數(shù)、屬性和次序是否正確；8 是否存在與當(dāng)前入口點無關(guān)的參數(shù)引用；9 是否修改了只讀型參數(shù)；10 對全程變量的定義各模塊是否一致；11是否把某些約束作為參數(shù)傳遞。 35如果模塊內(nèi)包括外部輸入輸出，還應(yīng)該考慮下列因素：文件屬性是否正確；OPEN/CLOSE語句是否正確；格式說明與輸入輸出語句是否匹配；緩沖區(qū)大小與記錄長度是否匹配；文件使用前是否已經(jīng)打開；是否處理了文件尾；是否處理了輸入/輸出錯誤；輸出信息中是否有文字性錯誤；36(2) 模塊局部數(shù)據(jù)結(jié)構(gòu)測試 檢查局部數(shù)據(jù)結(jié)構(gòu)是為了保證臨時存儲在模塊內(nèi)的數(shù)據(jù)在程序執(zhí)行過程中完整、正確。局部數(shù)據(jù)結(jié)構(gòu)往往是

14、錯誤的根源，應(yīng)仔細(xì)設(shè)計測試用例，力求發(fā)現(xiàn)下面幾類錯誤：不合適或不相容的類型說明；變量無初值變量初始化或省缺值有錯不正確的變量名（拼錯或不正確地截斷）出現(xiàn)上溢、下溢和地址異常。除了局部數(shù)據(jù)結(jié)構(gòu)外，如果可能，單元測試時還應(yīng)該查清全局?jǐn)?shù)據(jù)（例如FORTRAN的公用區(qū)）對模塊的影響。37(3)模塊邊界條件測試檢測在數(shù)據(jù)邊界處模塊能否正常工作。模塊邊界測試是單元測試的一個關(guān)鍵任務(wù)，很可能發(fā)現(xiàn)新的軟件缺陷。實踐表明，邊界是特別容易出現(xiàn)故障的地方。例如：處理n維數(shù)組的第n個元素時很容易出錯，循環(huán)執(zhí)行到最后一次時也可能出錯。38(4)覆蓋測試-1檢驗?zāi)K運(yùn)行是否滿足特定的邏輯覆蓋。常見的計算錯誤包括：運(yùn)算的優(yōu)

15、先次序不正確或誤解了運(yùn)算的優(yōu)先次序；運(yùn)算的方式錯誤（運(yùn)算的對象彼此在類型上不相容）；算法錯誤；初始化不正確；運(yùn)算精度不夠；表達(dá)式的符號表示不正確等。 39(4)覆蓋測試-2常見的比較和控制流錯誤有：不同數(shù)據(jù)類型的比較；不正確的邏輯運(yùn)算符或優(yōu)先次序；因浮點運(yùn)算精度問題而造成的兩值比較不等；關(guān)系表達(dá)式中不正確的變量和比較符；“差1錯”，即不正確地多循環(huán)或少循環(huán)一次；錯誤的或不可能的循環(huán)終止條件；當(dāng)遇到發(fā)散的迭代時不能終止循環(huán)；不適當(dāng)?shù)匦薷牧搜h(huán)變量等。 40(5)出錯處理檢測-1比較完善的模塊設(shè)計要求能預(yù)見出錯的條件，并設(shè)置適當(dāng)?shù)某鲥e處理對策，以便在程序出錯時，能對出錯程序重新做安排，保證其邏輯上

16、的正確性。這種出錯處理也是模塊功能的一部分。 41(5)出錯處理檢測-2表明出錯處理模塊有錯誤或缺陷的情況有：出錯的描述難以理解；出錯的描述不足以對錯誤定位和確定出錯的原因；顯示的錯誤與實際的錯誤不符；對錯誤條件的處理不正確；在對錯誤進(jìn)行處理之前，錯誤條件已經(jīng)引起系統(tǒng)的干預(yù)；如果出錯情況不予考慮，那么檢查恢復(fù)正常后模塊可否正常工作。422.2 單元測試的環(huán)境在對每個單元進(jìn)行單元測試時，需要考慮它與周圍模塊的相互關(guān)系。在單元測試時，可使用樁模塊、驅(qū)動模塊。43驅(qū)動模塊與樁模塊驅(qū)動模塊：用以模擬被測模塊的上級模塊，相當(dāng)于被測模塊的主程序。樁模塊：用于模擬被測模塊的下級模塊，相當(dāng)于被測模塊調(diào)用的子模

17、塊。44驅(qū)動模塊樁模塊1#樁模塊1#樁模塊1#樁模塊1#被測模塊測試用例測試結(jié)果驅(qū)動模塊與樁模塊舉例45驅(qū)動模塊樁模塊2.3 組件測試-測試目標(biāo)功能測試非功能測試46單元功能測試單元測試的目標(biāo)是保證具體的測試對象按照規(guī)格說明的要求，完全正確地實現(xiàn)它的所有功能。這里的功能是指測試對象的輸入/輸出行為。為了驗證實現(xiàn)的正確性和完整性，需要用一系列的測試用例來測試組件，每個測試用例覆蓋特定的輸入/輸出組合（部分功能）。47單元功能測試中場發(fā)現(xiàn)的軟件缺陷有：計算錯誤遺漏程序路徑選擇錯誤48組件的非功能測試健壯性測試當(dāng)被錯誤調(diào)用時，模塊應(yīng)能夠通過合理的、健壯的方式處理這種錯誤，而不是中止服務(wù)或引起整個系統(tǒng)

18、崩潰。健壯性測試時，多使用負(fù)面測試用例。這種情況下，組件應(yīng)能進(jìn)行適當(dāng)?shù)漠惓Ｌ幚怼?9健壯性是需要成本的！組件的非功能測試效率測試：效率表明了組件對計算機(jī)資源利用的有效程度。如：內(nèi)存使用、計算時間、磁盤和網(wǎng)絡(luò)的訪問、執(zhí)行組件函數(shù)和算法的時間等。組件測試可以準(zhǔn)確地度量所測試組件的效率，并用準(zhǔn)確的度量標(biāo)準(zhǔn)表達(dá)出來（如內(nèi)存使用率用KB、響應(yīng)時間用微秒等）對組件的效率測試只在有需要時進(jìn)行。50組件的非功能測試可維護(hù)性測試：可維護(hù)性指程序中對修改系統(tǒng)的難易程度或繼續(xù)開發(fā)有影響的所有特性。如：代碼結(jié)構(gòu)、模塊化、代碼注釋的質(zhì)量、標(biāo)準(zhǔn)符合度、可理解性、文檔的最新性等。可維護(hù)性一般通過靜態(tài)測試，特別是評審來進(jìn)行。

19、512.4 單元測試用例的設(shè)計白盒測試要求達(dá)到一定的邏輯覆蓋率黑盒測試要求達(dá)到一定的功能覆蓋率，如需求覆蓋和接口覆蓋52單元測試用例設(shè)計應(yīng)考慮以下方面：正面測試：做了該做的負(fù)面測試：不做不該做的覆蓋率測試：根據(jù)特定的測試覆蓋率目標(biāo)，設(shè)計測試用例，以達(dá)到其覆蓋率要求其他特性測試：在需要的情況下，針對安全、保密、可靠性等需求設(shè)計測試用例測試驅(qū)動開發(fā)(Test Driven Development)測試驅(qū)動是目前在增量開發(fā)中非常流行的單元測試方法，這種方法在編碼前準(zhǔn)備測試用例并對測試用例進(jìn)行自動化，這種方法高度迭代，代碼塊被重復(fù)地測試和改進(jìn)，直到組件通過所有的測試。54本次課后任務(wù)以組為單位，用ja

20、va語言實現(xiàn)84頁的三角形程序代碼Triangle.javaTriMain.java設(shè)計文檔見2. 到JUnit官網(wǎng)下載JUnit最新版本（.zip）三角形程序的測試572.1.5. 使用Junit進(jìn)行單元測試JUnit是一個開發(fā)源代碼的Java測試框架，用于編寫和運(yùn)行可重復(fù)的測試。它是用于單元測試框架體系xUnit的一個實例（用于java語言）。它包括以下特性：1、用于測試期望結(jié)果的斷言（Assertion）2、用于共享共同測試數(shù)據(jù)的測試工具3、用于方便的組織和運(yùn)行測試的測試套件4、圖形和文本的測試運(yùn)行器 58為什么要用JUnit不需要編寫自己的框架。它是開放源代碼，因此不需要購買。 開發(fā)者

21、會使用它，可以找到許多幫助示例。它可以將測試代碼與產(chǎn)品代碼分開。它易于集成到構(gòu)建過程中。59使用-安裝從/網(wǎng)站上下載JUnit的最新版本JUnit4.6.zip，目前是4.6版，2009年4月16日發(fā)布。將JUnit4.6.zip解壓到一個目錄里，例如d:java60使用-在Eclipse中進(jìn)行配置啟動Eclipse；選擇要測試的項目，例SoftwareTest，按鼠標(biāo)右鍵，打開屬性窗口；在屬性窗口中選擇構(gòu)建路徑；按添加外部JAR鍵，在Junit存儲目錄中選擇junit-4.6.jar，按打開鍵；點擊OK，讓Eclipse重建路徑。 61使用-在Eclipse中進(jìn)行配置Move on.62在E

22、clipse中編寫簡單計算器程序public class Calculator public double add(double number1, double number2) return number1 + number2; public double sub(double number1, double number2) return number1 - number2; public double multiply(double number1, double number2) return number1 * number2; public double divide(double

23、 number1, double number2) return number1 / number2; public static void main(String args) Calculator calc = new Calculator();System.out.println(6+2=+calc.add(6, 2);System.out.println(6-2=+calc.sub(6, 2);System.out.println(6*2=+calc.multiply(6, 2);System.out.println(6/2=+calc.divide(6, 2);63對Calculato

24、r類中的方法進(jìn)行測試選中要測試的類，按右鍵選擇建立JUnit Test Case;測試用例的命名：classname+Test，例要測試的類為Calculator，則測試用例命名為CalculatorTest；選擇要測試的方法；64操作步驟：12365JUnit 中最常用的斷言assertEquals( expected, actual)其中，expected 是期望結(jié)果，actual是實際結(jié)果。如何對象都可以被拿來進(jìn)行相等性測試。66當(dāng)對浮點數(shù)進(jìn)行比較時需要指定一個額外的誤差參數(shù)，它表明你需要多接近才能認(rèn)為兩數(shù)相等。例：assertEquals(3.33, 10.0/3.0, 0.01)67

25、對Calculator類中的方法進(jìn)行測試import static org.junit.Assert.*;import org.junit.Test;public class CalculatorTest Testpublic void testAdd() fail(Not yet implemented);缺省生成代碼如下：68對Calculator類中的方法進(jìn)行測試import static org.junit.Assert.*;import org.junit.Test;public class CalculatorTest Test/告訴JUnit以下public void 方法可作為

26、測試用例運(yùn)行public void testAdd() Calculator calc = new Calculator();/實例化計算器 double res = calc.add(5, 8);/將結(jié)果放res/斷言 assertEquals(13,res,0);/用于判斷實際值和期望值是否相同期望結(jié)果實際結(jié)果Double類型時才需要69建議到網(wǎng)上查詢一些有關(guān)JUnit的資料70課上練習(xí)：JUnit單元測試使用JUnit，對Triangle.Java程序中的isTriangle(int a, int b, int c)triType(int a, int b, int c)的兩個方法進(jìn)行單

27、元測試本章主要內(nèi)容軟件開發(fā)與軟件測試1.1 軟件生命周期1.2 軟件開發(fā)模型1.3 軟件測試過程模型單元測試集成測試系統(tǒng)測試驗收測試711998年2月，美國宇航局（NASA）發(fā)射了一枚探測火星氣象的衛(wèi)星，預(yù)定于1999年9月23日抵達(dá)火星。然而研究人員驚訝地發(fā)現(xiàn)，衛(wèi)星沒有進(jìn)入預(yù)定的軌道，卻陷入了火星大氣層，很快就煙消云散了。NASA的官員經(jīng)過緊急調(diào)查，發(fā)現(xiàn)問題居然出在有些資料的計量單位沒有把英制轉(zhuǎn)換成公制，錯誤起自承包工程的洛克希德馬丁航天公司。美國企業(yè)包括太空工業(yè)使用英制，噴射推進(jìn)實驗室（國家實驗室）使用公制，承包商理應(yīng)把英制都轉(zhuǎn)換成公制，以便噴射推進(jìn)實驗室每天兩次啟動小推進(jìn)器，來調(diào)整太空船

28、的航向。導(dǎo)航員認(rèn)定啟動小推進(jìn)器的力是以公制的牛頓為單位。不料，洛克希德馬丁公司提供的資料卻是以英制的磅為單位，結(jié)果導(dǎo)致太空船的航向出現(xiàn)微小偏差。日積月累，終于差之毫厘，失之千里。733. 集成測試需求規(guī)格說明系統(tǒng)功能設(shè)計系統(tǒng)技術(shù)設(shè)計組件規(guī)格說明驗收測試組件測試編程集成測試系統(tǒng)測試驗證和確認(rèn)實現(xiàn)和集成743. 集成測試時常有這種情況發(fā)生，每個模塊都能單獨工作，但將這些模塊組裝起來之后卻不能正常工作。集成測試是通過測試發(fā)現(xiàn)和接口有關(guān)的問題。這里所說的接口包括被集成的模塊之間的接口及與外部系統(tǒng)的接口75集成測試對象集成測試的對象是已經(jīng)經(jīng)過單元測試的模塊76集成測試環(huán)境和組件測試一樣，集成測試也需要驅(qū)

29、動器。組件測試時設(shè)計的驅(qū)動模塊，其中的一部分驅(qū)動模塊在進(jìn)行集成環(huán)境時可以重用。77集成測試目標(biāo)集成測試的目標(biāo)是發(fā)現(xiàn)接口和相互之間協(xié)作的問題以及被集成部分之間的沖突。由于執(zhí)行的是相互連接的程序，所以發(fā)現(xiàn)問題更加困難。這些問題只能通過動態(tài)測試發(fā)現(xiàn)。數(shù)據(jù)交換和組件通信方面會存在這些問題。78發(fā)現(xiàn)的缺陷大概可以分為以下幾類：組件傳送了錯誤的數(shù)據(jù)或沒有傳送數(shù)據(jù)。接受數(shù)據(jù)的組件不能操作或崩潰。通訊正常，但被調(diào)用的組件使用不同的方法來解析收聽到的數(shù)據(jù)。數(shù)據(jù)內(nèi)容傳輸正確，但傳輸?shù)臅r間錯誤或傳輸完了。除了功能測試外，當(dāng)對應(yīng)的特性很重要或風(fēng)險很大時，在集成測試的時候也要進(jìn)行非功能測試，包括性能測試和接口容量測試等

30、。7980試圖通過裁減組件測試的方法來減少工作量的代價是發(fā)現(xiàn)的缺陷更少、問題診斷更困難，最終工作量不僅沒有減少反而會增加。最有效的方法通常是同時進(jìn)行組件測試和隨后的集成測試。81集成測試的策略組件集成的順序及方式影響測試的效率，具體體現(xiàn)就是測試的成本和收益。由于組件完成的時間不同，集成測試可以根據(jù)組件的完成順序來交付。但集成測試計劃應(yīng)努力根據(jù)相應(yīng)的風(fēng)險、系統(tǒng)架構(gòu)等組織組件的交付。集成測試開始的越早，編寫樁的工作量就越大。因此，必須選擇合適的測試策略。選擇集成策略應(yīng)考慮的因素系統(tǒng)結(jié)構(gòu)：決定整個系統(tǒng)包含的組件的數(shù)量和內(nèi)容，以及這些組件相互之間的依賴方式。項目計劃：決定系統(tǒng)中每個部分完成的時間，以及

31、何時可以進(jìn)行測試。測試計劃：決定測試的內(nèi)容、深度以及需要進(jìn)行哪些測試級別的測試。在考慮以上因素后設(shè)計可行的集成策略8283常用的集成測試策略非增量集成增量集成自頂向下自底向上隨意集成中樞集成84集成測試 -非增量型在非增量型（Big Bang ”莽撞/大爆炸”）集成中，將所有部件組合形成程序，然后對此進(jìn)行測試 問題：效率低下，調(diào)試?yán)щy假設(shè)系統(tǒng)的模塊結(jié)構(gòu)如下：ABCDAF增量集成 - 自頂向下測試從系統(tǒng)的頂層模塊開始，這些模塊只調(diào)用其它模塊但是沒有被其它模塊調(diào)用。用樁替代所有的低級別的組件。經(jīng)過測試的高級別組件可以作為測試驅(qū)動器。自頂向下又可分為深度優(yōu)先和廣度優(yōu)先優(yōu)點：不需要測試驅(qū)動器缺點：樁的

32、成本較高87集成測試 -增量型集成（自頂向下、深度優(yōu)先）：88As1s2s3ABs2s3s4ABCs3s4ABCDs4s5ABCDEs5ABCDEF測試A加入B加入C加入D加入E加入F集成測試 -增量型集成（自頂向下、廣度優(yōu)先）：89自頂向下增量式集成測試的步驟主控模塊作為測試驅(qū)動器；根據(jù)集成的方式（深度或廣度），下層的樁模塊一次一次地被替換為真正的模塊；在每個模塊被集成時，都必須進(jìn)行單元測試。重復(fù)第2步，直到整個系統(tǒng)被測試完成。增量集成 - 自底向上測試從不調(diào)用其它組件的底層系統(tǒng)組件開始，除了操作系統(tǒng)的函數(shù)。測試過的組件組成更大的子系統(tǒng)，集成后再進(jìn)行測試。優(yōu)點：不需要樁缺點：必須用測試驅(qū)動器

33、模擬更高級別的模塊91集成測試增量型集成（自底向上）：92自底向上增量式集成測試最下面的模塊先得到測試測試由測試驅(qū)動控制測試過的單元逐步加入測試不需要樁模塊父單元用測試過的子單元測試整個過程重復(fù)到最上面的模塊測試結(jié)束93集成測試兩種增量式集成測試的比較：自底向上：集成完成前程序一直是不完整的自頂向下：早期就顯現(xiàn)出程序的輪廓版本，允許演示，但自頂向下集成的樁很昂貴；增量集成 - 隨意集成按照組件完成的順序進(jìn)行集成優(yōu)點：節(jié)省時間缺點：樁和測試驅(qū)動器都需要增量集成 - 中樞集成向一個主干或中樞上逐步集成組件優(yōu)點：組件可以用任意的順序集成缺點：需要一個經(jīng)過詳細(xì)分析的主干和中樞96集成測試通常需要綜合使

34、用上面提到的各種策略 有效的辦法之一是混合采用自底向上和自頂向下、基于風(fēng)險優(yōu)選模塊集成?；诠δ艿募蓽y試從功能實現(xiàn)的角度出發(fā)，按照模塊功能的重程度組織集成的順序，即先對系統(tǒng)中主要的功能模塊進(jìn)行測試，然后以此類推，直到完成整個系統(tǒng)的集成測試。其主要目的是盡早地檢測系統(tǒng)的關(guān)鍵功能?；诠δ艿募蓽y試 步驟確定功能的重要等級（優(yōu)先級）分析優(yōu)先級最高的功能路徑，將該路徑上所有的模塊集成在一起進(jìn)行測試，必要時設(shè)計相應(yīng)的樁模塊和驅(qū)動模塊增加一個關(guān)鍵功能，重復(fù)步驟2，直至所有模塊都被集成進(jìn)被測系統(tǒng)集成測試用例的設(shè)計集成測試分析集成測試設(shè)計集成測試分析體系結(jié)構(gòu)分析系統(tǒng)實現(xiàn)的層次結(jié)構(gòu)組建之間的依賴關(guān)系模塊分析

35、確定本次要測的模塊找出與模塊關(guān)聯(lián)的所有模塊，并按關(guān)聯(lián)程度對模塊進(jìn)行排序按關(guān)聯(lián)程度，逐漸將這些模塊與該模塊集成并進(jìn)行測試接口分析接口劃分接口分類接口數(shù)據(jù)分析風(fēng)險分析接口劃分產(chǎn)品子系統(tǒng)子系統(tǒng)子系統(tǒng)子系統(tǒng)硬件子系統(tǒng)軟件子系統(tǒng)模塊模塊模塊程序程序程序單元單元系統(tǒng)的邊界、子系統(tǒng)的邊界和模塊的邊界；模塊內(nèi)的接口子系統(tǒng)內(nèi)模塊間的接口子系統(tǒng)間的接口子系統(tǒng)與操作系統(tǒng)間的接口系統(tǒng)與硬件見的接口系統(tǒng)與第三方軟件件的接口接口分類系統(tǒng)內(nèi)接口函數(shù)或方法接口消息接口類接口其它接口系統(tǒng)外接口集成測試設(shè)計為系統(tǒng)運(yùn)行設(shè)計測試用例等價類劃分法、邊界值分析法、決策表為正向測試設(shè)計用例基于輸入域的測試、基于輸出域的測試、等價類為逆向測

36、試設(shè)計用例故障猜測法、邊界值分析、特殊值測試、基于風(fēng)險的測試、基于故障的測試等104集成測試案例Commission類中共有三個方法：caclSale(int l,int s,int b):計算總銷售額caclCommission(int ts):計算傭金調(diào)用結(jié)構(gòu)如圖所示：mainCaclSaleCaclCommission本章主要內(nèi)容軟件開發(fā)與軟件測試1.1 軟件生命周期1.2 軟件開發(fā)模型1.3 軟件測試過程模型單元測試集成測試系統(tǒng)測試驗收測試1051064. 系統(tǒng)測試 系統(tǒng)測試是將已經(jīng)集成好的軟件系統(tǒng)，作為整個基于計算機(jī)系統(tǒng)的一個元素，與計算機(jī)硬件、外設(shè)、某些支持軟件、數(shù)據(jù)和人員等其它系

37、統(tǒng)元素結(jié)合在一起，在實際運(yùn)行（使用環(huán)境）下，對計算機(jī)系統(tǒng)進(jìn)行一系列的組裝測試和確認(rèn)測試。1074. 系統(tǒng)測試系統(tǒng)測試檢查集成后的產(chǎn)品能否滿足需求規(guī)格說明。系統(tǒng)測試屬于黑盒測試。集成測試從技術(shù)角度系統(tǒng)測試從用戶角度許多功能和系統(tǒng)屬性是從系統(tǒng)的所有組件相互協(xié)調(diào)的過程中得到的，因而只能在整個系統(tǒng)級別才能看到。http:/www.bmw.co.uk/bmwuk/homepage/1084.1 測試對象和測試環(huán)境系統(tǒng)測試時將系統(tǒng)看成一個整體進(jìn)行測試。系統(tǒng)測試應(yīng)該在盡可能和目標(biāo)運(yùn)行環(huán)境一致的情況下運(yùn)行。系統(tǒng)測試需要獨立的測試環(huán)境1094.2 測試目標(biāo)系統(tǒng)測試的測試目標(biāo)是確認(rèn)整個系統(tǒng)是否滿足規(guī)格說明中的功能

38、和非功能需求，以及滿足的程度。系統(tǒng)測試應(yīng)該發(fā)現(xiàn)由于需求不正確、不完整或?qū)崿F(xiàn)和需求不一致而引起的失效，并識別沒有文檔化或被遺忘的需求110系統(tǒng)測試由若干個不同的測試類型組成，每一種測試都有一個特定的目標(biāo)。然而，所有的測試都要充分地運(yùn)行系統(tǒng)，驗證系統(tǒng)個部分能否協(xié)調(diào)地工作并完成制定的功能。系統(tǒng)測試可分為以下兩大類：功能測試非功能測試111功能測試功能測試根據(jù)產(chǎn)品的需求規(guī)格說明書和測試需求列表，驗證產(chǎn)品的功能是否符合產(chǎn)品的需求規(guī)格。功能測試主要是為了發(fā)現(xiàn)以下錯誤：是否有不正確或遺漏了的功能？功能實現(xiàn)是否滿足用戶需求和系統(tǒng)設(shè)計的隱含需求？能否正確地接受輸入？能否正確地輸出結(jié)果？112功能測試的步驟：分解

39、并分析功能設(shè)計規(guī)格說明將功能劃分成邏輯組件，對每一組件列出詳細(xì)的功能對每一功能，采用解析的黑盒方法確定輸入和輸出開發(fā)功能測試用例開發(fā)功能覆蓋矩陣執(zhí)行測試用例并度量邏輯覆蓋根據(jù)功能和系統(tǒng)測試的組合邏輯覆蓋的提示，開發(fā)補(bǔ)充功能測試113例1：VSR系統(tǒng)中與價格計算相關(guān)的需求T 102.1選擇一個汽車型號；根據(jù)銷售手冊顯示相應(yīng)的基價；T 102.2選擇一個特殊設(shè)備；添加這個特殊設(shè)備的價格；T 102.3取消對一個特殊設(shè)備的選擇，去除相應(yīng)的價格；T 102.4選擇3個設(shè)備；規(guī)格說明中定義的折扣開始生效；R 100用戶可以從當(dāng)前的型號列表中選擇一個汽車型號R 101對于選擇的型號，顯示可以交付的附加設(shè)備

40、，用戶可以從這個列表中選擇想要的設(shè)備R102選擇的配置總價按照最新的價格列表計算，并實時更新對應(yīng)測試用例114系統(tǒng)測試中測試用例的設(shè)計基于原子系統(tǒng)功能注意體會系統(tǒng)測試用例和單元測試測試用例的區(qū)別。115測試用例框架建立合適的、可擴(kuò)展的測試用例框架，從而借助這個框架能有效地組織眾多的測試用例，包括對測試用例的分類、清晰的層次結(jié)構(gòu)等 116實例117測試用例參考模板1功能描述根據(jù)給定公式計算獎金用例目的測試獎金計算的正確性前提條件輸入大于0的月工作額，例2000編號輸入/動作期望的輸出/相應(yīng)實際情況1輸入司齡值：2獎金為02輸入司齡值：4獎金為50% 2000 = 10003輸入司齡值：7獎金為7

41、5% 2000 = 15004輸入司齡值：10獎金為100% 2000 = 20005輸入司齡值：-3，80，f提示“司齡數(shù)據(jù)必須在0至70之間”118測試用例參考模板2119課上、課后練習(xí)：對QQ中的群共享功能進(jìn)行系統(tǒng)測試，提交測試用例及測試結(jié)果；提交形式：電子文檔最晚提交時間：2011.5.30120非功能測試(1) 性能測試（Performance Testing）(2) 負(fù)載測試（Load Testing）(3) 容量測試（Volume Testing）(4) 壓力測試（Stress Testing）(5) 安全性測試（Security Testing）(6) 可靠性測試（Reliab

42、ility Testing）121(7) 健壯性測試（Robustness Testing）(8) 兼容性測試（Compatibility Testing）(9) 配置測試（Configuration Testing）(10) 可用性測試（Usability Testing）(11) 文檔測試（Documentation Testing）(12) 回歸測試（Regression Testing）122(1)性能測試（Performance Testing）測量特定用例的處理速度和響應(yīng)時間，通常依賴于不斷增加的負(fù)荷。性能測試應(yīng)關(guān)注的指標(biāo)用戶數(shù)：在線用戶數(shù)，并發(fā)用戶數(shù)；響應(yīng)時間：一定用戶并發(fā)下，請

43、求的響應(yīng)時間；處理能力：單位時間內(nèi)，系統(tǒng)對某一業(yè)務(wù)的峰值處理速度。123(2)負(fù)載測試（Load Testing）負(fù)載測試是一種性能測試，指數(shù)據(jù)在超負(fù)荷環(huán)境中運(yùn)行，程序是否能夠承擔(dān)。 可通過增加系統(tǒng)負(fù)載來測量系統(tǒng)的行為（如并發(fā)用戶數(shù)、事務(wù)數(shù)）124(3)容量測試（Volume Testing）確定系統(tǒng)可處理同時在線的最大用戶數(shù) 容量測試，通常和數(shù)據(jù)庫有關(guān)。容量和負(fù)載的區(qū)別在于：容量關(guān)注的是大容量，而不需要表現(xiàn)實際的使用。 125(4)壓力測試（Stress Testing）在系統(tǒng)資源特別低的情況下軟件系統(tǒng)運(yùn)行情況，目的是找到系統(tǒng)在哪里失效以及如何失效的地方。包括：Spike testing：短

44、時間的極端負(fù)載測試 Extreme testing：在過量用戶下的負(fù)載測試 Hammer testing：連續(xù)執(zhí)行所有能做的操作 126容量測試、負(fù)載測試、強(qiáng)度測試容量測試、負(fù)載測試、強(qiáng)度測試的英文解釋為： Volume Testing = Large amounts of data Load Testing = Large amount of users Stress Testing = Too many users, too much data, too little time and too little room 127性能測試、負(fù)載測試和強(qiáng)度測試比較混淆。負(fù)載測試和強(qiáng)度測試，都屬于性

45、能測試的子集。下面舉個跑步的例子進(jìn)行解釋。 性能測試，表示在一個給定的基準(zhǔn)下，能執(zhí)行的最好情況。例如，在沒有負(fù)重的情況下，你跑100米需要花多少時間（這邊，沒有負(fù)重是基準(zhǔn)）？ 負(fù)載測試，也是性能測試，但是他是在不同的負(fù)載下的。對于剛才那個例子，如果擴(kuò)展為：在50公斤、100公斤等情況下，你跑100米需要花多少時間？ 強(qiáng)度測試，是在強(qiáng)度情況下的性能測試。對于剛才那個例子，如果改為：在一陣強(qiáng)風(fēng)的情況下，你在負(fù)重或沒有負(fù)重的情況下，跑100米需要花多少時間？ 128(5)安全性測試（Security Testing）驗證系統(tǒng)的保護(hù)機(jī)制能否在實際中保護(hù)系統(tǒng)不受到非法的侵入由這種測試處理的安全問題是：范

46、圍控制數(shù)據(jù)庫和數(shù)據(jù)文件的備份以及在系統(tǒng)失效時的恢復(fù)記錄事務(wù)、系統(tǒng)使用、訪問嘗試等等的日志129(6)可靠性測試（Reliability Testing）在長時間運(yùn)行中測試（如失效的平均時間或指定用戶配置的失效率）在有使用代表性的環(huán)境中，為進(jìn)行軟件可靠性估計對該軟件進(jìn)行的功能測試。需要說明的是，使用代表性指的是在統(tǒng)計意義下該環(huán)境能反映出軟件的使用環(huán)境特性。 130(6)可靠性測試可靠性測試也是特別困難，因為它需要在常規(guī)工作負(fù)載條件下進(jìn)行軟件應(yīng)用的全方位運(yùn)行。實際上，這種任務(wù)只應(yīng)在計算機(jī)化模擬已經(jīng)運(yùn)行過、得到平均值之后進(jìn)行，并且只能在系統(tǒng)完成之后進(jìn)行。同時，所需資源巨大?？赏ㄟ^統(tǒng)計模型進(jìn)行，關(guān)鍵是

47、統(tǒng)計模型所代表的現(xiàn)實生活軟件系統(tǒng)的程度。131(7)健壯性測試（Robustness Testing）測量系統(tǒng)對于錯誤操作、錯誤編程、硬件故障的響應(yīng)，以及檢查系統(tǒng)異常處理和恢復(fù)的能力。132(8)兼容性測試（Compatibility Testing）兼容性測試(Software Compatibility Testing)指檢查軟件之間能否正確地交互和共享信息。一般而言，軟件的兼容性包括平臺的兼容性和數(shù)據(jù)的兼容性兩個方面 。兼容性測試的目標(biāo)就是要保證軟件按用戶期望的方式工作133軟件兼容的例子從Web頁面上剪切文字，然后在Word或其它文字處理軟件中粘貼。從電子報表程序保存帳目數(shù)據(jù)，在另一個

48、完全不同的電子表格程序中讀入；使照片修飾軟件在同一操作系統(tǒng)的不同版本正常工作；升級到新的數(shù)據(jù)庫程序，讀入現(xiàn)存所有數(shù)據(jù)庫，像老程序一樣對其進(jìn)行處理。134各種軟件應(yīng)用程序之間的兼容性135如果受命對新軟件進(jìn)行兼容性測試，就需要回答以下問題：軟件設(shè)計要求與哪些平臺（操作系統(tǒng)、Web瀏覽器或者操作環(huán)境）和應(yīng)用軟件保持兼容？如果要測試的軟件是一個平臺，那么設(shè)計要求什么應(yīng)用程序在其上運(yùn)行？應(yīng)該定義何種定義軟件之間交互的標(biāo)準(zhǔn)或者規(guī)范？軟件使用哪些數(shù)據(jù)與其它平臺和軟件交互和共享信息？136注意：在開始兼容性測試任務(wù)之前，需要對所有的可能的軟件組合等級劃分，使其成為驗證軟件之間正確交互的最小有效集合。 簡言之

49、，由于不可能在一個操作系統(tǒng)上全部測試數(shù)千個軟件程序，因此，需要決定測試哪些是最重要的。關(guān)鍵詞是“重要”。137(9)配置測試（Configuration Testing）確定按需求配置軟件或硬件時是否運(yùn)行正常。例如：操作系統(tǒng)的不同版本、用戶接口語言、硬件平臺等等。138(10)可用性測試 可用性測試是為了檢查客戶學(xué)習(xí)系統(tǒng)的容易性、操作的容易性和效率、系統(tǒng)輸出的可理解性等。 目的是讓軟件適合于用戶的實際工作風(fēng)格而不是強(qiáng)迫用戶的工作風(fēng)格適應(yīng)139可用性測試可用性測試應(yīng)當(dāng)在開發(fā)期間盡可能早地進(jìn)行并應(yīng)用到系統(tǒng)中去。在生存周期內(nèi)應(yīng)設(shè)法進(jìn)行兩到三次可用性測試。140(11)文檔測試（Documentati

50、on Testing）檢查文檔和系統(tǒng)行為是否一致。文檔測試同代碼測試或設(shè)計文檔審查一樣重要。一份錯誤的用戶手冊或程序員手冊可以導(dǎo)致程序運(yùn)行和維護(hù)期間的錯誤，這些錯誤可以帶來同軟件bug引起的同樣嚴(yán)重的破壞。141文檔測試文檔測試計劃應(yīng)包括以下三個部分：文檔完備性檢查：基于需求規(guī)格說明書和詳細(xì)的設(shè)計報告進(jìn)行，主要檢查所需的所有文檔是否已按規(guī)定和設(shè)計者的要求完成文檔正確性檢查：檢查文檔中所列的指導(dǎo)是否正確文檔編輯和風(fēng)格審查：檢查文檔的清晰性和與標(biāo)準(zhǔn)的一致性142軟件文檔的類型軟件測試人員通常不限于僅測試軟件，而要負(fù)責(zé)組成整個軟件產(chǎn)品的各個部分，保證文檔的正確性。143軟件文檔的類型包裝文字和圖形市

51、場宣傳材料、廣告以及其它插頁授權(quán)、注冊登記表標(biāo)簽和不干膠條安裝和設(shè)置指導(dǎo)用戶手冊聯(lián)機(jī)幫助指南、向?qū)永?、示例和模板錯誤提示信息144文檔測試的重要性軟件文檔是軟件的一部分，文檔的錯誤也是軟件缺陷。錯誤的解釋可能會導(dǎo)致用戶無法使用某些軟件已具有的功能。如安裝文檔不正確，用戶無法自行完成安裝，自然是嚴(yán)重的軟件缺陷。145好的文檔能提高易用性和可靠性，降低技術(shù)支持的費用，從而提高軟件的整體質(zhì)量。非代碼文檔的測試主要檢查文檔的正確性、完備性和可理解性。軟件驅(qū)動的文檔還得像程序一樣運(yùn)行起來實施測試。146正確性、完備性和可理解性正確性是指不要把軟件的功能和操作寫錯，也不允許文檔的內(nèi)容前后矛盾。完備性是指

52、文檔不可以“虎頭蛇尾”，更不許漏掉關(guān)鍵內(nèi)容。文檔中很多內(nèi)容對于開發(fā)者是“顯然”的，但對用戶而言不見得都是“顯然”的文檔要讓大眾用戶看得懂，能理解。文檔中的術(shù)語、縮寫詞，用戶能否理解？內(nèi)容和主題是否一致？147審查文檔時要找什么很多程序員能編寫出好程序，卻寫不出清晰的文檔。因此，測試人員應(yīng)與文檔作者密切配合，嚴(yán)格按照每個步驟進(jìn)行操作，檢查每個操作界面，嘗試每個示例。如果文檔是軟件驅(qū)動的，就要像軟件其余部分一樣進(jìn)行進(jìn)行測試。檢查索引表是否完整，搜索結(jié)果如果正確。超級鏈接和熱點是否跳轉(zhuǎn)到正確的頁面。利用等級劃分技術(shù)確定嘗試哪些測試用例。148文檔測試檢查清單通用部分聽眾術(shù)語內(nèi)容和主題正確性緊扣事實逐

53、步執(zhí)行檢查的內(nèi)容圖標(biāo)和屏幕抓圖樣例和示例拼寫和語法149課上練習(xí)畫板程序，找出應(yīng)該測試的文檔例子150(12)可維護(hù)性測試評估系統(tǒng)文檔的可維護(hù)性以及是否是最新的。非常重要，主要同以下問題有關(guān)：忠實遵守標(biāo)準(zhǔn)和開發(fā)規(guī)范的系統(tǒng)結(jié)構(gòu)手冊完整并符合標(biāo)準(zhǔn)內(nèi)部文檔符合編碼規(guī)范151(13)回歸測試因為經(jīng)常使用的軟件產(chǎn)品必須不斷更新，而產(chǎn)品的每一個版本都必須再測試。微軟的一位項目經(jīng)理在介紹微軟如何保證產(chǎn)品質(zhì)量時說：“微軟質(zhì)量保證的秘密就是：測試測試再測試！ 152(13)回歸測試（Regression Testing）回歸測試指在程序被修改后重新測試的過程，以保證這個修改沒有引入或暴露故障?？梢詾槊恳换顒舆M(jìn)行回歸測試（如：單元測試、可用性測試、功能測試、系統(tǒng)測試等）153回歸測試 回歸測試在軟件生命周期中扮演著重要的角色，因忽視回歸測試而造成嚴(yán)重后果的例子不計其數(shù)，導(dǎo)致阿里亞娜5型火箭發(fā)射失敗的軟件缺陷就是由于復(fù)用的代碼沒有經(jīng)過充分的回歸測試造成的。 154回歸測試回歸測試中使用的測試用例會多次運(yùn)行，因而必須很好地進(jìn)行文檔化，并使之具有可重用性。因此，它們通常是測試自動化的對象。155回歸測試在進(jìn)行回歸測試的時候，必須決定回歸測試的范圍。