《測試管理》PPT課件.ppt

1、第16章 測試管理,羅 東 俊 ZSUJONE126.COM,1,主要內(nèi)容,16.1測試管理基礎(chǔ) 16.2測試執(zhí)行周期的開始和結(jié)束 16.3隔離測試環(huán)境和開發(fā)環(huán)境 16.4測試用例的有效管理 16.5缺陷追蹤管理 16.6測試的評測,2,16.1測試管理基礎(chǔ),16.1.1 軟件測試管理的內(nèi)容 16.1.2 軟件測試管理工具,3,16.1.1 軟件測試管理的內(nèi)容,軟件測試管理的目的是確保軟件測試技術(shù)在項目的生命周期內(nèi)得到順利實施，并產(chǎn)生預(yù)期的效果。 按照管理的對象不同，軟件測試管理大致可分為： 軟件測試團隊組織管理 軟件測試計劃管理 軟件缺陷(錯誤)跟蹤管理 軟件測試件管理,4,軟件測試團隊組織

2、管理,就是指測試團隊?wèi)?yīng)該如何組建。 通常，一個好的測試團隊首先要有好的帶頭人，這個帶頭人必須具有極為豐富的開發(fā)經(jīng)驗，對開發(fā)過程中常見的缺陷或錯誤了然于胸，此外，他還應(yīng)具有親和力和人格魅力。 其次，測試團隊還應(yīng)有具備一技之長的成員，例如對某些自動化測試工具運用嫻熟或能輕而易舉地編寫自動化測試腳本。 另外，測試團隊還應(yīng)有兼職成員，例如驗收測試實施過程中，同行評審是最常使用的一種形式，這些同行專家就屬于兼職測試團隊成員的范疇。 測試團隊里往往包括幾個開發(fā)經(jīng)驗欠缺的新成員，這部分人員可以安排去從事交付驗收或黑盒測試之類的工作。,5,軟件測試計劃管理,就是指安排好測試流程 。 這部分內(nèi)容具體涵蓋軟件測試

3、策劃、軟件測試技術(shù)剪裁、測試進度管理、成本管理等幾個部分。 測試策劃工作主要是指具體測試活動實施之前做好策劃工作，如起草測試大綱以及測試計劃； 軟件測試技術(shù)剪裁工作主要是指測試團隊?wèi)?yīng)根據(jù)軟件項目的具體實際，剪裁出所要實施的測試技術(shù)； 測試進度管理工作主要是排出各項測試的時間進度及人員安排，如有變動時應(yīng)如何做相應(yīng)調(diào)整； 測試成本管理工作主要指管理測試活動中會涉及到的資源需求。,6,軟件缺陷(錯誤)跟蹤管理,就是確保發(fā)現(xiàn)的缺陷(錯誤)已經(jīng)被開發(fā)團隊糾正或處理過并且沒有引入新的缺陷(錯誤)。 具體來講，當(dāng)測試團隊通過各種途徑發(fā)現(xiàn)了文檔或代碼中的缺陷或錯誤以后，并不是交一份測試報告就草草了事，而是在遞

4、交報告以后繼續(xù)督促開發(fā)團隊及時關(guān)閉已知缺陷或錯誤。當(dāng)然，如有必要應(yīng)對這些缺陷、錯誤做嚴重程度排序，以便開發(fā)團隊能視輕重緩急安排處理順序。當(dāng)開發(fā)團隊關(guān)閉了測試報告中的缺陷(錯誤)以后，測試團隊還需驗證開發(fā)團隊在關(guān)閉過程中有沒有引入新的錯誤。通常，這個過程稱為回歸測試。回歸測試如發(fā)現(xiàn)問題，繼續(xù)報告開發(fā)團隊，按上述流程循環(huán)，直至回歸測試最終通過。,7,軟件測試件管理,是指努力建設(shè)好測試團隊的軟件測試件庫并對測試團隊成員進行技能培訓(xùn)以幫助他們能使用好這個軟件測試件庫。 測試件(Testware)是指測試工作形成的產(chǎn)品，包括測試團隊在長期實踐過程中逐步積累起來的經(jīng)驗教訓(xùn)、測試技巧、測試工具、規(guī)格文檔以及

