1、編輯課件1編輯課件27.1 7.1 管理文檔概述管理文檔概述 工程化的軟件生產方式是軟件業界始終在不懈追求的目標。工程化的軟件生產方式是軟件業界始終在不懈追求的目標。軟件項目管理方法適用與否，對軟件項目的成敗有著舉足輕重的軟件項目管理方法適用與否，對軟件項目的成敗有著舉足輕重的作用。而軟件項目管理方法改進的途徑之一，就是建立行之有效、作用。而軟件項目管理方法改進的途徑之一，就是建立行之有效、可操作性強的軟件管理文檔。可操作性強的軟件管理文檔。軟件管理文檔軟件管理文檔項目開發計劃項目開發計劃測試計劃測試計劃測試分析報告測試分析報告開發進度報告開發進度報告開發總結報告開發總結報告管理文檔的組成：管

2、理文檔的組成：管理文檔有以下幾個方面的作用：管理文檔有以下幾個方面的作用：維護人員維護人員軟件開發軟件開發管理人員管理人員軟件開發人員軟件開發人員軟件操作軟件操作人員人員用戶用戶軟件管軟件管理文檔理文檔編輯課件3 管理文檔的作用主要體現在三個方面 是軟件開發各階段工作成果的體現是軟件開發各階段工作成果的體現 把軟件開發過程中的一些把軟件開發過程中的一些“不可見不可見”的事物轉換成的事物轉換成“可可見見”的文字資料的文字資料 提供了管理人員、開發人員、操作人員和用戶之間相互提供了管理人員、開發人員、操作人員和用戶之間相互溝通、協調的窗口溝通、協調的窗口編輯課件47.2 7.2 項目開發計劃項目開

3、發計劃 項目開發計劃又稱軟件定義文檔，是和軟件本身一樣重要的項目開發計劃又稱軟件定義文檔，是和軟件本身一樣重要的知識資產，是項目啟動后第一件最重要的工作。知識資產，是項目啟動后第一件最重要的工作。 項目開發計劃一般包括資源需求、工作分解、工作目標、開項目開發計劃一般包括資源需求、工作分解、工作目標、開發團隊及人員安排、進度安排、內外接口約定、風險分析以及軟發團隊及人員安排、進度安排、內外接口約定、風險分析以及軟件質量控制機制等。件質量控制機制等。1. 1. 項目開發計劃書項目開發計劃書 項目開發計劃書的具體內容隨著項目和開發機構類型的不同而不同，一般項目開發計劃書的具體內容隨著項目和開發機構類

4、型的不同而不同，一般都會包括以下幾個部分：都會包括以下幾個部分： 項目目標項目目標。簡述項目目標，并列出影響管理的約束條件，如預算、時間。簡述項目目標，并列出影響管理的約束條件，如預算、時間 開發團隊及人員安排開發團隊及人員安排。闡述團隊組織方式、人員構成及分工。闡述團隊組織方式、人員構成及分工 軟硬件資源需求軟硬件資源需求。分析和列出所需資源，注明估算的資源需要時間及價格。分析和列出所需資源，注明估算的資源需要時間及價格 工作分解工作分解。分解項目為一系列活動，確定項目里程碑及可交付文檔。分解項目為一系列活動，確定項目里程碑及可交付文檔 項目進度項目進度。描述項目各活動之間的依賴關系、到達里

5、程碑的時間等。描述項目各活動之間的依賴關系、到達里程碑的時間等 風險分析風險分析。分析項目可能存在的風險、發生的可能性及應對風險的策略。分析項目可能存在的風險、發生的可能性及應對風險的策略 監控機制監控機制。制定詳細、可操作的項目監控機制，明確管理報告的遞交時間。制定詳細、可操作的項目監控機制，明確管理報告的遞交時間 開發估算開發估算。包括規模、工作量、成本等的估算，要求依據并積累歷史數據。包括規模、工作量、成本等的估算，要求依據并積累歷史數據編輯課件5 制定項目開發計劃的過程被稱為項目策劃。制定項目開發計劃的過程被稱為項目策劃。 由于計劃所具有的在時間上的提前性，項目開發由于計劃所具有的在時

6、間上的提前性，項目開發計劃通常會經常性的修正，有些部分甚至會頻繁的改計劃通常會經常性的修正，有些部分甚至會頻繁的改變！變！ 而部分內容的變化，會影響開發計劃的正確性和而部分內容的變化，會影響開發計劃的正確性和符合性，使其越來越偏離項目實際，最后變得沒有價符合性，使其越來越偏離項目實際，最后變得沒有價值。如隨著項目需求的逐漸明確引起的項目計劃細化、值。如隨著項目需求的逐漸明確引起的項目計劃細化、項目可提供資源變化引起的項目計劃的變化等。項目可提供資源變化引起的項目計劃的變化等。 所以，在實際工作中，需要有明確的責任人和操所以，在實際工作中，需要有明確的責任人和操作原則，來對項目計劃實施維護，并對

