1、1第一章軟件的定義軟件是： (1)指令的集合(計算機程序)，通過執行這些指令來滿足預期的特征、功能和性能需求； (2)數據結構，使得程序可以合理的利用信息； (3)文檔描述，用來描述程序操作和使用。2軟件的特性n軟件是設計開發的，而不是傳統意義上生產制造的。 -硬件可能會引入質量問題，但軟件不會（或易于糾正） -人員和工作成果之間的對應關系完全不同 -構建方法不同，軟件產品成本主要在于開發設計軟件的特性(續1）n軟件不會“磨損”。 -硬件的失效率稱為“浴缸曲線”。 早期具有相對較高的失效率（來自設計或生產缺陷）， 缺陷被逐個糾正后，失效率隨之降低并在一段時間內保持平穩， 因灰塵、震動、不當使用

2、、溫度超限等問題所造成的硬件組件損耗累積的效果而再次升高。 These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 3軟件的特性(續3）n雖然整個工業向著基于構件的構造模式發展，然而大多數軟件仍是根據實際的顧客需求定制的。 -交互式用戶界面使用可復用構件構造圖形窗口、下拉菜單和各種交互機制。These slides are designed to a

3、ccompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 45遺留軟件n軟件必須進行適應性調整，以滿足新的計算環境和技術的需求。n軟件必須升級以實現新的商業需求。n軟件必須擴展使之具有與更多現代系統和數據庫的互操作能力。n軟件必須進行改建使之能適應多樣化的網絡環境。為什么一定要變更為什么一定要變更? ?6軟件工程n若干事實:n在制定解決方案之前要理解問題n設計是一項關鍵的軟件工程活動n軟件必須保證高質量n軟件需

4、具備可維護性n種子定義（Fritz Bauer)：n（軟件工程是）建立和使用一套合理的工程原則，以便經濟地獲得可靠的、可以在實際機器上高效運行的軟件。 -未提及軟件質量，直接談到用戶滿意度或按時交付產品的要求、忽略了測量和度量的重要性和有效的軟件過程的重要性。7軟件工程nIEEE 定義：n軟件工程是：（1）將系統化的、規范的、可量化的方法應用于軟件的開發、運行和維護，即將工程化方法應用于軟件。（2）在(1)中所述方法的研究。-需要規范，也需要可適應性和靈活性8一種過程框架工作任務(task)工作產品里程碑和可交付成果QA 檢查點9框架包含的活動n溝通n策劃n建模n需求分析n設計n構建n代碼生成

5、n測試n部署10普適性活動n軟件項目跟蹤和控制n風險管理n軟件質量保證n技術評審n測量n軟件配置管理n可復用管理n工作產品的準備和生產11實踐的精髓nPolya 的建議：1.理解問題（溝通和分析）。2.計劃解決方案（建模和軟件設計）。3.實施計劃 （代碼生成）。4.檢查結果的準確性（測試和質量保證）。12Hooker的一般原則n1: 存在價值n2: 保持簡潔n3: 保持愿景n4:關注使用者n5: 面向未來n6: 計劃復用n7: 認真思考13第二章 通用過程模型軟件過程過程框架普適性活動軟件工程活動#1.1框架活動#1工作任務 工作產品質量保證點項目里程碑工作任務 工作產品質量保證點項目里程碑框

6、架活動#n軟件工程活動#n.1軟件工程動作#n.m任務集任務集任務集任務集軟降工程動作#1.k工作任務 工作產品質量保證點項目里程碑工作任務 工作產品質量保證點項目里程碑14過程流溝通策劃建模(a)線性過程流構建部署部署構建建模策劃溝通(b)迭代過程流建模構建(c)演化過程流部署策劃溝通增量交付溝通策劃建模時間構建部署(c)并行過程流小型項目的獲取需求任務集1.制定項目的利益相關者列表2.邀請所有的利益相關者參加一個非正式會議。3.征詢每一個人對于軟件特征和功能的需求。4.討論需求，并確定最終的需求列表。5.劃定需求優先級。6.標出不確定領域。These slides are designed

7、 to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.15大型項目的獲取需求任務集1.制定項目的利益相關者列表2.和利益相關者的每一個成員分別單獨討論，獲取所有的要求。3.基于任務集2中的調查，建立初步的功能和特征列表。4.安排一系列促進需求獲取的會議。5.組織會議。6.在每次會議上建立非正式的用戶場景。7.根據利益相關者的反饋，進一步細化用戶場景。8.建立一個修正的需求列表。9.使用質量功能部署

8、技術，劃分需求優先級。10.將需求打包以便軟件可以增量交付。These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.16大型項目的獲取需求任務集（續）11.標注系統的約束和限制。12.討論系統驗證方法。These slides are designed to accompany Software Engineering: A Practitioner

9、s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.1718過程模式類型n步驟模式定義了與過程的框架活動相關的問題。 例如“建立溝通”，它可能包括需求獲取等任務模式n任務模式定義了與軟件工程動作或是工作任務相關、關系軟件工程實踐成敗的問題。 例如“需求獲取” n階段模式定義在過程中發生的框架活動序列，即使 這些活動流本質上是迭代的。 例如“螺旋模型”和“原型開發” 19瀑布模型C Co om m m m u un ni i c ca at ti i o on n P Pl la an nn n

10、i in ng g M M o od de el l i i n ng gC Co on ns st tr ru uc ct ti i o on nD De ep pl l o oy ym m e en nt t anal ysi s desi gncode testp pr ro oj j e ec ct t i i n ni i t ti i a at ti i o on n r re eq qu ui i r re em m e en nt t g ga at th he er ri i n ng ge es st ti im ma at ti in ng g s sc ch he ed

11、 du ul li in ng g t tr ra ac ck ki in ng gd de el l i i v ve er ry y s su up pp po or rt t f fe ee ed db ba ac ck k溝通項目啟動需求獲取策劃項目估算進度計劃項目跟蹤建模分析設計構建編碼測試部署交付支持反饋20V模型需求建模體系結構設計構件設計代碼生成單元測試集成測試系統測試驗收測試可執行軟件使用中遇到的問題n實際的項目很少遵守瀑布模型提出的順序。n客戶通常難以清楚地描述所有的需求。n客戶必須要有耐心。These slides are designed to accompany So

12、ftware Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.21適用情形n當需求確定、工作采用線性方式完成時。These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.2223增量模型C C

13、o o m m m m u u n n i ic c a a t t i io o n nP P l la a n n n n i in n g gM M o o d d e e l li in n g gC C o o n n s s t t r ru u c c t t i io o n nD D e e p p l lo o y y m m e e n n t t d d e e l li iv v e e r ry y f fe e e e d d b b a a c c k kanal ysi s desi gncode testi ncrem ent # 1i ncrem ent

14、# 2del i very of 1st i ncrem entdel i very of 2nd i ncrem entdel i very of nth i ncrem enti ncrem ent # nproj ect cal endar ti m eC C o o m m m m u u n n i ic c a a t t i io o n nP P l la a n n n n i in n g gM M o o d d e e l li in n g gC C o o n n s s t t r ru u c c t t i io o n nD D e e p p l lo o

15、 y y m m e e n n t t d d e e l li iv v e e r ry y f fe e e e d d b b a a c c k kanal ysi s desi gncode testC C o o m m m m u u n n i ic c a a t t i io o n nP P l la a n n n n i in n g gM M o o d d e e l li in n g gC C o o n n s s t t r ru u c c t t i io o n nD D e e p p l lo o y y m m e e n n t t d

16、d e e l li iv v e e r ry y f fe e e e d d b b a a c c k kanal ysi s desi gncode test第1個增量第2個增量第n個增量交付第2個增量交付第3個增量交付第1個增量軟件功能和特征項目時間溝通策劃建模分析設計構件編碼測試部署交付反饋溝通溝通策劃策劃建模分析設計建模分析設計構件編碼測試構件編碼測試部署交付反饋部署交付反饋適用情形n初始的軟件需求明確，但是整個開發過程卻不宜單純運用線性模型。同時，可能迫切需要為用戶迅速提供一套功能有限的軟件產品，然后在后續版本中再進行細化和擴展功能。 例如第一個增量往往是核心產品，附加功能進

17、入下個增量計劃。These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.24特點n綜合了線性過程流和并行過程流的特征。n每個增量都提交一個可以運行的產品。These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-

18、Hill, 2009). Slides copyright 2009 by Roger Pressman.2526演化模型:原型開發Constructionof prototypeC C o o m m m m u u n n i ic ca at ti io o n nQ Q u u i ic ck k p p l la an nC C o o n n s st tr ru u c ct ti io o n n o o f f p p r ro o t to o t ty yp p e eM M o o d d e e l li in n g g Q Q u u i ic ck k d d

