1、第一章軟件工程概述1.什么是軟件？軟件是一系列按照特定順序組織的計算機數據和指令的集合，包括程序、數據和文檔2.什么是軟件危機，其內容主要是指什么？（1）軟件危機指落后的軟件生產方式無法滿足迅速增長的計算機軟件需求，從而導致軟件開發與維護過程中出現一系列問題的現象。（2）主要表現開發進度難以預測開發成本難以控制用戶對產品功能難以滿足產品質量無法保證，難以維護缺少適當的文檔資料3.什么是軟件工程？軟件工程是應用計算機科學、數學及管理科學等原理開發軟件的工程。它借鑒傳統工程的原則、方法，以達到提高軟件質量，降低開發成本的目的。4.軟件工程的目標及其組成部分（1）目標：在給定成本、進度的前提下，開發

2、出具有適用性、有效性、可修改性、可靠性、可理解性、可維護性、可重用性、可移植性、可追蹤性、可互操作性和滿足用戶需求的軟件產品。（2）組成部分方法: 是指產生某些結果的形式化過程。工具: 是用更好的方式完成某件事情的設備或自動化系統，如各種集成開發環境、編譯工具、測試工具等。過程: 生產特定產品的工具和技術的結合5.軟件開發方法的定義軟件開發方法是一種使用早已定義好的技術集及符號表示習慣組織軟件生產過程的方法。主要有：結構化方法、可視化開發方法和面向對象的開發方法等6. 好的軟件的一些主要衡量指標。例如McCall 的質量模型。第二章過程和生命周期建模1. 什么是軟件生命周期？主要分為哪些階段？

3、各個階段的主要任務及產生的主要制品？（1）軟件生命周期是指軟件的產生直到報廢或停止使用的過程。（2）階段、任務及制品問題定義：弄清“用戶需要計算機解決什么問題”，提出關于“系統目標與范圍的說明”，提交用戶審查和確認。可行性研究：了解用戶要求和現實環境，從技術、經濟、市場等方面研究并論證開發該軟件系統的可行性。需求分析：確定用戶對待開發軟件系統的需求，包括功能、性能、運行環境約束。編寫需求規格說明書和初步的用戶手冊。概要（總體）設計：根據SRS建立目標軟件系統總體結構、設計全局數據庫和數據結構，規定設計約束，制定集成測試計劃詳細設計：細化概要設計生成的各個模塊，詳細描述模塊的內部細節（算法、數據

4、結構等），形成可編程的程序模塊，制定單元測試計劃程序編碼：根據詳細設計規格說明書編寫源程序集成測試：根據概要設計規格說明書，將經過單元測試的模塊逐步進行集成和測試確認測試：根據軟件需求規格說明書，測試軟件系統是否滿足用戶的需求運行維護：對使用后的軟件進行維護，包括修正錯誤，增加功能，搬遷新環境等性能維護。2.需求分析的定義。在軟件工程中，需求分析指的是在建立一個新的或改變一個現存的電腦系統時描寫新系統的目的、范圍、定義和功能時所要做的所有的工作。即確定要計算機“做什么”，要達到什么樣的效果。3.典型的軟件開發過程模型的特點（優缺點）及要求，特別是原型法、瀑布模型、螺旋模型、增量和迭代等。一、瀑

5、布模型需求分析系統分析程序設計編碼單元測試和集成測試系統測試驗收測試運行和維護（1）要求：一個開發階段必須在另一個開發階段開始之前完成。當客戶引發的所有需求都已經過完整性和一致性分析，并形成需求文檔之后，開發團隊才能夠開始進行系統設計活動。每一個過程活動都有與其相關聯的里程碑和可交付產品。（2）特點：優點：采用規范的結構化方法；嚴格規定每個階段提交的文檔；要求每個階段交出的產品必須經過驗證缺點：對如何處理開發中產品和活動的變化沒有提供相關指導；將軟件開發視為制造而不是創造；創造一個產品沒有迭代的活動；需要等待很長的時間二、原型法原型法是指在獲取一組基本的需求定義后，利用高級軟件工具可視化的開發

