QC的使用和缺陷管理

第十二章QC使用和缺點管理IT@ANYQC的使用和缺陷管理第1頁本課程主要內容QC使用（重點）缺點管理（重點）缺點管理流程缺點基本要素缺點書寫規(guī)范缺點度量與分析編寫測試匯報（重點）QC的使用和缺陷管理第2頁本章目標會熟練使用QC進行測試過程管理（重點）能夠準確表示并統(tǒng)計缺點（重點）能夠編寫測試匯報（重點）QC的使用和缺陷管理第3頁第一部分QC使用缺點管理缺點管理流程缺點基本要素缺點書寫規(guī)范缺點度量與分析編寫測試匯報QC的使用和缺陷管理第4頁QC使用下載地址

/redirect.html?url=https%3A///cda/hpdc/navigation.do%3Faction%3DdownloadBinStart%26zn%3Dbto%26cp%3D54_4012_100__%26caid%3D40593%26jumpid%3Dhpr_R1002_USEN&qt=quicktest&type=HPR&pos=2&key=quicktest&alias=Software+Testing備注：

1.用戶名:testing_account@

密碼:wuye1232.QC10.0：運行在windowssp2環(huán)境上，windowsxp不能安裝QC的使用和缺陷管理第5頁QC安裝注意事項1.安裝前需要先安裝Oracle數(shù)據(jù)庫2.安裝時需要注意數(shù)據(jù)庫配置QC的使用和缺陷管理第6頁QC使用介紹1.QC是一款集測試版本控制、測試需求、測試用例、測試執(zhí)行、測試度量為一體測試管理工具。2.針對每一個模塊使用進行介紹，重點在于使用QC進行測試用例設計和測試執(zhí)行QC的使用和缺陷管理第7頁第二部分QC使用缺點管理缺點管理流程缺點基本要素缺點書寫規(guī)范缺點度量與分析編寫測試匯報QC的使用和缺陷管理第8頁軟件失敗術語缺點（defect）

偏差（variance）故障（fault）

失?。╢ailure）問題（problem）矛盾（inconsistency）錯誤（error） 特殊（feature）事件（incident）

缺點（bug）

異常（anomaly）故障、失敗、缺點：非常嚴重，甚至致命情況異常、事件、偏差：不是很尖銳，主要指未按預料運行，而不是說完全失敗問題、錯誤、缺點：最慣用術語QC的使用和缺陷管理第9頁缺點管理工具開源無償BugZilla、Mantis、JIRA、BugFree商業(yè)QC、IBMRationalClearQuest、CompuwareTrackRecordQC的使用和缺陷管理第10頁軟件缺點生命周期軟件缺點生命周期：從發(fā)覺缺點到處理缺點并關閉整個過程QC的使用和缺陷管理第11頁軟件缺點在整個生命周期中狀態(tài)關于軟件缺點在整個生命周期中狀態(tài)，跟每個企業(yè)開發(fā)流程相關，每個企業(yè)都有不一樣定義，下面是一個大致流程，可在此基礎上進行伸縮：1.測試人員發(fā)覺并統(tǒng)計缺點（new/open）2.測試人員將缺點提交給項目經理，項目經理會對該缺點進行確認2.1

假如確認為是一個缺點，那么項目經理會將該缺點進行分配（assigned）2.2

假如項目經理認為這不是一個缺點，那么會將該缺點打回給測試人員（rejeccted），或者直接關閉（closed）3.開發(fā)人員在接到這個缺點后，也需要先對缺點進行判斷3.1

假如是缺點，就對缺點進行處理（InProgress），處理完成（resolved/fixed）后將缺點重新返回給測試人員3.2

假如不是缺點，可直接返回給測試人員（rejected）4.測試人員接收到開發(fā)人員返回缺點后，需要做以下處理4.1

對于開發(fā)人員修復缺點（resolved/fixed）進行回歸測試，假如測試經過則置為（Testd/Closed），測試不經過能夠重開（Reopen），重新將缺點打回給開發(fā)人員4.1

