1.軟件過程

1.1能力成熟度模型（CMM）

????????軟件能力成熟度模型（CMM）將軟件過程改進分為以下五個成熟度級別，每個級別都定義了特定的過程特征和目標：

1. 初始級 (Initial)：

   • 軟件開發過程雜亂無章，缺乏明確步驟。
   • 項目成功依賴個人能力和英雄式核心人物。

2. 可重復級 (Repeatable)：

   • 建立基本的項目管理過程，跟蹤費用、進度和功能特性。
   • 有過程準則以重復以往項目的成功。

3. 已定義級 (Defined)：

   • 軟件過程文檔化、標準化，形成組織標準。
   • 所有項目采用并遵循這些標準過程進行開發和維護。

4. 已管理級 (Managed)：

   • 詳細度量標準用于軟件過程和產品質量。
   • 組織成員理解和控制過程及產品質量。

5. 優化級 (Optimized)：

   • 加強定量分析，持續改進過程。
   • 利用過程質量反饋和新觀念、新技術進行優化

1.2?CMMI（能力成熟度模型集成）

1) 階段式模型：

• 分為5個成熟度等級：
  • 初始級：過程不可預測且缺乏控制。
  • 已管理級：過程為項目服務。
  • 已定義級：過程為組織服務。
  • 定量管理級：過程已度量和控制。
  • 優化級：集中于過程改進。

2) 連續式模型：（考得比較多）

• CL?（未完成的）：過程域未執行或未得到CL?中定義的所有目標。
• CL?（已執行的）：共性目標是將可標識的輸入工作產品轉換成可標識的輸出工作產品。

• CL?（已管理的）：聚焦于過程管理的制度化，包括遵循文檔化計劃、資源分配、監控和控制等。

• CL?（已定義級的）：著重于過程定義的制度化，要求過程需從組織標準集中裁剪，并收集過程資產及度量數據以促進改進。

• CL?（定量管理的）：強調過程的定量管理，利用測量和質量保證手段控制和優化過程，并設定質量與執行的定量目標。

• CL?（優化的）：使用量化方法（統計學手段）持續改進和優化過程域，以適應客戶要求的變化和持續改進計劃。

1.3 軟件開發模型

1.3.1 瀑布模型

• 瀑布模型是一種典型的軟件過程模型，將軟件生存周期中的各個活動規定為依線性順序連接的若干階段的模型。

特點：

• 每個階段必須在前一階段完成之后才能開始。
• 一旦進入下一階段，就不能返回到前一階段進行修改。
• 這種模型強調文檔的重要性，每個階段結束時都會產生相應的文檔。

優點：

• 易于理解，管理成本低。
• 適用于需求明確且穩定的項目。

缺點：

• 缺乏靈活性，難以適應需求的變化。
• 如果前期的需求分析不準確，后期的修改成本會非常高。
• 對項目風險控制能力較弱。

1.3.2??V模型

• 定義：V模型是瀑布模型的一個變體，如圖5-3所示。
• 描述：V模型描述了質量保證活動和溝通、建模相關活動以及早期構建相關的活動之間的關系。

1.3.3 增量模型

增量模型融合了瀑布模型的基本成分和原型實現的迭代特征，假設可以將需求分段為一系列增量產品，每一增量可以分別開發。該模型采用隨著日程時間的進展而交錯的線性序列，每一個線性序列產生軟件的一個可發布的“增量”。

增量模型強調每一個增量均發布一個可操作的產品。

優點：

1. 第一個可交付版本所需要的成本和時間少；
2. 開發由增量表示的小系統所承擔的風險不大；
3. 由于很快發布了第一個版本，因此可以減少用戶需求的變更；
4. 運行增量投資，即在項目開始時，只投入少量資金，以后根據項目的進展情況逐步追加投資。

1.3.4?演化模型（Evolutionary Model）

演化模型是一種迭代的過程模型，使得軟件開發人員能夠逐步開發出更完整的軟件版本。特別適用于對軟件需求缺乏準確認識的情況。典型的演化模型有原型模型和螺旋模型等。

（1）原型模型（Prototype Model）

?

• 特點：
  • 快速原型：原型方法比較適合于用戶需求不清晰、需求經常變化的情況。當系統規模不是很大也不太復雜時，采用該方法比較好。
  • 目的：能快速、低成本地構建原型。
  • 過程：通過快速計劃、交流、快速設計方式建模、快速構造、評估等步驟，不斷迭代和完善原型。

注意：

• 演化模型是一種適應需求變化的軟件開發方法，特別適用于需求不明確或經常變化的情況。
• 原型模型是演化模型的一種具體實現，通過快速構建可執行的原型來逐步完善系統，適合小規模、需求不明確的項目。

1.3.5 螺旋模型

該模型特別適用于龐大、復雜并且具有高風險的系統。

優點

• 強調風險分析，適合高風險項目。
• 支持需求變化，提高適應能力。
• 便于項目管理決策調整。

缺點：

• 需要開發人員有豐富的風險評估經驗。
• 過多的迭代次數會增加開發成本，延遲提交時間。

?

• 特點：
  • 結合了瀑布模型和演化模型的優點。
  • 強調風險分析，確保項目順利進行。
  • 每個螺旋周期包含四個關鍵步驟：制訂計劃、風險分析、實施工程、用戶評估。
  • 通過不斷迭代和改進，逐步完善軟件產品。

?1.3.6 噴泉模型

噴泉模型是一種以用戶需求為動力，以對象作為驅動的模型，適合于面向對象的開發方法。

特點：

1. 克服了瀑布模型不支持軟件重用和多項開發活動集成的局限性

2. 迭代性和無間隙性：

   • 迭代性：開發過程具有迭代性，意味著開發活動常常需要重復多次，在迭代過程中不斷地完善軟件系統。
   • 無間隙性：開發活動之間沒有明顯的邊界，允許各開發活動交叉、迭代地進行。

3. 階段劃分：

   • 各個階段沒有明顯的界線，開發人員可以同步進行。
   • 主要階段包括分析、設計、實現、維護和演化。

優點

• 可以提高軟件項目的開發效率，節省開發時間。

缺點

• 在各個開發階段是重疊的，需要大量的開發人員，不利于項目的管理。
• 要求嚴格管理文檔，使得審核的難度加大。

1.3.7??統一過程模型（Unified Process Model）

統一過程模型是一種“用例和風險驅動，以架構為中心，迭代并且增量”的開發過程，由UML方法和工具支持。