6、環境，快速地建立一個目標系統的最初版本，并把它交給用戶試用、補充和修改，再進行新的版本開發。反復進行這個過程，直到得出系統的“精確解”，即用戶滿意為止。（1）要求（過程）確定用戶的基本需求；構造初始原形；運行、評價、修改原形；形成最終的管理信息系統（2）特點優點：符合人們認識事物的規律，系統開發循序漸進，反復修改，減少開發中的風險和不確定性；開發周期短，成本相對少。缺點：忽略軟件的總體質量和長期的可維護性；開發過程要經過多次反復修改評價，不便于管理；開發人員易將原型取代系統分析；缺乏規范化的文檔資料適用范圍：處理過程明確、簡單系統；涉及面窄的小型系統三、階段化開發：增量和迭代增量開發：需求文檔

7、中指定的系統按功能劃分為子系統。定義發布時首先定義一個小的功能子系統，然后在每一個新的發布中增加新功能。迭代開發：一開始就提交一個完整的系統，然后在每一個新的發布中改變每個子系統的功能。特點：縮短循環周期，客戶可以提前獲得一部分系統功能四、螺旋模型螺旋模型的每個迭代都圍繞4個主要活動：計劃；確定目標、可選方案及約束；評估可選方案及風險；開發與測試特點：優點：有利于軟件重用，重視軟件質量；減少過多測試缺點：風險驅動，需要豐富的風險評估經驗；主要適用于內部開發的大規模軟件項目；隨著迭代次數增加，工作量加大，開發成本增加4. 原型法的特點以及分類：探索型（遞增型）原型、實驗型（拋棄型）原型和演化型原

8、型。5.敏捷開發方法和極限編程的特點。（1）敏捷方法強調靈活性在快速、有效開發在軟件中的作用相對于過程和工具，更強調個人和交互的價值更喜歡在生產運行的軟件上投入時間 ，而不是在文檔的編寫上注重客戶的合作，而不是合同談判專注于對變化的反應，而不是創建一個計劃而后遵循這個計劃（2）極限編程具有強溝通、簡化設計和迅速反饋等特點，一般只適合于規模小、進度緊、需求不穩定、開發小項目的小團隊。極限編程的核心有4個要點：交流、簡單、反饋和勇氣。第三章計劃和項目管理1.了解項目計劃和管理的主要內容和常用方法（1）項目計劃要列出軟件開發要做的主要工作和任務清單，要回答“軟件工程項目做什么”。 強調可調性創造性分

9、析性響應性，用于協調項目編制、指導項目執行。（2）項目管理，就是項目的管理者，在有限的資源約束下，運用系統的觀點、方法和理論，對項目涉及的全部工作進行有效地管理。即從項目的投資決策開始到項目結束的全過程進行計劃、組織、指揮、協調、控制和評價，以實現項目的目標。主要有：階段化管理、量化管理和優化管理三個方面。2. 軟件可行性研究的內容。了解用戶要求和現實環境，從技術、經濟、市場等方面研究并論證開發該軟件系統的可行性。第四章獲取需求1.了解需求的重要性及需求分析階段的目標及主要產物。（1）重要性需求在軟件開發起到了決策的作用，提供了開發的方向，指明了開發策略缺少需求或需求錯誤會導致項目開發失敗（2

10、）目標及產物了解客戶要求分析系統的數據要求需求規格說明書2. 需求工程包括哪些方面？需求工程包括需求開發和管理，而需求開發又包括：需求獲取，需求分析，需求規格說明和需求驗證。3.需求的類型：功能需求、非功能需求或質量需求、設計約束、過程約束。4. 兩種需求文檔：需求定義文檔和需求規格說明書。5. 需求規格說明書的主要內容。略6. 常用的需求建模表示方法：ER圖、事件跟蹤、狀態機、Petri網、數據流圖、用例圖和原型法。第五章UML部分1.UML的作用：是為軟件系統的制品進行描述（specifying）、可視化（visualizing）、構造（constructing）、文檔化（document

