軟件工程要點串講

軟件工程要點串講（SUMMARY)第一講概述1.1軟件工程的研究內(nèi)容軟件工程要考慮專業(yè)軟件開發(fā)所需要的理論、方法和工具----工程技術(shù)問題軟件工程要考慮如何有效的在軟件開發(fā)中利用有限的成本資源----工程管理的問題1.2什么是軟件?軟件包括：---軟件的內(nèi)涵①能夠提供客戶所需功能與性能的計算機程序；②使程序能夠適當?shù)牟僮餍畔⒌臄?shù)據(jù)結(jié)構(gòu)；③用以描述程序開發(fā)過程及使用的文檔。軟件產(chǎn)品可以為一個特定的用戶設(shè)計開發(fā)，也可以為某一類通用的市場設(shè)計開發(fā)。軟件產(chǎn)品可以分成：通用軟件（GenericSoftware）定制軟件（BespokeSoftware）一個新的軟件并不一定是全新開發(fā)，可以由現(xiàn)有軟件或可復(fù)用軟件成分配置形成。1.2什么是軟件?模糊1.3什么是軟件工程？軟件工程是涉及軟件生產(chǎn)各個方面的一門工程學(xué)科軟件工程涉及軟件生命周期的各個方面，從軟件需求的確定到軟件退役。軟件工程：（1）將系統(tǒng)化的、規(guī)范的、可度量的方法應(yīng)用于軟件的開發(fā)、運行和維護的過程，即將工程化應(yīng)用于軟件；（2）研究（1）中的方法.——IEEE[IEE93]1.3

什么是軟件工程？1.4什么是成功的軟件項目一個成功軟件項目的三個要素包括：按時交付不超預(yù)算滿足用戶要求。1.5軟件過程與軟件生命周期

的相關(guān)概念軟件過程是指開發(fā)或制作軟件產(chǎn)品的一系列活動及其成果.所有的軟件過程中都包括四個基本活動:1.描述（Specification）-系統(tǒng)應(yīng)該提供的功能及其開發(fā)約束；2.開發(fā)（Development）-軟件產(chǎn)品的生產(chǎn)過程；3.有效性驗證（Validation）-檢驗軟件產(chǎn)品是否滿足了客戶的需要；4.進化（Evolution）-按照用戶的變更要求不斷的改進軟件。軟件生命周期是軟件過程的另一種形象描述，通常包括需求定義、分析與描述、軟件設(shè)計、實現(xiàn)、測試、維護與退役等活動。1.6什么是優(yōu)良軟件的屬性？優(yōu)良的軟件應(yīng)能交付相應(yīng)的功能與性能，而且應(yīng)具有良好的可維護性、可依賴性、有效性和可用性：可維護性（Maintainability）Softwaremustevolvetomeetchangingneeds;可依賴性（Dependability）Softwaremustbetrustworthy;有效性（Efficiency）Softwareshouldnotmakewastefuluseofsystemresources;可接受性（Acceptability）Softwaremustbeacceptedbytheusersforwhichitwasdesigned.Thismeansitmustbeunderstandable,usableandcompatiblewithothersystems.第二講軟件過程2.1瀑布模型（順序模型）2.1瀑布模型（順序模型）A.k.a.:ClassicLifeCycle瀑布模型的缺點和適用情況這種模型生硬的把一個軟件過程劃分成幾個界限清晰的階段，而且這些階段前后有嚴格的順序，這導(dǎo)致它很難對用戶的需求變更做出及時的調(diào)整；因此，瀑布模型只適合需求非常清楚和需求變更被嚴格限制的情況下。

2.2進化式開發(fā)模型基本思想：通過開發(fā)系統(tǒng)原型和用戶反復(fù)交互，以明確需求，使系統(tǒng)在不斷調(diào)整與修改中得以進化成熟。又叫做原型式開發(fā)方法。兩種基本類型：

探索式開發(fā);