典型代表

• 適用場景：適用于大型復雜軟件項目的開發。
• 特點：
  • 強調用例和風險驅動。
  • 以架構為中心。
  • 迭代和增量式開發。
  • 涵蓋從項目啟動到最終交付的全過程。
  • 各階段有明確的工作產品和目標。
• 起始階段：生命周期目標。
• 精化階段：生命周期架構。
• 構建階段：初始運作功能。
• 移交階段：產品發布。

?

• RUP (Rational Unified Process)：是UP的商業擴展，完全兼容UP，但比UP更完整、更詳細。

在準備系統所有藍圖的時候，RUP使用的是統一建模語言UML。

特點：用例驅動、以基本的架構為中心、迭代與增量。

1.

1.3.8 基于構件的模型（Component Software Development）

利用模塊化方法，將整個系統模塊化，并在一定構件模型的支持下，復用構件庫中一個或多個構件，通過組合手段提高效率，高質量地構造應用軟件系統的過程。

1.4 敏捷方法?

• 總體目標：通過盡早、持續地交付有價值的軟件來使客戶滿意。
• 靈活性：在軟件開發過程中加入靈活性，允許用戶在開發周期的后期增加或改變需求。

1.4.1?極限編程（XP）

• 特點：輕量級、高效、低風險、柔性、可預測、科學的軟件開發方式。
• 組成部分：由價值觀、原則、實踐和行為四個部分組成，彼此相互依賴、關聯，并貫穿于整個生存周期。

4大價值觀：溝通、簡單性、反饋、勇氣

5個原則：快速反饋、簡單性假設、逐步修改、提倡更改、優質工作

12個最佳實踐：

1. 計劃游戲（快速制定計劃、隨著細節的不斷變化而完善）

2. 小型發布（系統的設計要能夠盡可能早地交付）

3. 隱喻（找到合適的比喻傳達信息）

4. 簡單設計（只處理當前的需求，使設計保持簡單）

5. 測試先行（先寫測試代碼，然后再編寫程序）

6. 重構（重新審視需求和設計，重新明確地描述它們以符合新的和現有的需求）

7. 結隊編程

8. 集體代碼所有制

9. 持續集成（可以按日甚至按小時為客戶提供可運行的版本）

10. 每周工作40個小時

11. 現場客戶

12. 編碼標準

1.4.2 水晶法

每個不同的項目都需要一套不同的策略、約定和方法論。

1.4.3?并列爭求法（Scrum）

• 使用迭代的方法，其中把每30天一次的迭代稱為一個“沖刺”。
• 按需求的優先級別來實現產品。
• 多個自組織和自治的小組并行地遞增實現產品。

1.4.4 自適應軟件開發（ASD）

1. 有一個使命作為指導。
2. 特征被視為客戶價值的關鍵點。
3. 過程中的等待是很重要的，因此“重做”與“做”同樣關鍵。
4. 變化不被視為改正，而是被視為對軟件開發實際情況的調整。
5. 確定的交付時間迫使開發人員認真考慮每一個生產的版本的關鍵需求。
6. 風險也包含其中。

1.4.5?敏捷統一過程（AUP）

核心原理

• 連續性：在大型項目上采用連續的方法。
• 迭代性：在小型項目上采用迭代的方法。

AUP 采用經典的 UP 階段性活動，包括：

1. 初始
2. 精化
3. 構建
4. 轉換

團隊活動

1. 建模：建立對商業和問題域的模型表述，這些模型“足夠好”即可，以便團隊繼續前進。
2. 實現：將模型翻譯成源代碼。
3. 測試：像 XP 一樣，團隊設計和執行一系列的測試來發現錯誤以保證源代碼滿足需求。
4. 部署：對軟件增量的交付以及獲取最終用戶的反饋。
5. 配置及項目管理：著眼于變更管理、風險管理以及對團隊的任一制品的控制。項目管理追蹤和控制開發團隊的工作進展并協調團隊活動。
6. 環境管理：協調工具以支持技術過程基礎設施。

2.軟件需求

軟件需求是用戶對目標軟件系統在功能、行為、性能、設計約束等方面的期望，需預先估計系統可達到的目標，同時要注意非功能性需求。

1. 功能需求：關注軟件系統所具備的具體功能和操作流程。
2. 性能需求：關注軟件開發的技術性指標，如存儲容量限制、執行速度、響應時間及吞吐量。這些指標衡量軟件運行的效率和能力。
3. 用戶或人的因素：從用戶使用體驗和操作難度角度出發，確保軟件易用性。
4. 環境需求：確保軟件在不同的硬件和軟件環境下都能正常運行。
5. 界面需求：涉及軟件與其他系統交互時的數據處理和格式要求。
6. 文檔需求：不同的文檔服務于不同的對象，如開發人員、用戶等。
7. 數據需求：保證數據在軟件系統中的正確處理和存儲。
8. 資源使用需求：從資源利用角度確保軟件的正常開發和運行。
9. 安全保密要求：保障軟件系統和用戶數據的安全性和保密性。
10. 可靠性要求:這是衡量軟件系統穩定性和容錯能力的重要指標，確保軟件在出現錯誤時能夠快速恢復正常運行，減少對用戶使用的影響。
11. 軟件成本消耗與開發進度需求:這是衡量軟件系統穩定性和容錯能力的重要指標，確保軟件在出現錯誤時能夠快速恢復正常運行，減少對用戶使用的影響。
12. 其他非功能性要求

?

• 開發模式相關：確定采用何種開發模式，例如敏捷開發、瀑布模型等，不同的開發模式會影響項目的開發流程和管理方式。
• 質量控制方面：明確質量控制標準，設定項目的里程碑以及評審和驗收標準，同時確定各種質量要求的優先級。這些標準和要求是保證軟件質量的關鍵因素。
• 可維護性方面：考慮軟件的可維護性要求，包括軟件在后續使用過程中進行修改、升級和修復的難易程度，這關系到軟件的長期使用和持續發展。

3.軟件設計

3.1 概要設計

3.1.1設計軟件系統總體結構

軟件系統總體結構設計是概要設計的關鍵環節，直接影響后續詳細設計與編碼工作，軟件系統質量和整體特性在此階段基本確定。

3.1.2數據結構及數據庫設計

