測試計劃與測試管理

1、第七章 測試計劃與測試管理精選ppt7.1 測試文檔和測試計劃7.1.1 測試計劃概述7.1.2 測試計劃的主要內容7.1.3 編寫合適有效的測試計劃必須考慮的問題精選ppt7.1.1測試計劃概述什么是測試計劃：測試計劃包含項目范圍內的測試目的和測試目標的有關信息。此外，測試計劃還將確定實施和執(zhí)行測試時所使用的策略以及所需資源；以及對測試風險等做出預先的計劃和安排測試計劃包括測試主計劃和階段計劃。 項目開始時制訂測試主計劃。根據開發(fā)的迭代過程和測試主計劃對測試計劃進行細化，制訂各個階段的測試計劃。 精選ppt測試計劃概述（續(xù)）制定測試計劃的目的 一個計劃一定是為了某種目的而產生的，對于軟件質量

2、管理而言，制定測試計劃的目的主要有3個。1使軟件測試工作進行更順利2促進項目參加人員彼此的溝通3使軟件測試工作更易于管理精選ppt測試計劃概述（續(xù)）制定測試計劃的原則 制定測試計劃是軟件測試中最有挑戰(zhàn)性的一個工作。以下原則將有助于制定測試計劃工作。1制定測試計劃應盡早開始2保持測試計劃的靈活性3保持測試計劃簡潔和易讀4盡量爭取多渠道評審測試計劃5計算測試計劃的投入精選ppt7.1.2 測試計劃的主要內容1 范圍1.1 標識1.2 系統(tǒng)概述1.3 文檔概述1.4 與其它計劃的關系2 引用文檔3 軟件測試環(huán)境3.1 軟件項3.2 硬件和固件項3.3 權限3.4 安裝、測試與控制4 正式合格性測試4

3、.X （CSCI 名稱和項目唯一標識號）4.X.1 總體測試要求4.X.2 測試類4.X.3 測試級4.X.4 測試定義4.X.4.Y （測試名稱和項目唯一標識號）4.X.5 測試進度5 數據記錄、整理和分析精選ppt測試計劃主要內容(續(xù))1 范圍1.1 標識列現本文檔的：a 已批準的標識號；b 標題；c 縮略語；d 本文檔適用的系統(tǒng)和計算機軟件配置項（CSCI）。如果本文檔適用于系統(tǒng)中所有的CSCI，則也要說明。并用標題、縮略語和標識號寫出適用的CSCI。精選pptCSCI是計算機軟件配置項(Computer Software Configuration Item),CSC是計算機軟件部件(

4、Computer Software Component),CSU是計算機軟件單元(Computer Software Unit). HWCI (HardWare Configuration Item) 硬件配置項.項目測試過程中會產生許許多多的工作成果，例如測試計劃文檔、測試用例以及自動化測試執(zhí)行腳本和測試缺陷數據等，他們都應當被保存起來，以便查閱和修改。這些納入配置管理范疇的工作成果統(tǒng)稱為配置項(Configuration Item，CI)，每個配置項的主要屬性有：名稱、標識符、文件狀態(tài)、版本、作者、日期等。精選ppt測試計劃主要內容(續(xù))1.2 系統(tǒng)概述概述本文檔所適用的系統(tǒng)和CSCI 的

5、用途。1.3 文檔概述概述本文檔的用途和內容。1.4 與其它計劃的關系概述本計劃與其它項目測試計劃的關系。精選ppt測試計劃主要內容(續(xù))2 引用文檔按文檔號和標題列出本文檔引用的所有文檔。3 軟件測試環(huán)境分節(jié)標識和描述為執(zhí)行正式合格性測試所使用資源（軟件、固件和硬件）的實現和控制計劃。為減少重復，對在軟件測試環(huán)境和軟件工程環(huán)境中均用到的資源，可以引用在“軟件開計劃”文檔中有關的軟件工程環(huán)境的描述。精選ppt測試計劃主要內容(續(xù))3.1 軟件項 標識用于執(zhí)行正式合格性測試的軟件項（如，操作系統(tǒng)、編譯器、編碼審核器、動態(tài)路徑分析器、測試驅動器、預處理器、測試數據產生器、后處理器），描述并說明每個

6、軟件項的用途、保密處理和安全性問題。3.2 硬件和固件項標識用于軟件測試環(huán)境的計算機硬件、接口設備和固件項。描述并說明每個項目的用途、保密處理和安全性問題。精選ppt測試計劃主要內容(續(xù))3.3 權限標明軟件測試環(huán)境相關的每個項目的專利和權限。3.4 安裝、測試與控制本節(jié)應標識承制方為安裝和測試每個項目所制訂的計劃，還應要描述承制方為控制和維護軟件測試環(huán)境而制訂的計劃。 精選ppt人員人數、經驗和專長。他們是全職、兼職、業(yè)余還是學生？設備計算機、測試硬件、打印機、測試工具等。辦公室和實驗室空間在哪里？空間有多大？怎樣排列？軟件字處理程序、數據庫程序和自定義工具等。其他資源軟盤、電話、參考書、培

