僅供參考 ，不可轉載
有任何問題可以留言給小編，謝謝！！！
第一章 緒論
-
每18個月芯片的性能和速度均提高一倍，每隔12年軟件生產大約提高一倍。
-
軟件：是能夠完成預定功能和性能的可執行的計算機誠信度。包括使程序正常執行所需的數據，以及有關描述程序操作和使用的文檔。即：軟件 = 程序 + 文檔
-
軟件的特徵：
軟件的開發不同於硬件設計、不同於硬件製造、不同於硬件維修。 -
軟件危機出現的原因：
軟件維護費用的急劇上升，直接威脅計算機應用的擴大；
軟件生產技術進步緩慢，是家居軟件危機的重要原因。 -
軟件工程學的範疇：
軟件開發技術（軟件開發方法學、軟件工具、軟件工程環境）、軟件工程管理（軟件管理學、軟件經濟學、度量學）。 -
軟件工程：是指導計算機軟件開發和維護的工程學科。它採用工程的概念、原理、技術和方法來開發與維護軟件，目的是爲了實現按照預期的進度和經費完成軟件生產計劃，同時提高軟件的生產率和可靠性。
-
軟件的發展：大體經歷了 程序、軟件、軟件產品 3個階段。
-
工具 和 方法 是軟件開發技術的2大支柱。
-
3種編程泛型：
過程式編程泛型、面向對象編程泛型、基於構件技術的編程泛型
差異：過程式編程泛型是着眼於程序的過程和基本控制結構，粒度最小。
面向對象編程泛型：着眼於程序對象，粒度較大
基於構件技術的編程泛型：着眼於整個領域的類對象，粒度最大 -
面向對象程序設計中，數據和操作被封裝在一個對象中，對象之間則是通過消息相互聯繫。
-
構件：標準化/規格化的對象類。
-
常用變成力度的大小來比較3種編程泛型的差異。
粒度由小到大依次是：過程式編程範式、面向對象編程範式、基於構件的編程泛型。 -
軟件工程的分化（3代）：
傳統軟件工程：結構化分析-》結構化設計-》面向過程編碼-》軟件測試
面向對象軟件工程：OO分析與對象抽取-》對象詳細設計-》面向對象的編碼與測試
基於構件的軟件工程（以可複用構件和測試工具爲後盾）：
領域分析和測試計劃定製-》領域設計-》建立可複用構件庫-》按‘構件集成模型’查找與集成構件 -
軟件工程的分化：
傳統軟件工程：結構化分析-》結構化設計-》面向過程編碼-》軟件測試
面向對象軟件工程：OO分析與對象抽取-》對象詳細設計-》面向對象的編碼與測試
基於構件的軟件工程（以可複用構件和測試工具爲後盾）：
領域分析和測試計劃定製-》領域設計-》建立可複用構件庫-》按‘構件集成模型’查找與集成構件 -
分析先於設計，設計先於編碼，使程序（的結構）適合於問題（的結構）。
第二章 軟件生存週期與軟件過程 -
軟件生存週期：計劃、開發、運行3個時期。
需求分析-》軟件分析-》軟件設計-》編碼測試-》軟件測試-》運行維護 -
軟件生存週期：計劃、開發、運行3個時期。
需求分析-》軟件分析-》軟件設計-》編碼測試-》軟件測試-》運行維護
需求分析（用戶視角）：功能需求、性能需求、環境約束、外部接口描述。
軟件分析（開發人員視角）：建立與需求模型一致的，與實現無關的軟件分析模型。
軟件設計：總體設計/概要設計、詳細設計（確定軟件的數據結構和操作）。
編碼測試：把設計文檔翻譯爲源程序。單元測試通常與編碼同時進行。
軟件測試：是提高軟件質量的重要手段
軟件測試：單元測試、集成測試、系統測試。
運行維護：做好軟件維護，使軟件在整個生存週期內都能瞞住用戶的需求，並延長其使用壽命。 -
單元測試通常與編碼同時進行。
-
軟件測試：單元測試、集成測試、系統測試。
-
Boehm軟件生存週期的劃分：系統需求、軟件需求、概要設計、詳細設計、編碼糾錯、測試和預運行、系統維護。
-
瀑布模型 特點：階段間的順序性和依賴性、推遲實現的觀點、保證質量的觀點。
-
瀑布模型存在的問題：只有在需求分析準確的前提下，才能得到預期的結果。
快速原型模型：原型系統只包括對未來系統的主要功能以及系統的重要接口。特點：快速開發工具、循環、低成本。種類：漸進型、拋棄型。 -
常見的演化模型（漸增式、迭代式）：增量模型、螺旋模型。
-
增量模型：結合瀑布模型的順序特徵與快速原型法的迭代特徵。增量：小而可用的軟件
一般情況下，第一個增量是軟件的核心部分。如（增量一：需求-設計-實現和集成-交付客戶） -
螺旋模型（目前最常用）：當項目按照順時針方向沿螺旋線移動時，每輪螺旋包含：計劃、風險分析、建立原型、用戶評審 4種活動。（高風險的大型軟件採用此方法）
-
構件集成模型：適應於面向對象的軟件開發。利用預先封裝好的構件來構造應用軟件系統。
-
軟件開發方法可區分：形式化方法、非形式化方法。
-
形式化開發模型：轉換模型、淨室模型
-
轉換模型：是將形式化軟件開發和程序自動生成技術相結合的一種軟件開發模型。
轉換模型的開發過程：確定性實話的需求規格說明書、進行自動化的程序變換、對形式化開發記錄進行測試。
轉換模型的常用技術：
基於模型的需求規格說明書及其變換技術；
基於代數結構的需求規格說明書及其變換技術；
基於時序邏輯的需求規格說明書及其驗證技術以及基於可視化的技術。 -
淨室模型：是一種形式化的增量開發模型。力求在分析和設計階段消除錯誤。
-
統一過程RUP 包括 4 個階段：初始、細化、構造、遷移。以用例爲驅動, 以系統架構爲中心的迭代與增量過程。每個階段又分爲若干次迭代，每次迭代都有一個核心工作流，有5 個活動（需求、分析、設計、實現、測試）。
-
敏捷開發是一種以人爲核心、迭代、循序漸進的開發方法。
-
敏捷開發的價值觀：個體和交互勝過過程和工具、可以工作的軟件勝過面面俱到的文檔、客戶合作勝過合同談判、響應變化勝過遵循計劃。
-
軟件可行性研究：經濟可行性、技術可行性、運行可行性、法律可行性。
-
可行性研究的步驟：對當前系統進行調查研究、導出新系統的解決方案、提出推薦方案、編寫可行性論證報告。
-
可行性論證報告的內容：系統概述、可行性分析、結論意見。
-
軟件風險分析包括：風險識別（項目風險、技術風險、商業風險）、風險預測、風險的駕馭和監控。
-
軟件計劃的7種類型：項目實施計劃、質量保證計劃、軟件測試計劃、文檔編制計劃、用戶培訓計劃、綜合支持計劃、軟件分發計劃。
-
風險預測：又稱風險估計，一般包括兩方面的內容：（1）風險發生的可能性（2）風險發生後所產生的的後果
1> 建立風險可能性尺度
2> 估計對產品和項目的影響
第三章 結構化分析與設計 -
結構化設計 SD ； 結構化分析 SA ； 軟件需求規格說明書 SAS ； 結構圖 SC ；數據字典 DD ；
狀態轉換圖 STD ； 數據流圖 DFD -
瀑布模型的生命週期：需求定義與分析-》總體設計-》詳細設計-》編碼-》測試-》維護
-
系統的開發流程（SA和SD流程）：
結構化分析（工具：DFD，PSPEC） ------》分析模型（分層DFD圖）+SRS
結構化設計（工具：SC圖） （映射）------》初始設計模型（初始SC圖）
初始設計模型（初始SC圖） （優化）------》最終設計模型（最終SC圖） -
結構化分析的基本步驟：自頂向下，功能分解（分層DFD）、由後向前，定義數據和加工（DD, PSPEC）、根據需要，分析複雜數據和動態模型（E-R圖，CFD,CSPEC,STD）、編寫軟件需求規格說明書SRS。
-
SA需求分析的兩項基本任務：建立系統分析模型、編寫SRS。
-
分析模型組成：功能模型、數據模型、行爲模型 3種。
-
抽象 和 分解 是結構化分析的主要指導思想，細化的實質是分解。分解 和 細化 是軟件設計的策略。
-
SD階段把分析模型中的DFD圖轉換爲 最終SC圖。
-
傳統軟件的開發技術：結構化設計、模塊設計。
-
軟件設計：總體設計/概要設計（初始SC圖、最終SC圖）、詳細設計（用逐步細化的方法，完成模塊的說明）。
-
需求分析的步驟：需求獲取、需求提煉、需求描述、需求驗證。
-
SA模型的組成
-
SA模型同時覆蓋了信息模型、功能模型、行爲模型 3種模型。
-
DFD圖不能表示程序的控制結構（如選擇、循環結構）。
-
加工規格說明通常用結構化語言、判定表、判定樹作爲描述工具。
-
軟件中的數據分爲3類：數據項（數據元素）、數據流（多個相關數據項）、數據文件和數據庫。
-
數據字典的組成：數據項、數據流、數據存儲(文件或數據庫)、加工(處理邏輯)、外部項(人、物或其它軟件系統)。
-
SD模型是由SA模型映射而來的。
SA模型的數據字典可轉換爲待開發系統的數據設計
數據流圖可轉換爲體系結構設計（SC圖）與接口設計
加工規格說明可轉換爲模塊內部的詳細過程設計 -
SD模型的組成：從上到下依次是：過程設計、接口設計、體系結構設計、數據設計。
-
結構化分析的基本步驟：
自頂向下對系統進行功能分解，畫出DFD圖；由後向前定義系統的數據和加工；編制DD和PEPES；寫出SRS。 -
把不需要分解的加工成爲基本加工。把逐步分解成爲“自頂向下，逐步細化”。
-
DFD的優點：便於實現，便於使用。
-
傳統的軟件設計可細分爲:面向數據流設計（SD方法）、面向數據結構設計（Jackson方法）。
-
用數據流圖表示邏輯模型，在設計階段，按照數據流圖的不同類型（變換型、事務型）轉換爲相應的軟件結構。
-
結構化設計通常從DFD圖到SC圖的映射開始。
-
面向數據流的設計方法：從DFD圖到SC圖的映射的4個步驟 ：
複審DFD圖，必要時可再次進行修改或細化；
鑑別DFD圖的結構特徵:事務？變換？；
按照規則，把DFD圖爲初始的SC圖 ；
改進初始的SC圖 。
27. 變換型結構：由輸入、變換中心和輸出三部分組成。
事務型結構：具有在多種事務中選擇執行某類事物的能力。
28. 變換映射的步驟：劃分DFD圖的邊界、建立初始SC圖的框架、分解SC圖的各個分支。
事務映射的步驟：在DFD圖上確定邊界、畫出SC圖框架、分解和細化接受分支和發送分支。
29. 優化結構設計的指導規則：對模塊分割、合併和變動調用關係的指導規則、保持高扇入/低扇出的原則、作用域/控制域規則。
30. 模塊設計（詳細設計）的主要任務是編寫軟件的模塊設計說明書。目的是確定模塊採用的算法和塊內數據結構。
31. 模塊設計的原則：清晰第一的設計風格、結構化的控制結構、逐步細化的實現方法。
32. “結構化”保證程序的清晰、易讀,“逐步細化”實現程序的正確、可靠。
33. 結構化程序設計原理和逐步細化的實現方法是完成模塊設計的基礎。
第四章 面向對象和UML
-
面向對象的基本特徵：抽象、封裝、集成、多態。
-
面向對象開發的優點：提高軟件系統的可複用性、可擴展性、可維護性。
-
元素之間的聯繫有：關聯、泛化、依賴、實現、聚集、組合。
-
UML的4個抽象層次：用戶模型、模型、元模型、元元模型。
-
UML的模型元素：1、一類模型元素用於表示模型中的某個概念2、另一類用於表示模型元素之間相互連接的關係。
-
UML的2類圖：
靜態圖（用例圖、類圖、對象圖、構件圖、部署圖）；
動態圖（狀態圖、時序圖、協作圖、活動圖）
5種視圖：用例視圖、邏輯視圖、進程視圖、構件視圖、部署視圖。 -
UML的特點：同意標準、面向對象、表達能力強，可視化。
-
UML模型作爲測試階段的依據：
單元測試使用類圖和類規格說明；集成測試使用構件圖和協作圖；系統測試使用用例圖來驗證系統行爲。 -
UML靜態建模機制包括：用例圖、類圖、對象圖構件圖、部署圖。
用例圖有：系統邊界、用例、參與者、關聯等。用例之間存在的關係：擴展關係、包含關係。
包與包之間的關係有：依賴、泛化。 -
UML動態建模機制包括：狀態圖、時序圖、協作圖、活動圖。
-
消息：簡單消息、同步消息、異步消息。狀態圖有：初態、終態、中間態。
-
時序圖中的消息可以是信號或操作調用。
-
狀態圖用來描述一個特定對象的所有可能狀態以及引起其狀態轉移的時間。一個狀態圖包括一系列的狀態以及狀態之間的轉移。（狀態、狀態轉移、事件、在狀態圖之間發送消息）一個對象 多個對象的使用 《活動圖》
-
時序圖着重體現交互的時間順序；協作圖着重體現交互對象間的靜態鏈接。
-
時序圖和協作圖適合描述單個用例中幾個對象的行爲；活動圖適合表現跨越多用例或多線程的複雜行爲。
-
構件圖可以用來表現、編譯、鏈接、執行時構件間的依賴關係。
-
UML用圖表示語法，用元模型表示語義，採用模型來描述系統的結構（靜態特徵）以及行爲（動態特徵）。
第五章 需求工程和需求分析 -
軟件需求的3個層次：業務需求、用戶需求、功能需求。軟件項目中40%~60%的問題源自軟件需求階段。
-
軟件需求的6個特性：功能性、可用性、可靠性、性能、可支持性、設計約束。
-
功能性：普通功能、全局性功能。
-
軟件需求工程：是一門應用有效的技術和方法，合適的工具和符號來確定、管理和描述目標系統及其外部行爲特徵的學科。
-
需求分析的步驟：需求獲取、需求建模、需求描述（編寫SRS）、需求驗證。
-
需求分析的主要任務：建立需求模型。需求分析是迭代過程。
常見模型有：用例圖、數據流圖、實體聯繫圖、控制流圖、狀態轉換圖。 -
需求建模方法：結構化分析建模方法、面向對象分析建模。
-
結構化需求模型由3部分組成：功能模型（數據流圖、加工規格說明書）、數據模型（數據字典、ER圖）、行爲模型（狀態轉換圖、控制流圖、控制規格說明書）。
-
面向對象需求模型：用例模型（用例圖、用例規約）、補充規約、術語表。
-
面向對象需求建模的步驟：畫用例圖、寫用例規約、描述補充規約、編寫術語表。
-
用例規約文檔的內容：簡要說明、事件流、特殊需求、前置條件和後置條件。
-
用例規約的檢查：功能需求的完備性、模型是否易於理解、是否存在不一致性、避免二義性。
-
軟件需求規格說明書SRS的內容：引言、信息描述、功能描述、行爲描述、質量保證、接口描述、其他描述。
-
質量保證闡明軟件交付前進行功能測試、性能測試。接口描述包括系統用戶界面、硬件接口、軟件接口、通信接口。
-
需求管理的流程：需求確認（需求評審和需求承諾）、需求跟蹤、需求變更。需求跟蹤有兩種方式，正向跟蹤與逆向跟蹤。
需求變更的流程：變更申請、審批、更改、更新確認。 -
需求管理的5個特定實踐：
-
基線(Baseline) 是軟件文檔或源碼(或其它產出物)的一個穩定版本,它是進一步開發的基礎。
-
需求變更管理：需求變更通常按變更申請->審批->更改->重新確認的流程進行
第六章 面向對象分析 -
面向對象分析OOA的建模步驟：需求理解、定義類和對象、標識對象的屬性和操作、標識類的結構和層次、建立對象-關係模型、建立對象-行爲模型、評審OOA模型。
-
分析類：邊界類、控制類、實體類
-
OOA的優點：同時加強了對問題空間和軟件系統的理解；改進包括用戶在內的軟件分析有關的各類人員之間的交流；對需求的變化具有較強的適應性；很好的支持軟件複用；確保從需求模型到設計模型的一致性。
-
分析模型(是一種概念模型)的特點：全面覆蓋軟件的功能需求；分析模型與軟件的實現無關；分析模型的表述方法與所採用的分析技術有關。
-
典型的五層次模型：建立類/對象層（抽象出類和對象）、建立屬性層（設計靜態屬性和關係）、建立服務層（定義動態屬性和消息通信）、建立結構層（定義層次結構關係）、建立主題層（每個主題構成一個子系統）。
-
OOA方法的共同特徵：類和類層次的表示、建立對象-關係模型、建立對象-行爲模型。
-
建立對象-行爲模型（1、時序圖2、協作圖3、爲分析類分配職責4、狀態圖）
-
建立對象-關係模型（1、分析類的屬性2、分析類的關聯3、分析類圖4、分析類的合併）
-
面向對象開發的全過程：OOA（分析）、OOD（設計）、OOP（編碼）、OOT（測試）。
-
從建立需求到開發軟件成品先後要生成分析、設計、實現3種模型。
-
用例模型是面向對象分析最常用的一種模型。
-
用例分析的步驟：補充用例規約、研究用例的事件流，將用例的職責分配給若干分析類、分析類之間的協作。
-
分析類的類型：邊界類、控制類、實體類。
-
邊界類包括：用戶界面類、系統接口類、設備接口類。如事務管理器、資源協調器、錯誤處理器都可爲控制類。
-
爲分析類分配職責是OOD的重點。實體類具有持久性。
-
對象-關係模型的內容：分析類的屬性、分析類的關聯、分析類圖、分析類的合併。
-
時序圖中的元素有：對象、對象生命線、消息。協作圖中的元素有：對象、鏈接、消息流。
-
面向對象分析的任務是：將需求階段產生的需求模型 轉換爲 軟件分析模型。
面向對象設計的任務是：將分析階段建立的分析模型 轉換爲 軟件設計模型。
第七章 面向對象設計 -
軟件設計的基本概念：模塊（定義輸入、輸出和特性的程序實體）與構件、抽象與細化、信息隱藏、軟件複用。
-
軟件設計的基礎：分析階段對目標系統的數據、功能、行爲建模。
-
軟件設計包括：數據設計、體系結構設計、接口設計、過程設計。
-
分解和模塊獨立性是實現模塊設計的重要指導思想。
-
模塊數與開發工作量的關係：
-
概要設計(總體設計)：包括軟件的結構和接口設計，並編寫概要設計文檔。詳細設計，確定模塊內部的算法和數據結構，產生描述各模塊程序過程的詳細文檔。每個階段完成的文檔都必須經過複審。
-
模塊的獨立性從2個方面度量：模塊本身的內聚、模塊之間的耦合。
-
內聚分類：低內聚（偶然性內聚、邏輯性內聚、時間性內聚）、中內聚（過程性內聚、通訊性內聚）、高內聚（順序性內聚、功能性內聚）。
-
高內聚低耦合
-
耦合分類：弱耦合（非直接耦合、數據耦合、特徵耦合）、中耦合（控制耦合）、較強耦合（外部耦合、公共耦合）、強耦合（內容耦合）。
-
一個模塊，一個功能 是模塊化設計的一條準則。
-
OO設計模型由系統架構層、類和對象層、消息層、責任層4個層次組成。
-
面向對象設計中，數據和過程被封裝爲類/對象的屬性和操作；接口被封裝爲對象間的消息，而體系結構的設計則體現爲系統的技術基礎設施和具有控制流程的對象間的協作。
-
OOD的軟件設計可劃分爲2個層次：系統架構設計、系統元素設計。
-
系統架構設計的內容：系統高層結構設計、確定設計元素、確定任務管理策略、實現分佈式機制、設計數據存儲方案、人機界面設計。系統元素設計的內容：子系統設計、分包設計、類/對象設計。
-
軟件模式分類（按抽象級別）：架構模式、設計模式、習慣用法。
-
常用的架構模式有：層次架構、模型-視圖-控制架構、管道-過濾器架構、黑板架構。
-
層次架構的基本原則：將系統劃分不同的層次。確定設計元素的主要工作是：確定設計類、子系統、子系統接口。
-
面向並行需求的技術：引進任務管理部件、基於進程和線程的控制。
-
任務管理策略：多處理機方案、操作系統方案、應用程序方案。
-
設計管理併發任務對象的策略：確定任務的特徵、定義一個協調者任務和與之關聯的對象、集成其它任務和協調者。
-
面向對象設計的任務：1、系統架構設計（指系統主要組成元素的祖師或結構，以及其他全局性決策，組成元素之間通過接口進行交互）6個活動（1、系統高層結構設計2、確定設計元素3、確定任務管理策略4、實現分佈式機制5、設計數據存儲方案6、人際界面設計）2、系統元素設計（系統元素包括組成系統的類、子系統與接口、包等）設計的內容爲：（1、類/對象設計2、子系統設計3、包設計）
-
任務管理部件的設計步驟：識別由事件驅動和時間驅動的任務、識別關鍵性任務，任務優先級和任務管理類、定義任務、必要時擴充有關任務的類和對象。
-
軟件模式的分類：架構模式、設計模式、習慣用法
-
任務管理3中解決方案：1、多處理器方案2、操作系統方案3、應用程序方案
-
分包的原則：將邊界類打包、將功能相關的類打包。高內聚-低耦合的原則，包之間的耦合表現爲依賴關係。
-
類設計的步驟：創建初始設計類、定義操作、定義方法、定義狀態、定義屬性、定義依賴關係、定義關聯關係、定義泛化關係、處理非功能性需求。
-
子系統設計的具體步驟：將子系統行爲分配給子系統元素、描述系統元素和說明子系統依賴關係
-
面向對象設計的任務：系統架構設計，系統高層結構設計、確定設計元素、確定任務管理策略、實現分佈式機制、設計數據存儲方案、人機界面設計。系統元素設計的內容：子系統設計、分包設計、類/對象設計。
-
軟件模式分類（按抽象級別）：架構模式、設計模式、習慣用法。
-
任務管理策略：多處理機方案、操作系統方案、應用程序方案。
第八章 編碼和測試 -
選擇編碼語言的標準：應用領域、算法與設計複雜性、數據結構的複雜性、效率的考慮。
-
測試和糾錯：
測試（testing）的目的與任務：目的：發現程序的錯誤；任務：通過執行程序，暴露潛在的錯誤。
糾錯（debugging）的目的與任務：目的：定位和糾正錯誤；任務：消除軟件故障，保證程序的可靠運行。 -
軟件:待測軟件，包括軟件需求規格說明書、設計說明書和源程序代碼等文檔資料。
測試配置:包括測試計劃、測試用例和測試期望結果。
評價:將測試結果和期望的結果相比較，如果不符就意味着錯誤，需要糾正(糾錯)。
可靠性:對測試結果進行收集和評價，得到可靠性的相關指標。 -
如果出現規律性、嚴重性的錯誤，軟件質量可靠性值得懷疑，需進一步測試；
-
如果軟件功能完成較好，出現的錯誤也易糾正，那麼：或者軟件質量和可靠性是可以接受的；或者未發現錯誤，不排除測試配置考慮不周，可能潛伏着的錯誤。
軟件測試的階段並解釋：（生命週期）
一、單元測試
單元測試：單元測試又稱模塊測試，是就是對程序代碼中最小的涉及模塊單元進行測試。目的是檢測軟件模塊單元的
測試方法：靜態測試、動態測試
單元測試的階段：模塊接口測試 、路徑測試、錯誤處理測試、邊界條件測試
二、集成測試
集成測試：集成測試又稱組裝測試，是將軟件產品各個模塊組裝起來，目的是檢驗軟件接口中是否正確性，以及組裝後的整體功能、性能表現。
測試方法：非增式集成方法、增式集成方法（自底向上集成、自頂向下集成、組合方式集成）等策略進行測試，利用黑盒測試爲主，白盒測試爲輔的測試方法進行測試。
三、系統測試
系統測試：系統測試是對已經集成的好的系統進行徹底的測試，以驗證軟件系統的正確性和性能是否滿足其所指定的要求。
測試方法：黑盒測試
系統測試階段：
一般系統的主要測試工作都集中系統測試階段。根據不同的系統，所進行的測試種類也很多。
功能測試： 性能測試：安全測試：兼容測試： 安裝卸載測試：
四、驗收測試
驗收測試：驗收測試是部署軟件的最後的一個測試操作，驗收測測試的目的是確保軟件的準備就緒，向軟件購買展示軟件系統滿足其用戶的需求。
五、迴歸測試：
迴歸測試是在軟件維護階段，對軟件進行修改之後進行的測試。其目的是檢驗對軟件進行的修改是否正確。
黑盒測試：只把軟件測試看作一個黑盒子，我們不關心盒子的是什麼的樣子，只關心軟件輸入的數據和輸出的結果。
它只檢查程序功能是否按照需求規格說明書的規定正常使用，程序能否接收輸入數據而產生正確的輸出信息。
黑盒測試着眼於程序外部結構，不考慮內部邏輯結構，主要針對軟件界面和軟件功能進行測試。
白盒測試：把盒子蓋子打開，去研究裏面的源代碼和程序結果 -
模塊邏輯中採用單入口、單出口標準結構、避免使用容易引起混淆的結構和語句、嵌套深度不超過3—4層。
-
測試的特性：挑剔型、複雜性、不徹底性、經濟型。
-
測試分類：靜態分析（靜態分析器分析、代碼評審（代碼會審、走查、辦公桌檢查））；
動態測試（黑盒測試（功能測試）、白盒測試（結構測試））。 -
測試文檔內容：測試計劃、測試報告。測試計劃的主體是測試內容說明：測試項目名稱、測試目的、步驟和進度、測試用例設計。測試報告的主題是測試結果：測試項目名稱、實測結果和期望結果的比較、發現問題、測試效果。
-
黑盒測試分類：等價類法、邊界值法、錯誤猜測法。
-
白盒測試分類：路經測試（點覆蓋、邊覆蓋、路徑覆蓋）、邏輯覆蓋測試（語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、條件組合覆蓋）。
-
路徑測試法：1、程序圖
-
(2)路經測試的特徵：滿足結構測試的最低要求、有利於安排循環測試。
-
(3)選擇測試路徑的原則：1、選擇具有功能含義的路徑2、儘量用短路徑替長路徑3、從上一條測試路徑到下一條測試路徑，應儘量減少變動的部分（包括變動的邊和結點）4、由簡到繁，如果可能，應考慮不含循環的測試路徑，然後補充對循環的測試5、除非不得已（如爲了要覆蓋某條邊），不要選取沒有明顯功能含義的複雜路徑。
-
V(G)=判定結點+1（區域數）
-
測試的層次性（單元測試（編譯、靜態分析器檢查、代碼評審、動態測試）、集成測試（目的和任務、策略與步驟（自頂向下測試、有底向上測試、混合方式測試））、高級測試）
-
路經測試的特徵：滿足結構測試的最低要求、有利於安排循環測試。
-
2種OO集成測試策略：基於線程的測試、基於使用的測試。
題目1：多模塊程序的測試有哪些層次？各層測試主要解決什麼問題？
解答：
多模塊測試的層次 所處時段 解決的問題 涉及測試方法 成果
單元測試/模塊測試 編碼階段 1. 對模塊代碼進行編譯，發現並糾正其語法錯誤； -
進行靜態分析，驗證模塊結構及其內部調用序列是否正確；
-
確定模塊的測試策略，並據此設計一組測試用例和必要的測試軟件；
-
用選定的測試用例對模塊進行測試，直至滿足測試終止標準爲止；
-
注重執行路徑、出錯處理路徑、局部數據結構、模塊的對外接口的測試
-
編制單元測試報告。 黑盒測試——程序外部測試、功能性測試 測試報告
白盒測試——程序內部測試、覆蓋測試
集成測試 集成測試階段 1. 制訂集成測試實施策略 -
確定集成測試的實施步驟，設計測試用例
-
逐一地添加模塊，進行測試 模塊（子系統或小系統）集成測試；訓練驅動與樁的設計、組合及集成測試。 已組裝軟件
高
級
測
試 確認測試 集成測試階段 1. 進一步驗證軟件的有效性，即驗證軟件的功能和性能是否與用戶的要求一致 已確認軟件
系統測試 驗收階段 1. 測試是否與硬件協調運行
2. 測試是否和原來就有的其它軟件協調運行
3. 測試是否完成SRS對它的要求 系統的性能檢驗和軟件系統實時運行狀況的測試 可運行的系統
題目1：軟件維護有哪些種類？他們的目標分別是什麼？
解答：軟件維護的種類以及對應目標依次是:
a) 完善性維護
在軟件漫長的運行時期中,用戶往往會對軟件提出新的功能要求與性能要求。爲了適應這些變化,應用軟件原來的功能和性能需要擴充和增強。這種增加軟件功能、增強軟件性能、提高軟件運行效率而進行的維護活動稱爲完善性維護。
b) 適應性維護
讓軟件適應運行環境的改變而進行的一種維護。
c) 糾錯性維護
糾正在開發期間未能發現的遺留錯誤。
d) 預防性維護
爲了提高軟件的可維護性和可靠性而對軟件進行的修改稱爲預防性維護。
題目2：軟件配置管理的主要功能是什麼？
解答：系統的管理軟件系統中的多重版本；
全面記載系統開發的歷史過程，包括爲什麼修改，誰做了修改，修改了什麼；
管理和追蹤開發過程中危害軟件質量以及影響開發週期的缺陷和變化；
輸入數據 有效等價類 無效等價類
地區碼 1、 空
2、 3位數字 3、 非空，但有非數字字符
4、 非空，位數小於3位數字
5、 非空，位數多於3位數字
電話號碼前三位 6、非‘000’且非‘111’的3位數字 7、空
8、非空，但有非數字字符
9、非空，位數小於3位數字
10、非空，位數多於3位數字
電話號碼後四位 11、任意4位數字 12、空
13、非空，但有非數字字符
14、非空，位數小於4位數字
15、非空，位數多於4位數字
對開發過程進行有效的管理和控制。
表7.1 “電話號碼”的等價分類
表7.2 有效等價類的測試用例
測試數據 期望結果 測試範圍
地區碼 號碼前三位 號碼後四位
NULL 123 4567 輸入有效 1、6、11
010 234 5678 輸入有效 2、6、11
表7.3 無效等價類的測試用例
測試數據 期望結果 測試範圍
地區碼 號碼前三位 號碼後四位
#1* 123 4567 地區碼輸入無效 3、6、11
01 234 5678 地區碼輸入無效 4、6、11
0123 258 8888 地區碼輸入無效 5、6、11
NULL NULL 8888 號碼前三位輸入無效 1、7、11
010 #1* 6666 號碼前三位輸入無效 1、8、11
020 45 6688 號碼前三位輸入無效 1、9、11
NULL 789 8866 號碼前三位輸入無效 1、10、11
NULL 666 NULL 號碼後四位輸入無效 2、6、12
010 888 *02# 號碼後四位輸入無效 2、6、13
020 688 23 號碼後四位輸入無效 2、6、14
NULL 866 45678 號碼後四位輸入無效 2、6、15
閱讀下列程序：
PROCEDURE SAMPAL (A，B：REAL； VAR X：REAL);
BEGIN
IF (A>3) AND (B=2)
THEN X:=X/A
IF (A=6) OR (X>4)
THEN X:=X+1
END;
爲上述程序設計測試用例（參考教材相關例題）。
實驗要求：形成相應的實驗報告。包括：
1、 畫出程序流程圖，程序圖
2、 實現語句覆蓋用例設計
3、 實現判定覆蓋用例設計
4、 實現條件覆蓋用例設計
5、 實現判定/條件覆蓋用例設計
6、 實現條件組合覆蓋用例設計
7、 實現路徑覆蓋用例設計（完全覆蓋）。
第一部分:程序流程圖、程序圖
設本例中的兩個判斷IF (A>3) AND (B=2) 記爲P1，IF (A=6) OR (X>4) 記爲P2。
第二部分：語句覆蓋用例設計——使程序中每個語句至少執行一次。
測試用例 P1 P2 執行路徑
A B X
6 2 36 T T a-c-e
第三部分：判定覆蓋用例設計——使每個判定的真假分支都至少執行一次。
測試用例 P1 P2 執行路徑
A B X
8 2 32 T F a-c-d
6 0 32 F T a-b-e
第四部分：條件覆蓋用例設計——使每個判定的每個條件的可能取值至少執行一次。
測試用例
第一判定表達式 第二判定表達式 執行路徑
A B X A>3 B=2 A=6 X>4
3 2 36 -T1 T2 -T3 T4 a-b-e
6 0 24 T1 -T2 T3 -T4 a-b-e
未覆蓋c、d分支，不滿足判定覆蓋的要求。
條件覆蓋不一定包含判定覆蓋，判定覆蓋也不一定包含條件覆蓋。
第五部分：判定/條件覆蓋用例設計——選取足夠多的測試用例，使判斷中的每個條件的所有可能取值至少執行一次，同時每個判斷本身的所有可能判斷結果至少執行一次。
測試用例 第一判定表達式 第二判定表達式 執行路徑
A B X A>3 B=2 A=6 X>4
6 2 36 T1 T2 T3 T4 a-c-e
3 2 36 -T1 T2 -T3 T4 a-b-e
6 0 24 T1 -T2 T3 -T4 a-b-e
6 0 24 -T1 -T2 -T3 -T4 a-b-d
能同時滿足判定、條件兩種覆蓋標準。
第六部分：條件組合覆蓋用例設計——所有可能的條件取值組合至少執行一次。
A>3, B=2 ；A>3, B≠2 ；A≯3, B=2 ；A≯3, B≠2
A=6, X>4 ；A=6, X≯4 ；A≠6, X>4 ；A≠6, X≯4
測試用例 第一判定表達式 第二判定表達式 執行路徑
A B X A>3 B=2 A=6 X>4
6 2 36 T1 T2 T3 T4 a-c-e
3 2 36 -T1 T2 -T3 T4 a-b-e
6 0 24 T1 -T2 T3 -T4 a-b-e
6 0 24 -T1 -T2 -T3 -T4 a-b-d
第七部分：實現路徑覆蓋用例設計——覆蓋每一個可能的路徑。
測試用例 第一判定表達式 第二判定表達式 執行路徑
A B X A>3 B=2 A=6 X>4
6 2 36 T1 T2 T3 T4 a-c-e
4 2 16 T1 T2 -T3 -T4 a-c-d
3 0 24 -T1 -T2 -T3 T4 a-b-e
6 0 24 -T1 -T2 -T3 -T4 a-b-d
第一判定表達式:
設條件 A>3 取真 記爲 T1
假 -T1
條件 B=2 取真 記爲 T2
假 -T2
第二判定表達式：
設條件 A=6 取真 記爲 T3
假 -T3
條件 X>4 取真 記爲 T4
假 -T4