• 數據結構設計：在需求分析階段對數據特性描述的基礎上，概要設計階段進一步細化，宜采用抽象數據類型，詳細設計階段規定具體實現細節。
• 數據庫設計
  • 概念設計：基于數據分析，采用自底向上方法從用戶視角進行視圖設計，常用 E - R 模型表述數據模型，它是數據庫和數據結構設計的基礎。
  • 邏輯設計：結合具體數據庫管理系統（DBMS）特征，基于 E - R 模型建立數據庫邏輯結構。
  • 物理設計：針對不同 DBMS 的物理環境差異，設計數據模式的物理細節，如數據項存儲要求、存取方法和索引建立等。

3.1.3編寫概要文檔

主要編寫概要設計說明書、數據庫設計說明書、用戶手冊以及修訂測試計劃等文檔。

3.1.4評審

對設計部分是否完整實現需求規定的功能、性能等要求，設計方法的可行性，關鍵處理及內外部接口定義的正確性、有效性和各部分一致性等進行全面評審。

3.2詳細設計

3.2.1算法設計

對每個模塊進行細致的算法設計，運用圖形、表格、語言等工具精確描述模塊處理過程的詳細算法，這是實現模塊功能的核心步驟。

3.2.2數據結構設計

針對模塊內的數據結構進行設計，目的是優化數據的組織和存儲方式，以提高模塊對數據的處理效率。

3.2.3數據庫物理設計

確定數據庫的物理結構，包括存儲位置、存儲方式等，使數據庫在實際運行環境中能夠高效存取數據。

3.2.4其他設計

1. 代碼設計：為提升數據輸入、分類、存儲和檢索等操作的效率，節約內存空間，對數據庫中特定數據項的值進行代碼設計，例如采用編碼規則來簡化數據表示。
2. 輸入 / 輸出格式設計：設計合理的輸入 / 輸出格式，確保數據的輸入便捷準確，輸出直觀易懂，符合用戶使用習慣和系統需求。
3. 用戶界面設計：根據軟件系統的類型和用戶需求，設計友好、易用的用戶界面，提升用戶體驗。

3.2.5文檔編寫

編寫詳細設計說明書，全面記錄詳細設計階段的各項成果，為后續的編程實現和系統維護提供清晰的指導。

3.2.6評審

對處理過程的算法和數據庫的物理結構進行評審，檢查設計的合理性、正確性和高效性 ，及時發現并糾正潛在問題。

4.系統測試

4.1系統測試與調試

系統測試是為發現錯誤而執行程序的過程，成功的測試是能發現尚未被發現的錯誤的測試。

信息系統測試包括軟件測試、硬件測試和網絡測試，文中側重軟件測試。

原則：

1. 盡早且持續測試原則：測試不應在應用系統開發完成后才進行，由于開發過程的復雜性和多階段性，錯誤可能出現在各個階段，所以測試應貫穿開發全過程，盡早發現并糾正錯誤。
2. 獨立測試原則：測試工作應由專門人員而非原開發人員或小組承擔。因為開發人員可能不愿承認自己工作的錯誤，且容易受自身編程思路限制，專門人員測試更客觀、有效。
3. 全面設計測試方案原則：設計測試方案時，不僅要確定輸入數據，還要依據系統功能確定預期輸出結果，通過比較實際輸出與預期結果來判斷測試對象的正確性。
4. 覆蓋多種輸入條件：設計測試用例時，既要包含有效、合理的輸入條件，也要涵蓋不合理、失效的輸入條件。避免只關注正常情況測試，以發現異常情況下可能存在的隱患。
5. 雙重檢驗程序功能：測試程序時，不僅要檢查程序是否實現了預期功能（做了該做的事），還要檢查是否存在多余操作（做了不該做的事），防止多余工作影響程序效率和帶來潛在危害。
6. 嚴格遵循測試計劃：嚴格按照包含測試內容、進度安排、人員安排、測試環境、測試工具和測試資料等的測試計劃進行測試，避免測試的隨意性，保障測試工作按進度協調開展。
7. 妥善保存測試文檔：妥善保存測試計劃和測試用例，使其作為軟件文檔的一部分，為后續軟件維護提供便利。
8. 利用測試用例復用：測試用例是精心設計的成果，在糾正錯誤、擴充系統功能等需要重新測試或追加測試時，可復用之前的測試用例或在此基礎上修改后使用，提高測試效率，減少重復性工作。
9. 系統測試階段的測試目標來自于需求分析階段。

4.2單元測試

????????單元測試也稱模塊測試，在模塊編寫完成且無編譯錯誤后進行，側重于模塊內部處理邏輯和數據結構，機器測試常用白盒測試法，可同時測試多個模塊。

4.2.1單元測試的內容

? ? ? ? 單元測試主要檢查模塊的以下5個特征：

? ? ? ? （1）模塊接口

? ? ? ? （2）局部數據結構

? ? ? ? （3）重要的執行路徑

? ? ? ? （4）出錯處理

? ? ? ? （5）邊界條件

4.2.2單元測試的過程

????????由于模塊不是獨立運行的程序，各模塊之間存在調用與被調用的關系。在對每個模塊進行測試時，需要開發兩種模塊。

• ?驅動模塊：相當于一個主程序，接收測試例子的數據，將這些數據送到測試模塊，輸出測試結果。
• 樁模塊(也稱為存根模塊)：樁模塊用來代替測試模塊中所調用的子模塊，其內部可進行少量的數據處理，目的是為了檢驗入口，輸出調用和返回的信息。

????????一些增量集成策略：

????????1.自頂向下集成測試

????????自頂向下集成測試是一種構造軟件體系結構的增量方法。模塊的集成順序為從主控模塊(主程序)開始，沿著控制層次逐步向下，以深度優先或廣度優先的方式將從屬于(或間接從屬于)主控模塊的模塊集成到結構中。

????????集成過程可以通過下列5個步驟完成：

• 主控模塊用作測試驅動模塊，用這些從屬于主控模塊的所有模塊代替樁模塊。
• 依靠所選擇的集成方法(即深度優先或廣度優先)，每次用實際模塊替換一個從屬樁模塊。
• 在集成每個模塊后都進行測試。
• 在完成每個測試集之后，用實際模塊替換另一個樁模塊。
• 可以執行回歸測試，以確保沒有引入新的錯誤。
• 回到第(2)步繼續執行此過程，直到完成了整個程序結構的構造。

?????2.自底向上集成測試

????????自底向上集成測試就是從原子模塊(程序結構的最底層構件)開始進行構造和測試。由于構件是自底向上集成的，在處理時所需要的從屬于給定層次的模塊總是存在的，因此，沒有必要使用樁模塊。自底向上集成策略可以利用以下步驟來實現。