7、訓資料等。測試計劃主要內容(續(xù))精選ppt測試計劃主要內容(續(xù))4 正式合格性測試分節(jié)對每個正式合格性測試進行說明，并描述軟件測試計劃對每個CSCI 作正式合格性測試的要求。4.X （CSCI 名稱和項目唯一標識號）從4.1 節(jié)開始編號。用名稱和項目的唯一標識號標識CSCI。4.X.1 總體測試要求從4.1.1 開始編號。描述用于所有正式合格性測試或用于一組正式合格性測試的要求。例如：每個正式合格性測試都需要滿足下列一般要求：精選ppt測試計劃主要內容(續(xù))a 測量CSCI 的大小和執(zhí)行時間；b 用假設值、最大值和錯誤值作為輸入對CSCI 進行測試。c 對CSCI 進行錯誤判斷和出錯恢復的測試

8、，包括相關的錯誤信息。對不同的實際問題應外加相應的專門測試。例如，驗證雷達跟蹤要求的正式合格性測試需滿足下列要求：（1）對特定環(huán)境條件的組合，用模擬數據對CSCI 進行測試；（2）用從該環(huán)境中提取的“真實數據”作為輸入，對CSCI 進行測試。精選ppt測試計劃主要內容(續(xù))4.X.2 測試類從4.1.2 節(jié)開始編號。描述要進行的正式合格性測試的種類或類型（如：強度測試、時間性測試、錯誤輸入測試、最大能力測試等）。4.X.3 測試級從4.1.3 節(jié)開始編號。描述要進行的正式合格性測試的級別，例如：aCSCI 級（如果需要，也可劃分為CSC 或CSU 級）：評測與CSCI 要求的符合程度；bCSC

9、I 到CSCI 集成級：評測與CSCI 外部接口要求的符合程度；精選ppt測試計劃主要內容(續(xù))cCSCI 到HWCI 集成級：評測與CSC 外部接口要求的符合程度；d系統(tǒng)級：評測與整個系統(tǒng)CSCI 要求的符合程度。4.X.4 測試定義從4.1.4 節(jié)開始編號。分節(jié)標識和描述用于CSCI 的各項正式合格性測試。4.X.4.Y （測試名稱和項目唯一標識號）從4.1.4.1 節(jié)開始編號。用測試名和項目唯一標識號標識正式合格性測試。本切要給出下列用于測試的信息，這些信息的一部分或全部可以用圖表給出，如：a 測試對象；b 特殊要求（如：48 小時設備連續(xù)運行）；c 測試級；精選ppt測試計劃主要內容(

10、續(xù))d 測試種類或類型；e 在軟件需求規(guī)格說明中規(guī)定的合格性方法；f 該測試所涉及的軟件需求規(guī)格說明對CSCI 工程需求的交叉引用；g 該測試所涉及的接口需求規(guī)格說明對CSCI 接口需求的交叉引用；h 記錄的數據類型；i 假定和約束條件。4.X.5 測試進度說明或引用本文檔4.X.4 的測試進度。5 數據記錄、整理和分析分節(jié)描述按本測試計劃所作測試的數據整理和分析過程。并說明根據數據整理和分析得到的信息和結果。數據記錄、整理和分析的結果應清楚地顯示出是否達到測試目標。精選ppt7.1.3 編制合適有效的測試計劃考慮的問題1 了解手頭的任務和相關的測試目標2 考慮風險3 根據功能優(yōu)先級安排測試工

11、作4 規(guī)劃測試環(huán)境精選ppt 1了解手頭的任務和相關的測試目標Step1:了解手頭的任務、它的范圍和與之關聯(lián)的測試目標,必須對實現測試目標過程中起作用的每個細節(jié)都清楚。How to understand?理解系統(tǒng)：功能需求+非功能需求涉及整個系統(tǒng)的討論會和文檔（對系統(tǒng)要解決的問題的有關討論、高層次的商業(yè)需求陳述、產品管理的案例研究和商業(yè)案例）及早介入（測試經理等）：增加對客戶需求、客戶問題、潛在的風險和功能的理解理解企業(yè)文化和過程測試組和開發(fā)組獨立還是一體化？測試方法是否適應“極限編程”的方法？精選ppt了解手頭的任務和相關的測試目標（續(xù)）實現的范圍（測試范圍）測試的期望管理層對測試的期望？客