拋棄式原型法.問題缺乏過程可見性;系統(tǒng)結(jié)構(gòu)通常會很差;需要一些特別的技術(shù)（如原型快速開發(fā)技術(shù)），通常與主流技術(shù)不兼容.適用情況適合中小規(guī)模的交互系統(tǒng);可用于大型系統(tǒng)的局部開發(fā)（如系統(tǒng)界面），可以和瀑布模型混合使用；生命周期較短的系統(tǒng)。2.2進化式開發(fā)模型2.3增量式開發(fā)增量式開發(fā)的特點在這種開發(fā)方式中，系統(tǒng)不是作為一個整體交付，而是被分解成若干個增量，每個增量交付系統(tǒng)的部分功能。用戶的需求按優(yōu)先級排隊，優(yōu)先級最高的需求被放入最早交付的增量中。這樣，優(yōu)先級最高的系統(tǒng)功能就得到最多的測試，系統(tǒng)的可靠性較高。

第三講需求工程3.1需求工程過程需求工程過程并不具有唯一的模型，在所有的過程中都會涉及一些共同的活動，它們是：可行性研究；需求導(dǎo)出與分析；需求描述；需求有效性驗證;需求管理。3.2可行性研究可行性研究要決定被提議的系統(tǒng)是否值得去做。進行可行性研究包括信息評估、信息匯總和書寫報告三部分工作。3.3需求的兩個不同層次的描述用戶需求從客戶的角度，采用自然語言配合以圖表對目標系統(tǒng)應(yīng)提供的服務(wù)以及系統(tǒng)操作要受到的約束進行的聲明。系統(tǒng)需求系統(tǒng)需求是一種結(jié)構(gòu)化文檔，要運用一些專業(yè)的模型詳細的描述系統(tǒng)的功能及其約束。系統(tǒng)需求文檔有時也稱為功能描述，應(yīng)該是精確的，它可以成為雙方之間合同的重要內(nèi)容，同時作為開發(fā)工作的依據(jù)。3.4功能需求與非功能需求功能需求對系統(tǒng)應(yīng)提供的功能，系統(tǒng)在特定的輸入下做出的反應(yīng)及特定條件下的行為的描述。某些情況下還要包括系統(tǒng)不應(yīng)做什么。非功能需求對系統(tǒng)提供服務(wù)或功能時收到的約束進行描述。如時間約束、開發(fā)過程約束和標準等。領(lǐng)域需求這種需求來自于系統(tǒng)的應(yīng)用領(lǐng)域，反映領(lǐng)域特征。可能是功能需求也可能是非功能需求。3.4功能需求與非功能需求功能性需求與非功能性需求相比較，非功能需求往往更為關(guān)鍵，因為非功能需求表示的是系統(tǒng)的整體特征，而功能性需求描述的則是局部功能。（參看課本例子加強理解）3.7需求導(dǎo)出與分析這個階段在可行性研究之后進行，通常與需求描述交叉進行。需求導(dǎo)出的過程活動包括：需求發(fā)現(xiàn)、需求的分類與組織、優(yōu)先排序和沖突解決、需求文檔化。3.7需求導(dǎo)出與分析需求的發(fā)現(xiàn)與識別是整個過程中最為關(guān)鍵的活動，負責(zé)收集目標系統(tǒng)級現(xiàn)存系統(tǒng)的相關(guān)信息并從這些信息中提煉出用戶需求和系統(tǒng)需求。信息的來源包括已有的文件，系統(tǒng)的信息持有者（stakeholders）以及相近系統(tǒng)的規(guī)約描述。3.8結(jié)構(gòu)化分析（SA）建模結(jié)構(gòu)化分析方法是一種面向數(shù)據(jù)流的系統(tǒng)建模技術(shù)，它從數(shù)據(jù)加工的角度對系統(tǒng)進行規(guī)格描述；SA幫助分析者理解系統(tǒng)的功能，并采用模型與用戶進行交流；不同的模型從不同的角度對系統(tǒng)進行描述。結(jié)構(gòu)化分析建模結(jié)構(gòu)化分析方法建立的分析模型結(jié)構(gòu)如下圖：實體—關(guān)系圖