• 連接低層構件以構成完成特定子功能的簇。
• 編寫驅動模塊(測試的控制程序)以協調測試用例的輸入和輸出。
• 測試簇。
• 去掉驅動程序，沿著程序結構向上逐步連接簇。

????????3.回歸測試?

????????每當加入一個新模塊作為集成測試的一部分時，軟件發生變更，建立了新的數據流路徑，可能出現新的IO，以及調用新的控制邏輯。這些變更可能會使原來可以正常工作的功能產生問題。在集成測試策略的環境下，回歸測試是重新執行已測試過的某些子集，以確保變更沒有傳播不期望的副作用。

????????回歸測試要執行的測試子集包含以下3 種測試用例：

1. 能夠測試軟件所有功能的具有代表性的測試樣本。
2. 額外測試，側重于可能會受變更影響的軟件功能。
3. 側重于已發生變更的軟件構件測試。

????????4.冒煙測試

????????當開發軟件產品時,冒煙測試是一種常用的集成測試方法,是時間關鍵項目的決定性機制它讓軟件團隊頻繁地對項目進行評估。本質上，冒煙測試方法包括下列活動:
????????(1)將已經轉換為代碼的軟件構件集成到構建中。一個構建包括所有的數據文件、庫、可復用的模塊以及實現一個或多個產品功能所需的工程化構件。
????????(2)設計一系列測試以暴露影響構建正確的完成其功能的錯誤，其目的是為了發現極有可
能造成項目延遲的業務阻塞錯誤。

????????(3)每天將該構建與其他構建及整個軟件產品(以其當前形勢)集成起來進行冒煙測試。
這種集成方法可以自頂向下，也可以自底向上。

4.2.3 測試方法?

? ? ? ? 軟件測試方法分為靜態測試和動態測試：

????????(1)靜態測試：靜態測試是指被測試程序不在機器上運行，而是采用人工檢測和計算機輔助靜態分析的手段對程序進行檢測。
????????(2)動態測試：動態測試是指通過運行程序發現錯誤。在對軟件產品進行動態測試時可以采用黑盒測試法和白盒測試法。測試用例由測試輸入數據和與之對應的預期輸出結果組成。在設計測試用例時，應當包括合理的輸入條件和不合理的輸入條件。

• 黑盒測試

????????黑盒測試也稱為功能測試，在完全不考慮軟件的內部結構和特性的情況下，測試軟件的外部特性。

? ? ? ? 1.等價類劃分:將輸入域劃分為若干等價類（有效/無效），每個類選取一個代表值測試。

????????2.?邊界值分析:測試輸入域的邊界值（如最小值、最大值、略小于邊界、略大于邊界）。

????????3.?因果圖法:分析輸入條件（因）與輸出結果（果）的邏輯關系，生成判定表。

• 步驟：

  1. 確定輸入條件與輸出結果。

  2. 繪制因果圖（邏輯關系：與、或、非）。

  3. 轉換為判定表，生成測試用例。

????????4. 錯誤法:基于經驗和直覺推測程序中所有可能存在的各種錯誤，從而有針對性地設計測試用例的方法。其基本思想是列舉出程序中所有可能有的錯誤和容易發生錯誤的特殊情況，根據它們選擇測試用例。

• McCabe 度量法

????????McCabe 度量法是通過定義環路復雜度，建立程序復雜性的度量，它基于一個程序模塊的程序圖中環路的個數。計算有向圖G的環路復雜性的公式為:V(G)=m-n+2，其中V(G)是有向圖G中的環路個數，m是G中的有向弧數，n是G中的節點數。

????????????????????????????????????????????????

• 白盒測試

1. 語句覆蓋：每條語句至少執行一次（最弱覆蓋）。

2. 判定覆蓋（分支覆蓋）：每個判斷的真/假分支至少執行一次。

3. 條件覆蓋：每個判斷中的每個條件（子表達式）的真/假均被覆蓋。

4. 判定-條件覆蓋：同時滿足判定覆蓋和條件覆蓋。

5. 條件組合覆蓋：覆蓋所有條件的真/假組合（覆蓋強度最高）。

6. 路徑覆蓋：覆蓋程序中所有可能的執行路徑（實際中復雜度高，通常僅針對關鍵路徑）。

5.系統維護

5.1系統可維護性概念

5.1.1系統可維護性的評價指標

(1)可理解性。指別人能理解系統的結構、界面、功能和內部過程的難易程度。模塊化、詳細設計文檔、結構化設計和良好的高級程序設計語言等都有助于提高可理解性。

(2)可測試性。診斷和測試的容易程度取決于易理解的程度。好的文檔資料有利于診斷和測試，同時，程序的結構、高性能的測試工具以及周密計劃的測試工序也是至關重要的。為此，開發人員在系統設計和編程階段就應盡力把程序設計成易診斷和測試的。此外，在進行系統維護時，應該充分利用在系統測試階段保存下來的測試用例。
(3)可修改性。診斷和測試的容易程度與系統設計所制定的設計原則有直接關系。模塊的耦合、內聚、作用范圍與控制范圍的關系等都對可修改性有影響。

5.1.2系統維護的內容及類型

????????系統維護主要包括硬件維護、軟件維護和數據維護。
????????1.硬件維護
? ? ? ? 2.軟件維護
????????軟件維護主要是指根據需求變化或硬件環境的變化對應用程序進行部分或全部修改。

????????根據維護的目的和內容，軟件維護分為以下四類：

維護類型	核心內容	典型場景	考試重點
正確性維護	正確性維護是指改正在系統開發階段已發生而系統測試階段尚未發現的錯誤，	- 用戶報告程序崩潰或邏輯錯誤。 - 測試階段未覆蓋的隱藏問題。	占比約?15%~25%（非最高）。
適應性維護	使軟件適應外部環境的變化（硬件、操作系統、數據庫、法規等）。	- 操作系統升級導致兼容性問題。 - 數據庫從MySQL遷移到Oracle。	占比約?20%~25%。
完善性維護	根據用戶需求新增功能或優化現有功能（非缺陷修復）。	- 用戶提出新的報表需求。 - 優化系統響應速度或界面交互。	占比最高（約?50%~60%）。
預防性維護	主動優化代碼結構、文檔或架構，降低未來維護成本（預防潛在問題）。	- 重構冗余代碼提升可讀性。 - 更新技術文檔或增加注釋。	占比最低（約?5%），常被忽略。