19、e e s si ig g n nD D e e l li iv ve e r ry y & & F Fe e e e d d b b a ac ck kD epl oym entcommunicationQuickplanModelingQuick designConstructionof prototypeDeploymentdelivery &feedback溝通快速策劃快速建模設計構建原型部署交付及反饋適用情形n客戶提出了一些基本功能，但沒有詳細定義功能和特性需求n開發人員可能對算法的效率、操作系統的兼容性和人機交互的形式等情況并不確定These slides

20、are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.27特點n很少是好用的，可能太慢太大，難以使用。n一般作為被丟棄的系統。These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009). Slides copyri

21、ght 2009 by Roger Pressman.2829演化模型：螺旋communicationplanning modelingconstructiondeployment delivery feedbackstartanalysis designcode testestimation scheduling risk analysis策劃項目估算制定進度計劃風險分析建模分析設計構建編碼測試部署交付反饋溝通開始特點n采用循環的方式逐步加深系統定義和實現的深度，同時降低風險。n確定一系列里程碑，確保利益相關者都支持可行的和令人滿意的系統解決方案。These slides are desig

22、ned to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.3031演化模型：協同Under r evi ewBasel i nedDoneUnderr evi si onAwai ti ngchangesUnderdevel opm entnoneModel i ng acti vi tyrepresents the stateof a software engi neeri ngacti vi