數(shù)據(jù)詞典狀態(tài)—遷移圖數(shù)據(jù)流圖數(shù)據(jù)對象描述控制規(guī)格說明加工規(guī)格說明結(jié)構(gòu)化分析模型的核心是數(shù)據(jù)詞典，它描述了所有的在目標系統(tǒng)中使用的和生成的數(shù)據(jù)對象。圍繞著這個核心的有三種圖：實體—關(guān)系圖(ERD)描述數(shù)據(jù)對象及數(shù)據(jù)對象之間的關(guān)系；數(shù)據(jù)流圖(DFD)描述數(shù)據(jù)在系統(tǒng)中如何被傳送或變換，以及描述如何對數(shù)據(jù)流進行變換的功能（子功能）；狀態(tài)—遷移圖(STD)描述系統(tǒng)對外部事件如何響應(yīng)，如何動作。因此，ERD用于數(shù)據(jù)建模，DFD用于功能建模，STD用于行為建模。

結(jié)構(gòu)化分析建模3.9

UML與面向?qū)ο蠓治龇椒ǚ先祟愖匀凰季S方式，易于理解、描述和實現(xiàn)。對需求變化有較好的適應(yīng)性：封裝機制和消息傳遞機制將需求變化影響限制在對象內(nèi)部。支持軟件復(fù)用：封裝性有助于實現(xiàn)復(fù)用；繼承、實例化實現(xiàn)了對象復(fù)用；類庫提供了大量公共代碼?？删S護性好：封裝性和消息傳遞造成低耦合，錯誤定位和修改容易；繼承與多態(tài)使得功能的擴展更加容易。開發(fā)過程銜接緊密：在軟件生命周期各階段可以使用同樣的模型描述。3.9.1面向?qū)ο蠓椒ㄅc結(jié)構(gòu)化方法相比較有以下優(yōu)勢：3.9.2理解UML

UML是一種標準的圖形化建模語言，它為不同領(lǐng)域的人們提供一種統(tǒng)一的交流標準，這種標準使得系統(tǒng)構(gòu)造者能夠用標準的、易于理解的方式建立能表達出他們想象力的系統(tǒng)藍圖，并使客戶、分析員、設(shè)計人員、程序員和系統(tǒng)其它涉及者能夠相互理解和達成一致，從而能夠有效地共享和交流設(shè)計結(jié)果。3.9.3需求導(dǎo)出工作流程訪談業(yè)務(wù)所屬人獲取高層的功能性需求

訪談項目干系人獲得所有的功能性和非功能性需求

通過SRS文檔確定項目約束和風(fēng)險

通過SRS文檔中的功能性需求創(chuàng)建項目詞典

通過SRS文檔創(chuàng)建初始用例圖

業(yè)務(wù)所屬者腦海中的模型項目干系人腦海中的模型愿景文檔SRS需求分析工作流程分析用例場景發(fā)現(xiàn)更多細節(jié)在分析的基礎(chǔ)上精化用例圖用活動圖驗證用例用CRC分析法確定關(guān)鍵抽象表述域模型中關(guān)鍵抽象之間的關(guān)系使用從用例場景中得到的對象圖來驗證域模型SRSUseCaseformCRC要求掌握：1）用例圖的畫法；2）用例表（用例規(guī)約描述）的基本結(jié)構(gòu)及描述方法；3）活動圖的畫法4）用CRC確定關(guān)鍵抽象的過程；5）用類模型表示關(guān)鍵抽象。3.10需求有效性驗證需求有效性驗證的目的是檢驗需求描述是否正確地反映了客戶的意愿。好的需求對軟件系統(tǒng)的開發(fā)效率及軟件質(zhì)量起著至關(guān)重要的作用。一個錯誤發(fā)現(xiàn)的越晚，修改它所付出的代價就越大。Fixingarequirementserrorafterdeliverymaycostupto100timesthecostoffixinganimplementationerror.階段需求分析軟件設(shè)計程序編碼單元測試驗收測試維護相對修復(fù)代價0.10.20.512520需求檢查