? ? ? ? 3.數據維護?：數據庫結構變更（如新增字段）、數據遷移或清洗。

5.2軟件質量屬性

????????可靠性、可用性和可維護性是軟件的質量屬性，軟件工程中，用0-1之間的數來
度量。
? ? ? ? 1.可靠性是指一個系統對于給定的時間間隔內、在給定條件下無失效運作的概率。可以用 MTTF/(1+MTTF)來度量，其中 MTTF （Mean Time To Failure）為平均無故障時間。
? ? ? ? 2.可用性是在給定的時間點上，一個系統能夠按照規格說明正確運作的概率。可以用MTBF/(1+MTBF)來度量，其中MTBF （Mean Time Between Failures）為平均失效間隔時間。
? ? ? ? 3.可維護性是在給定的使用條件下，在規定的時間間隔內，使用規定的過程和資源完成維護活動的概率。可以用 1/(1+MTTR)來度量，其中MTTR（Mean Time To Repair） 為平均修復時間。

6.軟件文檔

????????編寫高質量文檔可以提高軟件開發的質量文檔也是軟件產品的一部分，沒有文檔的軟件就不能稱之為軟件。軟件文檔的編制在軟件開發工作中占有突出的地位和相當大的工作量高質量文檔對于軟件產品的效益有著重要的意義。

7.軟件項目估算

7.1COCOMO 模型概述

• 全稱：Constructive Cost Model（構造性成本模型），由 Barry Boehm 提出。

• 用途：估算軟件開發項目的工作量（人月）、成本（費用）和工期（時間）。

• 適用階段：適用于軟件項目早期（需求明確后）的成本預測。

• 核心思想：基于代碼行數（KLOC）和調整因子計算工作量。

7.2COCOMO 模型的三個層次

????????COCOMO 模型是一種精確的、易于使用的成本估算模型。COCOMO 模型按其詳細程度分
為基本 COCOMO 模型、中級 COCOMO 模型和詳細 COCOMO 模型。

1.?基本 COCOMO（Basic COCOMO）

• 特點：基本 COCOMO 模型是一個靜態單變量模型，用于對整個軟件系統進行估算。僅考慮代碼行數（KLOC），忽略其他因素，適用于快速粗略估算。

• 公式：

  \text{工作量（人月）} = a \times (\text{KLOC})^b工作量（人月）=a×(KLOC)b\text{工期（月）} = c \times (\text{工作量})^d工期（月）=c×(工作量)d

• 系數表（根據項目類型選擇）：

  項目類型	a	b	c	d
  有機型（小型團隊）	2.4	1.05	2.5	0.38
  半分離型（中型）	3.0	1.12	2.5	0.35
  嵌入型（復雜約束）	3.6	1.20	2.5	0.32

• 項目類型說明：

  • 有機型：需求穩定，團隊經驗豐富（如企業內部系統）。

  • 嵌入型：嚴格約束下的復雜系統（如航天控制軟件）。

  • 半分離型：介于兩者之間（如銀行交易系統）。

2.?中間 COCOMO（Intermediate COCOMO）

• 特點：中級 COCOMO模型是一個靜態多變量模型,它將軟件系統模型分為系統和部件兩個層次系統由部件構成，它把軟件開發所需的人力(成本)看作是程序大小和一系列“成本驅動屬性的函數。在基本模型基礎上引入15個成本驅動因子（Cost Drivers），提高估算精度。

• 公式：

  \text{工作量} = a \times (\text{KLOC})^b \times \text{EAF}工作量=a×(KLOC)b×EAF

  • EAF（Effort Adjustment Factor）：15個成本驅動因子的乘積（每個因子取值范圍0.7~1.66）。

• 典型調整因子（考試高頻）：

  類別	示例因子	影響范圍
  產品屬性	軟件可靠性、數據庫復雜度	高→EAF增大
  硬件屬性	執行時間約束、內存限制	高→EAF增大
  人員屬性	開發人員經驗、團隊協作能力	低→EAF增大
  項目屬性	開發工具先進性、進度壓力	高→EAF增大

3.?詳細 COCOMO（Detailed COCOMO）

• 特點：它將軟件系統模型分為系統、子系統和模塊3個層次，除包括中級模型所考慮的因素外，還考慮了在需求分析、軟件設計等每一步的成本驅動屬性的影響，適用于大型項目。

• 考試重點：理解其分層細化思想，具體計算較少考查。

7.3COCOMOII模型

根據項目階段的不同，COCOMO II 分為以下三個子模型：

子模型	適用階段	規模度量	核心公式
應用組裝模型	早期需求階段，這時用戶界面的原型開發、對軟件和系統交互的考慮、性能的評估以及技術成熟度的評價是最重要的。	對象點（Object Points）	基于復用組件和界面復雜度估算規模。
早期設計模型	概要設計階段，在需求已經穩定并且基本的軟件體系結構已經建立時使用。	功能點（FP）	初步估算工作量，支持架構決策。
后體系結構模型	詳細設計及編碼階段，在軟件的構造過程中使用。	代碼行（SLOC）	最精確的估算模型，結合詳細成本驅動因子。

---

7.4PERT圖

????????PERT 圖是一個有向圖，圖中的箭頭表示任務，它可以標上完成該任務所需的時間。圖中的結點表示流入結點的任務的結束，并開始流出結點的任務，這里把結點稱為事件。只有當流入該結點的所有任務都結束時，結點所表示的事件才出現，流出結點的任務才可以開始。事件本身不消耗時間和資源，它僅表示某個時間點。一個事件有一個事件號和出現該事件的最早時刻和最遲時刻。最早時刻表示在此時刻之前從該事件出發的任務不可能開始;最遲時刻表示從該事件出發的任務必須在此時刻之前開始，否則整個工程就不能如期完成。每個任務還可以有個松弛時間(Slack Time)，表示在不影響整個工期的前提下完成該任務有多少機動余地。

7.5Gantt圖

????????Gantt圖是一種簡單的水平條形圖，它以日歷為基準描述項目任務。水平軸表示日歷時間線(如時、天、周、月和年等)，每個條形表示一個任務，任務名稱垂直地列在左邊的列中，圖中水平條的起點和終點對應水平軸上的時間，分別表示該任務的開始時間和結束時間，水平條的長度表示完成該任務所持續的時間。當日歷中同一時段存在多個水平條時，表示任務之間的并發。圖 5-12 所示的 Gantt 圖描述了3個任務的進度安排。任務1首先開始，完成它需要6個月時間;任務2在1個月后開始，完成它需要9個月時間;任務3在6個月后開始，完成它需要5 個月時間。