11、ing）的一種語言。2.UML中的41視圖：用例視圖，設計視圖，進程視圖，實現視圖，分布視圖。用例視圖：用來支持軟件系統的需求分析，它定義系統的邊界，關注的是系統的外部功能的描述。邏輯視圖（設計+進程）：定義系統的實現邏輯, 描述實現用例圖描述的功能以及設計軟件系統的設計概念。實現視圖：描述組成一個軟件系統的各個物理部件以各種方式組合起來，構成一個可實際運行的系統。分布視圖：描述軟件產品在計算機硬件系統和網絡上的安裝、分發、分布。3.UML中的三種擴展機制：構造型Stereotype；標記值 tagged value；約束 constraint.構造型(stereotype)：對UML詞匯（建

12、模元素）的擴充，用來描述和已有的UML建模元素類似，但又對特定的問題領域有特殊意義的建模元素。（類）標記值（tagged value）：對UML建模元素的構成(property)的擴充，用于為此建模元素增加新的規格說明。（類的屬性）約束（constraint）：約束用來擴充UML建模元素的語義，以便增加新的規則或修改已有的規則（關系）4.UML中所包含的9種圖形及各自的作用。類圖：包含類、接口、協同及其關系，用來描述邏輯視圖的靜態屬性。對象圖：包含對象及其關系，用來表示類圖的類的對象在系統運行過程中某一時刻的狀態。組件圖：描述系統的物理實現，包括構成軟件系統的各部件的組織和關系。類圖里的類在實

13、現時最終會映射到組件圖的某個組件。一個組件可以實現多個類。分布圖：描述系統的組件在運行時在運行節點上分布，一個節點可包含一個或多個組件。用例圖：描述系統的邊界和其上的動態行為，包括用例、系統作用者及其之間的關系。序列圖和協作圖：用來描述一組對象之間的動態交互。狀態圖和狀態機：用來描述對象的動態特性。前者強調對象對外部事件的相應及相應的狀態變遷，后者描述對象之間控制流的轉換和同步機制。5.用例圖的作用。用例圖用來描述軟件需求模型中的系統功能，通過一組用例可以描述軟件系統能夠給用戶提供的功能。用例圖可以作為整個系統開發過程中的開發依據，指導和驅動其他模型。6.用例圖的主要構成部分。參與者用例系統邊

14、界關系（箭頭）7.類圖的主要作用類圖是描述類、接口以及它們之間關系的圖，它顯示了系統中各個類的靜態結構，是一種靜態結構。8.了解類之間的各種關系：關聯、依賴、繼承或泛化、組合&聚合關聯：用來表示兩個（或多個）類的對象之間的結構關系，在代碼中表現為一個類以屬性的形式包含對類的一個或多個對象的引用。依賴：表示一個類以某種形式依賴于其他類。依賴關系中，其中一個類的改編可能會影響另一個類。在程序代碼中，依賴關系意味著一個類的對象出現在另一個類的操作當中。常見的有兩種情況：一個類將另一個類的對象作為自己某個操作的參數（形參），或者是操作的局部變量。泛化（繼承）：定義類和包之間的一般元素和特殊元素

15、之間的分類關系。聚合：表示類之間整體與部分的關系。聚合意味著一個類擁有但共享另一個類的對象。組合：特殊形式的聚合。一個部分類最多只屬于一個整體類，整體類不存在時，部分類將同時銷毀。9.了解類圖的基本建模步驟10.接口和抽象類的定義及各自的特點。（1）抽象類抽象類是指那些不具有任何對象的類，其作用是為其他的類描述它們的公共屬性和行為。通常，抽象類具有一組抽象操作。一個擁有至少一個抽象操作的類必定是一個抽象類。（2）接口接口是一組沒有實現的操作的集合。接口只提供操作的聲明，不提供任何相應的功能代碼。具體的功能代碼由使用該接口的類實現，這叫作實現關系。特點：接口只包含操作而不包含屬性，并且操作都是公

