缺陷、QC管理流程培訓(xùn)課件

缺陷管理培訓(xùn)前言-緒論引例：

1、1985到1987年，Therac-25輻射治療事故；

2、1996年6月4日，阿麗亞娜5型運(yùn)載火箭自毀事故；

3、2009年2月份Google的Gmail故障；總結(jié)：

1、

2、

……前言-緒論我們能做些什么呢？1、總發(fā)現(xiàn)缺陷早修復(fù)缺陷；2、不放過任何缺陷；3、管理咱們的工作；……四、QC操作介紹

1、登錄和賬戶管理

2、缺陷新建與提交

3、缺陷篩選與查

4、QC其他實(shí)用功能

5、常見問題五、如何提交高質(zhì)量缺陷

1、缺陷成熟度模型

2、高質(zhì)量缺陷定義

3、提交高質(zhì)量缺陷六、流程圖介紹

1、缺陷生命周期圖

2、提交缺陷流程

3、驗(yàn)證缺陷流程

4、狀態(tài)拓?fù)鋱D七、缺陷管理中的溝通技巧八、問題目錄缺點(diǎn)(defect)

故障(fault)問題(problem)

錯(cuò)誤(error)缺陷(bug)

異常(anomaly)這些詞的含義幾近相同。故障、失敗和缺點(diǎn)都指確實(shí)嚴(yán)重的情況，甚至是危險(xiǎn)的情況；異常、事件和偏差不是那么尖銳，主要指未按預(yù)料的運(yùn)行，而不是全部的失敗。問題、錯(cuò)誤和缺陷也許是最常用的術(shù)語(yǔ)。軟件缺陷常用術(shù)語(yǔ)軟件缺陷（Defect），常常又被叫做Bug。所謂軟件缺陷，即為計(jì)算機(jī)軟件或程序中存在的某種破壞正常運(yùn)行能力的問題、錯(cuò)誤，或者隱藏的功能缺陷。缺陷的存在會(huì)導(dǎo)致軟件產(chǎn)品在某種程度上不能滿足用戶的需要。IEEE729-1983對(duì)缺陷有一個(gè)標(biāo)準(zhǔn)的定義：從產(chǎn)品內(nèi)部看，缺陷是軟件產(chǎn)品開發(fā)或維護(hù)過程中存在的錯(cuò)誤、毛病等各種問題；從產(chǎn)品外部看，缺陷是系統(tǒng)所需要實(shí)現(xiàn)的某種功能的失效或違背。官方定義：軟件未實(shí)現(xiàn)產(chǎn)品說明書要求的功能。 軟件出現(xiàn)了產(chǎn)品說明書指明不會(huì)出現(xiàn)的錯(cuò)誤。 軟件實(shí)現(xiàn)了產(chǎn)品說明書未提到的功能。 軟件未實(shí)現(xiàn)產(chǎn)品說明書雖未明確提及但應(yīng)該實(shí)現(xiàn)的目標(biāo)。 軟件難以理解、不易使用、運(yùn)行緩慢或者——從測(cè)試員的角度看—— 最終用戶會(huì)認(rèn)為不好軟件缺陷定義2、軟件缺陷的第二大來源是設(shè)計(jì)；3、代碼錯(cuò)誤可以歸咎于軟件的復(fù)雜性、文檔資料的不足、進(jìn)度壓力或者普通的低級(jí)錯(cuò)誤，與(1)、(2)有關(guān)；4、其他原因，如誤解，重復(fù)錯(cuò)誤，測(cè)試錯(cuò)誤等只占極小的比例；軟件缺陷如何產(chǎn)生

軟件缺陷管理就是在開發(fā)中對(duì)發(fā)現(xiàn)的缺陷進(jìn)行跟蹤并確保每個(gè)被發(fā)現(xiàn)的缺陷被關(guān)閉。從某種意義上說，軟件項(xiàng)目管理過程可以看作是軟件產(chǎn)品的缺陷管理過程。前言-缺陷管理概論談戀愛？缺陷管理？<===>1、到底什么是缺陷管理？2、怎么實(shí)現(xiàn)缺陷管理？3、管理過程中應(yīng)該注意什么？問題導(dǎo)入