7、項目計劃的變作原則，來對項目計劃實施維護，并對項目計劃的變更實施必要的控制。更實施必要的控制。 另一個重要的方面是，在組織文檔時，就要考慮另一個重要的方面是，在組織文檔時，就要考慮到這種頻繁變更的需要，使得當變更發生時，文檔的到這種頻繁變更的需要，使得當變更發生時，文檔的相應部分能夠容易替換。相應部分能夠容易替換。編輯課件62. 2. 工作分解結構工作分解結構 工作分解結構工作分解結構(work breakdown structure, WBS)(work breakdown structure, WBS)是對整個是對整個項目工作的分級描述，是項目計劃開發的第一步。分解示意如項目工作的分級描述

8、，是項目計劃開發的第一步。分解示意如下圖所示。下圖所示。目標目標活動活動活動活動活動活動活動活動活動活動活動活動1 1級級2 2級級m m級級工作包工作包任務任務1 1任務任務2 2任務任務3 3 任務任務n n活動活動工作分解結構設計一工作分解結構設計一般可以采用般可以采用2 2種方法：種方法：- - 自上而下自上而下的方法。的方法。從項目的目標開始，從項目的目標開始，逐步分解，直到具逐步分解，直到具體任務體任務- - 自下而上自下而上的方法。也的方法。也稱集思廣益法。即稱集思廣益法。即從底層開始，逐層從底層開始，逐層集成，最后匯合后集成，最后匯合后完成目標完成目標編輯課件7工作分解工作分解

9、結構主要有結構主要有4 4個用途個用途： 思路工具思路工具：可以描述項目的整體思路，是一個計劃和設：可以描述項目的整體思路，是一個計劃和設計的工具；計的工具； 結構設計工具結構設計工具：是項目工作的結構圖，可以清晰表達項：是項目工作的結構圖，可以清晰表達項目各項工作間的相互關系；目各項工作間的相互關系； 計劃工具計劃工具：能夠展示項目全貌，說明為完成項目所需完：能夠展示項目全貌，說明為完成項目所需完成的各項活動；成的各項活動；1.1. 項目狀態報告工具項目狀態報告工具：可以作為項目狀態報告的框架。隨：可以作為項目狀態報告的框架。隨著低一級項目活動的完成，項目由下而上不斷整合，某著低一級項目活動

10、的完成，項目由下而上不斷整合，某一項工作的完成將成為里程碑，所以，工作分解結構就一項工作的完成將成為里程碑，所以，工作分解結構就定義了里程碑事件。定義了里程碑事件。編輯課件83. 3. 項目里程碑與階段性文檔項目里程碑與階段性文檔 由于軟件產品是無形的，因此，管理者需要通過文檔的形式由于軟件產品是無形的，因此，管理者需要通過文檔的形式獲得信息，了解軟件的開發狀況，以作出管理的決定。獲得信息，了解軟件的開發狀況，以作出管理的決定。 里程碑的建立，可以描述軟件開發活動一個過程的終結。在里程碑的建立，可以描述軟件開發活動一個過程的終結。在每個里程碑，都有一個正式的可以提交給管理層的階段性結果。每個里

11、程碑，都有一個正式的可以提交給管理層的階段性結果。比如，一份報告。比如，一份報告。 里程碑報告的內容不拘，以能清楚說明階段性結果為標準，里程碑報告的內容不拘，以能清楚說明階段性結果為標準，應能代表項目中一個特定邏輯意義上的階段的終結。應能代表項目中一個特定邏輯意義上的階段的終結。 要建立里程碑，軟件過程就一定要分解成一系列相關的基本要建立里程碑，軟件過程就一定要分解成一系列相關的基本活動，而每個基本活動都要有相應的輸出結果。如下圖，是一個活動，而每個基本活動都要有相應的輸出結果。如下圖，是一個需求描述中的活動，其中每個活動都有主要輸出。需求描述中的活動，其中每個活動都有主要輸出。可行性研究可行

12、性研究需求分析需求分析原型開發原型開發設計研究設計研究需求描述需求描述可行性報告可行性報告用戶需求用戶需求估算報告估算報告體系結構設計體系結構設計系統需求系統需求編輯課件94. 4. 項目進度項目進度 項目管理者要求估算完成各項活動所需的時間和資源，并將它們嚴密的組織起來，以安排項目進度。不同的項目，具有不同的項目開發進度。 初始的項目進度安排往往是不精確的，但隨著項目進展信息的不斷增多，進度安排也會越來越接近項目實際進度，因此，必須不斷更新項目進度。 項目進度包括將一個項目分解為若干獨立的活動，以及判斷完成這些活動所需的時間。通常，有些活動是可以并行的，項目管理者應組織并協調這些并行的工作。

13、項目進度過程見下圖：識別活動識別活動識別活動識別活動依賴關系依賴關系估算活動估算活動的資源的資源為活動分為活動分配資源配資源創建項目創建項目圖表圖表軟件需求軟件需求活動圖表及條形圖活動圖表及條形圖編輯課件10 在進度估算時，管理者需要有一定的余量。在進度估算時，管理者需要有一定的余量。 如項目難度大，則花費的時間也會較多。又如，項目個別如項目難度大，則花費的時間也會較多。又如，項目個別開發人員可能發生的變動，硬件環境的變化等，都是在估算開發人員可能發生的變動，硬件環境的變化等，都是在估算項目進度時必須考慮的因素。項目進度時必須考慮的因素。 除了時間和人員、環境的變化，資源和預算也需要考慮適除了

