測試計劃與測試管理

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

19、試用例進(jìn)行良好的管理精選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、其它；數(shù)據(jù)庫管理系統(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)平臺的被測軟件項目間的測試用例復(fù)用；精選ppt測試用例的管理屬性系統(tǒng)類型，屬性值用列表表示，包括：嵌入式、b/s、c/s、其它；編碼語言，屬性值用列表表示，包括：java、c+、c、smalltalk、dephi、其它；測試類型，屬性值用列表表示，包括：功能（包括可使用性測試）、兼容性、負(fù)載測試、強(qiáng)度測試、數(shù)據(jù)庫容量測試、安全性測試、其它;測試階段項目名稱創(chuàng)建人/創(chuàng)建時間 重要級別:狀態(tài)精選ppt測試用例體本身的屬性包括以下屬性：測試

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

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

23、、MI的TestDirector等軟件；國內(nèi)比較有名的有中科院的I-test、北航的QESuite等軟件，在這些工具中，測試用例的管理只是其中的一個子系統(tǒng)，提供的功能有限。 精選ppt7.2.3 缺陷追蹤管理缺陷文檔包含的屬性舉例缺陷優(yōu)先級和嚴(yán)重性劃分缺陷的分離和重現(xiàn)缺陷的度量及其意義精選ppt1缺陷文檔包含的屬性舉例度量項目名稱 值 說明缺陷id Y+M+D+id 例如：08090101 表示2008年9月1日記錄的第1個 缺陷狀態(tài) 1，2 1新發(fā)現(xiàn)狀態(tài)，2正在修改狀態(tài) 3，4 3待確認(rèn)狀態(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的修改人解決方案 文字描述 提出解決當(dāng)前缺陷的方案并給出修改部分代碼修改時間 Y+M+D 例如080902表示2008年9月2日進(jìn)行修改修改次數(shù) N 用自然數(shù)記錄該缺陷被反復(fù)修改的次數(shù)確認(rèn)結(jié)果 1/0 1-表示缺陷已修復(fù)，0表示該

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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