16、有的(public)，不允許使用可見性限定符。 接口不能自己實現其操作，而是由相應的類來實現。接口沒有構造函數和析構函數，不能直接被實例化一個類可以實現多個接口。（3）對比接口是一個不帶實現的類，它只規定類的外部特性，包括公共屬性、操作及其語義，因此只有操作聲明而沒有方法體和物理存儲區。抽象類和接口很相似，也只定義接口而推遲定義其實現部分，然而抽象類允許增加一些方法的實現。語義層面上：抽象類是一種類是對一組具有相同屬性和方法的邏輯上有關系的事物的一種抽象。而接口則是對一組具有相同屬性和方法的邏輯上不相關的事物的一種抽象。抽象類中可以有自己的數據成員，也可以有非abstract的成員方法。而接口

17、中的方法只能有靜態的不能被修改的數據成員抽象類表示的是一種繼承關系，一個類只能使用一次繼承關系。但是，一個類卻可以實現多個interface。抽象類中的方法可以有默認行為。但接口中的方法卻不能擁有默認行為。11.交互圖的分類：順序圖和協作圖，各自的優缺點。UML2.0中協作圖改成通信圖。交互圖描述一個交互，其中包括了一系列的對象及其關系以及通過這些關系在對象之間傳送的消息。（1）順序圖強調的是消息發送的時間的先后順序。組成部分：對象：序列圖中所包含的每個對象用一個對象框（短式）表示，對象名需帶下劃線。生存線：對象框下畫的一條垂直虛線，稱為該對象的生存線，表示對象的生存時間。激活期：對象生存線上

18、的一個細長方形框，表示該對象的激活時間段，即活動期間。消息：對象之間消息的發送和接收用兩個對象生存線（激活期）之間的消息箭頭線。（2）協作圖強調的是發送和接收消息的對象之間的組織結構。一個協作圖顯示了一系列的對象和在這些對象之間的聯系以及對象間發送和接收的消息。構成：對象；連接；在此連接上傳遞的消息（3）對比相同點：它們都表現出了對象之間的交互信息。兩個圖對象的繪制方式相同不同點：順序圖反映了對象之間交互的時間關系，而通信圖反映了對象之間交互的空間關系。順序圖用于展示特定的業務場景，而通信圖用來展示詳細的業務過程。順序圖的對象在圖形的頂部一字排開，而通信圖對象的擺放位置在二維空間只要選擇合適的

19、位置即可。通信圖不能表現組合片段。12.狀態圖和活動圖各自的作用。（注意活動圖中泳道的作用）（1）狀態圖狀態圖描述了一個對象或交互過程在它的生命周期中對一系列外界激勵的所呈現出的不同狀態以及它相應的響應和活動。狀態圖描述交互對對象內部的影響，交互圖中的消息在這里變成外部事件對對象發出的命令，對象對這些命令的響應導致對象的狀態發生變化。因此，從這個意義上說，狀態圖是順序圖的進一步細化，并且是對核心對象（選擇核心對象的依據是看是否在多個交互圖中有多個消息指向該對象）的細化。（2）活動圖在UML里, 用來為非反應型對象建模的狀態機被稱為活動圖。活動圖是一種特殊形式的狀態機，用于對計算流程和工作流程建

20、模。活動圖著重表現活動的控制流，描述在對象之間傳遞的操作泳道：活動圖可以用來表達軟件對象的比較復雜的動態行為。這些動態行為l 可能是模擬現實世界的某個機構的各業務部門的運作情況；l 也可能是一個復雜的算法，l 這算法可能需要由軟件系統中的多個協同共同實現。(協同指的是多個類的對象共同工作，以提供單個類的的對象單獨工作不能提供的動態行為)在UML里，對在語義上互相關聯的活動狀態的子集的劃分，是使用泳道(swim lane)實現的。泳道是活動圖里對其中的活動按照其職責上的關聯進行的劃分。泳道在活動圖內是一系列的垂直的隔斷。在活動圖里，泳道區分了其中的活動的不同職責。在有泳道的活動圖中，每一活動都屬