14、時間和人員、環境的變化，資源和預算也需要考慮適當的余量。當的余量。 恰當的估算方法是采用恰當的估算方法是采用“理想實際理想實際”方式。即先估算理方式。即先估算理想值，然后逐步加入預計出現的狀況、偶然因素致成的狀況、想值，然后逐步加入預計出現的狀況、偶然因素致成的狀況、項目開發人員的素質和經驗項目開發人員的素質和經驗 作為經驗數據，一般在最初估算的基礎上增加作為經驗數據，一般在最初估算的基礎上增加30%30%作為實作為實際可能發生的狀況值，再預留際可能發生的狀況值，再預留20%20%的估算值給所謂不可預見的估算值給所謂不可預見的其它問題，則進度估算的結果會較符合實際。的其它問題，則進度估算的結果

15、會較符合實際。編輯課件11任任 務務持續時間持續時間( (天數天數) )依依 賴賴 關關 系系T1T18 8T2T21515T3T31515T1(M1)T1(M1)T4T41010T5T51010T2T2，T4(M2)T4(M2)T6T65 5T1T1，T2(M3)T2(M3)T7T72020T1(M1)T1(M1)T8T82525T4(M5)T4(M5)T9T91515T3T3，T6(M4)T6(M4)T10T101515T5T5，T7(M7)T7(M7)T11T117 7T9(M6)T9(M6)T12T121010T11(M8)T11(M8)5. 5. 運用圖和表描述項目進度運用圖和表描述

16、項目進度 項目進度可以采用圖表工具更直觀的表示任務分解、活動依賴關系和人員分配情況等。 下表是一個“任務的持續時間及其依賴關系”的例子。編輯課件12甘特圖法(Gantt Chart)的例子tw12345678ABCD當前進度當前進度優點：簡單，能動態地反映優點：簡單，能動態地反映開發進程開發進程缺點：難以反映多個任務間的缺點：難以反映多個任務間的邏輯關系邏輯關系條形圖和活動網絡圖是表示項目進度的兩種圖形表示法。(1) 條形圖。又稱甘特圖法(Gantt Chart)，可以表示面向活動的負責人是誰，以及活動的開始和結束時間。如下圖所示的例子。編輯課codingA test

17、ingA debuggingAB coding understandingC modifyingC testingB testingC debuggingB debuggingC testingABC012356789 codingA testingA debuggingA understandingC modifyingC testingB testingC debuggingB debuggingC testingABC4 debuggingAB coding 例：開發三個模塊A、B、C。 A為公用模塊，B、C的測試須等A的調試完成后進行。A的編碼需6天，測試8天，調試6天。B的編碼需7天

18、，測試8天，調試6天。C利用已有的模塊，須先理解原模塊8天，再修改8天，測試9天，調試7天。最后三模塊集成測試需5天完成。(2) 活動網絡圖。又稱網絡計劃法 表示構成一個項目的不同活動之間的依賴關系。是用網狀圖表安排與控制各項活動的方法。最適合反映多個工作之間的邏輯關系。編輯課件14持續時間持續時間Lasting Time機動時間機動時間Slack Time編編號號EarliestStart TimeLatestStart Time012345678941363029222014126006142082028293641(0)(0)(15)(4)(2)(4)(0)(2)(0)(2)(0)(0)

19、686678886975(1) 標出標出 Lasting Time(2) 標出標出 EST: = 從起點始，所有進從起點始，所有進入事件的入事件的 EST+LT 中最大的中最大的(3) 標出標出 LST: = 從終點從終點(EST = LST)始，所有離開事件的始，所有離開事件的 LST LT 中最小的中最小的(4) 標出標出 ST: = 終點終點LST 起點起點EST LT(5) 標出標出Key Path：即即EST = LST的的所有事件組成的路徑所有事件組成的路徑通常，甘特圖適合按開發階段安排，以作項目總體進度控制。網絡計劃法便于在細節上安排人力，適合按開發階段或子項目的工作步驟安排。編

20、輯課件15風風 險險風險類型風險類型風風 險險 描描 述述職員跳槽職員跳槽項目項目有經驗的職員未完成項目就跳槽有經驗的職員未完成項目就跳槽管理層變更管理層變更項目項目不同的管理層考慮、關注的事情會不同不同的管理層考慮、關注的事情會不同硬件缺乏硬件缺乏項目項目項目所需的基礎硬件沒有按期交付項目所需的基礎硬件沒有按期交付需求變更需求變更項目和產品項目和產品軟件需求與預期的相比，將會有較大變化軟件需求與預期的相比，將會有較大變化描述延遲描述延遲項目和產品項目和產品有關主要接口的描述未按期完成有關主要接口的描述未按期完成低估了系統規模低估了系統規模項目和產品項目和產品過低估計了系統的規模過低估計了系統