23、 ty or task建模活動非活動狀態表示阮籍工程活動或任務的某一狀態完成狀態已建立基線正在評審狀態正在開發狀態等待變更請求正在修改狀態特點(以建模活動為例）n在某一特定時間，建模活動可能處于圖中所示的任何一種狀態中。其他活動、動作或任務，可以用類似的方式表示。n所有的軟件工程活動同時存在并處于不同的狀態。These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pr

24、essman.3233其他過程模型n基于構件的開發這個過程模型能夠使軟件復用，是一個發展目標n形式化方法強調需求的數學規范說明 一個變型是凈室（ cleanroom)軟件工程。n面向方面的軟件開發（AOSD）為定義、說明、設計和構建方面提供過程和方法 如果某個關注點涉及系統多個方面的功能、特性和信息，可稱為橫切關注點，由方面性需求來定義。n統一過程一種“用例驅動，以架構為核心，迭代并且增量”的軟件過程與統一建模語言的緊密結合34統一過程(UP)sof twar e i ncr em entRel easeI I n nc ce ep pt ti i o on nE El l a ab bo o

25、r ra at ti i o on nc co on ns st tr ru uc ct ti i o on nt tr ra an ns si i t ti i o on np pr ro od du uc ct ti i o on ninceptionelaboration起始細化策劃溝通部署轉換構建構建建模生產發布軟件增量35UP 階段I ncepti onEl aborati onConstructi onTransi ti onProducti onU UP P P Ph ha as se es sW Wo or rk kf fl lo ow ws sRequirementsAnal

26、ysisDesignImplementationTestIterations#1#2#n-1#nSupportUP階段需求工作流分析設計實現測試支持迭代起始細化構建轉換生產36UP工作產品I ncepti on phaseEl aborati on phaseConstructi on phaseTransi ti on phaseVi si on docum ent I ni ti al use-case m odel I ni ti al proj ect gl ossaryI ni ti al busi ness case I ni ti al ri sk assessm ent. Pr

