軟件文檔寫作第7講管理文檔完整

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

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

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

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

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

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

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

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

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

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

11、程碑，都有一個正式的可以提交給管理層的階段性結(jié)果。比如，一份報告。比如，一份報告。 里程碑報告的內(nèi)容不拘，以能清楚說明階段性結(jié)果為標準，里程碑報告的內(nèi)容不拘，以能清楚說明階段性結(jié)果為標準，應(yīng)能代表項目中一個特定邏輯意義上的階段的終結(jié)。應(yīng)能代表項目中一個特定邏輯意義上的階段的終結(jié)。 要建立里程碑，軟件過程就一定要分解成一系列相關(guān)的基本要建立里程碑，軟件過程就一定要分解成一系列相關(guān)的基本活動，而每個基本活動都要有相應(yīng)的輸出結(jié)果。如下圖，是一個活動，而每個基本活動都要有相應(yīng)的輸出結(jié)果。如下圖，是一個需求描述中的活動，其中每個活動都有主要輸出。需求描述中的活動，其中每個活動都有主要輸出?？尚行匝芯靠尚?/p>

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

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

14、時間和人員、環(huán)境的變化，資源和預(yù)算也需要考慮適當?shù)挠嗔?。當?shù)挠嗔俊?恰當?shù)墓浪惴椒ㄊ遣捎们‘數(shù)墓浪惴椒ㄊ遣捎谩袄硐雽嶋H理想實際”方式。即先估算理方式。即先估算理想值，然后逐步加入預(yù)計出現(xiàn)的狀況、偶然因素致成的狀況、想值，然后逐步加入預(yù)計出現(xiàn)的狀況、偶然因素致成的狀況、項目開發(fā)人員的素質(zhì)和經(jīng)驗項目開發(fā)人員的素質(zhì)和經(jīng)驗 作為經(jīng)驗數(shù)據(jù)，一般在最初估算的基礎(chǔ)上增加作為經(jīng)驗數(shù)據(jù)，一般在最初估算的基礎(chǔ)上增加30%30%作為實作為實際可能發(fā)生的狀況值，再預(yù)留際可能發(fā)生的狀況值，再預(yù)留20%20%的估算值給所謂不可預(yù)見的估算值給所謂不可預(yù)見的其它問題，則進度估算的結(jié)果會較符合實際。的其它問題，則進度估算的結(jié)果

15、會較符合實際。編輯課件11任任 務(wù)務(wù)持續(xù)時間持續(xù)時間( (天數(shù)天數(shù)) )依依 賴賴 關(guān)關(guān) 系系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、項目進度 項目進度可以采用圖表工具更直觀的表示任務(wù)分解、活動依賴關(guān)系和人員分配情況等。 下表是一個“任務(wù)的持續(xù)時間及其依賴關(guān)系”的例子。編輯課件12甘特圖法(Gantt Chart)的例子tw12345678ABCD當前進度當前進度優(yōu)點：簡單，能動態(tài)地反映優(yōu)點：簡單，能動態(tài)地反映開發(fā)進程開發(fā)進程缺點：難以反映多個任務(wù)間的缺點：難以反映多個任務(wù)間的邏輯關(guān)系邏輯關(guān)系條形圖和活動網(wǎng)絡(luò)圖是表示項目進度的兩種圖形表示法。(1) 條形圖。又稱甘特圖法(Gantt Chart)，可以表示面向活動的負責(zé)人是誰，以及活動的開始和結(jié)束時間。如下圖所示的例子。編輯課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 例：開發(fā)三個模塊A、B、C。 A為公用模塊，B、C的測試須等A的調(diào)試完成后進行。A的編碼需6天，測試8天，調(diào)試6天。B的編碼需7天

18、，測試8天，調(diào)試6天。C利用已有的模塊，須先理解原模塊8天，再修改8天，測試9天，調(diào)試7天。最后三模塊集成測試需5天完成。(2) 活動網(wǎng)絡(luò)圖。又稱網(wǎng)絡(luò)計劃法 表示構(gòu)成一個項目的不同活動之間的依賴關(guān)系。是用網(wǎng)狀圖表安排與控制各項活動的方法。最適合反映多個工作之間的邏輯關(guān)系。編輯課件14持續(xù)時間持續(xù)時間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的的所有事件組成的路徑所有事件組成的路徑通常，甘特圖適合按開發(fā)階段安排，以作項目總體進度控制。網(wǎng)絡(luò)計劃法便于在細節(jié)上安排人力，適合按開發(fā)階段或子項目的工作步驟安排。編

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

49、4 接口測試 當模塊或子系統(tǒng)被集成時，就有一個事先定義的接口供其它組件調(diào)用。接口測試的目的就是檢測因接口錯誤或?qū)涌谶M行的無效假設(shè)而造成的系統(tǒng)缺陷。下圖就是對接口測試的示意圖。測試用例測試用例ABC 圖中，指向方塊邊界的箭頭表示測試用例不是只針對單個組件的，而是對組件構(gòu)成的整個子系統(tǒng)的。 接口錯誤是對象之間交互的結(jié)果，而不是出于單個對象的行為。因此，接口錯誤是不可能通過對單個對象的測試發(fā)現(xiàn)的。 這種測試形式非常適合面向?qū)ο蟮南到y(tǒng)。 強度測試 系統(tǒng)被完全集成后，就可以進行總體性能測試了。 為性能測試所設(shè)計的測試用例要保證能夠測試到系統(tǒng)的正常負荷。通常，要設(shè)計出一系列的測試，使得系統(tǒng)的測試負荷能穩(wěn)

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

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