軟件測試第07章修改課件(PPT 115頁)

1、第 7 章 測試項目管理軟件測試技術 之第1頁，共115頁。第 7 章 測試項目管理 測試項目管理概述1軟件測試過程管理2測試文檔3測試的組織與人員管理4測試的配置管理5軟件測試的風險管理6軟件測試的成本管理7第2頁，共115頁。第 7 章 測試項目管理 測試項目管理概述1軟件測試過程管理2測試文檔3測試的組織與人員管理4測試的配置管理5軟件測試的風險管理6軟件測試的成本管理7第3頁，共115頁。7.1 測試項目管理概述7.1.1 測試項目管理 測試項目管理就是以測試項目為管理對象；通過一個臨時性的專門的測試組織，運用專門的軟件測試知識、技能、工具和方法，對測試項目進行計劃、組織、執(zhí)行和控制；

2、并在時間成本、軟件測試質量等方面進行分析和管理活動。 測試項目管理應遵循的原則：質量第一，需求可靠，時間充足，計劃得當，適當引入測試自動化和測試工具，獨立的測試環(huán)境。第4頁，共115頁。 測試項目范圍管理就是界定項目所必須包含且只需包含的全部工作，并對其他的測試項目管理工作起指導作用，以確保測試工作順利完成。 7.1.2 軟件測試項目的范圍管理第5頁，共115頁。 項目目標確定后，下一步過程就是確定需要執(zhí)行哪些工作，或者活動來完成項目的目標，這就是要確定一個包含項目所有活動在內的一覽表。準備這樣的一覽表通常有兩種方法： 一種是讓測試小組利用“頭腦風暴法”根據經驗，集思廣益來形成。這種方法比較適

3、合小型測試項目。 另一種是對更大更復雜的項目建立一個工作分解結構WBS和任務的一覽表。7.1.2 軟件測試項目的范圍管理 工作分解結構WBS是將一個軟件測試項目分解成易于管理的更多部分或細目，所有這些細目構成了整個軟件測試項目的工作范圍。第6頁，共115頁。WBS 模 版圖形類型第7頁，共115頁。WBS 模 版清單類型1. 變化計數器1.1 比較兩個版本的程序1.1.1 預處理1.1.2 文件比較1.1.3 結果處理1.2 找出修改后的程序中增加和刪除的代碼行1.2.1 找出增加的代碼行1.2.2 找出刪除的代碼行1.3 統(tǒng)計修改后的程序中增加和刪除的代碼行數1.3.1 統(tǒng)計增加代碼行數1.

4、3.2 統(tǒng)計刪除代碼行數1.4 統(tǒng)計總的代碼行數 1.5 設定標記以指示修改的次數1.6 在程序的頭部增加修改紀錄第8頁，共115頁。 WBS組織并定義了整個測試項目的范圍，未列入工作分解結構的工作將排除在項目范圍之外。 WBS的應用將給所有的項目管理人員提供一個一致的基準，即使項目人員變動時，也有一個互相可以理解和交流溝通的平臺。7.1.2 軟件測試項目的范圍管理第9頁，共115頁。WBS 模 版圖形類型第10頁，共115頁。第 7 章 測試項目管理 測試項目管理概述1軟件測試過程管理2測試文檔3測試的組織與人員管理4測試的配置管理5軟件測試的風險管理6軟件測試的成本管理7第11頁，共115

5、頁。7.2 軟件測試過程管理7.2.1 軟件項目的跟蹤與質量控制 軟件測試和軟件開發(fā)一樣，都遵循軟件工程的原理，有它自己的生命周期。軟件的測試過程管理基于廣泛采用的“V”模型。“V”模型支持系統(tǒng)測試周期的任何階段。第12頁，共115頁。7.2.1 軟件項目的跟蹤與質量控制V 模 型第13頁，共115頁。 (1) 測試可以在需求分析階段就及早開始，在做需求分析、產品功能設計的同時，測試人員就可以閱讀、審查需求分析的結果，創(chuàng)建測試的準則。7.2.1 軟件項目的跟蹤與質量控制第14頁，共115頁。 (2) 當系統(tǒng)設計人員在做概要設計時，測試人員可以了解系統(tǒng)是如何實現的，基于什么樣的平臺，這樣可以設計

