軟件工程基礎知識
軟件工程是指應用計算機科學、數學及管理科學等原理，以工程化的原則和方法來解決軟件問題的工程，其目的是提高軟件生產率、提高軟件質量、降低軟件成本。
軟件工程概述
1968年在德國的NATO（North Atlantic Treaty Organization，北大西洋公約組織）會議上首次提出了“軟件工程”這個名詞，希望用工程化的原則和方法來克服軟件危機。
軟件的生存週期
軟件的生存週期：一個軟件產品或軟件系統也要經歷孕育、誕生、成長、成熟、衰亡等階段。
軟件的生存週期包括：可行性分析與項目開發計劃、需求分析、設計（概要設計和詳細設計）、編碼、測試、維護等活動，可以將這些活動以適當的方式分配到不同的階段去完成。
（1）可行性分析與項目開發計劃
參加人：用戶、項目負責人、系統分析師。
產生的文檔：可行性分析報告和項目開發計劃。
（2）需求分析
參加人：用戶、項目負責人、系統分析師。
產生的文檔：軟件需求說明書。
（3）概要設計
開發人員把確定的各項功能需求轉換成需要的體系結構。
參加人：系統分析師、軟件設計師。
產生的文檔：概要設計說明書。
（4）詳細設計
主要任務是設計功能模塊。
參加人：軟件設計師與程序員。
產生的文檔：詳細設計文檔。
（5）編碼
主要任務是編寫源程序。
（6）測試
參加人：軟件設計師、系統分析師。
產生的文檔：軟件測試計劃、軟件測試報告。
（7）維護
軟件維護是軟件生存週期中時間最長的階段。
軟件生存週期模型
（1）瀑布模型
（2）演化模型
（3）螺旋模型（制定計劃、風險分析、實施工程、用戶評估）
（4）噴泉模型（適合面向對象的開發方法）
軟件開發方法
（1）結構化方法
（2）Jackson方法
（3）維也納開發方法（VDM）
（4）面向對象開發方法（面向對象分析、面向對象設計、面向對象實現）
軟件需求分析
（1）需求分析的任務
確定軟件系統的綜合要求
系統界面要求
系統功能要求
系統性能要求
安全性、保密生、可靠性方面的要求
系統的運行要求
異常處理要求
將來可能提出的要求
分析軟件系統的數據要求
導出系統的邏輯模型
修正項目開發計劃
可開發一個原形系統
需求的分析
軟件需求：功能需求、非功能需求、設計約束。
軟件需求的分析方法
數據域有三種屬性：數據流、數據內容和數據結構。
需求工程
需求工程就是包括創建和維護系統需求文檔所必需的一切活動的過程，也就是指需求開發和需求管理兩個工作。
軟件開發項目管理
成本估算
成本估算方法：
自頂向下估算方法
自底向上估算方法
差別估算法
專家估算法
類推估算法
算式估算法（用於估算的方法有兩種基本類型：由理論導出和由經驗導出）
成本估算模型：
（1）Putnam模型：動態多變量模型。
（2）COCOMO模型：結構性成本模型。
（1）基本COCOMO模型
（2）中級COCOMO模型
（3）詳細COCOMO模型
風險分析
風險分析實際上是四個不同的活動：風險識別、風險預測、風險評估和風險控制。
（1）風險識別
風險識別：是試圖系統化地確定對項目計劃的威脅。
風險條目檢查表：
產品規模
商業影響
客戶特性
過程定義
開發環境
構建的技術
人員數目及經驗
（2）風險預測
風險預測（風險估算）：（1）風險發生的可能性及概率；（2）風險發生了所產生的後果。
風險預測活動：
（1）建立一個尺度或標準，以反映風險發生的可能性。
（2）描述風險的後果。
（3）估計風險對項目和產品的影響。
（4）標註風險預測的整體精確度，以免產生誤解。
（3）風險評估
風險評估三無組：（ri,li,xi），ri基中表示風險；li表示風險發生的概率；xi表示風險產生的影響。
一個對風險很有用的技術就是定義風險參考水準。對於大多數軟件項目來說，成本、進度和性能就是3種典型的風險參考水準。
風險評估中需要執行以下四個步驟：
（1）定義項目的風險參考水平值。
（2）建立每一組（ri,li,xi）與每一個參考水平值的關係。
（3）預測一組臨界點以定義項目終止區域，該區域由一條曲線或不確定區域所界定。
（4）預測什麼樣的風險組合會影響參考水平值。
（4）風險控制
風險控制的目的：輔助項目組建立風險控制的策略。
有效的策略須考慮的三個問題：
（1）風險避免
（2）風險監控
（3）風險管理及意外事件計劃。
進度管理
（1）進度安排的方式
系統最終交付日期已經確定，軟件開發部門必須在規定期限內完成。
系統交付日期只確定了大致年限，最後交付日期由軟件開發部門確定。
（2）進度安排常用圖形描述方法
Gantt圖
PERT圖
人員管理
程序設計小組的組織形式：
（1）主程序員組
（2）無主程序員組
（3）層次式程序員組
軟件配置管理
軟件配置管理（SCM，Software Configure Management）：主要目標是：標識變更、控制變更、確保變更正確的實現，報告有關變更。它是一組管理整個軟件生存期各階段的中變更的活動。
基線：是軟件生存期中各開發階段的一個特定點，它的作用是把開發各階段工作的劃分更加明確化，使本來連續的工作在這些點上斷開，便於檢查與肯定階段成果。
軟件配置項
軟件配置項（Software Configure Item,SCI）是軟件工程中產生的信息項，它是配置管理的基本單位，對已經成爲基線的SCI，雖然可以修改，但必須按照一個特殊的、正式的過程進行評估，確認每一個修改。
以下的SCI是SCM的對象，並可以形成基線：
（1）系統規格說明書。
（2）軟件項目實施計劃書。
（3）軟件需求規格說明書。
（4）設計規格說明書。
（5）源代碼清單。
（6）測試計劃和過程、測試用例和測試結果記錄。
（7）操作和安裝手冊。
（8）可執行程序。
（9）數據庫描述。
（10）用戶手冊。
（11）維護文檔。
（12）軟件工程標準。
（13）項目開發小結。
版本控制
軟件的每一個版本都是SCI的一個彙集，且各個版本都可能由不同的變種組成。
變更控制
爲有效地實現變更控制需要藉助於配置數據庫和基線的概念，配置數據庫可以分爲3類：
（1）開發庫
（2）受控庫（軟件配置庫）
（3）產品庫
軟件工具與軟件開發環境
軟件工具：通常也稱爲CASE（Computer Aided Software Engineering，計算機輔助軟件程）工具。是用來輔助軟件開發、運行、維護、管理、支持等過程中的活動的軟件。
軟件開發環境：是指支持軟件產品開發的軟件系統，它由軟件工具集和環境集成機制構成。
工具集：應包括軟件開發相關過程、活動、任務的軟件工個，以對軟件開發以提供全面的支持。
環境集成機制：爲工具集成和軟件開發、維護和管理提供統一的支持，它通常包括數據集成、控制集成、界面集成。
軟件工具
軟件工具的分類：
（1）軟件開發工具
（1）需求分析工具
（2）設計工具
（3）編碼與排錯工具
（2）軟件維護工具
（1）版本管理工具
（2）文檔分析工具
（3）開發信息庫工具
（4）逆向工程工具
（5）再工程工具
（3）軟件管理和軟件支持工具
（1）項目管理工具
（2）配置管理工具
（3）軟件評價工具
軟件開發環境
軟件開發環境（Software Development Environment）是支持軟件產品開發的軟件系統。由軟件工具集和環境集成機制構成，前者用來支持軟件開發的相關過程、活動和任務；後者爲工具集成和軟件開發、維護和管理提供統一的支持，它通常包括數據集成、控制集成和界面集成。
軟件開發環境的特徵：
（1）環境的服務是集成的。
（2）環境應支持小組工作方式，併爲其提供配置管理。
（3）環境的服務可用於支持各種軟件開發活動，包括分析、設計、編程、測試、調試、文檔等。
軟件過程管理
軟件過程：是軟件生存週期中的一系列相關活動，即用於開發和維護軟件及相關產品的一系列活動。
軟件產品的質量取決於軟件的開發過程，具有良好軟件過程的軟件機構能夠開發出高質量的軟件產品。
軟件過程評估的意義
（1）軟件過程改進的需求
軟件過程不斷改進是軟件工程的基本原理之一
軟件工程七原理：
按軟件的生存週期分階段指定計劃並認真實施；
逐階段進行確認；
堅持嚴格的產品控制；
使用現代程序設計技術；
明確責任；
用人少而精；
不斷改進開發過程。
軟件過程的改進是軟件生存週期的基本過程之一
（2）降低軟件風險的需要
軟件採購者的需要
軟件承製者的需要
軟件能力成熟度模型CMM簡介
軟件能力成熟度模型共分五級：
初始級
可重複級
已定義級
已管理級
優化級
統一過程（UP）
極限編程（XP）
軟件質量管理與質量保證
軟件質量是反映軟件系統或軟件產品滿足規定或隱含需求的能力的特徵和特性全體。
軟件質量保證是指爲保證軟件系統或軟件產品充分滿足用戶要求的質量而進行的有計劃、有組織的活動，其目的是生產高質量的軟件。
軟件質量特性
用來描述軟件質量特性的軟件質量模型：
（1）ISO/IEC 9126軟件質量模型
功能性（適應性、準確性、互用性、依從性、安全性）
可靠性（成熟性、容錯性、可恢復性）
易使用性（易理解性、易學性、易操作性）
效率（時間特性、資源特性）
可維護性（易分析性、易改變性、穩定性、易測試性）
可移植性（適應性、易安裝性、一致性、易替換性）
（2）Mc Call軟件質量模型
Mc Call軟件質量模型從軟件產品的運行、修正、轉移三個方面確定了11個質量特性。
Mc Call給出了一個三層模型框架，第一層是質量特性，第二層是評價準則、第三層是度量指標。
軟件質量保證
軟件質量的三個要點：
（1）滿足用戶需求。
（2）遵循規定的標準。
（3）滿足某些隱含需求。
軟件質量保證7個主要活動相關的各種任務：
（1）應用技術方法
（2）進行正式的技術評審
（3）測試軟件
（4）標準的實施
（5）控制變更
（6）度量
（7）記錄保存和報告
軟件複雜性
軟件度量的一個重要分支就是軟件的複雜性度量。
軟件複雜性度量的主要參數：規模、難度、結構、智能度。
程序複雜性主要有以下幾種度量方法：
（1）代碼行度量法：源代碼的行數
（2）McCabe度量法：控制流的複雜性
軟件評審
質量：通常可以理解爲“用戶滿意程度”。爲了使用用戶滿意，有兩個必要條件：設計質量、程序質量。
設計質量：設計的規格說明書附合用戶的要求。
程序質量：程序按規格說明書所規定的情況正確執行。
設計質量的評審內容
（1）評價軟件的規格說明書是否合乎用戶的要求。
（2）評審可靠性。
（3）評審保密措施實現情況。
（4）評審操作特性實現情況。
（5）評審性能實現情況
（6）評審軟件是否具有可修改性、可擴充性、可互換性和可移植性。
（7）評審軟件是否具有可測試性。
（8）評審軟件是否具有複用性。
程序質量的評審內容
（1）軟件的結構
功能結構
數據結構
功能結構
數據結構與功能結構的對應關係
功能的通用性
模塊的層次
模塊結構
控制流結構
數據流結構
模塊結構與功能結構的對應關係
處理過程的結構
（2）與運行環境的接口
與硬件接口
與用戶接口
軟件容錯技術
提高軟件質量和可靠性的技術大致可分爲兩類：
（1）避開錯誤
（2）容錯技術
容錯軟件的定義
（1）規定功能的軟件，在一定程度上具有容錯能力，則稱之爲容錯軟件。
（2）規定功能的軟件，在因錯誤而發生錯誤時，仍然能在一定程度上完成預期的功能，則把該軟件稱爲容錯軟件。
（3）規定功能的軟件，在一定程序上能從錯誤狀態自動恢復到正常狀態，則稱之爲容錯軟件。
（4）規定功能的軟件，在一定程序上對自身錯誤的作用（軟件錯誤）具有屏蔽能力，則稱此軟件爲具有容錯功能的軟件，即容錯軟件。
容錯的一般方法
實現容錯的主要手段是冗餘。
冗餘技術的分類：
（1）結構冗餘
靜態冗餘
動態冗餘
混合冗餘
（2）信息冗餘
（3）時間冗餘
冗餘附加技術
冗餘附加技術是爲實現冗餘技術所需的資源和技術。
在屏蔽硬件錯誤的容錯技術中，冗餘附加技術包括：
（1）關鍵程序和數據的冗餘存儲和調用。
（2）檢測、表決、切換、重構、糾錯和復算的實現。
在屏蔽軟件錯誤的容錯系統中，冗餘附加技術的構成包括：
（1）冗餘備份程序的存儲及調用。
（2）實現錯誤檢測和錯誤恢復的程序。
（3）實現容錯軟件所需的固化程序。
系統分析基礎知識
系統分析概述
系統分析的目的和任務
系統分析的主要任務：對現行系統進一步詳細調查，將調查中所得到的文檔資料集中，對組織內部整體管理狀況和信息處理過程進行分析，爲系統開發提供所需資料，並提交系統方案說明書。
系統分析的主要步驟
系統分析過程如下：
（1）認識、理解當前的現實環境，獲取當前系統的“物理模型”。
（2）從當前系統的“物理模型”抽象出當前系統的“邏輯模型”。
（3）從當前系統的“邏輯模型”進行分析和優化，建立目標系統的“邏輯模型”。
（4）對目標系統的邏輯模型具體化（物理化），建立目標系統的“物理模型”。
系統分析階段的主要工作步驟分爲：
（1）對當前系統進行詳細調查，收集數據。
（2）建立當前系統的邏輯模型。
（3）對現狀進行分析，提出改進意見和新系統應達到的目標。
（4）建立新系統的邏輯模型。
（5）編寫系統方案說明書。
結構化分析方法
結構化分析（Structured Analysis，SA）：是一種面向數據流的需求分析方法，適用於分析大型數據處理系統。
結構化分析方法的基本思想是自頂向下逐層分解。
分析和抽象是人們控制問題複雜性的兩個基本手段。
SA分析方法的結果：一套分層的數據流圖、一本數據詞典、一組小說明（也稱爲加工邏輯說明）、補充材料。
數據流圖
數據流圖（數據流程圖，Data Flow Diagram，DFD）：是一種便於用戶理解、分析系統數據流程的圖形工具。
DFD的基本成分
（1）外部實體：存在於軟件系統之外的人員或組織。它指出了系統所需數據的發源地和系統產生數據的歸宿地。
（2）加工：描述了輸入數據流到輸出數據流的轉換。
（3）數據存儲：表示暫時存儲的數據，每個數據存儲都要命名。
（4）數據流：有一組固定成分的數據組成，表示數據的流向。除了流入或流出數據存儲的數據流，都要對它進行命名。
分層數據流的畫法
（1）畫系統的輸入和輸出
（2）畫系統的內部
確定加工：數據流的組成或值發生變化的地方，或是根據系統的功能。
確定數據流：當用戶把若干個數據看作一個單位來處理時，可把這些數據看成一個數據流。
確定數據存儲：對於一些以後某個時間要使用的數據可以組織成數據存儲。
（3）畫加工的內部
（4）重複分解子圖
對圖和加工進行編號
（1）父圖與子圖
（2）編號
頂層圖只有一張，不編號
0層圖只有一張，其中的加工號可編爲：0.1、0.2、……，或是1、2、……。
子圖號就是父圖中被分解的加工號。
子圖的加工號由圖號、圓點、序號組成。
應注意的問題：
（1）適當地爲數據流、加工、數據存儲、外部實體命名（名字應反映該成分的實際含義，避免空洞的名字）。
（2）畫數據流而不要畫控制流。
（3）一個加工的輸出數據流不應與輸入數據流同名（即使他們的組成成分相同）。
（4）允許一個加工有多條數據流流向另一個加工，也允許一個加工有兩個相同的輸出數據流流向兩個的加工。
（5）保持父圖與子圖平衡（父圖中某加工的輸入/輸出數據流必須與它的子圖的輸入/輸出數據流在數量上和名字上相同）。
（6）在自頂向下的分解過程中，若一個數據存儲首次出現時只與一個加工有關，那麼這個數據存儲應作爲這個加工的內部文件而不必畫出。
（7）保持數據守恆（一個加工所有輸出數據流中的數據必須能從該加工的輸入數據流中直接獲得，或者是通過該加工能產生的數據）。
（8）每個加工必須既有輸入數據流，又有輸出數據流。
（9）在整套數據流圖中，每一個數據存儲必須既有讀的數據流，又有寫的數據流（在某一張子圖中可能只有讀沒有寫，或者只有寫沒有讀）。
數據詞典
數據詞典就是爲數據流圖中的每個數據流、文件、加工以及組成數據流或文件的數據項作出說明。其中對加工的描述稱爲“小說明”，也可稱爲“加工邏輯說明”。
數據詞典的內容
數據詞典有：數據流、數據項、數據存儲和基本加工4類。
數據項：是組成數據流和數據存儲的最小元素。
源點、終點不在系統之內，故一般不在詞典中說明。
（1）數據流條目：數據流條目給出了DFD中數據流的定義，通常列出該數據流的各組成數據項。
（2）數據存儲條目：數據存儲條目是對數據存儲的定義。
（3）數據項條目：數據項條目是不可再分的數據單位。
（4）加工條目：加工條目是用來說明DFD中基本加工的處理邏輯的。
數據詞典
詞典管理：主要是把詞典條目按照某種格式組織後存儲在詞典中，並提供排序、查找、統計等功能。
加工邏輯的描述
加工邏輯也稱爲“小說明”。
常用的加工邏輯描述方法有三種：結構化語言、判定表和判定樹。
（1）結構化語言
結構化語言的結構：
（1）外層：順序結構、選擇結構、重複結構。
（2）內層：自然語言。
（2）判定表
判定表能清楚地表示覆雜的條件組合與應做的動作之間的對應關係。
判定表由四個部分組成四個區域，判定表的結構如下：
條件定義 || 條件取值的組合
===================================
動作定義 || 在各種取值的組合下應執行的動作
系統分析報告
系統分析報告中，數據流圖、數據字典和加工說明這3部分是主體，是系統分析報告中必不可少的部分。
系統分析報告必須簡明扼要、抓住本質，反映出目標系統的全貌和開發人員的思想。
系統分析報告的主要作用
（1）描述了目標系統的邏輯模型，作爲開發人員進行系統設計和實施的基礎。
（2）作爲用戶和開發人員之間的協議或合同，爲雙方的交流和監督提供基礎。
（3）作爲目標系統驗收和評價的依據。
系統分析報告的主要內容
（1）組織情況概述。
（2）現行系統概述。
（3）系統邏輯模型。
（4）新系統在各個業務處理緩解擬採用的管理方法、算法或模型。
（5）與新系統相配套的管理制度和運行體制的建立。
（6）系統設計與實施的初步計劃。
（7）用戶領導審批意見。
系統設計知識
系統的基本任務大體上分爲概要設計和詳細設計兩個步驟。
概要設計的基本任務
（1）設計軟件系統總體結構
（2）數據結構與數據庫設計
（3）編寫概要設計文檔
（4）評審
詳細設計的基本任務
（1）對每個模塊進行詳細的算法設計。
（2）對模塊內的數據結構進行設計。
（3）對數據庫進行物理設計，即確定數據庫的物理結構。
（4）其它設計。
（5）編寫詳細設計說明書。
（6）評審。
系統設計的基本原理
（1）抽象
（2）模塊化
（3）信息隱藏
（4）模塊獨立（藕合性和內聚性）
系統總體結構設計
系統總體結構設計的原則
（1）分解—協調原則。
（2）自頂向下的原則。
（3）信息隱蔽、抽象的原則。
（4）一致性原則。
（5）明確性原則。
（6）模塊之間的耦合性儘可能小，模塊內部的內聚度儘可能高。
（7）模塊的扇入係數與扇出係數要合理。
（8）模塊的規模適當。
子系統劃分
子系統劃分的原則
（1）子系統要具有相對獨立性。
（2）子系統之間數據的依賴性儘量小。
（3）子系統的劃分的結果應使數據冗餘較小。
（4）子系統的設置就考慮今後管理髮展的需要。
（5）子系統的劃分應便於系統分階段實現。
（6）子系統的劃分就考慮到各類資源的充分利用。
子系統結構設計
（1）每個子系統如何劃分成多個模塊。
（2）如何確定了系統之間、模塊之間傳送的數據及其調用關係。
（3）如何評價並改進模塊結構的質量。
（4）如何從數據流圖導出模塊結構圖。
系統模塊結構設計
模塊：是組成系統的基本單位，特點是可以組合、分解和更換。
根據模塊功能的具體化程序可分爲：邏輯模塊、物理模塊。
模塊應具備的四個要素：
（1）輸入和輸出。
（2）處理功能。
（3）內部數據
（4）程序代碼
模塊結構圖
結構設計的原則：
（1）凝聚性強，獨立性強。
（2）模塊的連接只能存在上下級之間的調用關係，不能有同級之間的橫向聯繫。
（3）整個系統呈樹狀結構，不允許網狀結構或交叉結構關係出現。
（4）所有的模塊都必須嚴格地分類編碼並建立檔案文件。
模塊結構的組成：模塊、調用、數據、控制信息、轉接符號。
數據存儲設計
結構化設計的方法
信息流的類型：變換流、事務流。
變換分析
（1）確定輸入流和輸出流，分離出變換中心。
（2）第一級分解。
（3）第二級分解。
（4）事務分析。
（5）SD方法的設計步驟。
面向數據結構的設計方法
Jackson圖
Jackson方法的設計步驟
（1）分析並確定輸入和輸出數據的邏輯結構。
（2）找出輸入數據結構與輸出數據結構間有對應關係的數據單元。
（3）從描述數據結構的Jackson圖到描述程序結構的Jackson圖。
（4）列出所有操作，並把他們分配到程序結構圖的適當位置。
（5）用僞碼錶示程序。
系統詳細設計
代碼設計
代碼設計的基本原則：唯一性、合理性、可擴充性、簡單性、適用性、規範性、系統性。
代碼設計步驟：
（1）確定輸出內容。
（2）選擇輸出設備與介質。
（3）確定輸出格式。
最終輸出方式常用的有兩種：報表輸出、圖形輸出。
輸入設計
輸入設計就遵循的原則：
（1）最小量原則
（2）簡單性原則
（3）早檢驗原則
（4）少轉換原則
輸入設計的內容
（1）確定輸入數據的內容
（2）輸入方式設計
（3）輸入格式設計
（4）校對方式設計
處理過程設計
（1）程序流程圖
（2）流圖（NS圖）
（3）形式語言
（4）決策樹
（5）決策表
用戶界面設計
（1）菜單方式
（2）會話管理方式
（3）提示方式與權限管理方式
安全控制設計
影響系統安全因素有：
（1）環境性因素
（2）數據處理因素
系統實施的知識
系統實施概述
系統實施的目的和任務
系統實施階段的主要任務：
（1）按總體設計方案購置和安裝計算機網絡系統。
（2）軟件準備。
（3）培訓。
（4）數據準備。
（5）投入切換和試運行。
系統實施的步驟
（1）按總體設計方案購置和安裝計算機網絡系統。
（2）建立數據庫系統。
（3）程序設計。
（4）收集有關數據並進行錄入工作，然後進行系統測試。
（5）人員培訓、系統轉換和試運行。
程序設計
程序設計方法
程序設計方法：結構化方法、原型方法、面向對象方法。
程序設計的基本模塊
基本類型如下：
（1）控制模塊
（2）輸入模塊
（3）輸入數據校驗模塊
（4）輸出模塊
（5）處理模塊
程序設計語言的選擇
系統測試與調試
系統測試的意義、目的及原則
系統測試：是爲了發現錯誤而執行程序的過程，成功的測試是發現尚未發現的錯誤的測試。
系統測試的目的：就是希望以最少的人力和時間發現潛在的各種錯誤和缺陷。
信息系統測試應包括：軟件測試、硬件測試和網絡測試。
信息系統測試的基本原則：
（1）儘早並不斷地進行測試。
（2）測試工作應該避免由原開發軟件的人或小組承擔。
（3）設計測試方案的時候，不僅要確定輸入數據，而且要根據系統功能確定預期輸出結果。
（4）在設計測試實例時，不僅要設計有效合理的輸入條件，也要包含不合理、失效的輸入條件。
（5）在測試程序時，不僅要查檢程序是否做了該做的事，還要檢查程序是否做了不該做的事。
（6）嚴格按照測試計劃進行，避免測試的隨意性。
（7）妥善保存測試計劃、測試例子，作爲軟件文檔的組成部分，爲維護提供方便。
（8）測試例子都是精心設計出來的，可以爲重新測試或追加測試提供方便。
測試過程
一個規範化的測試過程通常包括以下測試活動：
（1）制定測試計劃
（2）編制測試大綱
（3）根據測試大綱設計和生成測試用例
（4）實施測試
（5）生成測試報告
測試策略呼測試方法
軟件測試分爲：靜態測試（人工檢測、計算機輔助分析）、動態測試（黑盒測試法、白盒測試法）。
測試用例的設計
測試用例的組成：測試輸入數據和與之對應的預期輸出結果。在設計測試用例時，應當包括合理的輸入條件和不合理的輸入條件。
用黑盒法設計測試用例
黑盒測試（功能測試）不考慮內部結構和特性，測試軟件的外部特徵。
用黑盒法測試主要是爲了發現以下的錯誤：
（1）錯誤的功能和遺漏的功能。
（2）界面錯誤、輸入是否正確接收、輸出是否正確。
（3）數據結構和外部數據庫訪問錯誤。
（4）性能是否能夠接受。
（5）是否有初始化或終止性錯誤。
用白盒法設計測試用例
白盒測試（結構測試）根據程序的內部結構和邏輯來設計測試例子。
白盒測試常用的技術是邏輯覆蓋和基本路徑測試。
覆蓋標準：語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、條件組合覆蓋、路徑覆蓋。
白盒測試的原則：
（1）程序模塊中的所有獨立徑至少執行一次。
（2）在所有的邏輯判斷中，取“真”和取“假”的兩種情況至少都執行一次。
（3）每個循環都應在邊界條件和一般條件下各執行一次。
（4）測試程序內部數據結構的有效性等。
軟件的測試步聚
（1）單元測試（模塊測試）
（2）集成測試（增量式集成和非增量式集成）
（3）確認測試
（4）系統測試
調試
調試方法：
（1）試探法
（2）回溯法
（3）對分查找法
（4）歸納法
（5）演繹法
系統文檔
系統文檔的作用：
（1）用戶與系統分析人員在系統規劃和系統分析階段通過文檔進行溝通。
（2）系統開發人員與項目管理人員通過文檔在項目期內進行溝通。
（3）系統測試人員與系統開發人員通過文檔進行溝通。
（4）系統開發人員與用戶在系統運行期間進行溝通。
（5）系統開發人員與系統維護人員通過文檔進行溝通。
（6）用戶與維修人員在運行期間進行溝通。
系統轉換
系統試運行階段的主要工作
（1）對系統進行初始化、輸入各原始數據記錄。
（2）覈對新系統輸出和舊系統輸出的結果。
（3）對實際系統的輸入方式進行考察。
（5）對系統實際運行、響應速度進行實際測試。
系統轉換的方式
系統轉換方式：直接轉換、並行轉換、分段轉換。
系統轉換實例
（1）初始階段
（2）推廣階段
（3）控制階段
（4）集成階段
（5）管理階段
（6）成熟階段
系統運行和維護知識
系統維護概述
系統可維護性概念
系統的可維護性可以定性地定義爲：維護人員理解、改正、改動、改進這個軟件的難易程度。
系統可維護性的評價指標：
（1）可理解性
（2）可測試性
（3）可修改性
維護與軟件文檔
文檔是軟件可維護性的決定因素。
軟件系統的文檔可分爲：用戶文檔、系統文檔。
軟件文檔的修改
維護應該針對整個軟件配置，不應該只修改源程序代碼。
系統維護的內容及類型
系統維護主要包括：硬件設備的維護、應用軟件的維護、數據的維護。
（1）硬件維護（定期的設備保養性維護、突發的故障維護）
（2）軟件維護（正確性維護、適應性維護、完善性維護、預防性維護）
（3）數據維護
系統維護的管理和步驟
步驟：
（1）提出維護或修改要求。
（2）領導審查並做出答覆，如同意則列入維護計劃。
（3）領導分配任務，維護人員執行修改。
（4）驗收維護成果並登記修改信息。
系統評價
系統評價的概述
系統評價的分類：（立項評價、中期評價、結項評價）
系統評價注意事項：
（1）數據採集問題
（2）信息系統並不是萬能系統。
系統評價的指標