5、一些經(jīng)過少量修改就能推廣至通用的測試腳本程序。,8,16.1.2 軟件測試管理工具,采用高水平的軟件測試管理工具則能保證以一個較小規(guī)模的測試隊伍完成復(fù)雜的大量的測試工作，以此來做到對成本和時間效率的有效管理。 除此之外，通過該軟件，用戶也可以及時地掌握軟件的測試和完成情況，并對整個過程進行監(jiān)督和管理，這對用戶控制成本和做相應(yīng)的安排也是有好處的。 目前，市場上主流的企業(yè)級測試管理工具主要有Mercury TestDirector和IBM RationalTest Manager,9,TestDirector的主要功能,用戶權(quán)限管理 TestDirector設(shè)置有六個用戶組，分別為TDAdmin、

6、QATester、ProjectManager、Developer、Viewer、Customer 集中式項目信息管理 后臺采用集中式的數(shù)據(jù)庫(Oracle、SQLServer、Access等) 分布式訪問 定義測試工作流程 需求管理、規(guī)劃測試、安排測試進度并運行測試、缺陷管理、圖示和報告,10,開源軟件測試管理工具,第一個工具為TestLink(http：/ 第二個工具為Bugzilla Test Runner(http：/,11,16.2測試執(zhí)行周期的開始和結(jié)束,測試人員應(yīng)該為測試執(zhí)行周期的開始和結(jié)束定義入口標(biāo)準(zhǔn)和出口標(biāo)準(zhǔn)。 入口標(biāo)準(zhǔn)描述了測試小組何時可以開始測試一個特定的版本； 出口標(biāo)準(zhǔn)

7、描述了軟件完成充分測試的時間。 由于測試資源是有限的，測試預(yù)算和測試人員的數(shù)目有限，測試時間有限，軟件發(fā)布時間緊張，因此測試工作的范圍一定要有限制。,12,系統(tǒng)測試執(zhí)行入口標(biāo)準(zhǔn),所有的單元測試和集成測試已經(jīng)成功完成。 軟件的生成(編譯)過程沒有任何錯誤。 軟件版本通過了煙霧測試(最基本的測試，關(guān)鍵功能的測試)。 配套文檔已經(jīng)完成，文檔的內(nèi)容涉及軟件版本的新功能和修改的內(nèi)容。 缺陷已經(jīng)修正并且準(zhǔn)備重新測試。 源代碼已經(jīng)存儲在版本控制系統(tǒng)中,13,測試出口標(biāo)準(zhǔn),已經(jīng)執(zhí)行了用來確定系統(tǒng)滿足指定的功能性和非功能性需求的測試過程。 在測試結(jié)果中記錄的所有1級、2級和3級的軟件問題都已經(jīng)解決。 在測試結(jié)果

8、中記錄的所有1級、2級的軟件問題都已經(jīng)解決。 在測試結(jié)果中記錄的所有1級、2級的軟件問題都已經(jīng)解決，同時90的3級問題已經(jīng)解決。 軟件發(fā)布時可能存在已知的低優(yōu)先級的缺陷(當(dāng)然有若干未知缺陷)。 一些度量也可以作為出口標(biāo)準(zhǔn)的一部分 缺陷修改的質(zhì)量 、缺陷趨勢分析,14,16.3隔離測試環(huán)境和開發(fā)環(huán)境,當(dāng)測試組執(zhí)行測試、實施測試策略時，測試環(huán)境必須和開發(fā)環(huán)境分離開。 如果沒有獨立的測試環(huán)境，那么測試工作就會遇到下面的一些問題： 環(huán)境的變化 版本管理 操作環(huán)境的變化,15,16.4測試用例的有效管理,16,測試用例分析例子,17,16.5缺陷追蹤管理,16.5.1軟件缺陷的生命周期和處理流程 16.

9、5.2軟件缺陷的嚴重性和優(yōu)先級 16.5.3軟件缺陷的報告、分離和再現(xiàn) 16.5.4軟件缺陷的度量 16.5.5缺陷管理系統(tǒng),18,16.5.1軟件缺陷的生命周期和處理流程,簡單的軟件缺陷生命周期,19,復(fù)雜的軟件缺陷生命周期例子,20,通用的軟件缺陷生命周期,21,缺陷狀態(tài),22,軟件缺陷分類,23,普通的缺陷處理流程,缺陷報告最初生成的狀態(tài)為“新”； 賦予各個小組打開不同問題的能力（錯誤請求、變更請求、增強請求） 選擇缺陷優(yōu)先級 評估缺陷，為缺陷分配狀態(tài) 若狀態(tài)為“打開”，則把缺陷分配給負責(zé)的人，變?yōu)椤伴_發(fā)”狀態(tài) 開始改正缺陷了，變?yōu)椤罢陂_發(fā)”狀態(tài) 缺陷改正完了，改為“修改完畢”狀態(tài)；或