6、系統(tǒng)的測試方案和測試計劃，并事先準備系統(tǒng)的測試環(huán)境。7.2.1 軟件項目的跟蹤與質量控制第15頁，共115頁。 (3) 當設計人員在做在做詳細設計時，測試人員可以參與設計，對設計進行評審，找出設計的缺陷，同時設計功能、新特性等各方面的測試用例，完善測試計劃。7.2.1 軟件項目的跟蹤與質量控制第16頁，共115頁。 (4) 在編程的同時，進行單元測試，是一種很有效的辦法，可以盡快找出程序中的錯誤，充分的單元測試可以大幅度提高程序質量、減少成本。7.2.1 軟件項目的跟蹤與質量控制第17頁，共115頁。 測試項目啟動 測試計劃階段 測試設計階段 測試執(zhí)行階段 測試結果的審查和分析7.2.2 軟件

7、項目的過程管理第18頁，共115頁。 (1) 測試項目啟動 確定項目組長，組建整個測試小組； 測試小組參加有關項目計劃、分析和設計的會議，獲得必要的需求分析、系統(tǒng)設計文檔以及相關產品/技術知識的培訓等。7.2.2 軟件項目的過程管理第19頁，共115頁。(2) 測試計劃階段 確定測試范圍、測試策略和方法； 對風險、日程表、資源等進行分析和估計。 制定一份測試計劃，其中描述了如何實施和管理軟件的測試過程，測試計劃經批準生效后，將被用來作為對測試過程跟蹤和監(jiān)控的依據。7.2.2 軟件項目的過程管理第20頁，共115頁。(3) 測試設計階段 制訂測試的技術方案、設計測試用例、選擇測試工具、寫測試腳本

8、等。需要制定測試設計規(guī)格說明書，測試用例說明，測試規(guī)程規(guī)格說明。應該考慮的要點： 所設計的測試技術方案的可行性，有效性，能否達到預期的測試目標； 所設計的測試用例的完整性，邊界條件是否考慮，覆蓋率能達到多少； 所設計的測試環(huán)境和用戶的實際使用環(huán)境是否接近。7.2.2 軟件項目的過程管理第21頁，共115頁。(4) 測試執(zhí)行階段 建立或測試相關的測試環(huán)境； 準備測試數據，執(zhí)行測試用例； 對發(fā)現的軟件缺陷進行報告、分析、跟蹤等。 測試執(zhí)行是測試的基礎，直接關系到測試的可靠性、客觀性和準確性。需要制定測試日志和缺陷總結報告。7.2.2 軟件項目的過程管理第22頁，共115頁。(5) 測試結果的審查和

9、分析 對測試結果進行整體的綜合分析，以確定軟件產品質量的當前狀態(tài)，為產品的改進或發(fā)布提供數據和依據。制定測試總結報告。 測試結果的審查和分析主要內容包括：審查測試全過程，對當前各個缺陷狀態(tài)的審查，結束標志以及項目總結。7.2.2 軟件項目的過程管理第23頁，共115頁。小 結 在具體的測試項目的跟蹤與監(jiān)控過程中，可以采用周報、日報、例會，以及里程碑評審會等方式來了解測試項目的進展情況，建立、收集和分析項目的實際狀態(tài)數據，對項目進行跟蹤與監(jiān)控，達到項目管理的目的。 7.2.2 軟件項目的過程管理第24頁，共115頁。第 7 章 測試項目管理 測試項目管理概述1軟件測試過程管理2測試文檔3測試的組

10、織與人員管理4測試的配置管理5軟件測試的風險管理6軟件測試的成本管理7第25頁，共115頁。7.3 測 試 文 檔 測試文檔是對要執(zhí)行的軟件測試及測試的結果進行描述、定義、規(guī)定和報告的任何書面或圖示信息。 軟件的需求分析階段、設計階段的內容都應該在測試文檔中有所體現。測試文檔對測試階段工作的指導與評價作用是非常顯著的。第26頁，共115頁。 促進項目組成員之間的交流溝通 便于對測試項目的管理 決定測試的有效性 檢驗測試資源 明確任務的風險 評價測試結果 方便再測試 驗證需求的正確性7.3.1 測試文檔的作用 總之，測試文檔記錄了測試的完整過程以及測試的結果，文檔是測試過程必要的組成部分，測試文

11、檔的編寫也是測試工作規(guī)范化的一個組成部分。在測試中，應該堅持按照軟件系統(tǒng)文檔標準編寫和使用測試文檔。第27頁，共115頁。7.3.2 主要軟件測試文檔第28頁，共115頁。 主要對軟件測試項目、所需要進行的測試工作、測試人員所應該負責的測試工作、測試過程、測試所需的時間和資源，以及測試風險等做出預先的計劃和安排。 測試計劃第29頁，共115頁。 測試計劃第30頁，共115頁。 在測試計劃中提煉測試方法，明確指出設計包含的特性以及相關的測試方法，并指定判斷特性通過/失敗的規(guī)則。 測試設計規(guī)格說明第31頁，共115頁。 測試用例規(guī)格說明文檔 有了測試設計說明，就可以按照測試設計說明的描述，對每一個