缺陷管理/軟件缺陷管理（DefectManagement）是在軟件生命周期中獲取、管理、溝通任何變更請(qǐng)求的過程（從變更的建議到變更的解決）?？梢源_保你的問題如需求或者缺陷被跟蹤管理而不丟失。

缺陷管理詳解-定義缺陷管理的意義：

1、保證信息的一致性

2、保證缺陷得到有效的跟蹤、解決

3、缺陷分析和度量缺陷管理詳解-意義軟件缺陷管理一般包括兩個(gè)方面：1、缺陷信息的收集與跟蹤；完整的軟件缺陷信息是輔助缺陷修復(fù)、缺陷信息處理、分析和利用的前提和基礎(chǔ)，也是對(duì)缺陷進(jìn)行跟蹤必不可少的步驟。因?yàn)椋ǔＲ粋€(gè)項(xiàng)目的缺陷整體跟蹤，就是缺陷的實(shí)時(shí)狀態(tài)報(bào)告。也就是說，缺陷的跟蹤是了解缺陷所在其生命周期的狀態(tài)。通過了解缺陷的實(shí)時(shí)狀態(tài)，對(duì)測(cè)試過程、項(xiàng)目進(jìn)展的控制和管理都有很大幫助，可以督促開發(fā)人員盡快修正缺陷，調(diào)整測(cè)試或開發(fā)計(jì)劃。缺陷管理詳解-組成要素2、缺陷信息的統(tǒng)計(jì)與分析；

通過分析缺陷數(shù)據(jù)的趨勢(shì)，評(píng)估軟件質(zhì)量和測(cè)試過程的效率。在評(píng)估缺陷時(shí)應(yīng)遵照缺陷分析策略中指定的分析標(biāo)準(zhǔn)，最常用的缺陷分析方法有四種：

★缺陷分布報(bào)告；

★缺陷趨勢(shì)報(bào)告； ★缺陷年齡報(bào)告；

★測(cè)試結(jié)果進(jìn)度報(bào)告；缺陷管理詳解-組成要素

軟件缺陷管理實(shí)際是軟件測(cè)試流程管理的一個(gè)子過程,其應(yīng)用模型一般主要由四個(gè)部分組成：缺陷收集、缺陷跟蹤、缺陷度量、項(xiàng)目評(píng)估。

如下圖：缺陷管理詳解-缺陷管理模型缺陷收集缺陷度量缺陷跟蹤項(xiàng)目評(píng)估

軟件缺陷管理流程原則是簡(jiǎn)介高效，避免過多的處理環(huán)節(jié)，同時(shí)要形成一種不同角色之間互相監(jiān)督、互相制衡的結(jié)構(gòu)。軟件缺陷管理過程設(shè)計(jì)各種任務(wù)和角色，只有清晰的規(guī)定了這些任務(wù)和角色的基礎(chǔ)上才能對(duì)軟件缺陷數(shù)據(jù)進(jìn)行合理的定義。缺陷管理詳解-缺陷管理與軟件角色關(guān)系圖缺陷管理的核心價(jià)值：缺陷分析與預(yù)防

缺陷預(yù)防的著眼點(diǎn)在于缺陷的共性原因(CommonCause)。通過尋找、分析和處理缺陷的共性原因，實(shí)現(xiàn)缺陷預(yù)防。BUG預(yù)防并不是一個(gè)不切實(shí)際的目標(biāo)，但是不能期望它在一夜之間發(fā)生。我們?cè)陂_發(fā)過程中應(yīng)該積極為開發(fā)小組提供缺陷分析，使BUG逐漸改善。因此，缺陷管理的最終目標(biāo)是預(yù)防BUG，不斷提高整個(gè)開發(fā)團(tuán)隊(duì)的技能和實(shí)踐經(jīng)驗(yàn)，而不只是修正它們。缺陷管理詳解-核心價(jià)值與實(shí)現(xiàn)缺陷管理的核心價(jià)值實(shí)現(xiàn)：