12、戶期望的測試類型？（驗收測試？遵從的方法？預定的里程碑？可交付使用的含義？）吸取教訓：以前的測試工作中學到了什么？（確定測試策略、設定實際的測試預期）工作量大?。撼醪焦烙嬳椖康膹碗s度的工作量解決方案的類型：最終是實現了最復雜的解決方案？較短時間開發(fā)、更劃算的解決方案？（決定采用的測試類型）精選ppt了解手頭的任務和相關的測試目標（續(xù)）技術選擇：實現技術？引起的問題？架構？系統(tǒng)類型？（確定測試策略、選擇測試工具）預算（確定測試類型、測試工作量）時間表：系統(tǒng)測試的時間？截止日期？調整測試時間表獲得測試環(huán)境所需的硬件和軟件？評估、購買和實現測試工具分階段的解決方案（迭代開發(fā)？發(fā)行許多版本？）精選pp

13、t2考慮風險軟件測試人員要明確地指出計劃過程中的風險，并與測試管理員和項目管理員交換意見。這些風險應該在測試計劃中明確指出，在進度中予以考慮。有些風險是真正存在的，而有些最終證實是無所謂的，重要的是盡早明確指出，以免在項目晚期發(fā)現時感到驚慌。風險分析是一項十分艱巨的工作，尤其是第一次嘗試進行時更是如此，但是以后會好起來，而且也值得這樣做。精選ppt考慮風險(續(xù))一般而言，大多數測試小組都會發(fā)現自己的資源有限，不可能窮盡測試軟件所有方面。如果能勾畫出風險的輪廓，將有助于測試人員排定待測試項的優(yōu)先順序，并且有助于集中精力去關注那些極有可能發(fā)生失效的領域。下面是一些潛在的問題和風險的例子：不現實的交

14、付日期與其他系統(tǒng)的接口 處理巨額現金的特征極其復雜的軟件 有過缺陷歷史的模塊發(fā)生過許多或者復雜變更的模塊安全性、性能和可靠性問題 難于變更或測試的特征精選ppt考慮風險(續(xù))確定測試策略時了解項目風險，每個項目都有一系列的風險，其中某些風險的級別可能比另一些風險高。（風險級別的排列考慮了損失發(fā)生的可能性和損失帶來的影響的嚴重程度）風險分類和來源風險評估降低風險的測試策略精選ppt考慮風險(續(xù))風險分析（續(xù)）風險分析所提供的信息，有助于測試經理作出決定：根據技能的高低、需要的工作量、風險和質量目標分配測試人員精選ppt降低風險的測試策略把測試工作的重點放在系統(tǒng)中可能會引起絕大多數問題的那些部分。

15、測試經理必須確定風險最大的部分、最可能出現問題的部分、最易失靈的功能對風險低和影響小的功能，只執(zhí)行必須的測試工作，并可為新手提供積累經驗的機會。產生可預測的、更高質量的測試結果精選ppt3 制定測試策略(續(xù))根據功能優(yōu)先級安排測試工作最需要的功能的最先開發(fā)和測試根據不同的標準劃分優(yōu)先級風險最高到最低復雜度最高到最低客戶的需要（市場和銷售）預算的限制時間的限制人員限制（特殊需求？誰來做？）綜合使用以上方法，得到一個功能的總體價值，并進行排序，得到功能優(yōu)先級表。精選ppt4 規(guī)劃測試環(huán)境測試環(huán)境：支持測試工作的所有物質元素測試數據、硬件、軟件、網絡和設備測試環(huán)境必須反映軟件最終運行環(huán)境的基線配置設

16、計測試環(huán)境獲得客戶環(huán)境的樣本（os,支撐軟件，硬件）確定是否需要一個歸檔機制來存儲測試后生成的大文件（日志）確定網絡特性（帶寬、網絡協(xié)議等）確定服務器os確定需要的自動測試工具的許可證數量確定執(zhí)行某些測試過程需要的其他軟件確定硬件環(huán)境時考慮測試數據的需求（規(guī)模）考慮配置測試需要的特殊資源（活動硬盤和圖像庫）精選ppt7.2軟件測試管理7.2.1 測試執(zhí)行周期的入口標準（開始時間）和 出口標準（完成時間）7.2.2 測試用例管理7.2.3 缺陷追蹤管理精選ppt7.2.1系統(tǒng)測試周期的入口和出口標準1入口標準在系統(tǒng)測試期間,為了接受一個軟件版本,必須滿足以下標準:所有的單元測試和集成測試成功完成

17、、軟件的生成過程沒有任何錯誤、配套文檔完成、缺陷已經修正并且準備重新測試源代碼已經存儲在版本控制系統(tǒng)只有以上標準滿足后,測試組才接受軟件版本并開始測試周期精選ppt測試周期的入口和出口標準(續(xù))2出口標準:描述了軟件完成了充分測試的時間.測試資源有限,測試預算和測試工程師的人數有限,截止期限很快就到了,測試工作的范圍也有一定的限制.即使?jié)M足了出口標準，只是說明它對客戶是有用的。所有基于需求的、預先定義的測試過程在執(zhí)行過程中沒有出現任何重大錯誤高優(yōu)先級的問題已經被開發(fā)人員修正，并且由測試組成員用回歸測試進行了驗證已經執(zhí)行了用來確定系統(tǒng)滿足指定的功能性和非功能性需求的測試過程精選ppt測試周期的入