27、oj ect pl an, phases and i terati ons. Busi ness m odel , i f necessary. One or m ore prototypes I In nc ce ep pt ti io o n nUse-case m odelSuppl em entary requi rem ents i ncl udi ng non-functi onal Anal ysi s m odel Software archi tecture Descri pti on. Executabl e archi tectural prototype. Prel i

28、 m i nary desi gn m odel Revi sed ri sk l i stProj ect pl an i ncl udi ng i terati on pl an adapted workfl ows m i l estones techni cal work products Prel i m i nary user m anualDesi gn m odelSoftware com ponents I ntegrated software i ncrem ent Test pl an and procedure Test cases Support docum enta

29、ti on user m anual s i nstal l ati on m anual s descri pti on of current i ncrem ent Del i vered software i ncrem ent Beta test reports General user feedback起始階段愿景文檔初始用例模型初始項目術語初始商業案例初始風險評估項目計劃，階段和迭代。商業模型，如果必要一個或更多的原型開發細化階段構建階段轉換階段用例模型包括非功能性的補充需求分析模型軟件體系結構描述可執行體系結構原型初步設計模型修訂風險列表包含迭代計劃的項目策劃調整工作流里程碑技術

30、工作產品初步用戶手冊設計模型軟件構件集成軟件增量測試計劃和步驟測試用例支持文檔用戶手冊安裝手冊當前增量說明交付軟件增量Beta測試報告一般用戶反饋37第四章 質量功能部署（QFD)(Quality Function Deployment, QFD)-將客戶要求轉化成軟件技術需求的質量管理技術n3類需求：正常需求、期望需求和令人興奮的需求n功能部署決定系統所需的每一個功能的“價值”（由客戶感知）n信息部署確定數據對象和事件n任務部署檢查系統行為n價值分析決定需求的相對優先權n用戶場景識別將要構建系統的使用線索n產生需求表38第七章 設計nMitch Kapor，Lotus 1-2-3的創始人,在

31、 Dr. Dobbs雜志上發表了“軟件設計宣言”，他說：n良好的軟件設計應該展示：n堅固：程序應該不含任何妨礙其功能的缺陷。n適用：程序應該符合開發的目標。 n愉悅：使用程序的體驗應是愉快的。實現設計目標的途徑n先實現多樣化（獲取所有方案和設計的原始資料，包括目錄、教科書和頭腦中的構件、構件方案和知識），然后再進行聚合。n匯聚信息后，挑選合適的元素，考慮取舍候選方案，然后聚合，使之成為“構件的某種特定的配置，從而創建最終的產品。These slides are designed to accompany Software Engineering: A Practitioners Approac