BUG預(yù)防策略非常簡(jiǎn)單和容易實(shí)現(xiàn)，策略是發(fā)現(xiàn)BUG，找出BUG的根源，然后尋找一個(gè)方法來預(yù)防類似的BUG在將來出現(xiàn)。這策略并不需要昂貴的花費(fèi)，但是卻可帶來極大的額外價(jià)值。1、BUG記錄；

BUG分析的第一步是記錄BUG，值得注意的是記錄BUG不應(yīng)該滿足于記錄BUG的表面癥狀。2、利用BUG分析了解開發(fā)質(zhì)量趨勢(shì)；對(duì)于測(cè)試出來的BUG進(jìn)行缺陷分類，找出那些關(guān)鍵的缺陷類型，進(jìn)一步分析其產(chǎn)生的根源，從而針對(duì)性的制定改進(jìn)措施。3、發(fā)布BUG分析經(jīng)驗(yàn),提高團(tuán)隊(duì)成員能力；分析得出來的BUG實(shí)踐經(jīng)驗(yàn)應(yīng)該被記錄并發(fā)布，這樣其他的開發(fā)人員就可以通過學(xué)習(xí)這些經(jīng)驗(yàn)避免類似的錯(cuò)誤。缺陷管理詳解-核心價(jià)值與實(shí)現(xiàn)3、使用缺陷管理工具:BUG管理庫(kù)為了跟蹤和控制測(cè)試質(zhì)量，便于管理測(cè)試發(fā)現(xiàn)的BUG，需要為項(xiàng)目配置一個(gè)專用的缺陷跟蹤數(shù)據(jù)庫(kù)，以便報(bào)告、查詢、分類、跟蹤、處理和驗(yàn)證缺陷。4、把管理制度和配置策略相結(jié)合

有了先進(jìn)的缺陷管理工具，還需要有相應(yīng)的管理制度與之相配套，否則BUG管理就只是一個(gè)擺設(shè)。目前BUG管理制度方面主要的問題是不重視測(cè)試，認(rèn)為測(cè)試人員無關(guān)大局，隨便測(cè)測(cè)就行了，再或者就是雖然認(rèn)識(shí)到測(cè)試的重要性，但卻走向了極端，制定了極其嚴(yán)格的規(guī)章制度。缺陷管理詳解-如何高效地進(jìn)行缺陷管理1、ClearQuest(Business)

Rational一向以功能強(qiáng)大產(chǎn)品類型全面而著稱。RationalClearQuest是基于團(tuán)隊(duì)的缺陷和變更跟蹤解決方案，它包含在RationalSuite中。RationalSuite是針對(duì)分析人員、開發(fā)人員和測(cè)試人員進(jìn)行了優(yōu)化的一套軟件開發(fā)全面解決方案。作為它主要組件之一的RationalClearQuest是一套高度靈活的缺陷和變更跟蹤系統(tǒng)，適用于在任何平臺(tái)上，任何類型的項(xiàng)目中，捕獲各種類型的變更。缺陷管理工具-常用工具介紹QC（QualityCenter）

QC的前身就是大名鼎鼎的TD,改進(jìn)后現(xiàn)在可以叫QualityCenter.它是MercuryInteractive公司（現(xiàn)在軟件版權(quán)屬于惠普公司）推出的一個(gè)基于Web（偽）且支持測(cè)試管理的所有必要方面的應(yīng)用程序。該軟件提供統(tǒng)一、可重復(fù)的流程，用于收集需求、計(jì)劃和安排測(cè)試、分析結(jié)果并管理缺陷和問題。組織可使用該軟件在較大的應(yīng)用程序生命周期中實(shí)現(xiàn)特定質(zhì)量流程和過程的數(shù)字化。該軟件還支持在IT團(tuán)隊(duì)間進(jìn)行高水平溝通和協(xié)調(diào)。缺陷管理工具-QC介紹缺陷管理工具-QC介紹qc管理員qc管理員開發(fā)人員測(cè)試人員測(cè)試經(jīng)理缺陷管理工具-QC介紹1.QC訪問地址