21、于且只屬于一個泳道。泳道之間可以有變遷的傳遞。泳道從語義上可以理解為是一個模型包。泳道可以有名字，以區分不同狀態集合的職責。泳道可以用在為復雜的算法進行建模的活動圖上。這時，一個泳道對應于一個協同，其中的活動可以由一個或多各互相連接的類的對象實現。帶有泳道的活動圖也可以在軟件開發的需求分析階段用來為業務部門的業務流程的建模上，這時，泳道可以代表業務流程中的一個業務部門。13.組件圖的作用以及組件與接口間的關系。組件是一個相對獨立的物理塊，是系統的一個物理和可替代的組成部分，一般作為一個獨立的文件存在。組件具有確定的借口，相互之間可以調用，組件之間存在依賴關系。組件圖的主要目的是顯示系統組件間的

22、結構關系。組件與接口：組件的一個重要特性就是實現了邏輯視圖中為軟件系統規定的設計詞匯的語義，語義除了靜態結構之外，即是其規定的動態行為。從組件外部來看，一個組件區分于另一個組件的的本質特征就是其動態行為。如果需要強調組件的動態行為，即組件為外部世界提供的服務，就可以使用接口。通過將軟件系統的劃分為不同的可執行組件，可以實現軟件系統的組件化。軟件系統在物理上由不同組件構成，有些組件向外部提供由接口規定的服務，有些組件使用這些服務。組件化的好處：組件是可替換的；邊界清晰；便于維護、升級；組件化的軟件系統可以是分布式的，不要求使所有組件都運行于一個結點一個組件實現了一個接口，被一個組件實現的接口是該

23、組件的實現接口。一個組件使用了另一個組件通過接口提供的服務，被一個組件調用的接口是該組件的輸入接口14.部署圖的作用以及節點的分類（1）部署圖（配置圖）是用來顯示系統中軟件和硬件的物理架構。從部署圖中，您可以了解到軟件和硬件組件之間的物理關系以及處理節點的組件分布情況。使用部署圖可以顯示運行時系統的結構，同時還傳達構成應用程序的硬件和軟件元素的配置和部署方式。部署圖描述了一個運行時的硬件結點，以及在這些結點上運行的軟件組件的靜態視圖。 部署圖顯示了系統的硬件，安裝在硬件上的軟件，以及用于連接異構的機器之間的中間件。（2）節點節點是運行時代表計算資源的物理元素。節點通常有內存及處理能力，它可以是

24、物理設備及運行在該設備上的軟件系統。節點分為處理機和設備處理機：能執行軟件、具備計算能力的節點，如主機、服務器、客戶機等設備：沒有計算能力的節點，如打印機、傳感器、終端等15.主要的面相對象設計原則及各自的原理：OCP,LSP,DIP,ISP,CARP,LoD設計原則名稱簡介里氏替換原則LSP任意父類可以出現的地方，子類也可以出現開閉原則OCP對擴展開發，對修改關閉單一職責原則SRP類的職責單一依賴倒轉原則DIP針對抽象（或接口）編程，而不針對具體編程接口隔離原則ISP使用多個專門接口要優于使用單一的接口組合聚合原則CRP優先使用組合或聚合關系，不要過于使用繼承關系迪米特原則LoD一個軟件實體

25、對其他實體的引用越少越好LSP李氏替換原則：如果在任何情況下，子類（或子類型）或實現類與基類都是可以互換的，那么繼承的使用就是合適的。為了達到這一目標，子類不能添加任何父類沒有的附加約束。OCP開閉原則：軟件實體（類、模塊、函數等）應該是可擴展的，但是不可修改的。SRP單一職責原則：規定一個類應該只有一個發生變化的原因。如果一個類承擔的職責過多，就等于把這些職責耦合在一起了。一個職責的變化可能會削弱或者抑制這個類完成其他職責的能力。這種耦合會導致脆弱的設計，當發生變化時，設計會遭受到意想不到的破壞。而如果想要避免這種現象的發生，就要盡可能的遵守單一職責原則。此原則的核心就是解耦和增強內聚性。I