7.6項目活動圖

1. 活動圖基本要素

   • 頂點：表示里程碑（事件），不消耗時間，僅標志活動的開始或結束。
   • 邊：表示活動（任務），標注持續時間，箭頭方向代表依賴關系。
   • 關鍵路徑：從起點到終點的最長路徑，決定項目最短工期。關鍵路徑上的活動稱為關鍵活動，其松弛時間為 0。

2. 關鍵路徑計算方法

   • 正向推導：從起點開始，計算每個事件的最早發生時間（ET）。若多個活動指向同一事件，取最大值作為 ET617。
   • 反向推導：從終點開始，計算每個事件的最晚發生時間（LT）。若多個活動從同一事件出發，取最小值作為 LT617。
   • 關鍵路徑判定：ET=LT 的事件構成關鍵路徑。

8.軟件配置管理

主要考點：

軟件配置管理其主要目標包括:變更標識、變更控制、版本控制、確保變更正確的實現、變更報告。

軟件配置管理其主要內容包括:版本管理、配置支持、變更支持、過程支持、團隊支持、變化報告、審計支持

上下為兩個不同的版本

軟件配置管理其主要內容包括:軟件配置標識、變更管理、版本控制、系統建立、配置審核、配置狀態報告

????????配置數據庫可以分為以下三類：
????????(1)開發庫。專供開發人員使用，其中的信息可能做頻繁修改，對其控制相當寬松。
????????(2)受控庫。在生存期某一階段工作結束時發布的階段產品，這些是與軟件開發工作相關的計算機可讀信息和人工可讀信息。軟件配置管理正是對受控庫中的各個軟件項進行管理，受控庫也稱為軟件配置庫。
????????(3)產品庫。在開發的軟件產品完成系統測試后，作為最終產品存入產品庫，等待交付用戶或現場安裝。

9.風險管理

9.1風險基本概念

• 風險三要素：風險事件（如技術難題、需求變更）、發生概率、影響程度。
• 特性：不確定性和損失，不確定性是指風險可能發生也可能不發生;損失是指如果風險發生，就會產生惡性后果。
• 風險分類：
  1. 項目風險：進度延誤、資源不足、團隊溝通問題。
  2. 技術風險：技術兼容性、代碼質量、新技術不成熟。
  3. 商業風險：

????????????????????????????????(1)市場風險。開發了一個沒有人真正需要的優良產品或系統。
????????????????????????????????(2)策略風險。開發的產品不再符合公司的整體商業策略。
????????????????????????????????(3)銷售風險。開發了一個銷售部門不知道如何去銷售的產品。
????????????????????????????????(4)管理風險。由于重點的轉移或人員的變動而失去了高級管理層的支持,
????????????????????????????????(5)預算風險。沒有得到預算或人員的保證。

9.2風險識別

????????風險識別試圖系統化地指出對項目計劃(估算、進度、資源分配等)的威脅。

????????識別風險的一種方法是建立風險條目檢查表。該檢查表可用于風險識別，并且主要用來識別下列幾種類型中的一些已知風險和可預測風險。

• 產品規模。與要開發或要修改的軟件的總體規模相關的風險
• 商業影響。與管理者或市場所施加的約束相關的風險。
• 客戶特性。與客戶的素質以及開發者和客戶定期溝通的能力相關的風險。
• 過程定義。與軟件過程定義的程度以及該過程被開發組織遵守的程度相關的風險。
• 開發環境。與用來開發產品的工具的可得性及質量相關的風險。
• 開發技術。與待開發軟件的復雜性及系統所包含技術的“新奇性”相關的風險
• 人員才于及經驗。與軟件工程師的總體技術水平及項目經驗相關的風險。

????????當然，也可以采用另一種風險條目檢查表格式，即僅僅列出與每一種類型有關的特性，最終給出一組風險因素和驅動因子以及它們發生的概率。風險因素包括性能、成本、支持和進度風險因素是以如下方式定義的。

• 性能風險。產品能夠滿足需求且符合其使用目的的不確定程度
• 成本風險。能夠維持項目預算的不確定程度。
• 支持風險。開發出的軟件易于糾錯、修改及升級的不確定程度
• 進度風險。能夠維持項目進度且按時交付產品的不確定程度。

9.3風險預測

????????一種簡單的風險預測技術是建立風險表。風險表的第1列列出所有的風險(由風險識別活動得到)，第 2~4列列出每個風險的種類、發生的概率以及所產生的影響。風險所產生的影響可用一個數字來表示:“1”表示災難性的;“2”表示嚴重的;“3”表示輕微的;“4”表示可忽略的。

???????整體的風險顯露度(RiskExposure，RE)可由下面的關系確定:
????????????????????????????????????????????????????????????????RE=P*C
????????其中，P是風險發生的概率，C是風險發生時帶來的項目成本。

9.4風險評估

????????在進行風險評估時，建立了如下形式的三元組:

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?(ri?,li?,xi?)? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??
????????在風險評估過程中，需要執行以下4個步驟。
????????(1)定義項目的風險參考水平值。
????????(2)建立每一組?(ri?,li?,xi?)?與每一個參考水平值之間的關系。
????????(3)預測一組臨界點以定義項目終止區域，該區域由一條曲線或不確定區域所界定。
????????(4)預測什么樣的風險組合會影響參考水平值。

9.5風險控制

????????風險控制的目的是輔助項目組建立處理風險的策略。一個有效的策略必須考慮以下3個
問題。

1. 風險避免：主動分析風險成因并采取措施規避風險。如針對 “頻繁人員流動” 風險（概率 70%，影響為嚴重 2 級），可采取探究流動原因、緩解可控起因、保障人員離開后的工作連續性、促進信息傳播交流、制定工作產品標準并建立創建機制、同等對待工作評審、為關鍵技術人員指定后備人員等策略。? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ????????(1)與現有人員一起探討人員流動原因(如惡劣的工作條件、低報酬、競爭激烈的勞動力市場等)。
   ????????(2)在項目開始之前采取行動，設法緩解那些能夠控制的起因。
   ????????(3)項目啟動之后，假設會發生人員流動，當有人員離開時，找到能夠保證工作連續性的方法。
   ????????(4)組織項目團隊，使得每一個開發活動的信息都能被廣泛傳播和交流。
   ????????(5)制定工作產品標準，并建立相應機制以確保能夠及時創建所有的模型和文檔。
   ????????(6)同等對待所有工作的評審。
   ????????(7)給每一個關鍵的技術人員都指定一個后備人員