對需求文檔中定義的需求要進行多種檢查，這些檢查包括：有效性，

Doesthesystemprovidethefunctionswhichbestsupportthecustomer’sneeds?一致性，

Arethereanyrequirementsconflicts?完備性，

Areallfunctionsrequiredbythecustomerincluded?現(xiàn)實性，

Cantherequirementsbeimplementedgivenavailablebudgetandtechnology?可檢查性，

Cantherequirementsbechecked?第四講設(shè)計工程

4.1軟件工程中的設(shè)計設(shè)計是一個把問題轉(zhuǎn)換成解決方案的創(chuàng)造性過程；設(shè)計解決的是“如何實現(xiàn)系統(tǒng)”的問題；從工程管理的角度，軟件設(shè)計可以分成概要設(shè)計（總體設(shè)計、系統(tǒng)設(shè)計）與細節(jié)設(shè)計（詳細設(shè)計）4.2設(shè)計概念4.2.1模塊化

4.2.1模塊化模塊化的思想，即把軟件劃分為可獨立命名和編址的構(gòu)件，每個構(gòu)件稱為一個模塊，每個模塊完成一個子功能，當把所有模塊組裝到一起成為一個整體時，便可以完成指定的功能。模塊組成系統(tǒng)或子系統(tǒng)。“一個復(fù)雜問題分割成若干個容易解決、容易管理的小問題后更易于求解”，模塊化正是以此為依據(jù)把系統(tǒng)劃分成若干個模塊，各個擊破。4.2.2信息隱藏與獨立性信息隱藏原理告訴我們，模塊應(yīng)該設(shè)計得使其所含信息（過程和數(shù)據(jù)）對于那些不需要這些信息的模塊來說不可訪問；每個模塊只完成一個相對獨立的特定功能；模塊之間僅交換那些為完成系統(tǒng)功能必須交換的信息，即模塊應(yīng)該功能獨立的。

采用信息隱藏原理指導(dǎo)模塊設(shè)計有很多好處：

1）它支持模塊的并行開發(fā)；

2）減少測試和后期維護的工作量。因為測試和維護階段不可避免地要修改設(shè)計和代碼，模塊對大多數(shù)數(shù)據(jù)和過程處理細節(jié)的隱藏可以減少錯誤向外傳播。

3）整個系統(tǒng)擴充功能只需“插入”新模塊，原有的多數(shù)模塊無須改動。模塊獨立性（Independency）

模塊獨立性的概念是模塊化、抽象和信息隱藏概念的直接產(chǎn)物，模塊獨立性是通過開發(fā)具有單一功能和與其他模塊沒有過多交互作用的模塊來達到的。獨立性好的模塊對其它的模塊依賴性小，修改時對其它模塊的影響小，易于修改和擴充，因此有良好的可維護性。模塊獨立性可用兩個定性準則來度量：耦合性（coupling）和內(nèi)聚性（cohesion）。

耦合是模塊之間相對獨立性的量度，而內(nèi)聚則是模塊功能相對強度的量度。