26、SP接口隔離原則：客戶端不應該依賴它不需要的接口；一個類對另一個類的依賴應該建立在最小的接口上。為了避免“肥接口(fat interface)”，應當以一個類實現多個接口，而各客戶僅僅獲知必須的接口DIP依賴倒轉原則：程序要依賴于抽象接口，不要依賴于具體實現。簡單的說就是要求對抽象進行編程，不要對實現進行編程，這樣就降低了客戶與實現模塊間的耦合。CRP組合復用原則：繼承復用：實現簡單，易于擴展。破壞系統的封閉性，從基類繼承而來的實現是靜態的，不能在運行時動態改變，缺乏靈活性（即“白盒”復用）。組合/聚合復用：耦合度較低，可以靈活地選擇成員對象的操作；可以在運行時動態改變。（即“黑盒”復用）迪米

27、特原則：指一個軟件實體應該盡量少與其他實體發生相互作用。16.設計模式的內容和分類。（1）設計模是一套被反復使用、多數人知曉的、經過分類編目的、代碼設計經驗的總結。一個模式有四個基本要素：模式名稱、問題、解決方案、效果（2）分類創建型模式：抽象的實例化過程，隱藏了對象創建的具體細節，使程序代碼不依賴具體的對象。例：單例模式、抽象工廠模式、建造者模式、工廠模式、原型模式。結構型模式：描述類和對象之間通過組織形成新的結構，以實現新的功能。例：適配器模式、橋接模式、裝飾模式、組合模式、外觀模式、享元模式、代理模式。行為型模式：描述算法以及對象之間的任務（職責）分配及它們之間的通訊模式。例：模版方法模

28、式、命令模式、迭代器模式、觀察者模式、中介者模式、備忘錄模式、解釋器模式、狀態模式、策略模式、職責鏈模式、訪問者模式。17.設計模式與面向對象設計原則之間的關系，特別是OCP原則設計模式就是實現了面向對象原則，從而達到了代碼復用、增加可維護性的目的。18.了解常見設計模式的設計思想及其原理，了解如何從OCP的角度進行分析第六章設計系統1.概念設計和技術設計的內容概念設計：是由分析用戶需求到生成概念產品的一系列有序的、可組織的、有目標的設計活動，它表現為一個由粗到精、由模糊到清晰、由抽象到具體的不斷進化的過程。技術設計：對主要硬件部分及其功能的描述，確定設計軟件構件的層次和功能、數據結構和數據流

29、2.好的設計的衡量：內聚和耦合內聚是一個模塊內部各成分之間相關聯程度的度量。（高內聚）耦合是指對象之間的依賴性（低耦合），耦合性是程序結構中各個模塊之間相互關聯的度量。它取決于各個模塊之間的接口的復雜程度、調用模塊的方式以及哪些信息通過接口。3.常用的內聚和耦合度類型（1）內聚類型低高：功能內聚、信息內聚、通信內聚、過程內聚、時間內聚、邏輯內聚、偶然內聚（2）耦合類型高低：內容耦合、公共耦合、外部耦合、控制耦合、標記耦合、數據耦合、非直接耦合第七章測試1.測試的目標和衡量標準目標：發現錯誤，只有當發現了錯誤時，測試才被認為是成功的。衡量標準：需求的覆蓋率；缺陷數量；缺陷重現率；效率；重用價值。

30、2.測試的分類（或組織）。各種類型的測試的主要任務及所依賴的文檔。模塊、構件、單元測試：對軟件中的最小可測試單元進行檢查和驗證，目的是檢驗軟件基本組成單位的正確性。集成測試：在單元測試的基礎上，將所有模塊按照設計要求組裝成為子系統，進行集成測試。目的是檢查軟件單位之間的接口是否正確。功能測試：對產品的各功能進行驗證，根據功能測試用例，逐項測試，根據需求文檔檢查產品功能完整性。性能測試：檢查系統的響應速度，結果精確性和數據的可訪問性驗收測試：指確認系統是否符合設計規格或契約之需求內容的測試安裝測試：確保該軟件在正常情況和異常情況的不同條件下，安裝后的正常運行。3.黑盒測試和白盒測試的思想，了解白