18、口和出口標準(續(xù))在測試結果中記錄的所有1級、2級和3級的軟件問題都已經解決在測試結果中記錄的所有1級、2級的軟件問題都已經解決在測試結果中記錄的所有1級、2級的軟件問題都已經解決，同時90%的3級問題已經解決。軟件發(fā)布時可能存在已知的低優(yōu)先級的缺陷（當然有若干未知缺陷）精選ppt測試周期的入口和出口標準(續(xù))一些度量也可以作為出口標準的一部分在回歸測試中，從以前運轉正常的功能中發(fā)現缺陷的比例？（修正工作破壞以前運轉正常功能的頻率？）缺陷修正失敗的頻率？新缺陷的發(fā)現率走勢？下降精選ppt7.2.2 測試用例的管理測試用例的管理屬性有那些？測試用例體本身的屬性有那些？測試用例管理系統(tǒng)可以協(xié)助對測

19、試用例進行良好的管理精選ppt測試用例的管理屬性行業(yè)，屬性值用列表表示，包括：銀行、電信、交通、電子、智能樓宇、其它.操作系統(tǒng)，屬性值用列表表示，包括：windows 98、windows 2000、windows XP、Unix、Linux，嵌入式軟件的操作系統(tǒng)有：Linux(armlinux/uClinux/RTlinux)、Vxworks、uCos/II、pSos、eCos、WinCE、Delta OS、VRTX、Nucleus、其它；數據庫管理系統(tǒng)，屬性值用列表表示，包括：sql server, my sol, oracle, Sybase, access，其它；瀏覽器，屬性值用列表表

20、示，包括：ie3.0,ie4.0，ie5.0,ie6.0,netscape3.0，netscape4.0，netscape6.0，其它；這三個屬性支持具有相同系統(tǒng)平臺的被測軟件項目間的測試用例復用；精選ppt測試用例的管理屬性系統(tǒng)類型，屬性值用列表表示，包括：嵌入式、b/s、c/s、其它；編碼語言，屬性值用列表表示，包括：java、c+、c、smalltalk、dephi、其它；測試類型，屬性值用列表表示，包括：功能（包括可使用性測試）、兼容性、負載測試、強度測試、數據庫容量測試、安全性測試、其它;測試階段項目名稱創(chuàng)建人/創(chuàng)建時間 重要級別:狀態(tài)精選ppt測試用例體本身的屬性包括以下屬性：測試

21、用例名稱、測試用例目的描述、測試用例版本號、相關附件、測試用例描述方式、測試用例前置條件、輸入、操作步驟、預期輸出、程序文件；與復用操作有關的屬性有：父測試用例id、修改原因、修改時間、修改人員。在這些屬性中，“測試用例目的描述”屬性記錄了測試用例的測試目的，因為每個測試用例都必須有明確的測試目標； “測試用例描述方式”屬性的值用列表表示，屬性值包括文本方式、源代碼（c，c+，java，rational腳本，qbasic，其它）、可執(zhí)行程序 ；精選ppt測試用例體本身的屬性“測試用例前置條件”屬性用文字描述測試用例執(zhí)行前必須滿足的條件，可能是和其他測試用例的關系，比如：在運行測試用例A的前提下

22、才能完成該測試用例就描述了測試用例A和該測試用例之間的關系；“輸入”屬性可以是某個數據源，要給出數據源的路徑和名稱；或是具體的數據，要給出具體數據；“操作步驟”屬性用文字描述操作步驟，各個操作步驟之間用“”進行分隔；“預期輸出”屬性指測試用例執(zhí)行后的預期結果；“程序文件”屬性是指有關的一些程序。(當測試用例是自動測試時所錄制的腳本程序或者是可執(zhí)行程序時.)“相關附件”屬性是指與測試用例有關的一些文件；精選ppt測試用例管理系統(tǒng)可以協(xié)助對測試用例進行良好的管理市場上比較有名的測試管理工具中，國外著名的有Rational公司的Test Manager、Compueware公司的QADirector