10、者“工作正?！?、“缺陷不能重現(xiàn)” 若創(chuàng)建了新版本，所有改正的缺陷改為“返測”狀態(tài) 測試工程師返測這些改動，設(shè)置狀態(tài)為“關(guān)閉-改正”、“返測失敗”,24,普通的缺陷處理流程,25,16.5.2軟件缺陷的嚴重性和優(yōu)先級,嚴重性(Severity)顧名思義就是軟件缺陷對軟件質(zhì)量的破壞程度，即此軟件缺陷的存在將對軟件的功能和性能產(chǎn)生怎樣的影響。 優(yōu)先級(Priority)是表示處理和修正軟件缺陷的先后順序的指標(biāo)，即哪些缺陷需要優(yōu)先修正，哪些缺陷可以稍后修正。 處理嚴重性和優(yōu)先級，既是一種經(jīng)驗技術(shù)，也是保證軟件質(zhì)量的重要環(huán)節(jié),26,嚴重性 vs. 優(yōu)先級,一般來說，嚴重性程度高的軟件缺陷具有較高的優(yōu)先級

11、。嚴重性高說明缺陷對軟件造成的質(zhì)量危害性大，需要優(yōu)先處理，而嚴重性低的缺陷可能只是軟件不太盡善盡美，可以稍后處理。 但是，嚴重性和優(yōu)先級并不總是一一對應(yīng)。因為修正軟件缺陷不是一件純技術(shù)問題，有時需要綜合考慮市場發(fā)布和質(zhì)量風(fēng)險等問題。,27,例如,如果某個嚴重的軟件缺陷只在非常極端的條件下產(chǎn)生，則沒有必要馬上解決。 另外，如果修正一個軟件缺陷，需要重新修改軟件的整體架構(gòu)，可能會產(chǎn)生更多潛在的缺陷，而且軟件由于市場的壓力必須盡快發(fā)布，此時即使缺陷的嚴重性很高，是否需要修正，需要全盤考慮。 另一方面，如果軟件缺陷的嚴重性很低，例如，界面單詞拼寫錯誤，但是如果是軟件名稱或公司名稱的拼寫錯誤，則必須盡快

12、修正，因為這關(guān)系到軟件和公司的市場形象。,28,嚴重性的常用劃分方法,29,優(yōu)先級的常用劃分方法,30,例如,極少發(fā)生的數(shù)據(jù)毀壞缺陷應(yīng)該劃分為嚴重性1，優(yōu)先級3； 導(dǎo)致用戶電話求助的安裝指示錯別字應(yīng)該劃分為嚴重性3，優(yōu)先級2； 只要一啟動就崩潰的測試軟件版本屬于嚴重性1，優(yōu)先級1； 如果認為某按鈕向頁面下方再移動一點，則屬于嚴重性4，優(yōu)先級4。 軟件缺陷的優(yōu)先級在項目期間也可能會發(fā)生變化。 原本標(biāo)記為優(yōu)先級2的軟件缺陷隨著時間即將用盡，以及軟件發(fā)布日期臨近，可能變?yōu)閮?yōu)先級4。,31,16.5.3軟件缺陷的報告、分離和再現(xiàn),報告軟件缺陷要以明顯、通用和再現(xiàn)的形式進行描述。 有效的軟件缺陷描述要求

13、 ： 簡單與短?。褐唤忉屖聦嵑脱菔尽⒚枋鲕浖毕荼匦璧募毠?jié)。 單一：每一個報告只針對一個軟件缺陷 明顯和通用：用使用者容易看懂的、展示通用性的簡單易行步驟描述的軟件缺陷 再現(xiàn)：軟件缺陷報告必須報告記錄按照預(yù)定步驟可以使軟件達到缺陷再次出現(xiàn)的相同狀況 使用IT業(yè)界慣用的表達術(shù)語和表達方法 補充完善軟件缺陷報告,32,缺陷報告基本組成,優(yōu)秀的錯誤描述主要由三個基本部分組成：摘要、重建步驟和隔離。 “摘要”又叫主題或標(biāo)題，是關(guān)于錯誤的一兩句話的描述，強調(diào)它對顧客或系統(tǒng)用戶的影響。 “重建步驟”提供了如何重復(fù)這個失敗的精確描述。 “隔離”是指測試人員收集的結(jié)果和信息，以確認錯誤確實是一個問題，并標(biāo)識那