2. 風險監控：監測能反映風險變化（變高或變低）的因素。如在人員流動案例中，需監測團隊成員對項目壓力的態度、團隊凝聚力、成員關系、報酬利益相關潛在問題、內外工作可能性等。
3. RMMM 計劃：風險管理策略可融入軟件項目計劃，或組成獨立的風險管理計劃（文中提及但未詳述，需關注其定義與作用）。

風險應對策略（考試重點）

策略	適用場景	示例
規避	風險影響極大且不可接受	放棄采用新技術，改用成熟方案。
減輕	風險可部分控制	增加測試用例覆蓋關鍵路徑。
轉移	風險可外包或分攤	購買保險、外包高風險模塊開發。
接受	風險影響小或應對成本過高	預留應急儲備金或時間緩沖。

10.軟件質量

????????軟件質量是指反映軟件系統或軟件產品滿足規定或隱含需求的能力的特征和特性全體。

10.1軟件質量特性

????????討論軟件質量首先要了解軟件的質量特性，目前已經有多種軟件質量模型來描述軟件質量特性，例如 ISO/EC 9126 軟件質量模型和 Mc Call 軟件質量模型。

1.ISO/EC 9126 軟件質量模型
????????ISO/EC9126 軟件質量模型由3個層次組成:第一層是質量特性，第二層是質量子特性第三層是度量指標

質量特性	子特性	典型場景
功能性	適合性、準確性、互用性、依從性、安全性	軟件是否實現需求文檔中的功能。
可靠性	成熟性、容錯性、易恢復性	系統在故障后能否快速恢復（如事務回滾）。
易用性	易理解性、易學性、易操作性	用戶界面是否友好，操作是否直觀。
效率	時間特性、資源利用率	系統響應時間、CPU/內存占用率。
可維護性	易分析性、易修改性、穩定性、易測試性	代碼是否模塊化，是否易于修復缺陷。
可移植性	適應性、易安裝性、一致性、易替換性	軟件能否在不同平臺或環境中運行。

2.Mc Call 軟件質量模型?

????????Mc Cal 軟件質量模型從軟件產品的運行、修正和轉移3個方面確定了 11個質量特性。Mc Cal 也給出了一個三層模型框架，第一層是質量特性，第二層是評價準則,第三層是度量指標。

1. 產品運行質量（面向用戶）

質量因素	定義	評價準則（示例）
正確性	軟件滿足需求規格的程度	需求覆蓋率、缺陷修復率。
可靠性	在規定條件下無故障運行能力	容錯性、一致性、故障恢復時間。
效率	資源利用率與響應速度	吞吐量、響應時間、內存占用率。
完整性	防止未授權訪問和數據丟失	加密強度、訪問控制粒度。
易用性	用戶學習和操作的容易程度	界面友好性、幫助文檔完整性。

2. 產品修正質量（面向維護）

質量因素	定義	評價準則（示例）
可維護性	軟件修改的難易程度	模塊化程度、代碼注釋率。
靈活性	適應需求變化的容易程度	配置參數化、接口擴展性。
可測試性	測試和驗證的容易程度	自動化測試覆蓋率、日志完整性。

3. 產品遷移質量（面向環境）

質量因素	定義	評價準則（示例）
可移植性	跨平臺和環境運行的能力	平臺兼容性、依賴庫標準化。
復用性	組件被其他系統復用的能力	接口通用性、功能獨立性。
互用性	與其他系統交互的能力	接口協議標準化、數據格式兼容性。

10.2軟件評審

10.2.1評審類型

1. 需求評審：審查需求規格說明書，確保需求的準確性、完整性、一致性、可驗證性，避免歧義與遺漏，減少后期變更風險。
2. 設計評審：評估系統架構、詳細設計文檔，檢查是否滿足需求，關注可維護性、可擴展性、性能及安全性，例如確認架構設計是否遵循規范。
3. 代碼評審：檢查代碼質量，發現潛在錯誤，確保代碼符合編碼標準與最佳實踐，提升可讀性與可維護性。
4. 測試評審：審查測試計劃、用例、結果，確保測試覆蓋全面，策略有效，例如驗證測試用例是否覆蓋所有需求點。
5. 發布前評審：在軟件發布前，全面檢查功能、性能、穩定性等，確認是否滿足用戶需求與質量標準。

10.2.2評審內容

• 文檔層面：檢查文檔結構合理性（如引言、系統設計概述、數據庫設計等）、內容完整性（無關鍵信息缺失）、語言準確性（無二義性）。
• 功能與性能：驗證功能設計是否滿足需求，性能指標（如響應時間、吞吐量）是否達標，安全性、兼容性等是否考慮周全。
• 過程合規性：確認開發過程是否遵循既定規范，例如代碼編寫是否符合團隊標準，測試流程是否完整。

10.2.3評審方法

1. 文檔評審：通過閱讀文檔發現問題，適用于初步檢查。
2. 評審會議：組織開發、測試、需求方等多方參與，集中討論評審內容，如需求評審會議。
3. 專家評審：邀請領域專家評估技術方案的合理性與可行性，例如架構設計的專家把關。
4. 集體審查：團隊成員交叉檢查，利用多人視角發現問題，常用于代碼評審。
5. 電子郵件評審：分散收集意見，適合非緊急、需遠程協作的場景。

10.2.4評審原則與標準

• 原則：文檔編寫需遵循簡潔明了、完整性、可讀性、獨立性、一致性、可追溯性、可維護性、可擴展性等原則，確保文檔質量。
• 標準：評審設計時關注合理性、可實現性、效率、可靠性、靈活性、可維護性、擴展性、穩定性等，例如評估架構是否具備良好的可擴展性以應對未來需求變化。

10.2.5評審流程要點

1. 準備階段：明確評審對象（如測試計劃、設計文檔），通知相關人員，確保資料齊全。
2. 執行階段：通過會議或文檔審查，記錄問題與建議，例如在代碼評審中標記風格不符處。
3. 跟蹤階段：跟進問題整改，驗證修復結果，更新評審記錄，確保閉環管理。

10.3軟件容錯技術