21、的規模CASECASE工具性能較差工具性能較差產品產品支持項目的支持項目的CASECASE工具達不到要求工具達不到要求技術變更技術變更業務業務系統的基礎技術被新技術取代系統的基礎技術被新技術取代產品競爭產品競爭業務業務系統還未完成，其它有競爭力的產品就已經上市了系統還未完成，其它有競爭力的產品就已經上市了6. 6. 風險管理風險管理 由于絕大多數軟件項目都存在不確定性，因此，風險管理對軟件項目而言就尤為重要。 根據產生的影響不同，一般將風險分為三類：項目風險、產品風險和業務風險。下表給出了一些典型風險：編輯課件16風險類型風險類型可可 能能 的的 風風 險險技術技術系統使用的數據庫的處理速度不

22、夠快系統使用的數據庫的處理速度不夠快要復用的軟件組件有缺陷，限制了項目的性能要復用的軟件組件有缺陷，限制了項目的性能人員人員招聘不到符合項目技術要求的職員招聘不到符合項目技術要求的職員在項目的非常時刻，關鍵職員生病，無法發揮作用在項目的非常時刻，關鍵職員生病，無法發揮作用職員所需的培訓跟不上職員所需的培訓跟不上機構機構重新進行機構調整，由不同的管理層負責這個項目重新進行機構調整，由不同的管理層負責這個項目開發機構的財務出現問題，必須削減項目預算開發機構的財務出現問題，必須削減項目預算工具工具CASE工具產生的編碼效率低工具產生的編碼效率低CASE工具不能被集成工具不能被集成需求需求需求發生變化

23、，主體設計要返工需求發生變化，主體設計要返工客戶不了解需求變更對項目造成的影響客戶不了解需求變更對項目造成的影響估算估算低估了軟件開發所需要的時間低估了軟件開發所需要的時間低估了缺陷的修補率低估了缺陷的修補率低估了軟件的規模低估了軟件的規模下圖是風險管理過程示意圖風險識別風險識別風險分析風險分析風險規劃風險規劃風險監控風險監控潛在的風險潛在的風險列表列表優先級高的優先級高的風險列表風險列表風險規避和風險規避和應急計劃應急計劃風險評估風險評估(1) (1) 風險識別風險識別 風險識別是風險管風險識別是風險管理的第一階段，其目理的第一階段，其目的是發現可能的風險。的是發現可能的風險。右表給出了可能

24、的風右表給出了可能的風險及風險類型的實例。險及風險類型的實例。 這些風險將可能影這些風險將可能影響到軟件產品、過程響到軟件產品、過程或業務。或業務。編輯課件17(2) 風險分析 風險分析就是對每一個已經識別的風險，對其出現的可能性和影響的嚴重性作出判斷。 風險出現可能性的評估大致可以有：非常小(75%)。風風 險險出現的可能性出現的可能性后果后果開發機構的財務出現問題，必須削減項目預算開發機構的財務出現問題，必須削減項目預算小小災難性災難性招聘不到符合項目技術要求的職員招聘不到符合項目技術要求的職員大大災難性災難性在項目的非常時刻，關鍵職員生病在項目的非常時刻，關鍵職員生病中等中等嚴重嚴重要復

25、用的軟件組件有缺陷，限制了項目的性能要復用的軟件組件有缺陷，限制了項目的性能中等中等嚴重嚴重需求發生變化，主體設計要返工需求發生變化，主體設計要返工中等中等嚴重嚴重開發機構調整，由不同的管理層負責這個項目開發機構調整，由不同的管理層負責這個項目大大嚴重嚴重系統使用的數據庫的處理速度不夠快系統使用的數據庫的處理速度不夠快中等中等嚴重嚴重低估了軟件開發所需要的時間低估了軟件開發所需要的時間大大嚴重嚴重CASE工具不能被集成工具不能被集成大大可容忍可容忍客戶不了解需求變更對項目造成的影響客戶不了解需求變更對項目造成的影響中等中等可容忍可容忍職員所需的培訓跟不上職員所需的培訓跟不上中等中等可容忍可容忍

26、低估了缺陷的修補率低估了缺陷的修補率中等中等可容忍可容忍低估了軟件的規模低估了軟件的規模大大可容忍可容忍CASE工具產生的編碼效率低工具產生的編碼效率低中等中等可忽略可忽略 風險影響大小的評估，可能的結果有：災難性的、嚴重的、可以容忍的和可以忽略的。 右表是對上表已識別風險分析后得出的結果作成的表格： 這個表格的內容應隨著項目的進展而更新。 經過風險分析和排序，就可以判斷哪些風險是最重要需要優先關注的，以有利于項目的順利開展。編輯課件18風風 險險策策 略略機構的財務風險機構的財務風險擬一份簡短報告，提交高層管理者，說明這個項目將對業務目標有重大貢獻擬一份簡短報告，提交高層管理者，說明這個項目

27、將對業務目標有重大貢獻職員招聘風險職員招聘風險穩定已有職員，加緊招聘工作，加緊已有低層職員的培訓、培養穩定已有職員，加緊招聘工作，加緊已有低層職員的培訓、培養職員生病風險職員生病風險重新對團隊進行組織，使更多工作可以并發和重疊，員工可以了解他人工作重新對團隊進行組織，使更多工作可以并發和重疊，員工可以了解他人工作有缺陷的組件有缺陷的組件購買更可靠、穩定的組件，替代有潛在缺陷的組件購買更可靠、穩定的組件，替代有潛在缺陷的組件需求變更需求變更導出可追溯信息來評估需求變更帶來的影響，把隱藏在設計中的信息擴大化導出可追溯信息來評估需求變更帶來的影響，把隱藏在設計中的信息擴大化機構調整機構調整擬一份簡短