2.QC登陸

用戶名：使用者中文姓名 密碼：管理員設(shè)置初始密碼，用戶也可以自行設(shè)置QC操作介紹-登錄和賬戶管理登陸成功頁(yè)面密碼修改密碼修改1.缺陷新建描述設(shè)計(jì)新缺陷相關(guān)信息，紅色字段為必填字段2.缺陷提交（操作后續(xù)提示圖）QC操作介紹-缺陷新建與提交缺陷新建與提交缺陷新建與提交添加附件QC操作介紹-缺陷篩選與查看QC操作介紹-缺陷篩選與查看1.收藏夾功能設(shè)置完篩選條件后可以將把本次搜索的條件保存在收藏夾，以便日后快速搜索2.缺陷分析使用QC提供的分析圖圖向?qū)?，?shí)現(xiàn)簡(jiǎn)要的缺陷分析。QC操作介紹-其他實(shí)用功能收藏夾圖向?qū)毕莘治鰣D1、用戶密碼遺忘，請(qǐng)聯(lián)系管理員；2、缺陷被鎖定，見下圖時(shí)，聯(lián)系管理員；3、QC標(biāo)配是IE6，其他瀏覽器需要另行設(shè)置；QC操作介紹-常見問題 Burnstein博士提出了測(cè)試成熟度模型（TMM），依據(jù)CMM的框架提出測(cè)試的5個(gè)不同級(jí)別，關(guān)注于測(cè)試的成熟度模型。它描述了測(cè)試過程，是項(xiàng)目測(cè)試部分得到良好計(jì)劃和控制的基礎(chǔ)。

TMM

測(cè)試成熟度分解為

5

級(jí)別，關(guān)注于

5

個(gè)成熟度級(jí)別遞增：

Phase

0

：測(cè)試和調(diào)試沒有區(qū)別，初了支持調(diào)試外，測(cè)試沒有其他 目的；

Phase

1

：測(cè)試的目的是為了表明軟件能夠工作； Phase

2

：測(cè)試的目的是為了表明軟件不能夠能夠正常工作；

Phase

3

：測(cè)試的目的不是要證明什么，而是為了把軟件不能正常 工作的預(yù)知風(fēng)險(xiǎn)降低到能夠接受的程度；

Phase

4

：

測(cè)試不是行為，而是一種自覺的約束 (mental

discipline)，不用太多的測(cè)試投入產(chǎn)生低風(fēng)險(xiǎn)的軟 件上的；如何提交高質(zhì)量缺陷-缺陷成熟度模型

問題：程序員是否經(jīng)常讓你在Bug單上再提供一些更多的信息？當(dāng)Bug單提交后，你是否經(jīng)常會(huì)再花很多時(shí)間來研究如何重現(xiàn)這個(gè)Bug？你是否經(jīng)常聽到開發(fā)人員說Bug在開發(fā)環(huán)境下無法重現(xiàn)？

原因：

BUG質(zhì)量不高！

那么，什么叫做高質(zhì)量缺陷呢？通俗的說，高質(zhì)量缺陷就是容易理解的有實(shí)際價(jià)值的缺陷。其中容易理解指開發(fā)人員或項(xiàng)目其他人員通過閱讀缺陷描述（或?yàn)g覽附件）就沒理解該缺陷的具體內(nèi)容，而不需要測(cè)試人員當(dāng)面重現(xiàn)才能理解；有實(shí)際價(jià)值指的是滿足軟件缺陷定義，對(duì)項(xiàng)目質(zhì)量有改進(jìn)。類似無描述缺陷、重復(fù)缺陷（同一原因不同現(xiàn)象的缺陷）等都是廢缺陷。如何提交高質(zhì)量缺陷-高質(zhì)量缺陷定義首先，要提高缺陷質(zhì)量，就必須首先要明白提交缺陷的目的是什么：