對于開發(fā)人員拒絕缺點（Rejected），普通是存在爭議缺點，經過項目組討論或評定后，確認不是缺點能夠直接對其進行關閉（Closed），假如確認是缺點，需要對其進行重開（Reopen,假如該缺點可暫緩修復或修復成本較高，需另行找時間修復，可將缺點掛起（Suspened）QC的使用和缺陷管理第12頁軟件缺點在整個生命周期中狀態(tài)主要狀態(tài)有：Open/New、Assigned、InProgress、Resloved、Rejected、Reopen、Tested/ClosedBug狀態(tài)走向：Open-ClosedOpen-Rejected-ClosedOpen-Assigned-InProgress-Resolved-ClosedOpen-Assigned-InProgress-Resolved-Reopen…ClosedOpen-Assigned-Rejected-ClosedQC的使用和缺陷管理第13頁軟件缺點處理流程及狀態(tài)改變QC的使用和缺陷管理第14頁缺點處理流程-示例1QC的使用和缺陷管理第15頁缺點管理綜合流程-示例2QC的使用和缺陷管理第16頁缺點基本要素缺點基本信息*缺點ID（由系統(tǒng)自動生成，唯一）*缺點標題測試軟件和硬件環(huán)境（特殊環(huán)境下可注明）*測試軟件版本（缺點發(fā)覺版本和修復版本，發(fā)覺版本是指當前版本，修復版本普通由項目經理確認）*缺點類型（功效、性能、使用方面、安全等等）*缺點嚴重程度（由測試人員確定）缺點處理優(yōu)先級（普通由項目經理確定）*復現(xiàn)缺點操作步驟（操作步驟）復現(xiàn)缺點測試數(shù)據(jù)（特定數(shù)據(jù)需要注明，比如特定賬號）*缺點實際結果描述（錯誤描述）*期望正確結果描述（期望結果）缺點產生原因分析（假如測試人員能判定原因就給出，不能判定就無需給出，以免誤導開發(fā)人員）注釋文字和截取缺點圖像缺點處理信息缺點提交者（系統(tǒng)默認）缺點處理者（1.項目經理指派，2.已知模塊缺點可由測試人員直接分配給開發(fā)人員）缺點處理方案（普通由開發(fā)者總結問題原因并給出修改方案）缺點提交時間缺點處理時間（普通情況下缺點提交時間和處理時間由缺點管理工具自動生成）QC的使用和缺陷管理第17頁缺點嚴重等級-按5類劃分分類嚴重等級等級描述A致命性(Critical)

不能執(zhí)行正常工作功效或主要功效，或者危及人身安全，主要表現(xiàn)在：

1.因為程序所引發(fā)死機,非法退出

2.死循環(huán)

3.造成數(shù)據(jù)庫發(fā)生死鎖

4.數(shù)據(jù)通訊錯誤

5.嚴重數(shù)值計算錯誤B嚴重

(Major)嚴重影響系統(tǒng)要求或基本功效實現(xiàn)，主要表現(xiàn)在：

1.功效不符

2.數(shù)據(jù)流錯誤

3.程序接口錯誤

4.輕微數(shù)值計算錯誤C普通

(Generic)普通性錯誤，比較輕易修復，主要表現(xiàn)在：

1.界面錯誤(詳細文檔)

2.打印內容、格式錯誤

3.簡單輸入限制未放在前臺進行控制

4.刪除操作未給出提醒QC的使用和缺陷管理第18頁缺點嚴重等級-按5類劃分分類嚴重等級等級描述D輕微

(Minor)比較輕微錯誤，普通是使用方面問題，主要表現(xiàn)在：

1.輔助說明描述不清楚

2.顯示格式不規(guī)范

3.長時間操作未給用戶進度提醒

4.提醒窗口文字未采取行業(yè)術語

5.可輸入?yún)^(qū)域和只讀區(qū)域沒有顯著區(qū)分標志

6.系統(tǒng)處理未優(yōu)化

E提議性

(Suggestion)從測試人員角度提出一些提議性問題，不一定是缺點QC的使用和缺陷管理第19頁缺點嚴重等級-按4類劃分分類嚴重等級等級描述A嚴重系統(tǒng)瓦解、數(shù)據(jù)丟失、數(shù)據(jù)損壞B較嚴重操作性錯誤、錯誤結果、遺漏功效C普通小問題、錯別字、UI布局、罕見故障D提議性不影響使用瑕疵或愈加好實現(xiàn)備注：缺點嚴重等級大致分為這么幾類，要么是5類，要么是4類，跟每個公司對缺點定義相關，面試時請注意按實際情況活學活用QC的使用和缺陷管理第20頁缺點優(yōu)先級

缺點優(yōu)先級描述1最高優(yōu)先級需要停頓深入測試，馬上修復缺點2次高優(yōu)先級缺點需要正常排隊等候修復或列入軟件公布清單，但需要在產品公布之前必須修復3中等優(yōu)先級假如時間允許應該修復缺點4最低優(yōu)先級缺點可能被修復，也可能不被修復就直接公布備注：缺點優(yōu)先等級大致分為，跟每個企業(yè)對缺點定義相關，面試時請注意按實際情況活學活用QC的使用和缺陷管理第21頁缺點書寫規(guī)范缺點標題（Title）標題應該保持簡短、準確，提供缺點本質信息，并便于讀者搜索查尋

