為什么要做缺陷分析
不論是在傳統(tǒng)的軟件開(kāi)發(fā)流程還是敏捷開(kāi)發(fā)流程中，缺陷的統(tǒng)計(jì)與分析都是軟件質(zhì)量保證的重要環(huán)節(jié)。
一些傳統(tǒng)的缺陷統(tǒng)計(jì)和分析往往把重點(diǎn)放在缺陷數(shù)量的統(tǒng)計(jì)上，用于衡量開(kāi)發(fā)和測(cè)試人員的KPI。例如某個(gè)功能模塊出現(xiàn)了重大的bug，那當(dāng)時(shí)負(fù)責(zé)開(kāi)發(fā)的開(kāi)發(fā)和測(cè)試都要出來(lái)“背鍋”。
不能說(shuō)這種方法是錯(cuò)的，但是如果把目的放在真正提高代碼的質(zhì)量上，缺陷的分析應(yīng)該擺脫這種找人背鍋的思路，回到真正的目的上來(lái)。一個(gè)缺陷的產(chǎn)生不能簡(jiǎn)單歸結(jié)于開(kāi)發(fā)的錯(cuò)誤或者測(cè)試的漏測(cè)，還需要從產(chǎn)品設(shè)計(jì)，架構(gòu)設(shè)計(jì)，用戶(hù)體驗(yàn)等方面進(jìn)行分析。
產(chǎn)品的質(zhì)量是內(nèi)建的，當(dāng)代碼完成的時(shí)候，質(zhì)量就已經(jīng)確定了。缺陷分析的價(jià)值應(yīng)該體現(xiàn)在如何幫助代碼開(kāi)發(fā)過(guò)程中的持續(xù)改進(jìn)中。
怎么做缺陷分析
前期準(zhǔn)備
缺陷分析的前期準(zhǔn)備工作主要體現(xiàn)在缺陷/Bug的記錄上。
要做到后期有效的缺陷分析，很重要的部分其實(shí)是前期記錄bug時(shí)的信息收集。
下面的一些信息都是必須要在創(chuàng)建和修復(fù)缺陷的時(shí)候記錄下來(lái)的：
缺陷發(fā)生的功能模塊
記錄下缺陷發(fā)生在哪一個(gè)功能模。復(fù)雜的系統(tǒng)里面有很多功能模塊組成，我們需要記錄下盡可能準(zhǔn)確的功能模塊，也有可能缺陷發(fā)生在不同模塊之間的交互中，例如不同微服務(wù)之間的業(yè)務(wù)通信，在service的provider和consumer的交互中出現(xiàn)問(wèn)題。那這種交互也可以看作是一個(gè)特別的模塊。模塊的定義并不是固定的，目的是定位缺陷發(fā)生的位置。
缺陷的Root Cause
Root Cause可以理解為錯(cuò)誤的根源。而這個(gè)根源指的是導(dǎo)致缺陷的原因。一些常見(jiàn)的root cause有：
- 編碼錯(cuò)誤：開(kāi)發(fā)在寫(xiě)代碼的過(guò)程中出現(xiàn)了錯(cuò)誤，包括邏輯錯(cuò)誤，場(chǎng)景分析的遺漏，功能未完全實(shí)現(xiàn)等等甚至是拼寫(xiě)錯(cuò)誤。
- 其他缺陷修改引入：開(kāi)發(fā)在修復(fù)其他某個(gè)缺陷的時(shí)候引入了當(dāng)前的缺陷。這在日常的開(kāi)發(fā)中是比較常見(jiàn)的問(wèn)題。修復(fù)Bug時(shí)，要確保當(dāng)前的修改對(duì)其他模塊和邏輯的影響不是一件容易的事情。
- 其他新功能引入：開(kāi)發(fā)在開(kāi)發(fā)某個(gè)新功能（Feature）的時(shí)候引入了當(dāng)前的缺陷。當(dāng)一個(gè)新功能與原有的業(yè)務(wù)邏輯有很強(qiáng)的依賴(lài)性（Dependency）的時(shí)候很容易出現(xiàn)這種bug。
- 其他架構(gòu)/Data Model/Service變化引入：這類(lèi)型的缺陷主要出現(xiàn)在不同系統(tǒng)/服務(wù)之間協(xié)同開(kāi)發(fā)的項(xiàng)目中。當(dāng)前項(xiàng)目所依賴(lài)的外部系統(tǒng)/服務(wù)也在進(jìn)行開(kāi)發(fā)，這些開(kāi)發(fā)帶來(lái)的變化就有可能造成當(dāng)前項(xiàng)目中出現(xiàn)缺陷。
- 需求理解偏差：這是一類(lèi)比較特別的root cause，看上去和代碼邏輯錯(cuò)誤很類(lèi)似。但還是有區(qū)別的，假設(shè)實(shí)際業(yè)務(wù)需求是A，開(kāi)發(fā)人員的理解也是A，結(jié)果實(shí)現(xiàn)的是B，這是編碼錯(cuò)誤。如果開(kāi)發(fā)人員的理解是C，實(shí)現(xiàn)的也是C，那就是需求理解偏差。這主要是為了考察開(kāi)發(fā)和產(chǎn)品需求之間的溝通是否正確。
- 需求歧義：缺陷的產(chǎn)生有時(shí)候并不一定都是開(kāi)發(fā)過(guò)程中產(chǎn)生的，也存在由于需求本身的描述不準(zhǔn)確導(dǎo)致缺陷的情況。不過(guò)在實(shí)際的工作中，需求描述的粒度如何把握是一門(mén)藝術(shù)，同時(shí)也能看出一個(gè)敏捷團(tuán)隊(duì)磨合程度。需求歧義并不是說(shuō)產(chǎn)品經(jīng)理
深入分析
一個(gè)信息記錄詳細(xì)的缺陷，也為后續(xù)的分析提供了足夠的信息支持。
一個(gè)深入的分析，可以從以下幾個(gè)角度切入：
參與人員
缺陷分析可以以頭腦風(fēng)暴的形式來(lái)展開(kāi)，參與的人員也不僅僅限于開(kāi)發(fā)和測(cè)試人員，產(chǎn)品經(jīng)理或者BA（業(yè)務(wù)分析）也可以參與到討論中。
與code review結(jié)合
缺陷分析要深入，幾乎難以避免的要去深挖代碼，通過(guò)對(duì)代碼的重新審視，抽絲剝繭的分析問(wèn)題發(fā)生的原因。是初期的設(shè)計(jì)缺陷，還是實(shí)現(xiàn)時(shí)場(chǎng)景考慮的不完整，又或是代碼結(jié)構(gòu)的不合理，這些都是需要對(duì)代碼進(jìn)行review才能知道。
同時(shí)修復(fù)這個(gè)缺陷的代碼也需要進(jìn)行review。因?yàn)榘l(fā)生缺陷的地方，可能是一個(gè)業(yè)務(wù)上的難點(diǎn)，也可能是代碼實(shí)現(xiàn)中的難點(diǎn)，缺陷的修復(fù)需要經(jīng)過(guò)code review，這樣有助于降低再次引起其他缺陷的風(fēng)險(xiǎn)。
對(duì)測(cè)試用例進(jìn)行review
對(duì)于產(chǎn)品環(huán)境發(fā)現(xiàn)的缺陷，很有必要對(duì)相關(guān)的功能的測(cè)試用例進(jìn)行重新審視。因?yàn)檫@個(gè)缺陷是測(cè)試活動(dòng)的漏網(wǎng)之魚(yú)。
一個(gè)在發(fā)布上線(xiàn)前沒(méi)有被發(fā)現(xiàn)的缺陷，一定程度上可以說(shuō)是escape from test。當(dāng)然其中的原因是很多的。有可能是測(cè)試用例設(shè)計(jì)時(shí)場(chǎng)景路徑考慮的不完全，又或者是團(tuán)隊(duì)對(duì)于真實(shí)業(yè)務(wù)數(shù)據(jù)的預(yù)估偏差，導(dǎo)致測(cè)試時(shí)沒(méi)有把這個(gè)場(chǎng)景的優(yōu)先級(jí)提高。因?yàn)闇y(cè)試的資源是有限的，一些優(yōu)先級(jí)較低的場(chǎng)景并沒(méi)有能夠加入到regression的自動(dòng)化測(cè)試中。
如果缺陷發(fā)生的場(chǎng)景沒(méi)有測(cè)試用例覆蓋，那需要針對(duì)這個(gè)缺陷增加測(cè)試用例，對(duì)于線(xiàn)上的嚴(yán)重缺陷，還需要增加相應(yīng)的自動(dòng)化測(cè)試用例加以覆蓋。
產(chǎn)品/需求/設(shè)計(jì)相關(guān)
缺陷的引入還有可能和產(chǎn)品的前期需求設(shè)計(jì)相關(guān)。
有的線(xiàn)上缺陷可能是需求分析不充分導(dǎo)致的。更多的可能是需求的表達(dá)不清晰導(dǎo)致的開(kāi)發(fā)測(cè)試?yán)斫馄钜氲?。這就需要整個(gè)團(tuán)隊(duì)的關(guān)注，尋求一種大家都能夠理解的需求描述粒度。
解決方案
經(jīng)過(guò)了前期的準(zhǔn)備和深入的分析，終于到了輸出的時(shí)候。一個(gè)缺陷分析沒(méi)有得到有價(jià)值的輸出，前面做的再好也是浪費(fèi)。一個(gè)針對(duì)缺陷分析的解決方案，就是這個(gè)有價(jià)值的輸出。
缺陷分析的輸出不是對(duì)缺陷的修復(fù)，而是避免同類(lèi)缺陷再次出現(xiàn)的解決方案，這是一個(gè)內(nèi)涵很廣的東西，它可以包括，但是不限于以下的內(nèi)容：
- 對(duì)產(chǎn)品業(yè)務(wù)需求/設(shè)計(jì)層面的改進(jìn)
- 對(duì)系統(tǒng)架構(gòu)層面的改進(jìn)
- 對(duì)代碼設(shè)計(jì)實(shí)現(xiàn)層面的改進(jìn)
- 對(duì)測(cè)試用例設(shè)計(jì)方面的改進(jìn)
- 對(duì)持續(xù)集成流程方面的改進(jìn)
- 對(duì)于敏捷團(tuán)隊(duì)日常工作實(shí)踐的改進(jìn)
缺陷分析的解決方案是一個(gè)來(lái)源于缺陷，但是又能站的更高走的更遠(yuǎn)的，并且可以操作和追蹤的解決方案。缺陷分析的整個(gè)過(guò)程中不用把思維局限在缺陷本身，而是可以從多個(gè)角度來(lái)看待一個(gè)缺陷。
最后，給大家一個(gè)小小的提示，缺陷分析要避免走向?yàn)槿毕菡胰吮冲伒姆较?，分析和討論的過(guò)程中要關(guān)注事件本身，而不是強(qiáng)調(diào)某個(gè)人在過(guò)程的責(zé)任。因?yàn)橘|(zhì)量是團(tuán)隊(duì)的責(zé)任，基于分析過(guò)程中發(fā)現(xiàn)的具體問(wèn)題，大家一起提出建設(shè)性的意見(jiàn)，這樣的持續(xù)改進(jìn)才是敏捷的正確實(shí)踐。
