一、過 程 管 理
軟件測試過程管理在各個階段的具體內容不同，在每個階段，測試任務都要經過從計劃、設計、執行到結果分析、總結等一系列相同步驟。
軟件測試過程管理主要集中在軟件測試項目啓動、測試計劃制定、測試用例設計、測試執行、測試結果審查和分析，以及如何開發或使用測試過程管理工具。
（一）測試的組織
實施一個測試的首要步驟之一就是考慮測試中涉及到的人員的高級組織、他們之間的相互關係以及如何將測試過程集成到現有的業務管理結構中。
圖10.1給出了測試過程組織的一種常見方法。
1) 測試主管
測試主管有權管理測試過程日常的組織，負責保證在給定的時間、資源和費用的限制下設計測試項目產生滿足所需的質量標準的產品。
測試主管在適當的時候也要負責與開發組進行聯絡，保證他們遵循在過程中引用的單元測試和集成測試方法。測試主管還要同獨立測試觀察員聯繫，接收有關沒有正確遵循測試過程的測試項目的報告。
測試主管向公司內的高級主管或領導報告，如質量保證主管或信息技術領導。在大的公司中，尤其對於那些遵循規範的項目管理過程的公司中，測試主管可以向測試程序委員會報告，該委員會負責把握測試程序的項目管理的總體方向。
測試主管的職位可以是一個兼職的角色，可以由一個現有的高級主管或領導(如QA主管或IT領導)兼任。在測試涉及的人員相對較少的小公司中尤其可能出現這種情況。
2) 測試組組長
測試組組長有權運作一個項目。其職責包括爲測試分析員和測試者分配任務，按照預定的計劃監控他們的工作進度，建立和維護測試項目文件系統，保證產生測試項目相關材料順利完成。這些材料包括：測試計劃文檔、測試規範說明文檔。測試組組長負責完成這些文檔，也可以授權測試分析員來完成這些文檔。
測試組組長聽取一個或多個測試分析員和測試者的報告，並向測試主管彙報。測試組組長將和獨立測試觀察員聯繫(如討論參加一個特定測試的可行性)，適當的時候還會和開發組組長聯繫(完成測試項目的早期計劃和基本的測試設計，並確定AUT測試的有效性)。在驗收測試時，測試組組長負責和用戶代表、操作代表聯繫，以便有一個或多個用戶來執行用戶和操作驗收測試。
3) 測試分析員
測試分析員負責設計和實現用於完成AUT測試的一個或多個測試腳本以及相關的測試用例。測試分析員也可以派去協助測試組組長生成測試規格說明文檔。
在調試測試用例的設計過程中，測試分析員需要分析AUT的需求規格說明，以便確定必須測試的特定需求。在這個過程中，測試分析員應該優先考慮測試用例，以反映被確認的特性的重要性以及在正常使用AUT中導致失敗的特性的風險。可以採用給每個測試用例賦一個高、中或低的值的方法來完成這一工作。這是一項重要的工作，因爲這種方法可以幫助測試組組長在時間和資源有限的情況下集中測試的人力。
在完成測試項目後，測試分析員負責備份和歸檔所有的測試文檔和材料。這些材料將提交給測試組組長進行歸檔。測試分析員還負責完成一份測試總結報告，這份報告簡要介紹該測試項目中的關鍵點。
測試分析員要向測試組組長彙報，並在開始測試AUT之前和測試者聯繫，向他們簡單介紹測試者的任務。
4) 測試者
測試者主要負責執行由測試分析員建立的測試腳本，並負責解釋測試用例結果並將結果記錄到文檔中。
在執行測試腳本之前，測試者首先要建立和初始化測試環境，其中包括測試數據和測試硬件，以及其它支持測試所需的軟件(加模擬器和測試輔助程序)。
在測試執行過程中，測試者負責填寫測試結果記錄表格，以便記錄執行每個測試腳本時觀察到的結果。測試者使用測試腳本對預期結果進行描述。
在完成測試以後，測試者還負責備份測試數據、模擬器或測試輔助程序以及測試中使用的硬件的說明。這些材料將提交給測試組組長歸檔。
（二）測試計劃階段
測試計劃要針對測試目的來規定測試的任務、所需的各種資源和投入、人員角色的安排、預見可能出現的問題和風險，以指導測試的執行，最終實現測試的目標，保證軟件產品的質量。
編寫測試計劃的目的是：
(1) 爲測試各項活動制定一個現實可行的、綜合的計劃，包括每項測試活動的對象、範圍、方法、進度和預期結果。
(2) 爲項目實施建立一個組織模型，並定義測試項目中每個角色的責任和工作內容。
(3) 開發有效的測試模型，能正確地驗證正在開發的軟件系統。
(4) 確定測試所需要的時間和資源，以保證其可獲得性和有效性。
(5) 確立每個測試階段測試完成以及測試成功的標準和要達到的目標。
(6) 識別出測試活動中的各種風險，並消除可能存在的風險，降低那些不可能消除的風險所帶來的損失。
1．測試策略的制定
測試策略描述當前測試的目標和所採用的測試方法。這個目標不是上述測試計劃的目標，而是針對某個應用軟件系統或程序的。具體的測試任務要達到的預期結果，包括在規定的時間內哪些測試內容要完成，軟件產品的特性或質量在哪些方面要得到確認。測試策略還要描述測試不同階段(單元測試、集成測試、系統測試)的測試對象、範圍和方法以及每個階段內所要進行的測試類型(功能測試、性能測試、壓力測試等)。
2．測試計劃過程
測試計劃經過計劃初期、起草、討論、審查等不同階段，最終生成。測試計劃過程如下所示：
(1) 計劃初期是收集整體項目計劃、需求分析、功能設計、系統原型、用例報告等文檔或信息，理解用戶的真正需求，瞭解技術難點、弱點或新的技術，和其餘項目相關人員交流，在各個主要方面達到一致的理解。
(2) 測試計劃最關鍵的一步就是確定測試需求、測試層次。將軟件分解成單元，對各個單元寫成測試需求，測試需求也是測試設計和開發測試用例的基礎，是用來衡量測試覆蓋率的重要指標。
(3) 計劃起草。根據計劃初期所掌握的各種信息、知識，確定測試策略，設計測試方法，完成測試計劃的框架。
(4) 內部審查。在提供給其它部門討論之前，先在測試小組或部門內部進行審查。
(5) 計劃討論和修改。召開有需求分析、設計、開發人員參加的計劃討論會議，測試組長將測試計劃設計的思想、策略做較詳細的介紹，並聽取大家對測試計劃中各個部分的意見，進行討論交流。
(6) 測試計劃的多方審查。項目中的每個人(即市場人員、開發人員、技術支持人員及測試人員)都應當參與審查。
(7) 測試計劃的定稿和批准。在計劃討論、審查的基礎上，綜合各方面的意見，就可以完成測試計劃書，然後報給測試經理或 QA 經理，得到批准，方可執行。
3．測試計劃的要點
軟件測試計劃的內容主要包括：產品基本情況、測試需求說明、測試策略說明、測試資源配置、計劃表、問題跟蹤報告、測試計劃的評審、結果等。除了產品基本情況、測試需求說明、測試策略等，測試計劃的焦點集中在：
(1) 計劃的目的：項目的範圍和目標，各階段的測試範圍、技術約束和管理特點。
(2) 項目估算：使用的歷史數據，使用的評估技術，工作量、成本、時間估算依據。
(3) 風險計劃：測試可能存在的風險的分析、識別，以及風險的迴避、監控、管理。
(4) 日程：項目工作分解結構，並採用時限圖、甘特圖等方法制定時間/資源表。
(5) 項目資源：人員、硬件和軟件等資源的組織和分配，人力資源是重點，日程安排是核心。
(6) 跟蹤和控制機制：質量保證和控制，變更管理和控制等。測試計劃書的內容也可以按集成測試、系統測試、驗收測試等階段去組織，爲每一個階段制定一個計劃書，也可以爲每個測試任務/目的(安全性測試、性能測試、可靠性測試等)制定特別的計劃書。
4．測試計劃的編寫內容
測試計劃內容有被測軟件的背景信息、測試目標、測試步驟、測試數據整理以及評估準則。它包括：
(1) 測試環境。在不同的條件下進行測試，所得到的結果是不同的。在測試計劃中測試環境指用戶使用環境或業務運行環境。
(2) 測試基本原理和策略。
(3) 測試計劃階段劃分。
(4) 測試計劃要點。
(5) 功能描述和功能覆蓋說明。
(6) 測試用例清單。說明每個測試用例所測試的內容。
(7) 測試開始準則和退出準則。
每個測試用例的序言至少包括下列信息：
(1) 測試用例說明和用途。
(2) 設置需求(輸入、輸出)。
(3) 運行測試用例的操作命令。
(4) 正常和異常信息。
(5) 編寫測試用例的作者。
（三） 軟件測試設計和開發
當測試計劃完成之後，測試過程就要進入軟件測試設計和開發階段。軟件測試設計是建立在測試計劃書的基礎上的。認真理解測試計劃的測試大綱、測試內容及測試的通過準則，通過測試用例來完成測試內容與程序邏輯的轉換，作爲測試實施的依據，以實現所確定的測試目標。軟件設計是將軟件需求轉換成爲軟件表示的過程，主要描繪出系統結構、詳細的處理過程和數據庫模式；軟件測試設計則是將測試需求轉換成測試用例的過程，它要描述測試環境、測試執行的範圍、層次和用戶的使用場景以及測試輸入和預期的測試輸出等。所以軟件測試設計和開發是軟件測試過程中一個技術深、要求高的關鍵階段。
軟件測試設計和開發的主要內容有：
(1) 制定測試的技術方案，確認各個測試階段要採用的測試技術、測試環境和平臺，以及選擇什麼樣的測試工具。系統測試中的安全性、可靠性、穩定性、有效性等測試技術方案是這部分工作內容的重點。
(2) 設計測試用例。根據產品需求分析、系統設計等規格說明書，在測試技術選擇的方案基礎上，設計具體的測試用例。
(3) 設計測試用例特定的集合，滿足一些特定的測試目的和任務，即根據測試目標、測試用例的特性和屬性(優先級、層次、模塊等)來選擇不同的測試用例，構成執行某個特定測試任務的測試用例集合(組)，如基本測試用例組、專用測試用例組、性能測試用例組、其它測試用例組等。
(4) 測試開發。根據所選擇的測試工具，將所有可以進行自動化測試的測試用例轉換爲測試腳本的過程。
(5) 測試環境的設計。根據所選擇的測試平臺以及測試用例所要求的特定環境，進行服務器、網絡等測試環境的設計。
1. 測試用例設計的方法和管理
軟件測試用例設計的方法有“白盒”測試和“黑盒”測試相對應的設計方法。“黑盒”測試的用例設計，採用等價類劃分、因果圖法、邊值分析、用戶界面測試、配置測試、安裝選項驗證等方法，適用於功能測試和驗收測試。“白盒”測試的用例設計有以下方法：
(1) 採用邏輯覆蓋(包括程序代碼的語句覆蓋、條件覆蓋、分支覆蓋)的結構測試用例的設計方法。
(2) 基於程序結構的域測試用例設計方法。“域”是指程序的輸入空間，域測試正是在分析輸入空間的基礎上，完成域的分類、定義和驗證，從而對各種不同的域選擇適當的測試點(用例)進行測試。
(3) 數據流測試用例設計的方法，是通過程序的控制流，從建立的數據目標狀態的序列中發現異常的結構測試方法。
(4) 根據對象狀態或等待狀態變化來設計測試用例，也是比較常見的方法。
(5) 基於程序錯誤的變異來設計測試用例，可以有效地發現程序中某些特定的錯誤。
(6) 基於代數運算符號的測試用例設計方法，受分支問題、二義性問題和大程序問題的困擾，使用較少。
2. 測試開發
根據所選擇的測試工具腳本語言，編寫測試腳本，將所有可以進行自動化測試的測試用例轉化爲測試腳本。其輸入就是基於測試需求的測試用例，輸出是測試腳本和與之相對應的期望結果，這種期望結果一般存儲在數據庫中或特定的格式化文件中。
測試開發的步驟如下：
首先要設立測試腳本開發環境，安裝測試工具軟件，設置管理服務器和具有代理的客戶端，建立項目的共享路徑、目錄，並能連接到腳本存儲庫和被測軟件等。
然後執行錄製測試的初始化過程、獨立模塊過程、導航過程和其它操作過程。結合已經建立的測試用例，將錄製的測試腳本進行組織、調試和修改，構造成一個有效的測試腳本體系，並建立外部數據集合。
（四）測試執行階段
當測試用例的設計和測試腳本的開發完成之後，就開始執行測試。測試的執行有手工測試和自動化測試兩種。手工測試指在合適的測試環境上，按照測試用例的條件、步驟要求，準備測試數據，對系統進行操作，比較實際結果和測試用例所描述的期望結果，以確定系統是否正常運行或正常表現。自動化測試是通過測試工具，運行測試腳本，並自動記錄下測試結果。
針對每個測試階段(代碼審查、單元測試、集成測試、功能測試、系統測試、驗收測試和安裝測試等)的結果進行分析，保證每個階段的測試任務得到執行，達到階段性目標。
（五）測試執行結束和測試總結
測試執行全部完成，並不意味着測試項目的結束。測試項目結束的階段性標誌是將測試報告或質量報告發出去後，得到測試經理或項目經理的認可。除了測試報告或質量報告的寫作之外，還要對測試計劃、測試設計和測試執行等進行檢查、分析，完成項目的總結，編寫“測試總結報告”。
（六）測試過程改進
軟件測試過程改進主要着眼於合理調整各項測試活動的時序關係，優化各項測試活動的資源配置以及實現各項測試活動效果的最優化。在軟件測試過程中，過程改進被賦予了舉足輕重的地位，在測試計劃、實施、檢查、改進的循環中，過程改進既是一次質量活動的終點，又是下次質量活動的原點，起着承上啓下的作用。
1．軟件測試過程改進的概念
測試過程的改進對象應該包括三個方面：組織、技術和人員。測試過程改進需要對組織給予特別關注，因爲過程都是基於特定的組織架構建設的，而且組織設置是否合理對過程的好壞有決定性的影響。軟件測試組織的不良架構通常表現在：
(1) 沒有恰當的角色追蹤項目進展。
(2) 沒有恰當的角色進行缺陷控制、變更和版本追蹤。
(3) 項目在測試階段效率低下、過程混亂。
(4) 只有測試經理了解項目，項目成了個人的項目，而不是組織的項目。
(5) 關心進度，而忘記了項目的另外兩個要素—質量和成本。
上述問題可從組織上找出原因。因此在測試過程改進中可以先將測試從開發活動中分離出來，把缺陷控制、版本管理和變更管理從項目管理中分離出來。此外，需要給測試經理賦予明確的職責和目標。技術的改進包括對流程、方法和工具的改進，它包括組織或者項目對流程進行明確的定義，引入統一的管理方法，並使用標準的經過組織認可的工具和模板。人員的改進主要是指對企業文化的改進，它將促使建立高效率的團隊和組織。
由於測試過程改進是一項長期的、沒有終點的活動，而且要獲得改進過程的收益也是長期的過程，因此在起步實施測試過程改進時，要充分考慮戰略，並根據公司的戰略目標確定測試部門的戰略，描繪遠景。將測試過程改進與公司戰略目標相聯繫，是改進成功實施的必要條件，也是各公司在實施測試過程改進中獲得的最佳實踐。
2. 軟件測試過程改進的具體方法
過程改進在軟件測試過程中佔有舉足輕重的位置，因此爲了更好地保證軟件質量，測試過程改進是測試人員經常要做的事情。下面列出了一些軟件測試過程改進的具體方法：
(1) 調整測試活動的時序關係。在軟件測試過程的測試計劃中，不恰當的測試時序會引起誤工和測試進度失控。例如，具體到某個工程實踐中，有些測試活動是可以並行的，有些測試活動是可以歸併完成的，有些測試活動在時間上存在線性關係等。所有這些一定要區分清楚並且要做最優化調整，否則會對測試進度產生不必要的影響。
(2) 優化測試活動資源配置。在軟件測試過程中，必然會涉及到人力、設備、場地、軟件環境與經費等資源。那麼如何合理地調配各項資源給相關的測試活動是非常值得斟酌的，否則會引起誤工和測試進度的失控。在測試資源配置中最常見的是人力資源的調配，測試部門如果能深入瞭解員工的專長與興趣所在，在進行人員分配時，根據各自的特點進行分配，就能對測試活動的開展起到事半功倍的效果。
(3) 提高測試計劃的指導性。測試計劃的指導性是指測試計劃的執行能力。在軟件測試過程中，很多時候實際的測試和測試計劃是脫節的，或者說很大程度上沒有按照測試計劃去執行。測試計劃的完成不僅僅是起草測試大綱，而且是爲了確保測試大綱中計劃的內容能真正被執行、真正用於指導測試工作，爲了更好地完成測試活動，保證軟件的質量。
(4) 確立合理的度量模型和標準。在測試過程改進中，測試過程改進小組應根據企業與項目的實際情況制定適合自己公司的質量度量模型和標準，做出符合自己公司發展策略的投入。但是質量度量模型和標準的確立不是馬上就可以進行的，而是測試過程改進小組隨着測試過程的進行不斷實踐、不斷總結、不斷改進的。
(5) 提高覆蓋率。覆蓋率越高，表明測試的質量越高。覆蓋率包括內容覆蓋和技術覆蓋。內容覆蓋指的是起草測試計劃、設計測試用例、執行測試用例和跟蹤軟件缺陷。內容覆蓋率越高，就越能避免故障被遺漏的情況。技術覆蓋指一項技術指標要儘可能地做到測試技術的覆蓋，採用科學的方法來驗證某項指標，可以更好地保證產品的質量。
二、需 求 管 理
（一） 需求管理概述
Standish Group從1994年到2001年的CHAOS Reports證實，導致項目失敗的最重要的原因與需求有關。2001年，Standish Group 的CHAOS Reports報導了該公司的一項研究，該公司對多個項目作調查後發現，百分之七十四的項目是失敗的，即這些項目不能按時按預算完成。其中提到最多的導致項目失敗的原因就是“變更用戶需求”。
（二）軟件測試中的需求分析
1．熟悉需求背景及商業目標
(1) 瞭解清楚項目發起的原因是爲了解決用戶的什麼問題。
(2) 清楚當前的解決方案是不是最優的以及爲什麼會這樣做。
2．業務模型法
(1) 考慮本項目與外部系統的交互，劃分系統邊界(除了本項目的需求中要求做的事情，其它的都可以是外部系統，本系統和外部系統之間的交互就是系統的邊界)。可以參考系統分析說明書。
(2) 確定測試範圍和關注點。系統的邊界是測試的重點，特別需要關注邊界交互時的數據交互。
3．業務場景法
(1) 考慮用例的調用者，考慮每一個用例提供的服務是供哪些外部用例或者系統調用，找出所有的調用者。調用的前提、約束都要考慮。每一個調用都可以考慮成一個大的業務流程。(一般和外部有交互的用例出錯的概率比較大，需要重點關注。具體被哪些外部調用，每個產品線都需要自己整理添加。)
(2) 考慮系統內部各個用例之間的交互(有可能PD劃分用例的粒度不同，我們暫時考慮用戶一次提交併且系統的狀態及數據發生變化的功能是一個用例)，形成內部業務流程圖。需要分析每個用例之間的約束關係、執行條件，設計出各種業務流程圖。
4．功能分解法
(1) 業務功能：與用戶實際業務直接相關的功能或細節。
(2) 輔助功能：輔助完成業務功能的一些功能或細節，比如設置過濾條件。
(3) 數據約束：主要用於控制在執行功能時，數據的顯示範圍、數據之間的關係等。
(4) 易用性需求：產品中必須提供便於功能操作使用的一些細節，比如快捷鍵就是典型的易用性需求。
(5) 編輯約束：在功能執行時，對輸入數據項目設定一些約束性條件，比如只能輸入數字。
(6) 參數需求：在功能中，需要根據參數設置不同，進行不同處理的細節。
(7) 權限需求：這裏的權限是指在功能的執行過程中，根據不同的權限進行不同的處理，不包括直接限制某個功能的權限。
(8) 性能約束：執行功能時，必須滿足的性能要求目前基本不涉及。
三、 軟件配置管理
（一）軟件配置管理概述
軟件配置管理(Software Configuration Management，SCM)是一種標識、組織和控制修改的技術。軟件配置管理應用於整個軟件工程過程。
軟件配置管理是在貫穿整個軟件生命週期中建立和維護項目產品的完整性。它的基本目標包括：
(1) 軟件配置管理的各項工作是有計劃進行的。
(2) 被選擇的項目產品得到識別、控制並且可以被相關人員獲取。
(3) 已識別出的項目產品的更改得到控制。
(4) 使相關組別和個人及時瞭解軟件基準的狀態和內容。
爲了達到上述目標，如下的方針應該得到貫徹執行：
(1) 技術部門經理和具體項目主管應該使用和遵循XSSC的OSSP中所描述的軟件配置管理的工作過程。
(2) 施行軟件配置管理的職責應被明確分配。相關人員得到軟件配置管理方面的培訓。
(3) 技術部門經理和具體項目主管應該明確他們在相關項目中所擔負的軟件配置管理方面的責任。
(4) 軟件配置管理工作應該享有足夠的資金支持，這需要在客戶、技術部門經理和具體項目主管之間協商。
(5) 軟件配置管理應該實施於如下產品：對外交付的軟件產品以及那些被選定的在項目中使用的支持類工具等。
(6) 軟件配置的整體性在整個項目生命週期中得到控制。
(7) 軟件質量保證人員應該定期審覈各類軟件基準以及軟件配置管理工作。
(8) 軟件基準的狀態和內容能夠及時通知給相關組別和個人。
（二） 軟件配置管理角色職責
對於任何一個管理流程來說，保證該流程正常運轉的前提條件就是要有明確的角色、職責和權限的定義。特別是在引入了軟件配置管理的工具之後，比較理想的狀態就是：組織內的所有人員按照不同的角色要求，根據系統賦予的權限來執行相應的動作。因此，在本文所介紹的這個軟件配置管理過程中主要涉及下列的角色和分工。
1) 項目經理
項目經理(Project Manager，PM)是整個軟件研發活動的負責人，他根據軟件配置控制委員會的建議，批准配置管理的各項活動並控制它們的進程。其具體職責爲以下幾項：
(1) 制定和修改項目的組織結構和配置管理策略。
(2) 批准、發佈配置管理計劃。
(3) 決定項目起始基線和開發里程碑。
(4) 接受並審閱配置控制委員會的報告。
2) 配置控制委員會
(1) 配置控制委員會(Configuration Control Board，CCB)負責指導和控制配置管理的各項具體活動的進行，爲項目經理的決策提供建議。其具體職責爲以下幾項：定製開發子系統；定製訪問控制；制定常用策略。
(2) 建立、更改基線的設置，審覈變更申請。
(3) 根據配置管理員的報告決定相應的對策。
3) 配置管理員
配置管理員(Configuration Management Officer，CMO)根據配置管理計劃執行各項管理任務，定期向CCB提交報告並列席CCB的例會。其具體職責爲以下幾項：
(1) 軟件配置管理工具的日常管理與維護。
(2) 提交配置管理計劃。
(3) 各配置項的管理與維護。
(4) 執行版本控制和變更控制方案。
(5) 完成配置審計並提交報告。
(6) 對開發人員進行相關的培訓。
(7) 識別軟件開發過程中存在的問題並擬就解決方案。
4) 系統集成員
系統集成員(System Integration Officer，SIO)負責生成和管理項目的內部和外部發布版本，其具體職責爲以下幾項：
(1) 集成修改。
(2) 構建系統。
(3) 完成對版本的日常維護。
(4) 建立外部發布版本。
5) 開發人員
開發人員(Developer，DEV)的職責就是根據組織內確定的軟件配置管理計劃和相關規定，按照軟件配置管理工具的使用模型來完成開發任務。
（三）軟件配置管理過程描述
1．項目計劃階段
一個項目設立之初，PM首先需要制定整個項目的計劃，它是項目研發工作的基礎。在有了總體研發計劃之後，軟件配置管理的活動就可以開展了。
在軟件配置管理計劃的制定過程中，它的主要流程如下：
(1) CCB根據項目的開發計劃確定各個里程碑和開發策略。
(2) CMO根據CCB的規劃，制定詳細的配置管理計劃，交CCB審覈。
(3) CCB通過配置管理計劃後交項目經理批准，發佈實施。
2．項目開發和維護階段
這一階段是項目研發的主要階段。在這一階段中，軟件配置管理活動主要分爲三個層面：
(1) 主要由CMO完成的管理和維護工作。
(2) 由SIO和DEV具體執行軟件配置管理策略。
(3) 變更流程。
這三個層面是彼此之間既獨立又互相聯繫的有機的整體。
在這個軟件配置管理過程中，它的核心流程應該是這樣的：
(1) CCB設定研發活動的初始基線。
(2) CMO根據軟件配置管理規劃設立配置庫和工作空間，爲執行軟件配置管理做好準備。
(3) 開發人員按照統一的軟件配置管理策略，根據獲得的授權的資源進行項目的研發工作。
(4) SIO按照項目的進度集成組內開發人員的工作成果，並構建系統，推進版本的演進。
在這個軟件配置管理過程中，它的核心流程應該是這樣的：
(1) CCB設定研發活動的初始基線。
(2) CMO根據軟件配置管理規劃設立配置庫和工作空間，爲執行軟件配置管理做好準備。
(3) 開發人員按照統一的軟件配置管理策略，根據獲得的授權的資源進行項目的研發工作。
(4) SIO按照項目的進度集成組內開發人員的工作成果，並構建系統，推進版本的演進。
（四）軟件配置管理的關鍵活動
1．配置項(Software Configuration Item，SCI)識別 Pressman對於SCI給出了一個比較簡單的定義：“軟件過程的輸出信息可以分爲三個主要類別：
① 計算機程序(源代碼和可執行程序)。
② 描述計算機程序的文檔(針對技術開發者和用戶)。
③ 數據(包含在程序內部或外部)。這些項包含了所有在軟件過程中產生的信息，總稱爲軟件配置項。”
軟件的開發過程是一個不斷變化着的過程，爲了在不嚴重阻礙合理變化的情況下控制變化，軟件配置管理引入了“基線(Base Line)”這一概念。IEEE對基線的定義是這樣的：“已經正式通過複審核批准的某規約或產品，它因此可作爲進一步開發的基礎，並且只能通過正式的變化控制過程改變。”
軟件的開發流程中把所有需加以控制的配置項分爲基線配置項和非基線配置項兩類。
2．工作空間管理
在引入了軟件配置管理工具(如CVS、VSS等)之後，所有開發人員都會被要求把工作成果存放到由軟件配置管理工具所管理的配置庫中，或是直接工作在軟件配置管理工具提供的環境之下。所以爲了讓每個開發人員和各個開發團隊能更好地分工合作，同時又互不干擾，對工作空間的管理和維護也成爲了軟件配置管理的一個重要的活動。
一般來說，比較理想的情況是把整個配置庫視爲一個統一的工作空間，然後再根據需要把它劃分爲個人(私有)、團隊(集成)和全組(公共)這三類工作空間(分支)，從而更好地支持將來可能出現的並行開發的需求。
每個開發人員按照任務的要求，在不同的開發階段，工作在不同的工作空間上。例如：對於私有開發空間而言，開發人員根據任務分工獲得對相應配置項的操作許可之後，即在自己的私有開發分支上工作，其所有工作成果體現爲在該配置項的私有分支上的版本的推進，除該開發人員外，其他人員均無權操作該私有空間中的元素；而集成分支對應的是開發團隊的公共空間，該開發團隊擁有對該集成分支的讀寫權限，其他成員只有只讀權限，它的管理工作由SIO負責；至於公共工作空間，則是用於統一存放各個開發團隊的階段性工作成果，它提供全組統一的標準版本，並作爲整個組織的知識庫。
3．版本控制
版本控制是軟件配置管理的核心功能。所有置於配置庫中的元素都應自動予以版本的標識，並保證版本命名的唯一性。版本在生成過程中，自動依照設定的使用模型自動分支、演進。除了系統自動記錄的版本信息以外，爲了配合軟件開發流程的各個階段，還需要定義、收集一些元數據來記錄版本的輔助信息和規範開發流程，並對軟件過程的度量做好準備。
4．變更控制
基線與變更控制緊密相連，在對各個SCI做出了識別，並且利用工具對它們進行了版本管理之後，如何保證它們在複雜多變的開發過程中真正地處於受控的狀態，並在任何情況下都能迅速地恢復到任一歷史狀態就成爲了軟件配置管理的另一重要任務。因此，變更控制就是通過結合人的規程和自動化工具，以提供一個變化控制的機制。 變更控制的對象主要指配置庫中的各基線配置項，變更管理的一般流程如下：
(1) (獲得)提出變更請求。
(2) 由CCB審覈並決定是否批准。
(3) (被接受)修改請求分配人員，提取SCI，進行修改。
(4) 複審變化。
(5) 提交修改後的SCI。
(6) 建立測試基線並測試。
(7) 重建軟件的適當版本。
(8) 複審(審計)所有SCI的變化。
(9) 發佈新版本。
5．配置狀態報告
配置狀態報告就是根據配置項操作數據庫中的記錄來向管理者報告軟件開發活動的進展情況。這樣的報告應該是定期進行，並儘量通過CASE工具自動生成，用數據庫中的客觀數據來真實反映各配置項的情況。
配置狀態報告應根據報告着重反映當前基線配置項的狀態，以作爲對開發進度報告的參照。同時也能從中根據開發人員對配置項的操作記錄來對開發團隊的工作關係作一定的分析。
6．配置審計
配置審計的主要作用是作爲變更控制的補充手段，來確保某一變更需求已被切實實現。在某些情況下，它被作爲正式的技術複審的一部分，但當軟件配置管理是一個正式的活動時，該活動由SQA人員單獨執行。
四、缺 陷 管 理
（一） 缺陷跟蹤管理系統概述
缺陷跟蹤管理系統(Defect Tracking System)是用於集中管理軟件測試過程中發現的缺陷的數據庫程序，可以通過添加、修改、排序、查尋、存儲操作來管理軟件缺陷。
1) 缺陷跟蹤管理系統的作用
(1) 便於缺陷的查找和跟蹤。對於大中型軟件的測試過程而言，報告的缺陷總數可能多達成千上萬個，如果沒有缺陷跟蹤管理系統的支持，要求查找某個錯誤，其難度和效率可想而知。
(2) 便於協同工作。缺陷跟蹤管理系統可以作爲測試人員、開發人員、項目負責人、缺陷評審人員協同工作的平臺。
(3) 保證測試工作的有效性。避免測試人員重複報錯，同時也便於及時掌握各缺陷的當前狀態，進而完成對應狀態的測試工作。
(4) 便於跟蹤和監控錯誤的處理過程和方法。可以方便地檢查處理方法是否正確，跟蹤處理者的姓名和處理時間，作爲工作量的統計和業績考覈的參考。
2) 缺陷跟蹤管理系統的實現原理
缺陷跟蹤管理系統在實現技術層面上看是一個數據庫應用程序。它包括前臺用戶界面、後臺缺陷數據庫以及中間數據處理層。
這類系統的用戶界面所顯示的信息一般應根據用戶的角色不同(測試人員、開發人員、項目負責人、缺陷評審員等)而略有差異，因爲各個角色使用該系統完成的任務各不相同，如測試人員用於報告缺陷或確認缺陷是否可以關閉，開發人員用於瞭解哪些缺陷需要他去處理以及缺陷經過處理後是否被關閉，而項目負責人需要及時瞭解當前有哪些新的缺陷，哪些必須及時修正等等。另外，不同角色所擁有的數據操作權限也不盡相同。例如開發人員無權通過其用戶界面往數據庫中填寫新的缺陷信息，也無權關閉某個已知缺陷；而測試人員無權決定分配誰去修正某個已知缺陷，無權決定是否要修正某個缺陷。
（二） 軟件缺陷內容
軟件缺陷包括如下內容：
(1) 可追蹤信息。如給每個缺陷分配一個缺陷編號，則每個編號必須是唯一的，可以根據該編號搜索、查看該缺陷的處理情況。
(2) 缺陷的基本信息。通常缺陷的基本信息包括缺陷狀態、缺陷標題、缺陷嚴重程度、缺陷緊急程度、缺陷提交人、缺陷提交日期、缺陷所屬、缺陷解決人、缺陷解決時間、缺陷解決結果、缺陷處理人、缺陷處理最終時間、缺陷處理結果、缺陷確認人、缺陷確認時間、缺陷確認結果等等。
(3) 缺陷的詳細描述，即對缺陷的特徵應做詳細的描述。例如程序代碼中的錯誤，應詳細描述錯誤發生的軟硬件環境、相關輸入輸出數據、出錯時程序的狀態等等，以方便編碼人員進行錯誤復現和錯誤定位。又如設計規格說明中的錯誤，應指明它與高層軟件開發文檔(如需求規格說明)中哪些條款相違背，爲什麼判爲違背，都需要描述清楚，以方便設計人員進一步覈實。
(4) 必要的附件。有時，某些缺陷可能無法用語言文字表達清楚，如用戶界面出現的一些缺陷，光用語言文字難以表述清楚。這時，就需要藉助於屏幕拷貝等方式來進一步描述缺陷。
（三）軟件跟蹤缺陷處理的一般流程
軟件跟蹤管理確保每個被發現的缺陷都能被解決。解決可能是指缺陷被修正，也可能是指項目組成員達成一致的處理意見(如不作處理)。
軟件跟蹤缺陷處理的流程如圖10.3所示。
![]()
圖10.3 缺陷處理流程
五、 風 險 管 理
（一）風險管理概述
近幾年來軟件開發技術、工具都有了很大的進步，但是軟件項目開發超時、超支，甚至不能滿足用戶需求而根本沒有得到實際使用的情況仍然比比皆是。軟件項目開發和管理中一直存在着種種不確定性，嚴重影響着項目的順利完成和提交。但這些軟件風險並未得到充分的重視和系統的研究。直到20世紀80年代，Boehm比較詳細地對軟件開發中的風險進行了論述,並提出軟件風險管理的方法。Boehm認爲,軟件風險管理指的是“試圖以一種可行的原則和實踐，規範化地控制影響項目成功的風險”，其目的是“辨識、描述和消除風險因素，以免它們威脅軟件的成功運作”。
（二）軟件項目風險管理
風險管理涉及的主要過程包括風險識別、風險量化、風險應對計劃制定和風險監控，如圖10.4所示。風險識別在項目的開始時就要進行，並在項目執行中不斷進行。就是說，在項目的整個生命週期內，風險識別是一個連續的過程。
（三）軟件項目中的風險
軟件項目的風險無非體現在以下四個方面：需求、技術、成本和進度。IT項目開發中常見的風險有如下幾類：
1) 需求風險
(1) 需求已經成爲項目基準，但需求還在繼續變化；
(2) 需求定義欠佳，而進一步的定義會擴展項目範疇；
(3) 添加額外的需求；
(4) 產品定義含混的部分比預期需要更多的時間；
(5) 在做需求時客戶參與不夠；
(6) 缺少有效的需求變化管理過程。
2) 計劃編制風險
(1) 計劃、資源和產品定義全憑客戶或上層領導口頭指令，並且不完全一致；
(2) 計劃是優化的，是“最佳狀態”，但計劃不現實，只能算是“期望狀態”；
(3) 計劃基於使用特定的小組成員，而那個特定的小組成員其實指望不上；
(4) 產品規模(代碼行數、功能點、與前一產品規模的百分比)比估計的要大；
(5) 完成目標日期提前，但沒有相應地調整產品範圍或可用資源；
(6) 涉足不熟悉的產品領域，花費在設計和實現上的時間比預期的要多。
3) 組織和管理風險
(1) 僅由管理層或市場人員進行技術決策，導致計劃進度緩慢，計劃時間延長；
(2) 低效的項目組結構降低生產率；
(3) 管理層審查決策的週期比預期的時間長；
(4) 預算削減，打亂項目計劃；
(5) 管理層作出了打擊項目組積極性的決定；
(6) 缺乏必要的規範，導致工作失誤與重複工作；
(7) 非技術的第三方的工作(預算批准、設備採購批准、法律方面的審查、安全保證等)時間比預期的延長。
4) 人員風險
(1) 作爲先決條件的任務(如培訓及其它項目)不能按時完成；
(2) 開發人員和管理層之間關係不佳，導致決策緩慢，影響全局；
(3) 缺乏激勵措施，士氣低下，降低了生產能力；
(4) 某些人員需要更多的時間適應還不熟悉的軟件工具和環境；
(5) 項目後期加入新的開發人員，需進行培訓並逐漸與現有成員溝通，從而使現有成員的工作效率降低；
(6) 由於項目組成員之間發生衝突，導致溝通不暢、設計欠佳、接口出現錯誤和額外的重複工作；
(7) 不適應工作的成員沒有調離項目組，影響了項目組其他成員的積極性；
(8) 沒有找到項目急需的具有特定技能的人。
5) 開發環境風險
(1) 設施未及時到位；
(2) 設施雖到位，但不配套，如沒有電話、網線、辦公用品等；
(3) 設施擁擠、雜亂或者破損；
(4) 開發工具未及時到位；
(5) 開發工具不如期望的那樣有效，開發人員需要時間創建工作環境或者切換新的工具；
(6) 新的開發工具的學習期比預期的長，內容繁多。
6) 客戶風險
(1) 客戶對於最後交付的產品不滿意，要求重新設計和重做；
(2) 客戶的意見未被採納，造成產品最終無法滿足用戶要求必須重做；
(3) 客戶對規劃、原型和規格的審覈決策週期比預期的要長；
(4) 客戶沒有或不能參與規劃、原型和規格階段的審覈，導致需求不穩定和產品生產週期的變更；
(5) 客戶答覆的時間(如回答或澄清與需求相關問題的時間)比預期長；
(6) 客戶提供的組件質量欠佳，導致額外的測試、設計和集成工作，以及額外的客戶關係管理工作。
7) 產品風險
(1) 矯正質量低下的不可接受的產品，需要比預期更多的測試、設計和實現工作；
(2) 開發額外的不需要的功能，延長了計劃進度；
(3) 嚴格要求與現有系統兼容，需要進行比預期更多的測試、設計和實現工作；
(4) 要求與其它系統或不受本項目組控制的系統相連，導致無法預料的設計、實現和測試工作；
(5) 在不熟悉或未經檢驗的軟件和硬件環境中運行所產生的未預料到的問題；
(6) 開發一種全新的模塊將比預期花費更長的時間；
(7) 依賴正在開發中的技術將延長計劃進度。
8) 設計和實現風險
(1) 設計質量低下，導致重複設計；
(2) 一些必要的功能無法使用現有的代碼和庫實現，開發人員必須使用新的庫或者自行開發新的功能；
(3) 代碼和庫質量低下，導致需要進行額外的測試，修正錯誤或重新制作；
(4) 過高估計了增強型工具對計劃進度的節省量；
(5) 分別開發的模塊無法有效集成，需要重新設計或製作。
9) 過程風險
(1) 大量的紙面工作導致進程比預期的慢；
(2) 前期的質量保證行爲不真實，導致後期的重複工作；
(3) 太不正規(缺乏對軟件開發策略和標準的遵循)，導致溝通不足，質量欠佳，甚至需要重新開發；
(4) 過於正規(教條地堅持軟件開發策略和標準)，導致過多耗時於無用的工作；
(5) 向管理層撰寫進程報告佔用開發人員的時間比預期的多；
(6) 風險管理粗心，導致未能發現重大的項目風險。
（四）軟件風險管理模型
1．Boehm模型
Boehm用公式RE=P(UO)*L(UO)對風險進行定義，其中RE表示風險或者風險所造成的影響，P(UO)表示令人不滿意的結果所發生的概率，L(UO)表示糟糕的結果會產生的破壞性的程度。在風險管理步驟上，Boehm基本沿襲了傳統的項目風險管理理論，指出風險管理由風險評估和風險控制兩大部分組成，風險評估又可分爲識別、分析、設置優先級3個子步驟，風險控制則包括制定管理計劃、解決和監督風險3步。
Boehm思想的核心是10大風險因素列表，其中包括人員短缺、不合理的進度安排和預算、不斷的需求變動等。針對每個風險因素，Boehm都給出了一系列的風險管理策略。在實際操作時，以10大風險列表爲依據，總結當前項目具體的風險因素，評估後進行計劃和實施，在下一次定期召開的會議上再對這10大風險因素的解決情況進行總結，產生新的10大風險因素表，依此類推。
10大風險列表的思想可以將管理層的注意力有效地集中在高風險、高權重、嚴重影響項目成功的關鍵因素上，而不需要考慮衆多的低優先級的細節問題。而且，這個列表是通過對美國幾個大型航空或國防系統軟件項目的深入調查，編輯整理而成的，因此有一定的普遍性和實際性。
2．CRM模型
SEI提出了持續風險管理模型(Continuous Risk Management，CRM)。
SEI的風險管理原則是：不斷地評估可能造成惡劣後果的因素；決定最迫切需要處理的風險；實現控制風險的策略；評測並確保風險策略實施的有效性。
CRM模型要求在項目生命期的所有階段都關注風險識別和管理。它將風險管理劃分爲5個步驟：風險識別、分析、計劃、跟蹤、控制。圖10.5所示的框架顯示了應用CRM的基礎活動及其之間的交互關係，強調了這是一個在項目開發過程中反覆持續進行的活動序列。每個風險因素開展的不同活動可以是併發的或者交替的。
圖10.5中的箭頭標識了信息的邏輯流，而溝通則是信息流的核心和手段。其中，風險識別依靠問卷完成，問卷覆蓋了大概200個問題，共涉及13個主要領域。風險分析側重於理解每個風險在該項目中的發生機率和後果嚴重性，從而產生最嚴重的10大風險問題。風險計劃是將如下內容文檔化：風險管理步驟的描述、負責人及其職責、行爲執行和完結的時間，並且確定風險處理的優先級，制定整體的管理計劃。風險跟蹤是獲取、整理並彙報10大風險問題當前的狀態，其目的是收集精確的、及時的和相關的信息，並將它們表達成容易理解的方式提交給負責人。風險控制是爲了根據風險及其緩解計劃進行及時而有效的決策，具體操作包括分析風險跟蹤階段產生的風險狀態信息，明確地決定採取什麼行動並實現它們。而處於核心地位的溝通則強調其有效性和針對性，要注意將合適的信息傳達給合適的組織層次以得到最有效的分析和管理，這些層次包括開發方和用戶方雙方的組織結構。
3．Leavitt模型
SEI和Boehm模型都以風險管理的過程爲主體，研究每個步驟所需的參考信息及其操作。而Aalborg大學提出的思路則是以Leavitt模型爲基礎，着重從導致軟件開發風險的不同角度出發探討風險管理。
1964年提出的Leavitt模型將形成各種系統的組織劃分爲4個有趣的組成部分：任務、結構、角色和技術。這4個組成部分和軟件開發的各因素很好地對應起來：角色覆蓋了所有的項目參與者，例如軟件用戶、項目經理和設計人員等；結構表示項目組織和其它制度上的安排；技術則包括開發工具、方法、硬件軟件平臺；任務描述了項目的目標和預期結果。Leavitt模型的關鍵思路是：模型的各個組成部分是密切相關的，一個組成部分的變化會影響其它的組成部分。如果一個組成部分的狀態和其它的狀態不一致，就會造成比較嚴重的後果，並可能降低整個系統的性能。
思 考 與 習 題
1. 簡述軟件測試管理過程及其主要功能。
2. 軟件風險分析的目的是什麼？
3. IEEE軟件測試計劃文檔模板規定了哪些測試方面的相關內容？
4. 測試管理的主要內容是什麼？
5. 需求管理是什麼？
6. 配置管理具有哪些關鍵活動？
7. 如何認識軟件缺陷管理？