23、、MI的TestDirector等軟件；國內比較有名的有中科院的I-test、北航的QESuite等軟件，在這些工具中，測試用例的管理只是其中的一個子系統(tǒng)，提供的功能有限。 精選ppt7.2.3 缺陷追蹤管理缺陷文檔包含的屬性舉例缺陷優(yōu)先級和嚴重性劃分缺陷的分離和重現缺陷的度量及其意義精選ppt1缺陷文檔包含的屬性舉例度量項目名稱 值 說明缺陷id Y+M+D+id 例如：08090101 表示2008年9月1日記錄的第1個 缺陷狀態(tài) 1，2 1新發(fā)現狀態(tài)，2正在修改狀態(tài) 3，4 3待確認狀態(tài)，4修改完畢狀態(tài)測試人員 id 001 編號為001的測試人員提交時間 Y+M+D+AM/PM 例如0

24、80902a 表示缺陷在2008年9月2日上午 提交 缺陷所屬項目 id wf01 項目編號為01的工作流系統(tǒng)缺陷所屬模塊 id wf0101 該缺陷位于工作流系統(tǒng)的01模塊開發(fā)人員 id 001 編號為001的測試人員缺陷類型 A-E 詳見表2優(yōu)先級 1，2 ,3，4 1-Urgent,2-High ,3-Midium,4-Low 修改人 id 001 編號為001的修改人解決方案 文字描述 提出解決當前缺陷的方案并給出修改部分代碼修改時間 Y+M+D 例如080902表示2008年9月2日進行修改修改次數 N 用自然數記錄該缺陷被反復修改的次數確認結果 1/0 1-表示缺陷已修復，0表示該

25、缺陷還需再次修改精選ppt2缺陷類別劃分 缺陷類別 標識/權值 說明A 類 A1/5.6 由程序執(zhí)行引起的死機、非法退出 A2/5.5 死循環(huán) A3/5.4 數據庫發(fā)生死鎖 A4/5.3 數據庫設計未達到第三范式的要求或需求規(guī)格說明的水平 A5/5.2 數據功能實現錯誤 A6/5.1 與數據庫連接錯誤 A7/5.0 數據通訊錯誤 B 類 B1/4.3 程序語法錯誤 B2/4.2 因錯誤操作迫使程序中斷 B3/4.1 程序接口錯誤 B4/4.0 數據庫的表、業(yè)務規(guī)則、缺省值未加完整性等約束條件 C 類 C1/3.4 操作界面錯誤(包括數據窗口內列名定義、含義是否一致) C2/3.3 打印內容、格

26、式錯誤 C3/3.2 簡單的輸入限制未放在前臺進行控制 C4/3.1 刪除操作未給出提示 C5/3.0 數據庫表中有過多的空字D 類 D1/2.5 界面不規(guī)范 D2/2.4 輔助說明描述不清楚 D3/2.3 輸入輸出不規(guī)范 D4/2.2 長操作未給用戶提示 D5/2.1 提示窗口文字未采用行業(yè)術語 D6/2.0 可輸入區(qū)域和只讀區(qū)域沒有明顯的區(qū)分標志 E 類 E1/6.1 遺漏部分功能 E2/6.1 實現功能與需求不相吻合精選ppt缺陷優(yōu)先級劃分優(yōu)先級 1 :緊急,需要馬上關注2:高級,是重要的,1處理完后趕快處理3:中級,可以用較長時間解決4:低級,時間和資源允許就解決精選ppt普通的缺陷處

27、理流程缺陷報告最初生成的狀態(tài)為“新”；賦予各個小組打開不同問題的能力（錯誤、變更請求、增強請求）選擇缺陷優(yōu)先級評估缺陷，為缺陷分配狀態(tài)若狀態(tài)為“打開”，則把缺陷分配給負責的人，變?yōu)椤伴_發(fā)”狀態(tài)開始改正缺陷了，變?yōu)椤罢陂_發(fā)”狀態(tài)缺陷改正完了，改為“修改完畢”狀態(tài)；或者“工作正?！?、“缺陷不能重現”若創(chuàng)建了新版本，所有改正的缺陷改為“返測”狀態(tài)測試工程師返測這些改動，設置狀態(tài)為“關閉-改正”、“返測失敗”精選ppt普通的缺陷處理流程精選ppt3缺陷的分離和重現有效地報告缺陷?(明顯,通用,再現步驟)執(zhí)行一些測試用例后出現分離缺陷記錄每一個步驟每一個停頓每一件工作查找時間依賴和競爭條件的問題(sl

28、ow軟盤,quick硬盤)(時間發(fā)生次序)與負荷相關的邊界條件內存泄露數據溢出考慮資源依賴性和內存網絡硬件共享的相互作用精選ppt4缺陷的度量及其意義為了保證軟件的質量，軟件開發(fā)組織必須對軟件測試中發(fā)現的缺陷進行有效的管理，確保測試人員發(fā)現的所有缺陷都能夠得到適當的處理。對缺陷數據進行分析和度量，使我們在改正缺陷的同時，挖掘出更多對項目管理有用的信息，以便建立高效的缺陷管理流程,并使缺陷管理更好地融入項目管理過程中，轉被動為主動，將缺陷管理從流程處理的模式下完全解脫出來，并將這一過程推向更高的階段量化管理階段.精選ppt缺陷的度量及其意義(續(xù))對收集的缺陷數據度量，并使用統(tǒng)計方法或者分析模型得