模塊的內(nèi)聚性越強，耦合性越弱，獨立性越強。4.3體系結(jié)構(gòu)設(shè)計體系結(jié)構(gòu)（architecture,又稱架構(gòu)）設(shè)計的任務(wù)是要識別出組成系統(tǒng)的子系統(tǒng)并建立子系統(tǒng)的控制和通信框架。體系結(jié)構(gòu)設(shè)計是聯(lián)系需求描述與其他設(shè)計活動的橋梁。系統(tǒng)的組成系統(tǒng)的組成反映的是系統(tǒng)組織所采用的基本策略。三種應(yīng)用廣泛的組成類型：數(shù)據(jù)中心體系結(jié)構(gòu)（容器模型）；客戶/服務(wù)器體系結(jié)構(gòu)；抽象機或分層體系結(jié)構(gòu)。4.3.1數(shù)據(jù)中心體系結(jié)構(gòu)（容器）數(shù)據(jù)中心體系結(jié)構(gòu)（容器模型）的基本特點：所有共享數(shù)據(jù)放到一個中心數(shù)據(jù)庫（容器）中，所有子系統(tǒng)都能從中存取數(shù)據(jù)；當系統(tǒng)中存在大量的數(shù)據(jù)共享時，數(shù)據(jù)中心（容器）模型是最為常用的體系結(jié)構(gòu)風(fēng)格。4.3.2客戶/服務(wù)器體系結(jié)構(gòu)客戶/服務(wù)器模型是一個分布式系統(tǒng)模型，數(shù)據(jù)和加工過程在多個處理器之間分配；這種模型的主要組成：一組為其它子系統(tǒng)提供服務(wù)的單機服務(wù)器；一組向服務(wù)器請求服務(wù)的客戶機；連接客戶機與服務(wù)器的網(wǎng)絡(luò)。4.3.3分層（抽象機）體系結(jié)構(gòu)這種模型把系統(tǒng)組織成一系列的層次（抽象機），每一層提供一組服務(wù)；這種模型支持增量式的開發(fā)，不同層次的服務(wù)可以單獨交付；層與層之間以接口相聯(lián)系，一個接口發(fā)生改變，只有毗鄰的層會受到影響；4.4控制模型控制模型考慮子系統(tǒng)之間的控制流，這是分解模型不考慮的問題。對控制流建模有兩種一般性的方法：集中式控制一個子系統(tǒng)專門負責(zé)控制，控制其他子系統(tǒng)的啟動與停止。基于事件的控制不將控制信息集中在一個子系統(tǒng)內(nèi)，每個子系統(tǒng)都能夠接受來自系統(tǒng)外部的事件并作出響應(yīng)。4.5從分析到設(shè)計的轉(zhuǎn)換——魯棒性分析魯棒性分析是這樣一個過程，它采用魯棒圖引導(dǎo)我們從用例轉(zhuǎn)換為支持用例實現(xiàn)的職責(zé)模型：需求模型設(shè)計模型SRS用例模型域模型魯棒性分析魯棒性分析的輸入：一個用例這個用例的用例場景這個用例的活動圖（如果可以用到）域模型（domainmodel）魯棒性分析的輸出：通過一個UML序列圖和一些設(shè)計組件：邊界、服務(wù)、實體組件，得出用魯棒圖表示的設(shè)計模型。魯棒性分析建立設(shè)計模型的過程1.選擇一個適當?shù)挠美?.把一個參與者放到協(xié)作圖里面。3.分析這個用例（活動圖）。對于用例的每一個動作：a.確定并增加邊界組件b.確定并增加服務(wù)組件c.確定并增加實體組件d.畫出這些組件間的關(guān)聯(lián)e.把每個組件都貼上用來滿足用例交互的動作標簽4.把協(xié)作圖轉(zhuǎn)換成序列圖（可選）4.6用戶界面設(shè)計過程4.7UI設(shè)計的黃金規(guī)則TheoMandel提出了界面設(shè)計的三條“黃金規(guī)則”：置于用戶控制之下；減少用戶的記憶負擔(dān)；保持界面一致。4.8錯誤消息錯誤消息的設(shè)計對界面設(shè)計的成敗是非常關(guān)鍵的。設(shè)計很差的錯誤消息會導(dǎo)致用戶對整個系統(tǒng)反感。錯誤消息應(yīng)該是禮貌的、簡明的、一致的和建設(shè)性的。4.9幫助系統(tǒng)設(shè)計軟件幫助系統(tǒng)不能是用戶手冊的簡單復(fù)制，應(yīng)該有一個合理的組織與結(jié)構(gòu)，應(yīng)該為用戶提供不同的入口。第五講軟件實現(xiàn)與驗證5.1程序設(shè)計與調(diào)試程序設(shè)計的任務(wù)是把設(shè)計轉(zhuǎn)換成程序以及在程序中去除錯誤，包括編程與調(diào)試兩個過程。通常，程序員要對自己開發(fā)的程序進行測試，這時程序中的一些明顯的錯誤會暴露出來并被根除，這個過程叫調(diào)試。驗證:

“Arewebuildingtheproductright？”.檢查軟件是否符合它的規(guī)格描述。有效性確認:

“Arewebuildingtherightproduct？”.檢查軟件是否滿足客戶的期待。5.2驗證和有效性確認（Verification

&

Validation）軟件審查

通過對系統(tǒng)的各種靜態(tài)成果，如需求文檔、設(shè)計文檔、源代碼，進行檢查和分析發(fā)現(xiàn)問題。Maybesupplementbytool-baseddocumentandcodeanalysis軟件測試

通過使用測試數(shù)據(jù)執(zhí)行系統(tǒng)，檢查運行結(jié)果來發(fā)現(xiàn)問題。Thesystemisexecutedwithtestdataanditsoperationalbehaviourisobserved5.3驗證和有效性確認過程的兩種基本方法：測試的目的是為了揭示程序中存在錯誤，而不是沒有錯誤。按照測試的不同目標可以把測試分成有效性測試與缺陷測試。審查與測試各有優(yōu)缺點，它們是互補的而不是對立的V&V技術(shù)；兩種技術(shù)在V&V過程中應(yīng)該一同配合使用；5.4程序測試與靜態(tài)審查測試和調(diào)試是不同的過程，通常交叉進行。檢驗和有效性驗證的目的是確定系統(tǒng)中存在缺陷；調(diào)試考慮的是定位和修改缺陷。測試和調(diào)試仔細的規(guī)劃能夠使程序檢查和測試的工作得到更多的回報。V&V過程的規(guī)劃應(yīng)該從開發(fā)過程的早期就開始。V&V規(guī)劃應(yīng)該明確的說明靜態(tài)檢查與測試任務(wù)與分工。測試規(guī)劃主要是制定測試過程標準，而不是描述測試本身。5.5V&V規(guī)劃系統(tǒng)開發(fā)的V模型5.7軟件測試階段活動測試階段組件測試

測試單個的程序組件；通常由程序開發(fā)者完成（除了要求特別高的系統(tǒng)）；這個階段的測試大多依靠測試者的經(jīng)驗。系統(tǒng)測試測試由組件整合成的子系統(tǒng)和系統(tǒng)；有專門的測試團隊進行測試；測試要依據(jù)需求規(guī)格說明進行。5.8集成測試自頂向下集成從主控模塊開始，沿著控制層次結(jié)構(gòu)逐步向下，利用深度優(yōu)先或廣度優(yōu)先的方式將從屬于主控模塊的其他模塊集成到系統(tǒng)結(jié)構(gòu)中。自底向上集成從原子模塊開始，從底層把模塊逐步向上集成為更大規(guī)模的子系統(tǒng)和系統(tǒng)。集成測試包括把組件集成為系統(tǒng)和對合成的系統(tǒng)進行測試，以發(fā)現(xiàn)組件集成過程帶來的問題，集成方式可以分為：M1M2M3M4M5M6M8M7M9增量集成測試為了簡化測試中錯誤定位的問題，可以采用增量集成的方法。5.9

測試用例設(shè)計測試用例的基本構(gòu)成可以包括：設(shè)計的輸入、期望的輸出、測試環(huán)境和測試對象的描述。設(shè)計測試用例是系統(tǒng)測試與組件測試的關(guān)鍵工作，主要是通過設(shè)計輸入數(shù)據(jù)與預(yù)計的輸出來測試系統(tǒng)。測試用例設(shè)計的目的是建立一組測試用例集合，用盡可能少的測試代價有效的發(fā)現(xiàn)系統(tǒng)缺陷并證明系統(tǒng)能夠滿足需求。設(shè)計測試用例的常用方法：劃分測試與邊界值分析；結(jié)構(gòu)化測試（白盒測試）。5.10等價劃分測試