當(dāng)我們發(fā)現(xiàn)一個(gè)缺陷時(shí)，我們需要把它告訴給開發(fā)人員。缺陷報(bào)告（Bugreport）就是這種溝通的媒介物。缺陷報(bào)告（Bugreport）的主要目的是讓開發(fā)人員親眼看到這個(gè)錯(cuò)誤。如果你不能和他一起以在他面前制造出那個(gè)失敗，那么就需要給他們足夠多的指引以便他們能夠自己制造出那個(gè)失敗。缺陷報(bào)告（Bugreport）就是解釋在期望結(jié)果和實(shí)際結(jié)果之間的差距并且詳細(xì)的說明如何重現(xiàn)那個(gè)場(chǎng)景。如何提交高質(zhì)量缺陷-提交高質(zhì)量缺陷如何在具體工作中提交高質(zhì)量缺陷？以下有些參考做法供各位學(xué)習(xí)：

1、摘要（概述）

Bug單的“摘要”部分是一個(gè)Bug單帶給讀者的最初印象，它在瀏覽大量Bug時(shí)起著非常重要的作用，每個(gè)Bug單都應(yīng)該有一個(gè)能夠突出重點(diǎn)的“摘要”，就好像做廣告一樣。好的摘要應(yīng)該控制在50~60個(gè)字符以內(nèi)（一個(gè)漢字算兩個(gè)字符），而且不要夾雜任何主觀色彩的文字。2、措辭 ★要據(jù)實(shí)反應(yīng)情況，不要夸大或縮小Bug的影響。 ★有時(shí)候會(huì)發(fā)現(xiàn)一些令人不可思議的低級(jí)Bug，但還是要盡量使用 較為委婉的詞語(yǔ)來表述，免得傷害開發(fā)人員的自尊心。 ★要考慮到目標(biāo)讀者，他們可能是開發(fā)人員、測(cè)試人員、管理人 員或者其他人，甚至是客戶，所以要讓目標(biāo)讀者都能看得懂Bug描 述。如何提交高質(zhì)量缺陷-提交高質(zhì)量缺陷3、描述

★盡量使用業(yè)界慣用的表達(dá)術(shù)語(yǔ)和表達(dá)方法。

★每條缺陷報(bào)告只包括一個(gè)缺陷。

★描述(Description)，簡(jiǎn)潔、準(zhǔn)確，完整，揭示缺陷實(shí)質(zhì)，記 錄缺陷或缺陷出現(xiàn)的位置描述要準(zhǔn)確反映缺陷的本質(zhì)內(nèi)容，簡(jiǎn)短 了。

★短行之間使用自動(dòng)數(shù)字序號(hào)，使用相同的字體、字號(hào)、行間距 短行之間使用自動(dòng)數(shù)字序號(hào)，使用相同的字體、字號(hào)、行間距， 可以保證各條記錄格式一致，做到規(guī)范專業(yè)。

★每一個(gè)步驟盡量只記錄一個(gè)操作保證簡(jiǎn)潔、條理井然，容易重 復(fù)操作步驟。

★確認(rèn)步驟完整，準(zhǔn)確，簡(jiǎn)短保證快速準(zhǔn)確的重復(fù)缺陷，“完整” 即沒有缺漏，“準(zhǔn)確”即步驟正確，“簡(jiǎn)短”即沒有多余的步驟。

★檢查拼寫和語(yǔ)法缺陷在提交每條缺陷或缺陷之前，檢查拼寫和 語(yǔ)法，確保內(nèi)容正確，正確的描述缺陷。