28、報告，提交高層管理者，說明這個項目將對業務目標有重大貢獻擬一份簡短報告，提交高層管理者，說明這個項目將對業務目標有重大貢獻數據庫的性能數據庫的性能研究購買高性能數據庫的可能性研究購買高性能數據庫的可能性低估開發時間低估開發時間再次估算開發時間，對要使用的組件、開發環境的效用進行檢查，明確資源再次估算開發時間，對要使用的組件、開發環境的效用進行檢查，明確資源(3) 風險規劃 風險規劃過程就是對已識別的每一個重大風險，確定相應的處理策略。制定風險管理計劃同樣需要項目管理者的判斷和經驗。 下表給出了處理上表中嚴重和災難性風險的可能的策略。風險規劃的策略有三類：風險規劃的策略有三類：- - 規避策略規

29、避策略：采用這些策略會降低風險出現的概率。如：采用這些策略會降低風險出現的概率。如“有缺陷的組件有缺陷的組件”- - 最低風險策略最低風險策略：采用這些策略會減少風險影響。如：采用這些策略會減少風險影響。如“職員生病風險職員生病風險”- - 應急計劃應急計劃：用以應對最嚴重的情形出現，以防萬一。如：用以應對最嚴重的情形出現，以防萬一。如“機構財務問題機構財務問題”編輯課件19風險類型風險類型潛在的特征潛在的特征技術技術硬件或支持軟件延遲交付，暴露出現許多技術問題硬件或支持軟件延遲交付，暴露出現許多技術問題人員人員職員工作士氣低靡，團隊成員之間關系不協調，工作分配不當職員工作士氣低靡，團隊成員之

30、間關系不協調，工作分配不當機構機構機構內說三道四，缺乏資深管理人員機構內說三道四，缺乏資深管理人員工具工具團隊成員不愿使用工具，抱怨團隊成員不愿使用工具，抱怨CASE工具，需要更強大的工作站工具，需要更強大的工作站需求需求很多需求變更請求以及客戶怨言很多需求變更請求以及客戶怨言估算估算跟不上雙方協商的進度，無法除掉暴露出來的缺陷跟不上雙方協商的進度，無法除掉暴露出來的缺陷(4) 風險監控 風險監控就是要對每一個識別的風險及其策略執行情況進行定期評估，從而確定風險出現可能性的變化趨勢以及風險影響的后果是否有所改變。通常，這類信息是不可能直接觀察到的，需要綜合其它因素。 應該指出的是，風險監控應該

31、是一個持續不斷的過程，在每一次對風險管理進行評估時，每一個重大的風險都應該進行單獨的討論和評估。 下表列舉了一些典型因素的例子，可能會對評這些估風險類型有幫助。編輯課件207.3 7.3 軟件測試計劃和測試報告軟件測試計劃和測試報告 軟件測試是軟件開發完成，投入運行前，對軟件需求、設計規格說明和編碼的最終復審，軟件質量保證的關鍵步驟，在軟件開發的整個過程中，占有極為重要的位置。 軟件測試文檔主要包括：測試規劃、測試策略、測試手段和測試結果。 由于測試工作的重要性，而人工測試又特別困難，因此，測試過程自動化會是測試技術發展的方向。1. 1. 軟件測試、軟件檢查和調試軟件測試、軟件檢查和調試 我們

32、已經知道軟件測試的目的是盡可能多的發現系統存在的錯誤。我們已經知道軟件測試的目的是盡可能多的發現系統存在的錯誤。所以，軟件測試包括軟件檢查與軟件測試。所以，軟件測試包括軟件檢查與軟件測試。- - 軟件檢查軟件檢查：對系統的各種表達形式，如文檔、設計圖和程序源代碼等：對系統的各種表達形式，如文檔、設計圖和程序源代碼等進行分析、檢查，這一工作應貫穿整個開發過程。進行分析、檢查，這一工作應貫穿整個開發過程。- - 軟件測試軟件測試：使用測試數據對軟件的實現進行運行檢查，查看系統的輸：使用測試數據對軟件的實現進行運行檢查，查看系統的輸出及運行行為是否符合設計要求。出及運行行為是否符合設計要求。編輯課件

33、21下圖表示了軟件檢查和軟件測試在軟件過程中的位置軟件檢查軟件檢查需求描述需求描述高層設計高層設計形式化描述形式化描述詳細設計詳細設計程程 序序原原 型型軟件測試軟件測試 從圖中可以看出，軟件檢查貫穿整個軟件過程，而軟件測試僅對原型或軟件程序。 軟件調試是一個對缺陷定位和修改的過程，同時也是一項技巧性很強的工作。軟件調試，從軟件測試的結果開始。如圖所示。測試結果測試結果描描 述述測試用例測試用例定位錯誤定位錯誤設計修復設計修復修復錯誤修復錯誤回歸測試回歸測試編輯課件222. 2. 軟件測試的成本軟件測試的成本 由于測試不可能窮盡，因此，就有了軟件測試的一個致命缺陷，即測試的不完全、不徹底性。因