良好缺點標題應該按照以下方式書寫：

盡可能按缺點發(fā)生原因與結果方式書寫（“執(zhí)行完A后，發(fā)生B，”或者“發(fā)生B，當A執(zhí)行完后”）防止使用含糊不清詞語，比如“功效中止，功效不正確，行為不起作用，”等。應該使用詳細文字說明功效怎樣中止，怎樣不正確，或怎樣不起作用為了方便搜索和查詢，請使用關鍵字為了便于他人了解，防止使術語、俚語或過分詳細測試細節(jié)舉例：品紅網站后臺使用管理員賬號登錄失敗QC的使用和缺陷管理第22頁缺點書寫規(guī)范復現(xiàn)步驟（ReproducibleSteps）

復現(xiàn)步驟包含怎樣使他人能夠很輕易復現(xiàn)該缺點完整步驟。為了到達這個要求，復現(xiàn)步驟信息必須是完整、準確、簡明、可復現(xiàn)。不友好重現(xiàn)步驟：復現(xiàn)步驟包含了過多多出步驟，而且句子結構混亂，可讀性很差，難于了解復現(xiàn)步驟包含了過少信息，丟失操作必要步驟。因為提供步驟不完整，開發(fā)人員經常需要種種猜測，努力嘗試復現(xiàn)步驟，浪費了大量時間。因為缺乏關鍵步驟，這些缺點通常被工程師以“不能復現(xiàn)”為由Rejected給測試人員

測試人員沒有對軟件缺點發(fā)生條件和影響區(qū)域進行隔離，軟件開發(fā)人員無法判斷該缺點影響軟件部分，不能進行徹底修正。QC的使用和缺陷管理第23頁缺點書寫規(guī)范正確重現(xiàn)步驟（ReproducibleSteps）：準確無誤重現(xiàn)操作步驟，步驟不多出，無遺漏每一個步驟盡可能只統(tǒng)計一個操作每一個步驟前使用數(shù)字對步驟編號盡可能使用短語和短句，防止復雜句型和句式將常見步驟合并為較少步驟，比如：1.Createtextframe.2.Addtext.能夠簡單合并成一步：1.Createanewtextframeandaddtext.只統(tǒng)計各個操作步驟是什么，不要包含每個操作步驟執(zhí)行后結果

說明：重現(xiàn)步驟可參考測試用例中步驟舉例：Login_Bug_001:品紅網站后臺使用管理員賬號登錄失敗操作步驟：進入品紅網站后臺管理界面輸入正確用戶名和密碼，點【登錄】按鈕QC的使用和缺陷管理第24頁缺點書寫規(guī)范實際結果（也就是錯誤描述）盡可能將缺點分解成多個缺點匯報，并使用交叉引用說明彼此之間聯(lián)絡。這些動作結果通常比較相同但缺點不一樣。首先進行更多隔離測試，縮小產生缺點范圍，查看是否產生多個缺點在實際結果部分，僅列出缺點一到兩個表現(xiàn)特征。使用注釋（Notes）部分列出缺點其它問題；在缺點第一個表現(xiàn)特征后，將隨即步驟和缺點表現(xiàn)特征移到注釋部分。主要信息幾乎總是包含在第一個斷言或錯誤里，其它錯誤都是第一個錯誤變種。舉例：001:品紅網站后臺使用管理員賬號登錄失敗操作步驟：進入品紅網站后臺管理界面輸入正確用戶名和密碼，點【登錄】按鈕錯誤描述：1.登錄失敗，系統(tǒng)給犯錯誤提醒QC的使用和缺陷管理第25頁缺點書寫規(guī)范自我檢驗和提問?

缺點匯報已經向讀者包含完整、準確、必要信息了嗎？?

一個缺點匯報中是否之匯報了一個缺點？?

讀者是否能輕易搜索該缺點？?

步驟是否能夠完全復現(xiàn)而且表示清楚嗎？?

是否包含了復現(xiàn)該缺點需要環(huán)境變量或測試所用數(shù)據(jù)文件？?

缺點標題是按照原因與結果方式書寫嗎？?