12、測試項進行具體的測試用例設計。第32頁，共115頁。 用于指定執(zhí)行一個測試用例集的步驟。 測試規(guī)程第33頁，共115頁。 由于記錄測試的執(zhí)行情況不同，可根據需要選用。 測試日志第34頁，共115頁。 在軟件測試過程中，對于發(fā)現的大多數軟件缺陷，要求測試人員簡捷、清晰地把發(fā)現的問題報告給判斷是否進行修復的小組，使其得到所需要的全部信息。 軟件缺陷報告第35頁，共115頁。IEEE8291998軟件測試文檔編制標準軟件缺陷報告模板目錄1軟件缺陷報告標識符2軟件缺陷總結3軟件缺陷描述 3.1 輸入 3.2 期望得到的結果 3.3 實際結果 3.4 異常情況 3.5 日期和時間 3.6 軟件缺陷發(fā)生步

13、驟 3.7 測試環(huán)境 3.8 再現測試 3.9 測試人員 3.10 見證人4影響 軟件缺陷報告第36頁，共115頁。 用于報告某個測試完成情況。 測試總結報告IEEE標準8291998軟件測試文檔編制標準測試總結報告模板目錄1測試總結報告標識符2總結3差異4綜合評估5結果總結5.1 已解決的意外事件5.2 未解決的意外事件6評價7建議8活動總結9審批第37頁，共115頁。 測試文檔記錄了測試的完整過程以及測試的結果，文檔是測試過程必要的組成部分，測試文檔的編寫也是測試工作規(guī)范化的一個組成部分。在測試中，應該堅持按照軟件系統(tǒng)文檔標準編寫和使用測試文檔。7.3 測 試 文 檔第38頁，共115頁。

14、WBS 模 版第39頁，共115頁。第 7 章 測試項目管理 測試項目管理概述1軟件測試過程管理2測試文檔3測試的組織與人員管理4測試的配置管理5軟件測試的風險管理6軟件測試的成本管理7第40頁，共115頁。7.4 測試的組織與人員管理7.4.1 測試的組織與人員管理概述 測試的組織與人員管理就是對測試項目相關人員在組織形式、人員組成與職責方面所做的規(guī)劃和安排。第41頁，共115頁。測試的組織與人員管理的任務是： 為測試項目選擇合適的組織結構模式； 合理配備人員，明確分工和責任； 對項目成員的思想、心理和行為進行有效地管理，充分發(fā)揮他們的主觀能動性，密切配合實現項目的目標。第42頁，共115頁

15、。（1）盡快落實責任 從軟件的生存周期看，測試往往指對程序的測試，但是，由于測試的依據是規(guī)格說明書、設計文檔和使用說明書，如果設計有錯誤，測試的質量就難以保證。實際上，測試的準備工作在分析和設計階段就開始了，在軟件項目的開始就要盡早指定專人負責，讓他有權去落實與測試有關的各項事宜。 測試的組織與人員管理應注意的原則第43頁，共115頁。（2）減少接口 要盡可能地減少項目組內人與人之間的層次關系，縮短通信的路徑，方便人員之間的溝通，提高工作效率。（3）責任明確、均衡 項目組成員都必須明確自己在項目組中的地位、角色和職責，各成員所負的責任不應比委任的權力大，反之亦然。 測試的組織與人員管理應注意的

16、原則第44頁，共115頁。 組織結構是指用一定的模式對責任、權威和關系進行安排，直至通過這種結構發(fā)揮功能。測試組織結構設計時主要考慮以下因素。 垂直還是平緩 集中還是分散 分級還是分散 專業(yè)人員還是工作人員 面向功能還是項目 7.4.2 測試人員的組織結構第45頁，共115頁。 進行軟件測試的測試組織結構形式很多， 目前常見的測試組織結構有獨立的測試小組和集成的測試小組兩種形式。7.4.2 測試人員的組織結構第46頁，共115頁。 獨立的測試小組，即主要工作是進行測試的小組，他們專門從事軟件的測試工作。 測試組設組長一名，負責整個測試的計劃、組織工作。測試組的其他成員由具有一定的分析、設計和測