等價劃分測試是測試用例設(shè)計的一種方法。設(shè)計測試用例時，可以按特征把數(shù)據(jù)輸入域化分成若干等價類，等價類中的每個數(shù)據(jù)應(yīng)該以同樣的方式得到處理，因此對于揭露程序中的錯誤是等效的。這樣，就可以選取少量有代表性的輸入數(shù)據(jù)作為測試數(shù)據(jù)，以期用較小的代價暴露較多的程序錯誤。

結(jié)構(gòu)化測試是根據(jù)軟件的結(jié)構(gòu)知識導(dǎo)出測試用例的測試方法。又叫做“白盒測試法”。對組件中所用的算法結(jié)構(gòu)的理解可以幫助我們找出更多的測試用例。5.11結(jié)構(gòu)化測試黑盒測試與白盒測試黑盒測試又叫做功能測試，測試者只關(guān)心系統(tǒng)的功能而不關(guān)心軟件的實現(xiàn)。也就是說測試者不必了解有關(guān)系統(tǒng)的任何細節(jié)，只把系統(tǒng)看成是一個能夠處理輸入，產(chǎn)生輸出的“黑盒子”，僅從功能的角度設(shè)計測試用例。白盒測試又叫做結(jié)構(gòu)測試，是一種根據(jù)軟件的結(jié)構(gòu)知識導(dǎo)出測試用例的設(shè)計方法。測試者把被測試組件看成是一個打開的“白盒子”，組件的內(nèi)部結(jié)構(gòu)對測試者是透明的，通過對所用算法結(jié)構(gòu)的分析設(shè)計測試用例。結(jié)構(gòu)化測試的目標目標：（1）保證一個模塊中的所有獨立路徑至少被執(zhí)行一次；（2）對所有的邏輯值均需測試真和假；（3）在上下邊界以及可操作的范圍內(nèi)執(zhí)行所有循環(huán)；（4）檢驗內(nèi)部結(jié)構(gòu)以確保其有效性。白盒測試能夠比黑盒測試發(fā)現(xiàn)更細小的缺陷。5.12邏輯覆蓋法邏輯覆蓋一系列測試過程的總稱，這組測試會逐漸進行越來越完整的通路測試。由于覆蓋測試的目標不同，邏輯覆蓋又可分為：語句覆蓋、判定覆蓋、條件覆蓋、判定－條件覆蓋、條件組合覆蓋及路徑覆蓋。其中語句覆蓋覆蓋度最弱，路徑覆蓋最強！5.13基本路徑測試基本路徑測試的原理：

“在程序控制流圖的基礎(chǔ)上，分析控制結(jié)構(gòu)的環(huán)路復(fù)雜度,并用這個復(fù)雜度為指南定義執(zhí)行路徑的基本集合，從而導(dǎo)出基本可執(zhí)行路徑集合，設(shè)計出測試用例并保證每個可執(zhí)行語句至少執(zhí)行一次，而且每個條件在執(zhí)行時都將分別取真、假兩種值?！闭莆毡局v課后作業(yè)與練習(xí)基本路徑測試First,wecomputethecyclomaticcomplexity:numberofsimpledecisions+1

ornumberofenclosedareas+1Inthiscase,V(G)=412345678Next,wederivetheindependentpaths:SinceV(G)=4,therearefourpathsPath1:1,2,3,6,7,8Path2:1,2,3,5,7,8Path3:1,2,4,7,8Path4:1,2,4,7,2,4,...7,8Finally,wederivetestcasestoexercisethesepaths.12345678基本路徑測試第六講軟件維護6.1系統(tǒng)變更與進化軟件系統(tǒng)變更是不可避免的，軟件系統(tǒng)開發(fā)的一個關(guān)鍵的問題就是如何實現(xiàn)和管理現(xiàn)存軟件的