14、些影響到錯誤表現(xiàn)的要素。,33,一份優(yōu)秀的缺陷報告,34,16.5.4軟件缺陷的度量,對缺陷數(shù)據(jù)進行分析和度量，使我們在改正缺陷的同時，將缺陷管理過程推向更高的階段量化管理階段 軟件開發(fā)只有引入了度量機制和定量化的管理，才能稱為真正意義上的“工程”，這一準(zhǔn)則清楚地體現(xiàn)在CMM中： CMM 4級（已管理級）引入了“定量軟件過程” CMM 5級（優(yōu)化級）則完全建立在定量管理的基礎(chǔ)之上，并明確提出了“缺陷預(yù)防”。,35,軟件缺陷度量的過程,軟件缺陷度量的過程可以分為四大部分： 計劃度量 執(zhí)行度量 分析度量結(jié)果 評價度量,36,計劃度量,嚴格地指定要度量什么，如何對數(shù)據(jù)進行合并產(chǎn)生滿足信息需要的結(jié)果。

15、 如： 在回歸測試中，從以前運轉(zhuǎn)正常的功能中發(fā)現(xiàn)缺陷的比例（修正工作破壞以前運轉(zhuǎn)正常功能的頻率） 缺陷修正失敗的頻率 新缺陷的發(fā)現(xiàn)率走勢,37,獲取度量數(shù)據(jù),缺陷文檔中可能包括的屬性有：缺陷ID、缺陷狀態(tài)、測試人員ID、提交時間、缺陷所屬項目ID、缺陷所屬模塊ID、開發(fā)人員ID、缺陷類型、嚴重級別、優(yōu)先級、修改人ID、解決方案、修改時間、修改次數(shù)、確認結(jié)果等。,38,幾個核心度量,缺陷持續(xù)時間 缺陷糾正到返測的時間 缺陷趨勢分析 缺陷修改的質(zhì)量 缺陷密度 測試人員工作效率,39,缺陷持續(xù)時間,缺陷持續(xù)時間是指從發(fā)現(xiàn)缺陷到改正缺陷的時間跨度，同時必須考慮缺陷修正工作的復(fù)雜度。 該度量用于驗證缺陷

16、是否被及時地解決，利用缺陷持續(xù)時間的數(shù)據(jù)，測試組可以分析開發(fā)組對改錯工作的反應(yīng)是否影響了測試工作的進度 一個缺陷的持續(xù)時間越長，糾正缺陷的難度可能就越大，因為可能在錯誤代碼的基礎(chǔ)上又加入了新的代碼,40,缺陷糾正到返測的時間,缺陷糾正到返測時間是指缺陷被修正并且在新版本中發(fā)布的時間到缺陷被返測的時間跨度。 該度量提供了一種衡量測試組的返測缺陷速度的方法。,41,缺陷趨勢分析,缺陷趨勢分析是指在測試生命周期內(nèi)，隨著測試工作的進行，發(fā)現(xiàn)缺陷的數(shù)量的變化趨勢。 缺陷趨勢分析有助于確定所發(fā)現(xiàn)的缺陷的變化趨勢，對于軟件產(chǎn)品發(fā)布而言，缺陷趨勢分析圖是輔助決策的重要依據(jù)。,42,缺陷發(fā)生率,43,缺陷趨勢圖

17、,44,缺陷修改的質(zhì)量,缺陷修改的質(zhì)量是指修改后剩余的缺陷數(shù)量，即重現(xiàn)率。 該度量測量的是缺陷修正工作給以前工作正常的功能帶來的新缺陷，或者破壞以前工作正常的功能的百分比。 例如，修復(fù)了100個缺陷，后來發(fā)現(xiàn)其中20個修復(fù)引入了新的缺陷，則缺陷糾正率為D=(100 - 20)/100100=80。,45,缺陷密度,缺陷密度(Defect Density)是指一段時間里發(fā)現(xiàn)的缺陷數(shù)與軟件大小的比例。 軟件的大小可以采用功能點度量，也可以用源代碼行數(shù)衡量。用數(shù)學(xué)公式表示為：DD=defects/KLOC或DD=defects/KFP KLOC表示每千行源代碼，KFP表示每千個功能點。 產(chǎn)品的缺陷密