17、試經驗的專業(yè)人員組成，人數根據具體情況可多可少，一般35人為宜。測試組長與開發(fā)組長在項目中的地位是同級、平等的關系。1獨立測試小組第47頁，共115頁。 獨立測試小組組織形式的好處：獨立測試小組會客觀的對待被測試的軟件，這樣測試、評價軟件的質量才真正有效。 面臨的問題：如何在軟件產品的生命周期中盡早開始工作。1獨立測試小組第48頁，共115頁。 集成測試小組是將測試與基本設計因素組合起來，構成的測試組織結構。 這是與獨立測試有關的一種集成測試組織形式，即集成測試小組是由需要向同一個項目經理匯報工作的測試人員和開發(fā)人員組成。 1集成測試小組第49頁，共115頁。 集成測試小組組織形式的好處：軟件

18、立項后，由測試人員和軟件開發(fā)人員并肩作戰(zhàn)，一起工作，可以減少軟件開發(fā)人員和測試人員合作時的不利因素，會極大地方便交流和溝通。集成測試小組成員也是專業(yè)的測試人員。1集成測試小組第50頁，共115頁。測試的組織與人員管理的任務是： 為測試項目選擇合適的組織結構模式； 合理配備人員，明確分工和責任； 對項目成員的思想、心理和行為進行有效地管理，充分發(fā)揮他們的主觀能動性，密切配合實現項目的目標。第51頁，共115頁。 測試人員的能力應包括以下幾項。 一般能力：包括表達、交流、協(xié)調、管理、質量意識、過程方法、軟件工程等； 測試技能及方法：包括測試基本概念及方法、測試工具及環(huán)境、專業(yè)測試標準、工作成績評估

19、等；7.4.3 測試人員第52頁，共115頁。 測試規(guī)劃能力：包括風險分析及防范、軟件放行/接收準則制定、測試目標及計劃、測試計劃和設計的評審方法等； 測試執(zhí)行能力：包括測試數據/腳本/用例、測試比較及分析、缺陷記錄及處理、自動化工具； 測試分析、報告和改進能力：包括測試度量、統(tǒng)計技術、測試報告、過程監(jiān)測及持續(xù)改進。7.4.3 測試人員第53頁，共115頁。測試組織的管理者必須具備： 了解與評價軟件測試政策、標準、過程、工具、培訓和度量的能力； 領導一個測試組織的能力，該組織必須堅強有力、獨立自主、辦事規(guī)范且沒有偏見； 吸引并留住杰出測試專業(yè)人才的能力； 領導、溝通、支持和控制的能力； 有提出

20、解決問題方案的能力； 測試時間、質量和成本控制的能力。7.4.3 測試人員第54頁，共115頁。測試的組織與人員管理的任務是： 為測試項目選擇合適的組織結構模式； 合理配備人員，明確分工和責任； 對項目成員的思想、心理和行為進行有效地管理，充分發(fā)揮他們的主觀能動性，密切配合實現項目的目標。第55頁，共115頁。 激勵，簡單地說就是調動人的工作積極性，把潛力充分發(fā)揮出來。 在管理學中，激勵是指管理者促進、誘導下屬形成動機，并引導其行為指向特定目標的活動過程。7.4.4 測試人員管理的激勵機制第56頁，共115頁。 管理者習慣用對自己有效的因素激勵測試人員，很可能發(fā)現無效； 過多行使權力、資金或處

21、罰手段很可能導致項目失敗； 注意采取卓有成效的非貨幣形式的激勵措施； 在項目進行過程中，而不僅是在項目結果時實施激勵措施；測試人員管理的激勵機制的關鍵點第57頁，共115頁。 獎勵應該在工作獲得認同后盡快兌現； 對項目成員的工作表現出真誠的興趣，是對他們最好的獎勵； 已經滿足的需要很可能不再成為激勵因素。 激勵因素是影響個人行為的東西，是因人而異、因時而異的。因此，管理者必須明確各種激勵的方式，并合理使用。測試人員管理的激勵機制的關鍵點第58頁，共115頁。 從測試管理的角度來說，為了高效地實現測試工作的目標，需要不斷地幫助他們進行知識的更新和技術能力的提升，這些就需要通過培訓來達到。7.4.

22、5 測試人員的培訓第59頁，共115頁。1軟件測試培訓內容 測試基礎知識和技能培訓； 測試設計培訓，測試工具培訓； 測試對象軟件產品培訓； 測試過程培訓； 測試管理培訓。 7.4.5 測試人員的培訓第60頁，共115頁。2制定測試人員培訓計劃 需要管理層的重視，在時間和資源上予以保證； 認真調查和分析測試人員的培訓要求； 將培訓活動安排在測試任務開始前； “邊干邊學”模式很可能犧牲質量和效率； 軟件測試實習活動要在整個培訓中占較大比例； 鼓勵合作學習，團隊演練； 對培訓效果要及時評價，對發(fā)現的不足進行改進。 7.4.5 測試人員的培訓第61頁，共115頁。第 7 章 測試項目管理 測試項目管理