32、h, 7/e (McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 3940設計模型n數據設計n信息模型 軟件數據結構n體系結構設計n定義軟件部件間的關系n接口設計n軟件內部、外部及與人之間的通信n構件級（過程）設計n軟件組件的過程性描述41分析模型- 設計模型Anal ysi s M odeluse- cases - t ext use- case di agr am s act i vi t y di agr am s swi m l ane di agr am sdat a f l ow di agr am s cont

33、 r ol - f l ow di agr am s pr ocessi ng nar r at i vesf fl lo ow w - -o or ri ie en nt te ed d e el le em m e en nt ts sb be eh ha av vi io or ra al le el le em m e en nt ts sc cl la as ss s- -b ba as se ed de el le em m e en nt ts ss sc ce en na ar ri io o- -b ba as se ed de el le em m e en nt ts s

34、cl ass di agr am s anal ysi s packages CRC m odel s col l abor at i on di agr am s st at e di agr am s sequence di agr am sD D a at ta a/ /C Cl la as ss s D D e es si ig gn nA A r rc ch hi it te ec ct tu ur ra al l D D e es si ig gn nI In nt te er rf fa ac ce e D D e es si ig gn nC Co om m p po on n

35、e en nt t- - L Le ev ve el l D D e es si ig gn nDesi gn Model基于場景的元素用例文本用例圖活動圖泳道圖基于類的元素類圖分析包CRC模型協作圖行為元素狀態圖順序圖面向流的元素數據流圖控制流圖處理敘述設計模型數據/類設計體系結構設計接口設計構件級設計分析模型42質量指導原則n設計應展示出這樣一種結構：（a）已經使用可識別的體系結構風格或模式創建；（b）由展示出良好設計特征的構件構成；（c）能夠以演化的方式實現，從而便于實現和測試。n對于更小的系統，設計有時可以線性開發。n設計應該模塊化；也就是說，應將軟件邏輯地劃分為元素或子系統。n設計應

36、該包含數據、體系結構、接口和構件的清晰表示。n設計應導出數據結構，這些數據結構適用于要實現的類，并從可識別的數據模式提取。n設計應導出顯示獨立功能特征的構件。n設計應導出接口，這些接口降低了構件之間以及與外部環境連接的復雜性。n設計的導出應根據軟件需求分析過程中獲取的信息采用可重復的方法進行。n應使用能夠有效傳達其意義的表示法來表達設計。43設計原則n設計過程中不要有“井蛙之見”。n設計應起源于分析模型。n設計不要白費力氣做重復工作。n在軟件和真實世界的問題之間，設計應能“最小化知識距離” DAV95 。n設計應表現出一致性和集成性。n設計結構應適應變化。n即使遇到數據、事件或操作條件異常時，

37、設計結構應能溫和處理。n設計不是編碼，編碼不是設計。n創建設計時就應對其質量進行評估，而不是創建之后。n評審設計以最小化概念上的（語義的）錯誤。來自來自 Davis DAV9544為什么要信息隱藏？n減少“負效應”的可能性n限制全局影響局部的設計決策n強調通過控制接口通信n不提倡使用全局數據n導致封裝高質量設計的屬性n導致高質量軟件45功能獨立n通過開發具有“專一”功能和“避免”與其他模塊過多的交互的模塊，可以實現功能獨立。模塊的獨立性有兩條定性標準進行評估：n內聚性顯示了某個模塊相關功能的強度。n一個內聚的模塊執行一個獨立的任務，與程序的其他部分構件只需要很少的交互。簡單地說，一個內聚的模塊

38、應該（理想情況下）只完成一件事情。n耦合性顯示了模塊間的相互依賴性。n耦合性依賴于模塊之間的接口復雜性、引用或進入模塊所在的點以及什么數據通過接口進行傳遞。模塊的獨立性高 n塊內聯系強 n塊間聯系弱 46七種內聚n偶然內聚偶然內聚模塊內各元素間無實質性聯系，功能無關；如：“讀A”和“寫B”等操作，就是被整合在一個模塊中，供其他模塊調用。n邏輯內聚邏輯內聚模塊內各元素在邏輯上相似功能；如：兩個邏輯上相似的兩個功能放在同一個模塊中，可以省去其中重復的部分。n時間內聚時間內聚模塊內各元素在同一時間段內執行；如：變量初始化等，在同一時間內執行47七種內聚n過程內聚過程內聚模塊內元素必須以特定次序執行；

39、n通信內聚通信內聚模塊內所有元素使用同一輸入，產生同一輸出；n順序內聚順序內聚模塊內元素必須以特定次序執行，前者輸出為后者輸入；n功能內聚功能內聚模塊內元素組成不可分的整體，完成特定功能。48七種耦合n非直接耦合非直接耦合兩模塊間沒有直接聯系n數據耦合數據耦合通過數據參數訪問另一模塊n特征耦合特征耦合通過數據結構傳遞記錄信息n控制耦合控制耦合通過控制參數或開關量來訪問另一模塊n外部耦合外部耦合一組模塊訪問同一全局簡單變量n公共耦合公共耦合一組模塊訪問同一公共數據結構n內容耦合內容耦合一個模塊直接轉入另一模塊內49第八章 體系結構風格一組構件一組連接件約束語義模型50體系結構風格n以數據為中心的

40、體系結構n數據流體系結構n調用和返回體系結構n面向對象體系結構n層次體系結構51第九章 基本設計原則n開閉原則(OCP)。“模塊構件應該對外延具有開放性，對修改具有封閉性”。nLiskov 替換原則(LSP)。“子類可以替換它們的基類”。n依賴倒置原則(DIP)。“依賴于抽象，而非具體實現”。n接口分離原則(ISP)。“多個客戶專用接口比一個通用接口要好”。n發布復用等價性原則(REP)。“復用的粒度就是發布的粒度”。n共同封裝原則(CCP)。“一同變更的類應該合在一起”。n共同復用原則(CRP).。“不能一起復用的類不能被分到一組”。52第十章 黃金規則n用戶操縱控制n減少用戶的記憶負擔n保

41、持界面一致53用戶操作控制54減輕用戶記憶負擔55保持界面一致第十四章 軟件質量保證n延伸前述的質量定義，軟件質量保證就是為了保證軟件高質量而必需的“有計劃、系統化的行動模式”。n軟件質量保證（質量管理）是適用于整個軟件過程的一種普適性活動，而不僅僅是在編碼完成之后才開始進行。These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 56軟件質量保證n

42、軟件質量保證是由兩個不同人群相聯系的多種任務組成分別是做技術工作的軟件工程師和負有質量策劃、監督、記錄、分析和報告責任的軟件質量保證組。n其中，軟件工程師通過采用可靠的技術方法和措施，進行技術評審，并進行周密計劃的軟件測試來獲得質量。n可見，軟件測試是軟件質量保證活動中的一部分。These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 5758軟件測試

43、測試是在交付產品給最終用戶之前，帶測試是在交付產品給最終用戶之前，帶著特定的目的在運行程序的過程中發現著特定的目的在運行程序的過程中發現錯誤。錯誤。測試的目的是為了發現測試對象的問題測試的目的是為了發現測試對象的問題，而不是證明測試對象沒有問題。，而不是證明測試對象沒有問題。59驗證與確認 書為主n軟件測試是通常所講的更為廣泛的主題驗證與確認的一部分。n驗證是指確保軟件正確地實現某一特定功能的一系列活動。 n確認指的是確保開發的軟件可追溯到客戶需求的另外一系列活動。Boehm Boe81 用另一種方式說明了這兩者的區別：n驗證：我們在正確地構造產品嗎？n確認：我們在構造正確的產品嗎？單元測試n

44、單元測試是對軟件的基本組成單元進行測試。n單元可以是：函數、子過程函數、子過程 類或類的方法類或類的方法 獨立的過程和函數獨立的過程和函數 一個菜單或顯示界面一個菜單或顯示界面These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 60單元測試的主要任務These slides are designed to accompany Software E

45、ngineering: A Practitioners Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 61模模塊塊模模塊塊接口接口局部數據局部數據結結構構獨立路徑獨立路徑測試測試出出錯處錯處理理邊邊界條件界條件增量式測試增量式測試的集成是逐步實現的： 逐次將未曾集成測試的模塊和已經集成測試的模塊（或子系統）結合成程序包，再將這些模塊集成為較大系統，在集成的過程中邊連接邊測試，以發現連接過程中產生的問題。按照不同的實施次序，增量式集成測試又可以分為三種不同的方法： （1）自頂向下增量式測試 （

46、2）自底向上增量式測試 （3）三明治測試混合增量測試These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 62自頂向下增量式測試n自頂向下增量式測試表示逐步集成和逐步測試是按照結構圖自上而下進行的，即模塊集成的順序是首先集成主控模塊（主程序），然后依照控制層次結構向下進行集成。從屬于主控模塊的按深度優先方式（縱向）或者廣度優先方式（橫向）集成到結構

47、中去。n深度優先方式的集成： 首先集成在結構中的一個主控路徑下的所有模塊，。 n廣度優先方式的集成： 首先沿著水平方向，把每一層中所有直接隸屬于上一層的模塊集成起來，直到底層。These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 6364自頂向下集成自底向上增量式測試n自底向上增量式測試表示逐步集成和逐步測試的工作是按結構圖自下而上進行的，即從程序

48、模塊結構的最底層模塊開始集成和測試。n由于是從最底層開始集成，對于一個給定層次的模塊，它的子模塊（包括子模塊的所有下屬模塊）已經集成并測試完成，所以不再需要使用樁模塊進行輔助測試。在模塊的測試過程中需要從子模塊得到的信息可以直接運行子模塊得到。These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 6566自底向上集成67三明治測試混合增量式測試是把

49、自頂向下測試和自底向上測試這兩種方式結合起來進行集成和測試。這樣可以兼具兩者的優點，而摒棄其缺點。68回歸測試n回歸測試重新執行已測試過的某些子集，以確保變更沒有傳播不期望的副作用。n無論什么時候修正軟件，軟件配置的某些方面（程序、文檔或支持數據）也發生變更。n回歸測試有助于保證變更（由于測試或其他原因）不引入無意識行為或額外的錯誤。n回歸測試可以手工進行，方法是重新執行所有測試用例的子集，或者利用捕捉/回放工具自動進行。69冒煙測試n為生產軟件創建“每日構建”的一種常見方法n冒煙測試步驟：n將已經轉換為代碼的軟件構件集成到“構建”中去。 一個構建包括所有的數據文件、庫、可復用的模塊以及實現一

50、個或多個產品功能所需的工程化構件。n設計一系列測試以暴露影響構建正確地完成其功能的錯誤。 其目的是為了發現極有可能造成項目延遲的“業務阻塞”錯誤。n每天將該構建與其他構建及整個軟件產品（以其當前的形式）集成起來進行冒煙測試。 這種集成方法可以是自頂向下，也可以自底向上。70測試CRC模型71高階測試n確認測試n關注點是軟件需求 確認測試也稱為合格性測試，是檢驗所開發的軟件是否能按用戶提出的要求進行。軟件確認要通過一系列證明軟件功能和要求一致的黑盒測試來完成，傳統軟件、面向對象軟件及WebApp之間的差別已經消失。n系統測試n關注點是系統集成 由于軟件只是計算機系統中的一個組成部分，軟件開發完成

51、之后，最終還要和系統中的硬件系統、某些支持軟件、數據信息等其他部分配套運行。這些測試已經超出軟件過程范圍，而且不僅僅由軟件工程師執行。n/測試n關注點是客戶使用 測試是由有代表性的最終用戶在開發者的現場進行的，開發者在后面觀看，并記錄錯誤和使用問題。 測試是在一個或者多個最終用戶場所進行。開發者通常不在場。高階測試n恢復測試n通過各種方式強制地使軟件發生故障，并驗證其能適當恢復。n安全測試n驗證建立在系統內的保護機制是否能夠實際保護系統不受非法入侵。n壓力測試n 以非正常的數量、頻率或容量的方式執行系統。測試是想要破壞程序。 n舉例： 如果正常的中斷頻率為每秒5次，強度測試設計為每秒50次中斷

52、。 把輸入數據的量提高一個數量級來測試輸入功能會如何響應。 若某系統正常運行可支持200個終端并行工作，強度測試則檢驗1000個終端并行工作的情況。These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 72高階測試n性能測試n用來測試軟件在集成環境中的運行性能，特別是針對實時系統和嵌入式系統，僅提供符合功能需求但不符合性能需求的軟件是不能被接受的。

53、n性能測試可以在測試過程的任意階段進行，但只有當整個系統的所有成分都集成在一起后，才能檢查一個系統的真正性能。n性能測試常常和強度（壓力）測試結合起來進行，而且常常需要硬件和軟件測試設備，這就是說，常常有必要在一種苛刻的環境中衡量資源的使用（比如，處理器周期）。These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 7374第十五章 可測試性n軟件工程師在設計與實現基于計算機的系統或產品時，應該想著可測試性。n軟件的可測試性是能夠被測試的容易程度。可測試的軟件應該具有下述特征：n可操作性有效地操作n可觀察性每個測試用例的結果都是易觀察的n可控制性測試