34、此，對于任何程序只能進行少量的測試。當發現錯誤，可以說明程序有問題，而未發現錯誤，卻不能聲稱程序沒有錯誤。 根據軟件工程的基本原理，當測試標準越高，則將要投入的人力、財力也越高。左圖反映了測試成本的變化規律。 為在軟件質量和投入之間取得需求平衡，可以采用著名的“進度、成本、質量”三角公式。如下右圖，即只要確定了其中兩項，就可以確定第三項。 因此，在編制軟件測試計劃時，必須考慮三者之間的關系。測試的程度測試的程度未發現的隱藏錯誤數未發現的隱藏錯誤數不足測試不足測試測試成本測試成本過度測試過度測試最佳測試點最佳測試點進度進度質量質量成本成本編輯課件233. 3. 軟件測試的原則軟件測試的原則測試時

35、，如果成功地實施了測試計劃和方案，就能夠發現系統中盡量多的錯誤。測試的一個附帶收獲是，能夠證明軟件的功能和性能是與需求說明相符的。要達成上述要求，就需要遵守以下原則：(1) (1) 測試規劃應包含測試工作的全部內容測試規劃應包含測試工作的全部內容。即不僅是程序測試，還包括文檔。即不僅是程序測試，還包括文檔(2) (2) 測試應貫穿軟件開發的整個過程測試應貫穿軟件開發的整個過程。即堅持各個階段的評審，杜絕隱患。即堅持各個階段的評審，杜絕隱患(3) (3) 測試用例應包括輸入和預期輸出測試用例應包括輸入和預期輸出。(4)(4) 設計測試用例時，輸入應包括合理的和不合理的數據設計測試用例時，輸入應包

36、括合理的和不合理的數據。(5) (5) 功能測試應由獨立第三方完成功能測試應由獨立第三方完成。但調試仍應由開發者自己完成。但調試仍應由開發者自己完成。(6) (6) 充分注意并利用測試中的群集現象充分注意并利用測試中的群集現象。(7) (7) 嚴格執行測試計劃，排除測試隨意性嚴格執行測試計劃，排除測試隨意性。計劃應明確規定，不隨意解釋。計劃應明確規定，不隨意解釋(8)(8) 應當對每一個測試結果做全面檢查應當對每一個測試結果做全面檢查。仔細分析測試結果，防止錯誤遺漏。仔細分析測試結果，防止錯誤遺漏(9)(9) 妥善保存測試計劃、測試用例、出錯統計和最終分析報告等測試文檔妥善保存測試計劃、測試用

37、例、出錯統計和最終分析報告等測試文檔。編輯課件244. 4. 軟件測試過程軟件測試過程從程序測試的角度看，測試分為兩個階段。如圖從程序測試的角度看，測試分為兩個階段。如圖單元單元( (構件構件) )測試測試集成集成( (組件組件) )測試測試軟件開發者完成軟件開發者完成獨立測試團隊承擔獨立測試團隊承擔程序測試過程的目的是盡可能多的發現并改正錯誤，提高軟件質量。程序測試過程的目的是盡可能多的發現并改正錯誤，提高軟件質量。測試過程的每一個階段也都會對前一階段有反饋信息。因此，測試過測試過程的每一個階段也都會對前一階段有反饋信息。因此，測試過程是一個不斷修正和進化的過程。其階段劃分如下圖所示程是一個

38、不斷修正和進化的過程。其階段劃分如下圖所示測試計劃測試計劃測試設計測試設計測試準備測試準備測試執行測試執行測試評估測試評估修正修正修正修正修正修正修正修正測試過程需要下面三個基礎數據和資料的支持：測試過程需要下面三個基礎數據和資料的支持：- -軟件配置軟件配置：軟件正常運行的環境配置。：軟件正常運行的環境配置。- - 測試配置測試配置：軟件測試運行的環境配置，是軟件配置的子集。：軟件測試運行的環境配置，是軟件配置的子集。- - 測試工具測試工具：為提高測試效率、降低測試勞動強度、保證測試質量使用的工具：為提高測試效率、降低測試勞動強度、保證測試質量使用的工具編輯課件25內內 容容說說 明明測試

39、過程測試過程描述測試過程的主要階段描述測試過程的主要階段需求跟蹤需求跟蹤用戶最關心系統能否目要求，測試計劃應包含對每項需求的單獨測試用戶最關心系統能否目要求，測試計劃應包含對每項需求的單獨測試測試項目測試項目軟件需求測試的內容都應在此定義軟件需求測試的內容都應在此定義測試時間安排測試時間安排給出總的時間安排和相應的資源分配給出總的時間安排和相應的資源分配測試記錄測試記錄測試所得到的結果、測試過程、執行情況等必須系統地記錄測試所得到的結果、測試過程、執行情況等必須系統地記錄軟硬件需求軟硬件需求列出測試所要使用的軟件工具和測試環境列出測試所要使用的軟件工具和測試環境約束約束需要考慮和預料的影響測試