23、概述1軟件測試過程管理2測試文檔3測試的組織與人員管理4測試的配置管理5軟件測試的風險管理6軟件測試的成本管理7第62頁，共115頁。 找不到某個文件的歷史版本； 開發(fā)人員使用錯誤的版本修改程序; 開發(fā)人員未經授權修改代碼或文檔； 人員流動，交接工作不徹底； 已修復的Bug在新版本中出現； 無法重新編譯某個歷史版本； 因協(xié)同開發(fā)中，或者異地開發(fā)，版本變更混亂導致整個項目失敗； 軟件項目中是否遇到如下的問題第63頁，共115頁。7.5 測試的配置管理 配置管理是在團隊開發(fā)中標識、控制和管理軟件變更的一種管理。目的是建立和維護在軟件生命周期中軟件產品的完整性和一致性。 測試活動的配置管理屬于整個軟

24、件項目配置管理的一部分，獨立的測試組織應建立專門的配置管理系統(tǒng)。一般來說，軟件測試配置管理包括5個最基本的活動：（1）配置標識； （2）版本控制 ；（3）變更控制； （4）配置狀態(tài)報告；（5）配置審計。第64頁，共115頁。1配置標識 配置標識主要是標識測試樣品、測試標準、測試工具、測試文檔（包括測試用例）、測試報告等配置項的名稱和類型。 所有配置項都應按照相關規(guī)定統(tǒng)一編號，按照相應的模板生成，并在文檔中的規(guī)定部分記錄對象的標識信息，標識各配置項的所有者及儲存位置，指出何時基準化配置項，這樣使得測試相關人員能方便地知道每個配置項的內容和狀態(tài)。7.5 測試的配置管理置于基線控制之下。需要加以控制

25、的配置項分為基線配置項和非基線配置項。所有基線配置項向測試人員開放讀取權限；而非基線配置項向測試組長、項目經理及相關人員開放。第65頁，共115頁。2版本控制 版本控制的目的是按照一定的規(guī)則保存配置項的所有版本，避免發(fā)生版本丟失或混淆等現象，并且可以快速準確地查找到配置項的任何版本。 7.5 測試的配置管理第66頁，共115頁。3變更控制 變更控制的目的并不是控制和限制變更的發(fā)生，而是對變更進行有效的管理，確保變更有序地進行。 7.5 測試的配置管理第67頁，共115頁。 變更控制主要包括以下內容：（1）規(guī)定測試基線，對每個基線必須描述下列內容： 每個基線的項，包括文檔、樣品和工具等； 與每個

26、基線有關的評審、批準事項以及驗收標準。7.5 測試的配置管理第68頁，共115頁。 規(guī)定何時何人創(chuàng)立新的基線，如何創(chuàng)立； 確定變更請求的處理程序和終止條件； 確定變更請求的處理過程中各測試人員執(zhí)行變更的職能； 確定變更請求和所產生結果的對應機制； 確定配置項提取和存入的控制機制與方式。7.5 測試的配置管理第69頁，共115頁。4配置狀態(tài)報告 配置狀態(tài)報告就是根據配置項操作數據庫中的記錄，來向管理者報告軟件測試工作的進展情況。 配置狀態(tài)報告應該包括以下主要內容： 定義配置狀態(tài)報告形式、內容和提交方式； 確認過程記錄和跟蹤問題報告，更改請求，更改次序等； 確定測試報告提交的時間與方式。7.5 測

27、試的配置管理第70頁，共115頁。5配置審計 配置審計的主要作用是作為變更控制的補充手段，來確保某一變更需求已被切實地執(zhí)行和實現。 配置審計包括以下主要內容： 確定審計執(zhí)行人員和執(zhí)行時機； 確定審計的內容與方式； 確定發(fā)現問題的處理方法。7.5 測試的配置管理第71頁，共115頁。第 7 章 測試項目管理 測試項目管理概述1軟件測試過程管理2測試文檔3測試的組織與人員管理4測試的配置管理5軟件測試的風險管理6軟件測試的成本管理7第72頁，共115頁。7.6 軟件測試風險管理1風險的基本概念 軟件風險是指開發(fā)不成功引起損失的可能性，這種不成功事件會導致公司商業(yè)上的失敗。 風險分析是對軟件中潛在的