29、出分析結果，以便: 了解缺陷集中的區(qū)域，明晰缺陷發(fā)展趨向，度量軟件開發(fā)過程中各階段工作產品的質量，評估開發(fā)人員的效率、測試人員的效率和項目進展的情況.這對于軟件過程的改進，軟件產品的發(fā)布，軟件質量的預測具有十分重要的意義。精選ppt缺陷的度量及其意義(續(xù))軟件開發(fā)只有引入了度量機制和定量化的管理，才能稱為真正意義上的“工程”，這一準則清楚地體現在CMM中：CMM 4級（已管理級）引入了“定量軟件過程”，CMM 5級（優(yōu)化級）則完全建立在定量管理的基礎之上，并明確提出了“缺陷預防”。 精選ppt缺陷的度量及其意義(續(xù))缺陷的發(fā)展趨勢缺陷的發(fā)展趨勢包括新發(fā)現缺陷數量增長趨勢和關閉缺陷數量的增長趨勢

30、。對于軟件產品發(fā)布而言，發(fā)展趨勢圖是輔助決策的重要依據。一般來說，軟件發(fā)布的必要條件是新缺陷的數量增加呈下降趨勢.精選ppt缺陷的度量及其意義(續(xù))精選ppt缺陷的度量及其意義(續(xù))缺陷的分布狀況在軟件開發(fā)過程中，缺陷分布狀況圖有助于我們了解各版本中缺陷數量的分布。特別在回歸測試階段中，缺陷的分布可以直接反映出版本的質量狀況（見下圖中各版本缺陷的分布狀況）。缺陷分布狀況圖有兩種，第一種是缺陷按模塊的分布狀況，另外一種是缺陷按產生的根本原因的分布狀況。缺陷的模塊分布圖反映的是各個模塊中缺陷數量的分布狀況。它可以被用來評估各模塊質量水平，開發(fā)難度。同時也能從側面反映出測試資源在各模塊分布的情況。精

31、選ppt缺陷的度量及其意義(續(xù))精選ppt5缺陷管理系統(tǒng)國內外已出現了一批質量較好的缺陷管理工具，其中比較有代表性的有：開源軟件Bugzilla、jiraCompuware公司的TrackRecord 、Rational公司的ClearQuest、北京航空航天大學的QAMonitor、上海微創(chuàng)軟件有限公司的BMS等。這些工具各有特色，在功能的全面性上也各不相同，但都是基于“找出缺陷、修改缺陷、進行回歸測試”這種面向流程處理的傳統(tǒng)模式，實現了缺陷管理的基本流程，并在此基礎上提供了一些查詢和統(tǒng)計功能；其共同的缺點是沒有充分利用軟件開發(fā)過程中產生的缺陷數據，不能以一種主動的、精確量化的方式對軟件缺陷

32、進行預防并提供軟件項目管理者所需的有關產品和過程的度量信息。 精選ppt7.3測試管理1.企業(yè)的測試策略2.企業(yè)的測試人員的組織3. 測試組織與管理4.測試部門的測試評估5. 測試部門的管理精選ppt1. 企業(yè)的測試策略1 理念：企業(yè)的主要目的是獲取利潤，降低測試成本也是盈利的一種方式。 用較低的代價實現有效的測試，不應為了追求完美的測試而不失一切代價。精選ppt1. 企業(yè)的測試策略2 如何合理地減少測試工作量減少冗余的測試白盒測試與黑盒測試的方式雖然不同，但往往有“異曲同工”之妙。在很多地方，白盒測試與黑盒測試會產生一模一樣的效果（或者能推理出來），這樣的測試是冗余的。在集成測試、系統(tǒng)測試階

33、段，可能要執(zhí)行多次“回歸測試”。每一次“回歸測試”都會存在不少的冗余，應當設法剔除不必要的重復測試工作。 減少無價值的測試無價值的測試通常是由于不懂得測試技術引起的。例如功能測試，在等價區(qū)間之中，本來只要測試一個典型的輸入就行了，如果有人在此區(qū)間測試了100次，那么其中99次就是無價值的。 。精選ppt1. 企業(yè)的測試策略如何“偷工減料” 有一些“短、平、快”的項目，經費本來就少，用戶對質量要求也馬馬虎虎。為了能多掙一點錢，開發(fā)方不得不采用“偷工減料”的方式來降低測試代價。偷工減料的途徑無非就是減少測試的內容和頻度。但不能砍得太狠，否則軟件拿不出手?；痉椒ㄊ钦页鲕浖行枰獌?yōu)先測試的部分,其它