40、過程的約束需要考慮和預料的影響測試過程的約束5. 5. 測試計劃的導出與結構測試計劃的導出與結構測試計劃應該從系統描述和設計中導出。下圖是測試計劃從系統描述和設計中導出示意圖需求描述需求描述系統描述系統描述系統設計系統設計詳細設計詳細設計單元代碼單元代碼測試測試驗收測驗收測試計劃試計劃系統集成系統集成測試計劃測試計劃子系統集成子系統集成測試計劃測試計劃服服 務務驗收測試驗收測試系統集成系統集成測試測試子系統集子系統集成測試成測試 測試計劃的主測試計劃的主要組成部分如右表要組成部分如右表所示所示編輯課件266. 6. 幾種常見的測試用圖表工具幾種常見的測試用圖表工具(1) 檢查表 檢查表是一張標

41、明了所要檢查項目和內容的表格，可以用來突出重點和總結整個過程的關鍵點。優點是簡潔、清晰。 典型的檢查表如需求檢查表、系統結構檢查表、代碼結構檢查表、共性缺陷檢查表等。 檢查表因其重要性，目前已實現了自動化和智能化。如IBM Rochester軟件開發中的PTF(program temporary fix，程序臨時修補)檢查表。(2) Pareto圖 一個按下降次序排列的頻率豎條圖。通常，X軸表示缺陷產生的原因，Y軸表示缺陷數。下圖就是一個軟件產品缺陷原因的Pareto圖。5040302010缺陷數缺陷數原因原因數據初始化數據初始化接口接口復雜邏輯復雜邏輯民族語言民族語言地址地址數據定義數據定義

42、編輯課件27(3) 直方圖 是一種樣本或總體的頻率計數的圖形表示。X軸自左至右按上升序列出某一個參數的單位間隔，Y軸為頻率計數。直方圖常用來表示某一參數的分布特性。如下圖是一個軟件產品按不同嚴重程度的缺陷頻率和缺陷報告提交的天數直方圖。10080604020總缺陷數的總缺陷數的%SEV2SEV1SEV3SEV4嚴重級別10080604020總缺陷數的總缺陷數的%8141715212228293536+缺陷報告提交的天數編輯課件287. 7. 設計軟件測試設計軟件測試(1) 缺陷測試設計 下圖是缺陷測試的一般模型。其中，需要設計測試用例，給出測試預期結果。測試用例是對測試需要的輸入和當前測試內容

43、的描述，運行結果需要和測試預期結果比較，以獲得測試是否通過的結論。測試用例測試用例測試數據測試數據測試結果測試結果測試報告測試報告設計測設計測試用例試用例準備測準備測試數據試數據用測試數據用測試數據運行程序運行程序將結果與測將結果與測試預期比較試預期比較 理想的測試是使每個可能的程序運行順序都能無遺漏的得到測試，然而這是不可能的。因此，測試需要基于一個可能的測試用例子集，制定和設計一個測試子集的選擇策略。編輯課件29輸輸 入入 數數 據據預期輸出結果預期輸出結果運行輸出結果運行輸出結果結果是否正常結果是否正常期望的期望的非期望的非期望的正常測試輸入數據正常測試輸入數據1n導致反常的輸入數據導致

44、反常的輸入數據1m 黑盒測試 黑盒測試是將系統作為一個黑盒子，只通過系統輸入，觀察其相應的輸出，來確定系統功能是否符合需求規格說明書的定義。因此，黑盒測試又稱功能測試或數據驅動測試。黑盒測試的系統模型如下圖。正常測試正常測試輸入數據輸入數據期望的輸期望的輸出結果出結果暴露缺陷的暴露缺陷的輸出結果輸出結果導致反導致反常的輸常的輸入數據入數據系系統統 黑盒測試方法即適合功能構成的系統，也適合對象構成的系統。測試的關鍵是要設計出有極大可能落在導致系統反常的輸入數據集合中的那些輸入。使用下表可以組織黑盒測試方法的輸入和輸出。編輯課件30輸入條件輸入條件有效等價類有效等價類無效等價類無效等價類 等價劃分

45、 黑盒測試的一種方法。等價劃分的測試方法就是把程序的輸入域劃分成若干不同性質得到的集合，在這些集合中，程序有基本一致的行為表現，然后從每個集合中選取少量有代表性的數據作為測試用例。下圖就是等價劃分測試的模型。系系統統無效輸入無效輸入有效輸入有效輸入輸出輸出 等價劃分方法測試用例的設計要經歷劃分等價類和選取測試用例兩步。等價類的劃分可以使用等價類表描述。確定測試用例則需要根據等價類表，按以下確定測試用例則需要根據等價類表，按以下3 3個步驟進行：個步驟進行：- - 為每個等價類規定唯一編號為每個等價類規定唯一編號- - 設計一個測試用例，使其盡可能多的覆蓋尚未覆蓋的有效等價類，重復該步設計一個測