28、問題進行識別、估計和評價的過程。 軟件測試中的風險分析是根據測試軟件將出現的風險，制定軟件測試計劃，并排列優(yōu)先等級。 第73頁，共115頁。 軟件風險分析的目的是確定測試對象、測試優(yōu)先級，以及測試的深度。有時還包括確定可以忽略的測試對象。 通過風險分析，測試人員識別軟件中高風險的部分，并進行嚴格徹底地測試；確定潛在的隱患軟件構件，對其進行重點測試。在制定測試計劃的過程中，可以將風險分析的結果用來確定軟件測試的優(yōu)先級與測試深度。7.6 軟件測試風險管理第74頁，共115頁。2軟件測試與商業(yè)風險 軟件測試是一種用來盡可能降低軟件風險的控制措施。軟件測試是檢測軟件開發(fā)是否符合計劃，是否達到預期的結果

29、的測試。如果檢測表明軟件的實現沒有按照計劃執(zhí)行，或與預期目標不符，就要采取必要的改進行動。因此，公司的管理者應該依靠軟件測試之類的措施來幫助自己實現商業(yè)目標。7.6 軟件測試風險管理第75頁，共115頁。3軟件風險分析 風險分析是一個對潛在問題識別和評估的過程，即對測試的對象進行優(yōu)先級劃分。風險分析包括以下兩個部分。 發(fā)生的可能性：發(fā)生問題的可能性有多大。 影響的嚴重性：如果問題發(fā)生了會有什么后果。7.6 軟件測試風險管理第76頁，共115頁。 通常風險分析采用兩種方法：表格分析法和矩陣分析法。通用的風險分析表包括以下幾項內容。 風險標識：表示風險事件的惟一標識； 風險問題：風險問題發(fā)生現象的

30、簡單描述； 發(fā)生可能性：風險發(fā)生可能性的級別（110）；7.6 軟件測試風險管理第77頁，共115頁。 影響的嚴重性：風險影響的嚴重性的級別（110）； 風險預測值：風險發(fā)生可能性與風險影響的嚴重性的乘積； 風險優(yōu)先級：風險預測值從高向低的排序。7.6 軟件測試風險管理第78頁，共115頁。 綜上所述，軟件風險分析的目的是：確定測試對象、確定優(yōu)先級，以及測試深度。在測試計劃階段，可以用風險分析的結果來確定軟件測試的優(yōu)先級。對每個測試項和測試用例賦予優(yōu)先代碼，將測試分為高、中和低的優(yōu)先級類型，這樣可以在有限的資源和時間條件下，合理安排測試的覆蓋度與深度。7.6 軟件測試風險管理第79頁，共115

31、頁。4軟件測試風險 軟件測試的風險是指軟件測試過程出現的或潛在的問題，造成的原因主要是測試計劃的不充分、測試方法有誤或測試過程的偏離，造成測試的補充以及結果不準確。測試的不成功導致軟件交付潛藏著問題，一旦在運行時爆發(fā)，會帶來很大的商業(yè)風險。7.6 軟件測試風險管理第80頁，共115頁。 主要是對測試計劃執(zhí)行的風險分析與制定要采取的應急措施，降低軟件測試產生的風險造成的危害。 測試計劃的風險一般指測試進度滯后或出現非計劃事件，就是針對計劃好的測試工作造成消極影響的所有因素，對于計劃風險分析的工作是制定計劃風險發(fā)生時應采取的應急措施。 7.6 軟件測試風險管理第81頁，共115頁。 其中，交付日期

32、的風險是主要風險之一。測試未按計劃完成，發(fā)布日期推遲，影響對客戶提交產品的承諾，管理的可信度和公司的信譽都要受到考驗，同時也受到競爭對手的威脅。交付日期的滯后，也可能是已經耗盡了所有的資源。計劃風險分析所做的工作重點不在于分析風險產生的原因，重點應放在提前制定應急措施來應對風險發(fā)生。當測試計劃風險發(fā)生時，可能采用的應急措施有：縮小范圍、增加資源、減少過程等措施。 7.6 軟件測試風險管理第82頁，共115頁。將采用的應急措施如下。 應急措施1：增加資源。請求用戶團隊為測試工作提供更多的用戶支持。 應急措施2：縮小范圍。決定在后續(xù)的發(fā)布中，實現較低優(yōu)先級的特性。 應急措施3：減少質量過程。在風險