31、盒測試中的基本路徑測試等方法。（1）黑盒測試也稱功能測試，它是通過測試來檢測每個功能是否都能正常使用。在測試中，把程序看作一個不能打開的黑盒子，在完全不考慮程序內部結構和內部特性的情況下，在程序接口進行測試，它只檢查程序功能是否按照需求規格說明書的規定正常使用，程序是否能適當地接收輸入數據而產生正確的輸出信息。黑盒測試著眼于程序外部結構，不考慮內部邏輯結構，主要針對軟件界面和軟件功能進行測試。（2）白盒測試又稱結構測試，是全面了解程序內部邏輯結構、對所有邏輯路徑進行的測試。"白盒"法是窮舉路徑測試。在使用這一方案時，測試者必須檢查程序的內部結構，從檢查程序的邏輯著手，得出測

32、試數據。（3）基本路徑測試基本路徑測試法是在程序控制流圖的基礎上，通過分析控制構造的環路復雜性，導出基本可執行路徑集合，從而設計測試用例的方法。設計出的測試用例要保證在測試中程序的每個可執行語句至少執行一次。在程序控制流圖的基礎上，通過分析控制構造的環路復雜性，導出基本可執行路徑集合，從而設計測試用例。4.單元測試的主要內容。包括模塊接口測試、局部數據結構測試、路徑測試、錯誤處理測試、邊界測試5.集成測試的類型及主要的測試策略。（1）類型自底向上：從軟件結構中最底層、最基本的軟件單元開始進行集成和測試自頂向下：一個模塊一個模塊地集成軟件，按照控制的結構，從主控模塊開始，向下逐個把模塊連結起來。

33、一次性測試；三明治測試：混合上下（2）策略非增量式：先測試好每一個軟件單元，然后依次集成在一起再測試整個程序。增量式：逐步把一個要被集成的軟件單元或不見，同已測試好的軟件部件結合起來測試。好處：占用人工、時間少，能較早發現模塊錯誤，利于并行開發。6.確認測試的內容。包括：安裝測試、功能測試、性能測試、安全性測試、兼容性測試、可使用性測試、文檔測試7.了解測試計劃的主要內容。測試計劃，描述了要進行的測試活動的范圍、方法、資源和進度的文檔；是對整個信息系統應用軟件組裝測試和確認測試。它確定測試項、被測特性、測試任務、誰執行任務、各種可能的風險。測試計劃可以有效預防計劃的風險，保障計劃的順利實施。8

34、.測試系統中的測試過程：功能測試、性能測試、驗收（確認）測試、安裝測試，及他們的內容第八章系統維護1.維護活動的類型：改正性、適應性、完善性、預防性2.各種維護活動的主要內容和目標改正性維護（17%-21%）：改正在系統開發階段已發生而系統測試階段尚未發現的錯誤。適應性維護（18%-25%）：指使用軟件適應信息技術變化和管理需求變化而進行的修改。完善性維護（50%-60%）：為擴充功能和改善性能而進行的修改，主要是指對已有的軟件系統增加一些在系統分析和設計階段中沒有規定的功能與性能特征。另外還包括處理效率和編寫程序的改進。預防性維護（4%）：為了改進應用軟件的可靠性和可維護性，適應未來軟硬件環境的變化，主動增加預防性的新的功能。3.軟件再生：文檔重構、重組、逆向工程、再工程，以及它們各自的內容和含義。文檔重構：對源代碼進行靜態分析，給出更多的信息重組：改變代碼結構逆向工程：根據代碼重新創建設計和規格說明信息再工程：對現有工程進行逆向工程，接著再改變規格說明和設計以完成邏