18、度直接影響著客戶的滿意程度。,46,各模塊中每千行代碼的缺陷密度,47,缺陷密度度量的缺點,缺陷密度這種度量方法是極不完善的，度量本身是不充分的。 這里邊存在的主要問題是：所有的缺陷并不都是均等構(gòu)造的。 各個軟件缺陷的惡劣程度，及其對產(chǎn)品和用戶的影響的嚴重程度，以及修復(fù)缺陷的重要程度有很大差別， 因此，有必要對缺陷進行“分級、加權(quán)”處理，給出軟件缺陷在各嚴重性級別或優(yōu)先級上的分布作為補充度量，,48,缺陷在各優(yōu)先級上的分布,49,缺陷嚴重程度分布,50,缺陷產(chǎn)生原因分布圖,它是缺陷分析中最為重要的一張圖表，因為它可以直接反映出各軟件工程活動的質(zhì)量，為軟件過程的改進提供直接的參考數(shù)據(jù)。 一般來說

19、，缺陷產(chǎn)生的根本原因劃分的越細致，分析的結(jié)果就越精確。 例如，當(dāng)發(fā)現(xiàn)需求中出現(xiàn)的缺陷比較多的時候，在未來的項目中我們可以通過需求評審、需求變更控制來減少該種缺陷的數(shù)量，以達到軟件質(zhì)量保證的目的。 同樣如果我們發(fā)現(xiàn)軟件設(shè)計過程中產(chǎn)生的問題比較多，那么就可以通過加強軟件設(shè)計階段中的審查活動來保證設(shè)計的質(zhì)量。,51,幾個綜合指標(biāo),測試人員工作效率 缺陷探測效率 發(fā)布前的缺陷消除率,52,測試人員工作效率,測試人員工作效率：是指測試人員在一定時期內(nèi)測試出不同類型缺陷的能力，它等于測試人員測試出的不同缺陷類型數(shù)量與對應(yīng)權(quán)值的乘積之和，再除以本次測試的周期，從而衡量測試人員的熟練程度。,53,缺陷探測效率

20、,缺陷探測效率(Defect Detection Efficien，DDE)：是指軟件生命周期的各個階段由測試人員發(fā)現(xiàn)缺陷的效率。它可以這樣計算：在各個生命周期階段發(fā)現(xiàn)某個階段產(chǎn)生的缺陷數(shù)與在該階段中產(chǎn)生的缺陷總個數(shù)的比例。 如果DDE為100，則表明該階段發(fā)現(xiàn)了所有在這個階段中產(chǎn)生的缺陷，沒有缺陷傳播到下一個階段。 如果DDE為30，則表明該階段發(fā)現(xiàn)了30在這個階段中產(chǎn)生的缺陷，將有70在這個階段中產(chǎn)生的缺陷傳播到下一個階段。 DDE說明了過程的效率。,54,發(fā)布前的缺陷消除率,發(fā)布前的缺陷消除率(Pre Delivery Defect Removal Efficiency)：是指軟件發(fā)布前

21、的各個階段發(fā)現(xiàn)的缺陷總數(shù)占軟件缺陷總數(shù)的比例。 如，發(fā)布前發(fā)現(xiàn)了300個缺陷，發(fā)布后使用半年又發(fā)現(xiàn)了100個缺陷，則發(fā)布前的缺陷消除率PDRE=300/(300+100)100=75。,55,16.5.5缺陷管理系統(tǒng),國內(nèi)外已出現(xiàn)了一批質(zhì)量較好的缺陷管理工具，其中比較有代表性的有： 開源軟件Bugzilla、jira Compuware公司的TrackRecord 、 Rational公司的ClearQuest、 北京航空航天大學(xué)的QAMonitor、 上海微創(chuàng)軟件有限公司的BMS等。 這些工具各有特色，在功能的全面性上也各不相同，但都是基于“找出缺陷、修改缺陷、進行回歸測試”這種面向流程處理的傳統(tǒng)模式，實現(xiàn)了缺陷管理的基本流程，并在此基礎(chǔ)上提供了一些查詢和統(tǒng)計功能； 其共同的缺點是沒有充分利用軟件開發(fā)過程中產(chǎn)生的缺陷數(shù)據(jù)，不能以一種主動的、精確量化的方式對軟件缺陷進行預(yù)防并提供軟件項目管理者所需的有關(guān)產(chǎn)品和過程的度量信息。,56,16.6測試的評測,16.6.1覆蓋評測 16.6.2質(zhì)量評測,5