33、分析過程中，確定某些風險級別低的特征測試，或少測試。7.6 軟件測試風險管理第83頁，共115頁。 上述列舉的應急措施要涉及到有關方面的妥協(xié)，如果沒有測試計劃風險分析和應急措施處理風險，開發(fā)者和測試人員采取的措施就比較匆忙，將不利于將風險的損失控制到最小。因此，軟件風險分析和測試計劃風險分析與應急措施是相輔相成的。7.6 軟件測試風險管理第84頁，共115頁。 由上面分析可以看出，計劃風險、軟件風險、重點測試、不測試，甚至整個軟件的測試與應急措施都是圍繞“用風險來確定測試工作優(yōu)先級”這樣的原則來構造的。軟件測試存在著風險，如果提前重視風險，并且有所防范，就可以最大限度減少風險的發(fā)生。在項目過程

34、中，風險管理的成功取決于如何計劃、執(zhí)行與檢驗每一個步驟。遺漏任何一點，風險管理都不會成功。7.6 軟件測試風險管理第85頁，共115頁。第 7 章 測試項目管理 測試項目管理概述1軟件測試過程管理2測試文檔3測試的組織與人員管理4測試的配置管理5軟件測試的風險管理6軟件測試的成本管理7第86頁，共115頁。7.7 軟件測試的成本管理7.7.1 軟件測試成本管理概述 軟件測試項目成本管理就是根據企業(yè)的情況和軟件測試項目的具體要求，利用公司既定的資源，在保證軟件測試項目的進度、質量達到客戶滿意的情況下，對軟件測試項目成本進行有效的組織、實施、控制、跟蹤、分析和考核等一系列管理活動，最大限度地降低軟

35、件測試項目成本，提高項目利潤。第87頁，共115頁。成本管理的過程包括： 資源計劃：包括決定為實施軟件測試項目需要使用什么資源以及每種資源的用量，資源需求清單。 成本估算：包括估計完成軟件測試項目所需西元成本的近似值。其主要輸出是成本管理計劃。 成本預算：包括將整個成本估算配置到各單項工作，以建立一個衡量績效的基準計劃。其主要輸出是成本基準計劃。 成本控制：包括控制軟件測試項目運算的變化，其主要輸出修正的成本估算、更新預算、糾正行動和取得的教訓。7.7 軟件測試的成本管理第88頁，共115頁。7.7.2 軟件測試成本管理的一些基本概念 對于一般項目，項目的成本主要由項目直接成本、管理費用和期間

36、費用等構成。 直接成本：指與項目有直接關系的成本費用，是與項目直接對應的，包括直接人工費用、直接材料費用和其他直接費用；項目管理費用：指為了組織、管理和控制項目所發(fā)生的費用，一般是簡介費用；期間費用：與項目的完成沒有直接關系，費用的發(fā)生基本上項目業(yè)務量的增減所影響。例如，日常的行政管理費用、醫(yī)療保險費用等。7.7 軟件測試的成本管理第89頁，共115頁。1測試費用有效性 風險承受的確定，從經濟學的角度考慮就是確定需要完成多少測試，以及進行什么類型的測試。經濟學所做的判斷，確定了軟件存在的缺陷是否可以接受，如果可以，能承受多少。測試的策略不再主要由軟件人員和測試人員來確定，而是由商業(yè)的經濟利益來

37、決定的。7.7 軟件測試的成本管理第90頁，共115頁。 “太少的測試是犯罪，而太多的測試是浪費?！睂︼L險測試得過少，會造成軟件的缺陷和系統(tǒng)的癱瘓；而對風險測試得過多，就會使本來沒有缺陷的系統(tǒng)進行沒有必要的測試，或者是對輕微缺陷的系統(tǒng)所花費的測試費用遠遠大于它們給系統(tǒng)造成的損失。7.7 軟件測試的成本管理第91頁，共115頁。 測試費用的有效性，可以用測試費用的質量曲線來表示，如圖7-1所示。隨著測試費用的增加，發(fā)現的缺陷也會越多，兩線相交的地方是過多測試開始的地方，這時，排除缺陷的測試費用超過了缺陷給系統(tǒng)造成的損失費用。7.7 軟件測試的成本管理第92頁，共115頁。圖7-1 測試費用的質量

38、曲線 第93頁，共115頁。2測試成本控制 測試成本控制也稱為項目費用控制，就是在整個測試項目的實施過程中，定期收集項目的實際成本數據，與成本的計劃值進行對比分析，并進行成本預測，及時發(fā)現并糾正偏差，使項目的成本目標盡可能好地實現。 7.7 軟件測試的成本管理第94頁，共115頁。 測試工作的主要目標是使測試產能最大化，也就是，要使通過測試找出錯誤的能力最大化，而檢測次數最小化。測試的成本控制目標是使測試開發(fā)成本、測試實施成本和測試維護成本最小化。 在軟件產品測試過程中，測試實施成本主要包括：測試準備成本、測試執(zhí)行成本和測試結束成本。7.7 軟件測試的成本管理第95頁，共115頁。(1) 測試