★盡量使用短語(yǔ)和短句，避免復(fù)雜句型句式軟件缺陷管理數(shù)據(jù) 庫(kù)的目的是便于定位缺陷，因此，要求客觀的描述操作步驟，不 需要修飾性的詞匯和復(fù)雜的句型，增強(qiáng)可讀性。如何提交高質(zhì)量缺陷-提交高質(zhì)量缺陷4、重現(xiàn)的步驟具體要求

★

每一步以及所有步驟組合起來應(yīng)該是符合邏輯的。

★清晰地列出所需的前置條件。

★描述一般性的步驟，例如，某一步驟需要用戶新建一個(gè)文件并 給它命名，那就不要寫“新建一個(gè)名為Mike’sFile的文件”，而最好 寫成“新建一個(gè)測(cè) 試文件TestFile”。

★步驟應(yīng)盡量詳細(xì)，例如，我們要描述通過MSWORD保存一個(gè) 文檔，那么有兩種方式，一是說得細(xì)點(diǎn)兒，即“從[文件]菜單里單擊 [保存]，……”，另一種就是說得簡(jiǎn)單點(diǎn)，即“保存文檔”，但請(qǐng)記 住，并非所有人都知道如何從MSWORD保存文檔，或者說所有人 都會(huì)使用同樣的方式保存文檔，所以描述的時(shí)候最好還是采用第一 種方式。

★寫完之后自己用新的測(cè)試數(shù)據(jù)或者在新的系統(tǒng)上按照步驟親自 執(zhí)行一遍，或許能夠發(fā)現(xiàn)Bug單里有一些是遺漏的或多余的步驟。如何提交高質(zhì)量缺陷-提交高質(zhì)量缺陷5、測(cè)試數(shù)據(jù)

開發(fā)人員重現(xiàn)Bug時(shí)可能不會(huì)訪問測(cè)試環(huán)境，有些Bug可能只能用一定的測(cè)試數(shù)據(jù)才能重現(xiàn)，所以盡量把測(cè)試數(shù)據(jù)附在Bug單上。6、屏幕截圖

屏幕截圖是Bug單里非常重要的組成部分，有時(shí)一張圖能勝過千言萬語(yǔ)，但也不能養(yǎng)成習(xí)慣不管有用沒用的圖都往上貼，或者是只貼圖而缺少文字描述。附圖能夠使開發(fā)人員結(jié)合你的描述快速地重現(xiàn)Bug是最理想的： ★所附圖片的尺寸和占用空間不要太大，盡量用jpg或gif格式，而 不要用bmp格式。 ★在圖中出問題的地方標(biāo)注一下，更利于開發(fā)人員快速定位。如何提交高質(zhì)量缺陷-提交高質(zhì)量缺陷7、嚴(yán)重級(jí)/優(yōu)先級(jí)

設(shè)置Bug的嚴(yán)重級(jí)之前，應(yīng)該全面地分析Bug的影響，如果我們認(rèn)為這個(gè)Bug的優(yōu)先級(jí)很高，那么應(yīng)該在Bug單里說明優(yōu)先級(jí)高的原因。如果Bug是由于程序版本恢復(fù)到上一版而產(chǎn)生的，那么不管它的嚴(yán)重級(jí)如何，它的優(yōu)先級(jí)應(yīng)該置成“高”。8、日志

如果可以的話一定要把程序報(bào)錯(cuò)的日志附上，這會(huì)讓開發(fā)人員比較容易進(jìn)行分析和調(diào)試。很多不能重現(xiàn)的Bug都是因?yàn)槿鄙偃罩?，開發(fā)人員就會(huì)返回去找測(cè)試人員要日志信息。如果日志文件不大的話，比如十幾行，那么可以直接把日志信息粘到Bug單里，如果日志很大的話，那么最好單獨(dú)粘到一個(gè)文件里，如txt格式的，然后當(dāng)作Bug單的附件就可以了。如何提交高質(zhì)量缺陷-提交高質(zhì)量缺陷流程圖介紹-缺陷生命周期流程圖介紹-提交缺陷流程流程圖介紹-