46、試用例，使其盡可能多的覆蓋尚未覆蓋的有效等價類，重復該步- - 設計測試用例，逐一覆蓋所有無效等價類設計測試用例，逐一覆蓋所有無效等價類編輯課件31 結構化測試 結構化測試是一種根據軟件結構知識和實現知識所進行的測試方法。結構化測試也成為白盒測試。結構化測試的過程如下圖所示。測試數據測試數據測試輸出測試輸出組件代碼組件代碼導出導出測試測試 結構化測試除了用于單元測試外，一般適合用于相對較小的程序，如一個子程序或對象的一個操作等。 結構化測試是通過代碼分析來估計需要多少測試用例，以保證測試過程中，程序或組件中所有語句都至少遍歷一遍。 路徑測試 是結構化測試的一種策略。即在程序控制流程圖的基礎上，

47、通過分析控制構造的環路復雜性，導出基本可執行路徑集合，從而設計測試用例。而設計出的測試用例要保證在測試中程序的每一個可執行語句都能至少執行一次。 在面向對象的程序開發過程中，路徑測試在測試對象中的方法時，常會用到。程序中的路徑數量通常與程序的長度成正比。編輯課件32(2) 集成測試設計 集成測試開始于系統組件、子系統或完整系統的組裝完成時，其目的是發現組件交互中的問題。 集成測試的主要困難是在測試過程中對發現的錯誤的定位。一個好的方法是采用所謂的增量法。即先從一個集成度最小的系統配置開始測試，完成后一個增量一個增量的增加配置，然后逐步完成系統完整配置的測試。下圖就是增量化集成測試的例子。ABT

48、1T2T3a.a. 測試序列1ABT1T2T3CT4b.b. 測試序列2ABT1T2T3c.c. 測試序列3CDT4T5編輯課件33 自頂向下的和自底向上的測試是兩種不同的測試策略 在自頂向下的集成測試中，系統的高層組件在系統設計和實現完成之前進行集成和測試。如下圖所示1 1級級1 1級級2 2級級2 2級級2 2級級測試序列測試序列 在自底向上的集成測試中，低層組件在高層組件開發出來之前進行集成和測試。如下圖所示N N 級級N N 級級N N 級級N N 級級N N 級級N-1N-1級級N-1N-1級級N-1N-1級級測試驅測試驅動程序動程序測試驅測試驅動程序動程序測試測試序列序列編輯課件3

49、4 接口測試 當模塊或子系統被集成時，就有一個事先定義的接口供其它組件調用。接口測試的目的就是檢測因接口錯誤或對接口進行的無效假設而造成的系統缺陷。下圖就是對接口測試的示意圖。測試用例測試用例ABC 圖中，指向方塊邊界的箭頭表示測試用例不是只針對單個組件的，而是對組件構成的整個子系統的。 接口錯誤是對象之間交互的結果，而不是出于單個對象的行為。因此，接口錯誤是不可能通過對單個對象的測試發現的。 這種測試形式非常適合面向對象的系統。 強度測試 系統被完全集成后，就可以進行總體性能測試了。 為性能測試所設計的測試用例要保證能夠測試到系統的正常負荷。通常，要設計出一系列的測試，使得系統的測試負荷能穩

50、步上升，直到系統達到性能極限。然后，強度測試繼續使用測試用例測試，直到系統失敗。這類測試有兩個作用：檢查系統的柔性；可能模擬到正常情況下的不尋常組合，以暴露系統正常情況下不會暴露的缺陷。編輯課件35(3) 面向對象的測試 盡管前面介紹的測試方法能夠用于面向對象程序的測試，但是面向對象的測試還具有自己的另外一些特點。 面向對象的單元測試 以往單元測試的方法可繼續沿用，實際測試類成員函數。對象的完全覆蓋測試應包括： - 對象中所有操作被單獨隔離的測試 - 對象中所有屬性的設置和訪問的測試 - 對象中所有可能狀態的測試 如果使用了繼承，則對類的測試應延伸到所有子類所繼承的操作。編輯課件36 面向對象

51、的集成測試 由于面向對象程序中，類相互依賴極其緊密，根本無法在編譯不完全的程序上對類進行測試。所以，面向對象的集成測試通常需要在整個程序編譯完成后進行。此外，面向對象程序具有動態特性，程序的控制流往往無法確定，因此也只能對整個編譯后的程序做基于黑盒的集成測試。 面向對象的集成測試能夠發現相對獨立的單元測試無法檢出的那些類相互作用時才會產生的錯誤。具體設計測試用例，可參考以下步驟：- 選定檢測的類，列出類的狀態、行為、傳遞的消息，及輸入/輸出的界定等- 利用結構關系圖確定待測類的所有關聯，確定覆蓋標準- 根據程序中類的對象構造測試用例，確認輸入、服務和期望產生的行為等編輯課件378. 8. 軟件測試計劃文檔軟件測試計劃文檔 測試計劃起到測試工作過程框架結構的功能，是好的測試工作的基礎。一個測試計劃的基本內容包括：基本情況分析、測試需求說明、測試策略和記錄、測試資源配置、問題跟蹤報告、測試計劃的評審等。 基本情況分析。包括系統運行平臺、應用領域、特點和主要功能模塊等。分析要點有：測試目的和側重點、系統適合于測試的內容/操作劃分、測試的潛在風險、系統與測試相關的資料說明。 測試需求說明。列出測試功能項，規定應該測試的具體內容。 測試策略和記錄。描述如何開展測試，規定測試記錄的內容。必要時，應給出測試記錄