實際結果和期望結果是否描述不夠清楚而輕易引發(fā)歧義嗎？QC的使用和缺陷管理第26頁缺點書寫規(guī)范防止常見錯誤用“User（用戶）”代替使用者，防止使用“I（我）”、“You（你）”等人稱代詞客觀地反應出缺點現(xiàn)象和完整信息，不要對軟件質量優(yōu)劣做任何主觀性強烈批評、嘲諷，防止使用情緒化語言和強調符號，比如黑體、全部字母大寫、斜體、感嘆號、問號等對實際結果描述要清楚，防止使用含義含糊詞匯，諸如“Seems（似乎）”、“Appearstobe（看上去可能）”等等客觀地描述缺點信息，防止包含自認為比較幽默內容，因為不一樣讀者文化和觀念不一樣，很多幽默內容在他人看來，往往難以準確了解，甚至可能引發(fā)誤解對于無法確定缺點，應該先將問題統(tǒng)計下來，然后經過電子郵件或口頭交流，確認是缺點后再匯報到缺點庫中，防止查詢和統(tǒng)計結果不準確性對于偶發(fā)性缺點，先將缺點統(tǒng)計在缺點庫中，視缺點發(fā)生頻率進行處理，頻率高必須要求修改，頻率低可先將缺點掛起，待日后修復，防止不重現(xiàn)就直接提交缺點QC的使用和缺陷管理第27頁完整缺點統(tǒng)計示例001(BugID，系統(tǒng)自動生成)品紅網站后臺使用管理員賬號登錄失?。˙UG標題）缺點發(fā)覺版本：ph_0801_01(當前版本）缺點修復版本：默認（由項目經理統(tǒng)一分配）測試環(huán)境：（需要特殊說明時給出）嚴重等級：嚴重（視缺點詳細情況給出）優(yōu)先級：默認（由項目經理統(tǒng)一分配）操作步驟：1.進入品紅網站后臺管理界面2.輸入正確用戶名和密碼，點【登錄】按鈕測試數(shù)據(jù)：用戶名：bass密碼：bass錯誤描述：（實際結果）1.管理員賬號登錄失敗，系統(tǒng)給犯錯誤提醒（主要缺點）2.錯誤提醒信息中“登陸”使用錯誤（次要缺點）期望結果：

1.管理員賬號能夠成功登錄品紅網站后臺系統(tǒng)2.提醒信息中“登陸”應改為“登錄”分配給：項目經理或開發(fā)人員姓名（新建BUG默認給項目經理）測試人員：測試人員姓名缺點狀態(tài)：new（默認新建缺點時狀態(tài)）QC的使用和缺陷管理第28頁缺點統(tǒng)計分析按錯誤類型按嚴重等級按優(yōu)先級別按問題狀態(tài)按問題類型與嚴重程度組合按發(fā)覺人員與嚴重程度組合QC的使用和缺陷管理第29頁缺點統(tǒng)計分析按模塊分布QC的使用和缺陷管理第30頁缺點統(tǒng)計分析按對象分布QC的使用和缺陷管理第31頁缺點統(tǒng)計分析按缺點類型分布QC的使用和缺陷管理第32頁缺點密度分析缺點密度軟件缺點分為經過評審或測試等方法發(fā)覺已知缺點和還未發(fā)覺潛在缺點兩種缺點密度=已知缺點數(shù)量/產品規(guī)模QC的使用和缺陷管理第33頁缺點注入-發(fā)覺矩陣缺點移除率=（本階段發(fā)覺缺點數(shù)/本階段注入缺點總數(shù)）*100%缺點泄漏率=（下游發(fā)覺本階段缺點數(shù)/本階段注入缺點總數(shù)）*100%計算缺點移除率意義能夠有效衡量測試用例是否充分測試效率是否充分分析出軟件開發(fā)各個步驟質量，找到最需要改進步驟QC的使用和缺陷管理第34頁缺點注入-發(fā)覺矩陣缺點注入階段缺點發(fā)覺階段需求設計編碼注入總數(shù)需求階段5

5設計階段1365

78編碼、單元測試階段4101832系統(tǒng)測試階段4397104驗收測試階段001919發(fā)覺總計2678134238階段缺點移除率19.23%83.33%13.43%

矩陣每行表示該階段或活動發(fā)覺各階段產生缺點數(shù)矩陣每列表示該階段或活動注入缺點泄漏到后續(xù)各步驟缺點數(shù)。QC的使用和缺陷管理第35頁缺點注入-發(fā)覺矩陣缺點注入階段缺點發(fā)覺階段需求設計編碼注入總數(shù)需求階段5

5設計階段1365

78編碼、單元