1. 結構冗余：通過冗余硬件 / 軟件模塊提升可靠性，按工作方式分為：
   • 靜態冗余：多模塊同時運行，通過表決機制（如多數表決）屏蔽故障模塊，如三模冗余系統。
   • 動態冗余：故障時切換到備份模塊，如雙機熱備（主系統故障，備用系統接管）。
   • 混合冗余：結合靜態與動態冗余，靈活應對不同故障場景。
2. 信息冗余：添加額外信息檢測 / 糾正錯誤，如校驗碼（CRC 校驗）、糾錯碼（海明碼），確保數據傳輸或存儲的正確性。
3. 時間冗余：重復執行指令或程序消除瞬時錯誤，如網絡請求失敗后重試，或關鍵操作多次執行驗證結果一致性。在程序復算中比較常用的方法是程序滾回(Program Rollback)技術。
4. 冗余附加技術：支持上述冗余的資源與技術，包括冗余程序的存儲調用、錯誤檢測與恢復程序、固化程序（如 BIOS 中的容錯處理）等。

????????在屏蔽硬件錯誤的容錯技術中，冗余附加技術包括:
? ? ?1.關鍵程序和數據的冗余存儲及調用。
? ? ?2.檢測、表決、切換、重構、糾錯和復算的實現。
????????在屏蔽軟件錯誤的容錯系統中，冗余附加技術的構成包括?

1. 冗余備份程序的存儲及調用
2. 實現錯誤檢測和錯誤恢復的程序
3. 實現容錯軟件所需的固化程序

11.軟件工具

1.軟件開發工具

階段	工具類型	典型工具 / 技術	功能說明
需求分析	需求建模工具	Visio、Axure、UML 工具（如 Enterprise Architect）	繪制用例圖、流程圖，輔助需求結構化表達，生成需求規格說明書。
設計階段	架構設計工具	Rose、StarUML、Archimate	支持 UML 建模（類圖、組件圖、部署圖），輔助系統架構設計與可視化。
編碼階段	集成開發環境（IDE）	Eclipse、IntelliJ IDEA、VS Code	提供代碼編輯、編譯、調試、版本控制集成功能，支持多語言開發（Java、C++ 等）。
測試階段	單元測試工具	JUnit（Java）、NUnit（.NET）、PyTest（Python）	自動執行單元測試用例，生成測試報告，驗證代碼邏輯正確性。
測試階段	性能測試工具	LoadRunner、JMeter	模擬多用戶并發場景，測試系統性能瓶頸，分析響應時間、吞吐量等指標。
測試階段	自動化測試工具	Selenium（Web 自動化）、Appium（移動自動化）	錄制 / 回放用戶操作，實現功能測試自動化，減少手工測試成本。

2. 軟件維護工具

工具類型	典型工具 / 技術	功能說明
版本控制工具	Git、SVN、GitHub、GitLab	管理軟件不同版本，記錄變更歷史，支持分支管理（如 Feature 分支、Hotfix 分支），實現代碼回滾與合并。
逆向工程工具	IDA Pro、JD-GUI、DotPeek	將目標代碼（二進制 / 字節碼）反編譯為高級語言或設計模型（如類圖），輔助理解遺留系統邏輯。
重構工具	IDE 內置重構功能（如 IDEA 的 Refactor）	自動優化代碼結構（如重命名變量、提取方法、優化循環），提升代碼可讀性與可維護性。
代碼分析工具	SonarQube、Checkstyle、FindBugs	靜態分析代碼質量，檢測潛在缺陷（如代碼異味、安全漏洞、性能問題），生成質量報告。
調試工具	WinDbg、GDB、VS 調試器	定位運行時錯誤，支持斷點調試、變量監控、調用棧分析，輔助修正程序缺陷。
配置管理工具	Ansible、Chef、Puppet	自動化管理系統配置，確保維護過程中環境一致性（如服務器部署、軟件依賴管理）。
數據遷移工具	ETL 工具（如 Talend、Kettle）	支持不同數據庫 / 系統間的數據遷移與轉換，輔助系統升級或數據整合維護。

2. 維護場景應用

12.補充知識

1.倉庫風格

倉庫風格是一種軟件體系結構，其中包含一個數據倉庫和若干個其他構件。數據倉庫位于該體系結構的中心，其他構件訪問該數據倉庫并對其中的數據進行增、刪、改等操作。數據庫系統、超文本系統和黑板系統都屬于倉庫風格。

該體系結構的優點包括:
①對可更改性和可維護性的支持② 可復用的知識源:③ 支持容錯性和健壯性。

缺點包括:
① 測試困難:②不能保證有好的解決方案:③ 難以建立好的控制策略;④ 低效⑤ 昂貴的開發工作⑥缺少并行機制的支持。

2.調試方法
目前，常用的調試方法有以下幾種。
1)試探法
調試人員分析錯誤的癥狀，猜測問題所在的位置，利用在程序中設置輸出語句，分析寄存器、存儲器的內容等手段獲得錯誤的線索，一步步地試探和分析出錯誤所在。這種方法效率很低，適合于結構比較簡單的程序。
2)回溯法調試人員從發現錯誤癥狀的位置開始，人工沿著程序的控制流程往回跟蹤代碼，直到找出錯誤根源為止。這種方法適合于小型程序，對于大規模程序，由于其需要回溯的路徑太多而變得不可操作。
3)對分查找法這種方法主要用來縮小錯誤的范圍，如果已經知道程序中的變量在若干位置的正確取值，可以在這些位置上給這些變量以正確值，觀察程序運行的輸出結果，如果沒有發現問題，則說明從賦予變量一個正確值開始到輸出結果之間的程序沒有錯誤，問題可能在除此之外的程序中。否則錯誤就在所考察的這部分程序中，對含有錯誤的程序段再使用這種方法，直到把故障范圍縮小到比較容易診斷為止。
4)歸納法
歸納法就是從測試所暴露的問題出發，收集所有正確或不正確的數據，分析它們之間的關系，提出假想的錯誤原因，用這些數據來證明或反駁，從而查出錯誤所在。
5)演繹法演經法根據測試結果，列出所有可能的錯誤原因:分析已有的數據，排除不可能和彼此矛盾的原因;對其余的原因，選擇可能性最大的，利用己有的數據完善該假設，使假設更具體;用假設來解釋所有的原始測試結果，如果能解釋這一切，則假設得以證實，也就找出錯誤，否則，要么是假設不完備或不成立，要么有多個錯誤同時存在，需要重新分析，提出新的假設直到發現錯誤為止。

?

?

?