39、準備成本控制 目標是使時間消耗總量、勞動力總量最小化。(2) 測試執(zhí)行成本控制 目標是使總執(zhí)行時間和所需的測試專業(yè)設備盡可能地減少。7.7 軟件測試的成本管理第96頁，共115頁。 對部分重新測試進行合理的選擇，將風險降至最低，而成本同樣會很高，必須將其與測試執(zhí)行成本進行比較，權衡利弊。利用測試自動化，進行重新測試，其成本效益是較好的。部分重新測試選擇方法有兩種： （1） 對由于程序變化而受到影響的每一部分進行重新測試； （2） 對與變化有密切和直接關系的部分進行重新測試。7.7 軟件測試的成本管理第97頁，共115頁。 （3）測試結束成本控制 （4）降低測試實施成本 （5）降低測試維護成本

40、降低測試維護成本，與軟件開發(fā)過程一樣，加強軟件測試的配置管理，所有測試的軟件樣品、測試文檔（測試計劃、測試說明、測試用例、測試記錄、測試報告）都應置于配置管理系統(tǒng)控制之下。降低測試維護工作成本主要考慮：7.7 軟件測試的成本管理第98頁，共115頁。 對于測試中出現的偏差要增加測試； 采用漸進式測試，以適應新變化的測試； 定期檢查維護所有測試用例，以獲得測試效果的連續(xù)性。7.7 軟件測試的成本管理第99頁，共115頁。 保持測試用例效果的連續(xù)性是重要的措施，有以下幾個方面： 每一個測試用例都是可執(zhí)行的，即被測產品功能上不應有任何變化； 基于需求和功能的測試都應是適合的，若產品需求和功能發(fā)生小的

41、變化，不應使測試用例無效； 每一個測試用例不斷增加使用價值，即每一個測試用例不應是完全冗余的，連續(xù)使用，應是成本效益高的。7.7 軟件測試的成本管理第100頁，共115頁。3質量成本 測試是一種帶有風險性的管理活動，可以使企業(yè)減少因為軟件產品質量低劣，而花費不必要的成本。7.7 軟件測試的成本管理第101頁，共115頁。（1）質量成本要素 質量成本要素主要包括一致性成本和非一致性成本。一致性成本是指用于保證軟件質量的支出，包括預防成本和測試預算，如測試計劃、測試開發(fā)、測試實施費用。7.7 軟件測試的成本管理第102頁，共115頁。 非一致性成本是由出現的軟件錯誤和測試過程故障（如延期、劣質的發(fā)

42、布）引起的。這些問題會導致返工、補測、延遲。追加測試時間和資金就是一種由于內部故障引起的非一致性成本。非一致性成本還包括外部故障（軟件遺留錯誤影響客戶）引起部分。一般情況下，外部故障非一致性成本要大于一致性成本與內部故障非一致性成本之和。7.7 軟件測試的成本管理第103頁，共115頁。（2）質量成本計算 質量成本一般按下式計算：質量成本 = 一致性成本 + 非一致性成本7.7 軟件測試的成本管理第104頁，共115頁。4缺陷探測率 缺陷探測率是另一個衡量測試工作效率的軟件質量成本的指標。缺陷探測率=測試發(fā)現的軟件缺陷數/(測試發(fā)現的軟件缺陷數+客戶發(fā)現并反饋技術支持人員進行修復的軟件缺陷數)

43、7.7 軟件測試的成本管理第105頁，共115頁。測試投資回報率可按下式計算：投資回報率 = 利潤 / 測試投資100%7.7 軟件測試的成本管理第106頁，共115頁。例 假設對一個客戶管理軟件進行測試。 屬于質量預防方面的一致性成本只考慮軟件測試的投資； 把發(fā)布之前、之后發(fā)現及修改的錯誤看成非一致性成本； 假設發(fā)現的錯誤為300個，故障成本已知，測試過程的估算如下：第107頁，共115頁。例 在開發(fā)過程單元測試階段，軟件開發(fā)人員發(fā)現及修改一個錯誤需要50元； 建立獨立的測試進行系統(tǒng)和集成測試，測試人員發(fā)現錯誤，開發(fā)人員修改后，測試人員再確認，一個錯誤需要花費300元； 在產品發(fā)布后，由客戶發(fā)現，報告技術支持人員，相關開發(fā)人員修改，測試組再進行回歸測試，一個錯誤需要花