作為一名測(cè)試人員，最大的成就就是像福爾摩斯一樣，利用超強(qiáng)的觀察力，嚴(yán)密的邏輯推理能力，迅速找出軟件的"罪犯"，將其繩之以法?？墒窃诔蔀?福爾摩斯"之前，觀察力、邏輯推理能力，是需要不斷訓(xùn)練的。這篇文章實(shí)際就是軟件測(cè)試的"犯罪心理學(xué)"(初級(jí)版)：利用軟件缺陷數(shù)據(jù)，對(duì)缺陷進(jìn)行分類匯總，計(jì)算缺陷分析指標(biāo)，進(jìn)而發(fā)現(xiàn)軟件生命周期的各個(gè)階段的不足，制定相應(yīng)改進(jìn)方法，增強(qiáng)軟件過程人為活動(dòng)的規(guī)范性，最終目標(biāo)提升軟件交付質(zhì)量，提升測(cè)試效率
一、缺陷管理庫
缺陷管理庫記錄了缺陷相關(guān)的資料，為缺陷分析提供了詳細(xì)的信息，而只有正確的信息，才能保障正確的分析結(jié)果。
1.1 缺陷定義
軟件缺陷是指在產(chǎn)品說明、設(shè)計(jì)、編碼階段中的任何不足。一般要求將需求評(píng)審、設(shè)計(jì)評(píng)審、代碼檢查、測(cè)試、項(xiàng)目組內(nèi)部發(fā)現(xiàn)、用戶反饋等幾種手段發(fā)現(xiàn)的缺陷都統(tǒng)一記錄在缺陷跟蹤系統(tǒng)中，進(jìn)行統(tǒng)一管理、統(tǒng)計(jì)。而目前很多項(xiàng)目缺陷跟蹤系統(tǒng)中往往只包含了測(cè)試階段的缺陷統(tǒng)計(jì)，在此基礎(chǔ)上的缺陷分析勢(shì)必存在局限性。
1.2 缺陷信息
為了便于缺陷定位、跟蹤和修改，需要收集盡量多的有效信息，比較常見的缺陷信息如下：
- 缺陷描述
- 被測(cè)產(chǎn)品信息：比如App名稱、版本號(hào)
- 測(cè)試環(huán)境：wifi、數(shù)據(jù)網(wǎng)絡(luò)、測(cè)試環(huán)境、生產(chǎn)環(huán)境
- 測(cè)試機(jī)型：機(jī)型、系統(tǒng)版本號(hào)
- 測(cè)試步驟
- 預(yù)期及實(shí)際結(jié)果
- 復(fù)現(xiàn)概率
- 測(cè)試輔助信息：截圖、視頻、日志
- 缺陷狀態(tài)
- 缺陷優(yōu)先級(jí)：標(biāo)識(shí)處理和修正軟件缺陷的先后順序指標(biāo)
- 缺陷嚴(yán)重程度
- 缺陷發(fā)生的組件
- 缺陷創(chuàng)建時(shí)間
- 缺陷發(fā)現(xiàn)人
- 缺陷責(zé)任修改人
- 缺陷修復(fù)時(shí)間
- 缺陷產(chǎn)生原因
在提交缺陷時(shí)，需要遵循以下5個(gè)原則：
- 準(zhǔn)確性：缺陷每個(gè)組成部分描述準(zhǔn)確，不會(huì)產(chǎn)生誤解
- 完整性：復(fù)現(xiàn)該缺陷完整的步驟、截圖、日志
- 一致性：按照一致的格式書寫全部缺陷信息
- 簡(jiǎn)潔性：只包含必不可少的信息，不包括任何多余的內(nèi)容
- 清晰性：每個(gè)組成部分的描述清晰，易于理解
這一步其實(shí)可以理解成培養(yǎng)測(cè)試人員的觀察能力，信息收集能力。只有不斷觀察、收集正確信息，才可以為后續(xù)的偵查做好準(zhǔn)備工作。
二、缺陷分析
缺陷分析是在形成缺陷管理庫的基礎(chǔ)上，對(duì)缺陷進(jìn)行宏觀及微觀緯度的分析。通過缺陷分析，發(fā)現(xiàn)各種類型缺陷發(fā)生的概率，確定缺陷集中的區(qū)域，明確缺陷的發(fā)展趨勢(shì)，追蹤和分析缺陷產(chǎn)生的原因。在此分析基礎(chǔ)上，對(duì)軟件生命周期中各個(gè)角色、項(xiàng)目流程做改善和優(yōu)化，提高軟件測(cè)試質(zhì)量，提升測(cè)試效率。
缺陷分析僅僅是一種手段，而非最終目的。利用缺陷分析結(jié)論，反思和回溯缺陷產(chǎn)生的各個(gè)階段，思考如何避免類似問題，不再踩坑，在下次測(cè)試中得到提升，才是我們想要的結(jié)果。同樣的，缺陷分析的成果是一個(gè)持續(xù)改進(jìn)優(yōu)化閉環(huán)的過程，它是測(cè)試人員潛移默化中測(cè)試能力的提升，也是項(xiàng)目流程中各個(gè)角色共同保障產(chǎn)品質(zhì)量意識(shí)的推動(dòng)。例如缺陷分析發(fā)現(xiàn)很多需求缺陷是到測(cè)試階段才發(fā)現(xiàn)，那么就有必要加大需求評(píng)審力度；缺陷分析發(fā)現(xiàn)開發(fā)修復(fù)缺陷引入新缺陷比例很高，那么開發(fā)團(tuán)隊(duì)在修復(fù)缺陷的時(shí)候要考慮到對(duì)周邊區(qū)域的影響，并且要通知相關(guān)區(qū)域的專家加強(qiáng)代碼審查。當(dāng)然測(cè)試團(tuán)隊(duì)也要盡可能多的在相關(guān)區(qū)域做一些回歸測(cè)試。大家可以結(jié)合自身項(xiàng)目來利用缺陷分析優(yōu)化項(xiàng)目實(shí)踐。
三、宏觀缺陷分析技術(shù)
宏觀缺陷分析是指對(duì)缺陷信息進(jìn)行分類和匯總，利用統(tǒng)計(jì)的方法計(jì)算分析相關(guān)指標(biāo)，編寫缺陷分析報(bào)告的活動(dòng)。宏觀缺陷分析的方法很多，這里主要關(guān)注缺陷發(fā)展趨勢(shì)分析、缺陷分布狀況分析、缺陷注入-發(fā)現(xiàn)分析。
3.1 缺陷發(fā)展趨勢(shì)分析
項(xiàng)目管理中一項(xiàng)非常重要但十分困難的工作就是平衡進(jìn)度、質(zhì)量和成本。測(cè)試人員可以提供缺陷提交、缺陷修復(fù)的趨勢(shì)圖表，幫助管理者從中發(fā)現(xiàn)一些簡(jiǎn)單的缺陷發(fā)展趨勢(shì)（這種缺陷可以是本文論述的廣義缺陷發(fā)現(xiàn)手段確定的，也可以是單純的測(cè)試手段發(fā)現(xiàn)的），從而了解軟件質(zhì)量趨勢(shì)。
這里給出一個(gè)常用的分析圖，x軸代表時(shí)間，y軸代表以下四種類型缺陷的數(shù)量：
- 發(fā)現(xiàn)數(shù)：累計(jì)的所有被發(fā)現(xiàn)bug的數(shù)量
- 關(guān)閉數(shù)：累計(jì)的所有被關(guān)閉bug的數(shù)量
- 日（期）發(fā)現(xiàn)數(shù)：當(dāng)日（期）發(fā)現(xiàn)的缺陷數(shù)量
- 日（期）關(guān)閉數(shù)：當(dāng)日（期）關(guān)閉的缺陷數(shù)量
3.2 缺陷分布狀況分析
3.2.1 缺陷嚴(yán)重程度分布
缺陷嚴(yán)重程度度量有助于識(shí)別不同嚴(yán)重程度缺陷在所有缺陷中的比重，有助于開發(fā)測(cè)試人員資源的計(jì)劃和分配。
這里給出一個(gè)常用的缺陷嚴(yán)重程度分析圖，x軸代表時(shí)間，y軸代表各嚴(yán)重級(jí)別的缺陷數(shù)量。
通過缺陷嚴(yán)重程度圖表，分析各嚴(yán)重程度缺陷發(fā)現(xiàn)趨勢(shì)，判斷產(chǎn)品質(zhì)量是否趨于穩(wěn)定。如果高嚴(yán)重程度的缺陷大量增加通常意味著產(chǎn)品質(zhì)量出現(xiàn)問題。
3.2.2 缺陷模塊分布
按照缺陷對(duì)應(yīng)的產(chǎn)品組成部分來匯總?cè)毕輸?shù)據(jù)，利用這樣的分布，可以找出我們產(chǎn)品高危模塊，針對(duì)高危模塊，調(diào)整測(cè)試策略。
3.2.3 ODC（正交缺陷分析）
正交缺陷分類法（Orthogonal Defect Classification，ODC）介紹了一種不同于大家常用的非常有效的軟件缺陷分類及分析方法，它定義了八個(gè)正交的缺陷屬性用于對(duì)缺陷的分類。所謂正交性是指缺陷屬性之間不存在關(guān)聯(lián)性，各自獨(dú)立，沒有重疊的冗余信息。
- 對(duì)于缺陷提交者，他需要給這個(gè)缺陷分配“活動(dòng)（Activity）”、“觸發(fā)（Trigger）”、“影響（Impact）”這三個(gè)屬性。
- Activity：項(xiàng)目生命周期的一個(gè)階段，該缺陷發(fā)生在該階段，例如需求、設(shè)計(jì)、代碼階段，即缺陷發(fā)現(xiàn)階段
- Trigger：可以理解成測(cè)試的手段
- Impact：對(duì)用戶的影響，例如安全性、易用性
- 當(dāng)一個(gè)開發(fā)人員關(guān)閉一個(gè)缺陷時(shí)，他可以分配“階段（Age）”、“來源（Source）”、“限定符（Qualifier）”、“類型（Type）”以及“目標(biāo)（Target）”這五個(gè)屬性。
- Age：描述缺陷對(duì)應(yīng)的代碼屬于新代碼，舊代碼，還是修復(fù)bug引入
- Source：定義缺陷來源，是自身代碼問題，還是第三方代碼導(dǎo)致
- Qualifier：指明了所進(jìn)行的修復(fù)應(yīng)歸于缺失，錯(cuò)誤或者還是外來的代碼或者信息
- Type：缺陷真正的原因，例如初始化、算法等
- Target：描述缺陷是由于設(shè)計(jì)還是編碼引入，即缺陷注入階段
關(guān)于ODC分析方法，需要結(jié)合實(shí)際項(xiàng)目，對(duì)不同屬性進(jìn)行篩選，優(yōu)化不同屬性對(duì)應(yīng)的值。
軟件缺陷分析方法：ODC 這篇文章中詳細(xì)解釋了ODC各屬性及對(duì)應(yīng)的值。
3.3 缺陷注入-發(fā)現(xiàn)矩陣
利用缺陷的兩個(gè)重要屬性：缺陷發(fā)現(xiàn)階段、缺陷注入階段，分析缺陷數(shù)據(jù)，繪制出"缺陷注入-發(fā)現(xiàn)矩陣"，從中分析項(xiàng)目生命周期各個(gè)環(huán)節(jié)的質(zhì)量，優(yōu)化相關(guān)流程。
- 缺陷移除率：（本階段發(fā)現(xiàn)的缺陷數(shù)/本階段注入的缺陷數(shù))*100%，它反映的是該活動(dòng)階段的缺陷清除能力
- 缺陷泄漏率：（下游發(fā)現(xiàn)的本階段的缺陷數(shù)/本階段注入的缺陷總數(shù)）*100%，它反映的是本階段質(zhì)量控制措施落實(shí)的成效
如上圖例子，需求階段一共注入了34個(gè)缺陷，需求評(píng)審時(shí)只發(fā)現(xiàn)了4個(gè)，設(shè)計(jì)過程中發(fā)現(xiàn)了15個(gè)，編碼和單元測(cè)試階段發(fā)現(xiàn)了12個(gè)，系統(tǒng)測(cè)試階段發(fā)現(xiàn)3個(gè)。這樣，需求階段的缺陷移除率 4/34*100%=11.76%。這個(gè)結(jié)果說明，我們需要重新審視需求評(píng)審，加大需求評(píng)審力度。另外，編碼階段的缺陷大部分依賴于系統(tǒng)測(cè)試發(fā)現(xiàn)，很顯然，項(xiàng)目開發(fā)過程中的單元測(cè)試和集成測(cè)試活動(dòng)開展不夠深入。我們可以進(jìn)一步分析這些系統(tǒng)測(cè)試出來的測(cè)試缺陷，是不是可以被更前端的評(píng)審/測(cè)試/設(shè)計(jì)討論活動(dòng)所替代。
四、微觀缺陷分析技術(shù)
微觀缺陷分析是指從單個(gè)有價(jià)值的缺陷入手，追蹤和分析缺陷產(chǎn)生的本質(zhì)原因。
并不是所有的缺陷都有必要去做微觀缺陷分析，因此首先需要挑選"合適的缺陷"。這里給出幾點(diǎn)建議
- 選擇典型有代表性的：同類型的一系列問題
- 選擇有發(fā)現(xiàn)難度：積累缺陷庫，對(duì)測(cè)試用例做補(bǔ)充
- 選擇有推廣意義的：該缺陷很普遍，可以推廣到其他業(yè)務(wù)線
再挑選合適的缺陷后，我們緊接著需要收集該缺陷相關(guān)的有效信息進(jìn)行下一步缺陷原因分析。這些缺陷信息包括提交缺陷時(shí)信息，同時(shí)也包括和開發(fā)討論獲取的信息。
接著就是追蹤缺陷產(chǎn)生的真正原因。網(wǎng)絡(luò)上有很多總結(jié)的分析方法，有"望、聞、問、切"診斷法，有"5W"法，還有"探案分析法"。其實(shí)個(gè)人覺得在這一步驟中，更多需要積累經(jīng)驗(yàn)，善于追根究底，多問為什么，多理解產(chǎn)品實(shí)現(xiàn)邏輯，產(chǎn)品設(shè)計(jì)思路，有了這些基礎(chǔ)之后，合理的推理分析即可。
下面這兩篇文章是非常好的結(jié)合實(shí)踐總結(jié)的微觀缺陷分析，大家可以通過他們的分析積累經(jīng)驗(yàn)。