34、次要部分可以忽略或將來再測試.“偷工減料”方法的測試優(yōu)先級：哪些功能是軟件的特色？ 哪些功能是用戶最常用的？ 如果系統(tǒng)可以分塊賣的話，哪些功能塊在銷售時最昂貴？ 哪些功能出錯將導致用戶不滿或索賠？哪些程序是最復雜、最容易出錯的？哪些程序是相對獨立，應當提前測試的？哪些程序最容易擴散錯誤？哪些程序是全系統(tǒng)的性能瓶頸所在？哪些程序是開發(fā)者最沒有信心的？精選ppt1. 企業(yè)的測試策略3 測試的經濟學(下頁)“Too little testing is a crimetoo much testing is a sin.”4 測試獎勵機制根據缺陷的危害程度，把獎金分等級。每個新缺陷對應一份獎金，把獎金發(fā)

35、給第一個發(fā)現該缺陷的人。獎金額要適當，太低了人們不感興趣，太高了會讓項目破產的。 精選ppt測試的經濟學精選ppt2. 測試人員的組織1 了解開發(fā)人員的測試心理測試的目的是找出盡可能多的缺陷。所以測試是“破壞性”的，而開發(fā)卻是“建設性”的。開發(fā)人員總是喜歡欣賞程序的成功之處，而不愿看到失敗之處。讓開發(fā)者去做“蓄意破壞”的測試，就象殺自己的孩子一樣難以接受。 開發(fā)者對自己的程序印象深刻，并總以為是正確的（自信是應該的）。倘若在設計時就存在理解錯誤，或因不良的編程習慣而流下了隱患，他本人很難發(fā)現這類錯誤.開發(fā)者對自己的程序的功能、接口十分熟悉，他自己幾乎不可能因為使用不當而引發(fā)錯誤，這與大眾用戶的

36、情況不太相似，所以測試自己的程序不具備典型性。 結論：開發(fā)人員應當測試自己的程序，這是他分內的工作。但是開發(fā)人員在測試自己的程序時，很難做到客觀、公正，所以自我測試不具有說服力。 精選ppt2. 測試人員的組織2 如何組織測試人員：應當視企業(yè)的人力資源而定條件特別好的公司，可以為每一個開發(fā)人員分配一名獨立的測試人員。這樣的測試人員職業(yè)化程度很高，可以完成單元測試、集成測試和系統(tǒng)測試工作，能夠實現開發(fā)與測試同步進行。條件比較好的公司，可以設置一個獨立的測試小組，該測試小組輪流參加各個項目的系統(tǒng)測試。而單元測試、集成測試工作由項目的開發(fā)小組承擔。 條件一般的公司，養(yǎng)不起獨立的測試小組。單元測試、集

37、成測試工作由項目開發(fā)小組承擔。當項目進展到系統(tǒng)測試階段，可以從項目外抽調一些人員，加上開發(fā)人員，臨時組織系統(tǒng)測試小組。 條件比較差的公司，也許只有一個項目和為數不多的一些開發(fā)人員。那么就讓開發(fā)人員一直兼任測試人員的角色，相互測試對方的程序。如果人員實在太少了，只好讓開發(fā)者測試自己的程序，有測試總比沒有測試好吧！ 精選ppt2. 測試人員的組織3 避免開發(fā)人員與測試人員產生矛盾開發(fā)人員的注意事項： 不要敵視測試人員。要理解測試的目的就是發(fā)現缺陷，是測試人員的工作職責。不要以為測試人員吃飽了沒事干，存心找茬。 不要輕視測試人員，別說人家技術水平差，不配搞開發(fā)只好搞測試。 測試人員的注意事項： 發(fā)現

38、缺陷時不要嘲笑開發(fā)人員，別說他的程序真臭、到處是Bug。 在開發(fā)人員壓力太大時或心情不好時不要火上澆油，發(fā)現缺陷時別大聲嚷嚷。 請留意另一種極端：如果測試人員與開發(fā)人員的關系非常好，可能會導致在測試的時候“手下留情”，這對項目也是一種傷害。 精選ppt3. 測試組織與管理測試管理的目的測試管理中的PDCA測試管理控制對象的管理測試流程控制和管理統(tǒng)計分析和決策支持軟件測試過程組織精選ppt精選ppt測試管理的目的通過對產品的整個測試流程進行控制和管理，提高企業(yè)軟件測試的管理水平；灌輸和強化企業(yè)的管理理念；確保開發(fā)產品的質量；進一步提高企業(yè)的市場競爭能力精選ppt測試管理中的PDCAP：測試計劃D

39、：測試案例及測試步驟的設計C：測試實施和錯誤跟蹤A：測試總結與報告精選ppt測試管理控制對象的管理測試管理控制對象（測試文檔）包含的內容：測試計劃測試案例各案例的具體測試步驟問題報告測試總結報告精選ppt測試管理控制對象的管理軟件測試文件描述要執(zhí)行的軟件測試及測試的結果測試文件的編寫是測試工作規(guī)范化的一個組成部分開始于需求分析階段、使用于整個生命周期中精選ppt軟件測試的過程及組織測試階段測試方法的應用測試人員的組織軟件測試文件精選ppt測試階段準備工作全面熟悉系統(tǒng)編寫測試計劃設計測試用例劃分階段精選ppt需求審查階段組長系統(tǒng)分析員軟件開發(fā)管理者軟件設計、開發(fā)人員測試人員用戶精選ppt設計評審

40、階段組長系統(tǒng)分析員軟件設計人員測試負責人精選ppt程序測試組長：負責整個測試的計劃、組織工作測試人員：運行測試并記錄測試結果精選ppt軟件測試文檔測試文檔的類型測試文檔的使用精選ppt4.測試部門的測試評估測試經理必須跟蹤、監(jiān)督和評估測試工作的實現，并在必要時進行改進。測試工作的核心力量是測試工程師。評估測試人員的有效性對測試人員的期望評估測試人員測試工作的要點評估測試組的有效性行業(yè)知識、測試技巧和經驗角色和職責評估測試組測試活動質量的幾個方面精選ppt4.1評估測試人員的有效性測試人員的期望（達到共識）遵守測試標準和測試過程保持進度（提交各種產品的時間）達到目標和完成指派的任務（為每人分配的

41、任務必須形成文檔，確定截止期限和完成目標）控制預算（購買測試工具時）精選ppt評估測試人員測試工作的要點行業(yè)專家和技術專家行業(yè)專家:是否具備應用程序的行業(yè)領域的知識技術專家:測試人員履行自動測試時,根據預定標準評估自動測試過程開發(fā)的腳本?重新運行腳本時能夠恢復基線數據庫?開發(fā)自動測試工具-代碼的可讀性和可靠性?是否了解系統(tǒng)的功能?熟悉測試工具?有經驗的測試人員與初學者是否遺漏 了缺陷?功能和非功能性測試（測試人員對各種可利用的測試技術的了解程度，以及對哪種技術能夠提高手頭測試任務的測試效率?對應用程序行為的理解程度，測試過程的深度如何？）精選ppt功能性測試評估時要考慮的問題測試過程中的步驟是

42、否完全映射為需求的步驟?是完全可追溯的嗎?測試的輸入步驟和預期輸出正確嗎?在測試過程的功能流中遺漏了重要的測試步驟嗎?設計有效的測試過程時是否經過了分析思考的過程?是否遵從了測試過程的創(chuàng)建標準?在認定測試過程有效和完整之前,由于誤解和缺乏交流導致的修改次數是多少?制作測試用例的過程中是否運用了有效的測試技術?精選ppt驗證測試過程的深度?測試過程的內容?只測試了較高層次上的功能,還是觸及到了程序的實質性功能?與需求的深度有關(系統(tǒng)應該添加A類型的記錄-添加,查詢,類型為A,添加多條?)若測試過程遺漏細節(jié),則測試工程師需要培訓測試階段（測試、測試、系統(tǒng)測試、用戶驗收測試）不同階段有不同任務。測試

43、測試(測試人員需要把測試人員的測試過程文檔化)開發(fā)生命周期的各個階段(及早介入,需求階段,發(fā)現細微的缺陷)精選ppt服從命令和關注細節(jié)遵照指示和注意細節(jié) (周例會每天)缺陷類型、缺陷率和缺陷文檔缺陷類型(技能水平測試類型測試階段應用程序的復雜度和成熟度)(復雜的、與行業(yè)領域相關的缺陷/簡單的外觀缺陷)缺陷報告：是否包含了足夠的信息可以使開發(fā)人員重現缺陷？缺陷報告標準化參考：測試人員的績效評定辦法精選ppt測試工程師的自我評價關注發(fā)現的缺陷類型 (總是發(fā)現不重要的缺陷？)測試過程足夠詳細嗎？是否覆蓋了高優(yōu)先級的缺陷所需的深度以及數據和基本功能的組合與變化？是否同時包含了對非法數據和合法數據的測試？是否聽取了來自需求人員、開發(fā)人員和其他測試人員的反饋意見？對可用的測試技術了解嗎？了解應用程序功能的實質和足夠的行業(yè)知識嗎？主要缺陷是否發(fā)現太晚了？（開始階段是否集中在低優(yōu)先級的需求上？）精選ppt所測試的部分是否缺陷太少了?測試覆蓋的內容是否足夠全面？正在執(zhí)行的測試類型是否最高效？是否遺漏了重要的步驟？應用程序是否復雜度很低？功能的實現是否不可能留下重要缺陷？檢查附在缺陷文檔上的意見，確定開發(fā)人員和其他測試人員對