持續(xù)測試之下的正確質(zhì)量度量丨IDCF

來源：獨(dú)行高飛

作者：CrissChan

比爾·蓋茨曾經(jīng)說過用代碼行數(shù)來衡量軟件的生產(chǎn)力，就像用飛機(jī)的重量來衡量飛機(jī)的生產(chǎn)進(jìn)度一樣。所以找到正確的度量質(zhì)量的指標(biāo)我們才能得到正確的質(zhì)量結(jié)果。這就如同被很多人千行代碼缺陷率遭到很多人的詬病一樣，網(wǎng)上曾經(jīng)有一個笑話就是說千行代碼缺陷率的。

一個笑話

某公司有兩個開發(fā)團(tuán)隊(duì)，團(tuán)隊(duì)間針對缺陷密度的千行代碼缺陷率這個指標(biāo)做對比，千行代碼缺陷率高的團(tuán)隊(duì)扣獎金獎勵給千行代碼缺陷率低的團(tuán)隊(duì)。

在第一個月團(tuán)隊(duì)A的千行代碼缺陷率高過了團(tuán)隊(duì)B，團(tuán)隊(duì)A的小伙伴很不情愿的被扣了績效，但是團(tuán)隊(duì)B的成員卻很開心。

在第二個月開始的時(shí)候，團(tuán)隊(duì)A的負(fù)責(zé)人就召集團(tuán)隊(duì)成員討論對策，總不能每個月都被扣績效獎金，最后討論的結(jié)果就是將一些用遞歸、抽象等優(yōu)秀的方法寫的代碼改成最原始的寫法，這樣通過增大千行代碼缺陷率的分母來降低這個度量指標(biāo)，果不其然，在第二個月月底統(tǒng)計(jì)的時(shí)候，團(tuán)隊(duì)A的千行代碼缺陷率大幅度低于團(tuán)隊(duì)B，團(tuán)隊(duì)A終于報(bào)了仇，很是開心。

團(tuán)隊(duì)B的成員就覺得蹊蹺，因此私下打聽到了團(tuán)隊(duì)A的做法，因此團(tuán)隊(duì)B也決定效仿，但是就算這樣肯定也無法低于團(tuán)隊(duì)A的千行代碼缺陷率，在團(tuán)隊(duì)B內(nèi)部不斷的討論中，他們決定將Tomcat源代碼引入項(xiàng)目中，在千行代碼缺陷率分母上占領(lǐng)絕對的統(tǒng)治地位。那么結(jié)果就是一來一往幾個月下來公司因?yàn)轫?xiàng)目代碼寫的越來越難以維護(hù)，無法按時(shí)交付很多需求，最后導(dǎo)致兩個團(tuán)隊(duì)的項(xiàng)目都失敗了，公司也因此關(guān)門大吉，但是團(tuán)隊(duì)A和團(tuán)隊(duì)B的項(xiàng)目代碼倉庫中有當(dāng)前所有開源項(xiàng)目的源代碼。

麥克納馬拉謬誤

當(dāng)然，上面只是一個笑話。但是這則笑話卻說明了一個道理，你度量什么，就會得到什么。這也是著名的古德哈特定律的體現(xiàn)，古德哈特定律是說當(dāng)一個度量成為目標(biāo)，它就不再是一個好的度量。這也就是說如果一個指標(biāo)被用作政策目標(biāo)時(shí)，它很快就失去了捕捉被測量的現(xiàn)象或特征的能力，以經(jīng)濟(jì)學(xué)家查爾斯·古德哈特之名命名。他在1975年的一篇批判撒切爾貨幣政策文章中指出，一旦為控制它而對其施加壓力，任何觀察到的統(tǒng)計(jì)規(guī)律將會坍塌。這里面還有一個印度有關(guān)眼鏡蛇的故事。

在殖民時(shí)期的印度，德里的眼鏡蛇泛濫成災(zāi)。為了減少城里的眼鏡蛇數(shù)量，當(dāng)?shù)卣慕鉀Q方案是獎勵獵殺眼鏡蛇。由于賞金足夠慷慨，許多人開始獵捕眼鏡蛇，這正好導(dǎo)致了預(yù)期的結(jié)果：眼鏡蛇數(shù)量減少。隨著眼鏡蛇數(shù)量的下降，在野外尋找眼鏡蛇變得越來越困難，人們開始變得相當(dāng)有創(chuàng)業(yè)精神。他們開始在家里養(yǎng)眼鏡蛇，然后像以前一樣殺死眼鏡蛇來領(lǐng)取賞金。地方當(dāng)局意識到，在這個城市里已經(jīng)很少有眼鏡蛇，但他們支付賞金仍然像以前一樣多。于是，地方官員決定取消賞金。其結(jié)果是人們把毫無價(jià)值的眼鏡蛇放回野外，導(dǎo)致了比開始前更大的眼鏡蛇問題。

在制定度量指標(biāo)的時(shí)候，一旦一個指標(biāo)被作為組織績效的一部分被采納，那么他就會導(dǎo)致行為的改變，從而發(fā)生不正當(dāng)?shù)募睿瑢?dǎo)致非計(jì)劃內(nèi)后果。所以在質(zhì)量上既要有度量，更要選擇正確的度量指標(biāo)。

在度量質(zhì)量的時(shí)候，除了要避免古德哈特定律也要避免麥克納馬拉謬誤，麥克納馬拉謬誤是指使可測量的重要而不是試圖使重要的可測量。它由美國社會學(xué)家丹尼爾·揚(yáng)克洛維奇（Daniel Yankelovich）于1972年提出，但直至1994年因管理大師查爾斯·漢迪《空雨衣》一書而廣為流傳。該謬論以曾任美國國防部部長的羅伯特·麥克納馬拉之名命名。麥克納馬拉謬論的描述如下：

• 第一步是測量任何容易測量的，這目前沒有什么問題。

• 第二步是無視那些不容易測量的，或賦予它任意的數(shù)值，這是人為誤導(dǎo)。

• 第三步是假設(shè)那些不容易測量的都不重要，這是盲目。

• 第四步是宣稱不容易測量的不存在，這是自殺。

麥克納馬拉一生有著耀眼的履歷。1937年畢業(yè)于美國加州大學(xué)伯克利分校、獲得經(jīng)濟(jì)與哲學(xué)雙學(xué)位，1939年獲得美國哈佛大學(xué)工商管理碩士（MBA）。曾任福特汽車公司總裁，是該公司成立初期以來第一位擔(dān)任該職位的非福特家族總裁。其后任美國國防部部長（1961年－1968年，為美國史上任期最久的國防部長），以及世界銀行行長（1968年－1981年）。肯尼迪總統(tǒng)邀請麥克納馬拉擔(dān)任國防部長，希望他能將他在福特公司使用的管理技術(shù)應(yīng)用到美軍的管理中,發(fā)起一場“麥克納馬拉革命（McNamara Revolution）”。在越戰(zhàn)期間，他依據(jù)定量觀察（或量度）做出決策，或以量化數(shù)據(jù)衡量成功，如擊斃敵軍的尸體數(shù)量，敵我雙方死亡數(shù)量的比率等，但忽略了其他因素。其理由是這些其他因素?zé)o法得到證實(shí)。由此帶來的誤判是越戰(zhàn)失利的原因之一。在度量指標(biāo)的選取上要避免在燈下找鑰匙，通過指定的度量指標(biāo)將所有人的關(guān)注點(diǎn)集中在了燈光之下，這可能導(dǎo)致忽略不易測量或?qū)嶋H上不可測量的方面，即使它們同等重要或更重要。那么對于一個持續(xù)迭代的項(xiàng)目的度量指標(biāo)，最本質(zhì)的選取原則就是度量的好處要大于成本，如果度量的成本超過了益處，必將導(dǎo)致很多偷奸取巧的辦法出現(xiàn)。

設(shè)計(jì)一些“測謊題”

20世紀(jì)80年代，范·海倫是一個超級巨星樂隊(duì)，《滾石》雜志中曾經(jīng)寫過，他們出現(xiàn)在哪里，盛大、喧鬧的狂歡都會跟隨。那么每次他們和其他合作商開演唱會的時(shí)候都會提供一個有50頁附件的巡演合同，合同中有常規(guī)的安保要求、技術(shù)細(xì)節(jié)之外，有一些很特別的內(nèi)容，例如在零食的要求部分他們指定了薯片、堅(jiān)果、蝴蝶餅和M&M巧克力豆，在邊上還有一個超級醒目的特別注釋：絕對不要棕色的。這份要求被一些合作商宣傳出來大家都認(rèn)識為范·海倫在耍大牌，難道棕色的巧克力豆和其他顏色的味道不一樣嗎？這個我相信大家的答案都是否定的。其實(shí)這是因?yàn)椋丁ず惖难莩獣昧撕芏嘞冗M(jìn)的技術(shù)設(shè)計(jì)規(guī)模龐大、思維超前，以便能夠造就盛大的狂歡效果，因此他們才需要50多頁附件，為了能確保合作商能夠詳細(xì)看過附件，他們的棕色巧克力豆就是驗(yàn)證條件，如果他們到達(dá)了演出場地，看到了有裝有棕色巧克力豆的碗，那么說明合作商根本沒有好好看他們的附件，因此他們就需要花費(fèi)更多的精力去檢查全部的設(shè)備是否安裝合格。

從而可以看出，度量以及一些測謊度量的設(shè)置也是很重要的。回到開始的笑話，如果團(tuán)隊(duì)的度量是驅(qū)使大家用優(yōu)秀的編碼實(shí)踐去考察千行代碼缺陷率，那么也并不會導(dǎo)致一切皆輸?shù)牡夭剑虼诉@么多的度量指標(biāo)，也是相互制約的，這就和很多心理測試問卷一樣，他里面有很多來衡量受測者心理是不是健康之外，還有很多是測謊題，來考察受測者是不是說謊了。也就是說在整體的度量指標(biāo)的選擇中，千行代碼缺陷率可以選擇，但是一定要有一個可以制約笑話中的問題的指標(biāo)來做“測謊題”。綜合了上述全部的對于度量指標(biāo)的選取的原則和定律之上。

質(zhì)量度量指標(biāo)

分別在質(zhì)量和效率兩個方向制定這幾十個指標(biāo)，每一個指標(biāo)的制定都有它自己的度量角度，具體如下：

• 開卡成功率，主要是指在測試左移的時(shí)候，在開卡階段，每次開卡都能夠順利完成將需求故事卡片移動進(jìn)入看板中的開發(fā)負(fù)責(zé)的泳到中。如果開卡失敗，那么需要產(chǎn)品經(jīng)理繼續(xù)補(bǔ)充完善后，再次開卡，那么這就不算開卡成功，因此開卡成功率是由第一次開卡就可順利進(jìn)入開發(fā)負(fù)責(zé)泳道的需求故事卡片數(shù)量除以進(jìn)入開卡的需求故事卡總數(shù)量。這個值越接近1，說明需求故事卡片設(shè)計(jì)的很完善，產(chǎn)品經(jīng)理的產(chǎn)出物質(zhì)量很好。

• 驗(yàn)卡成功率，是指在測試左移的時(shí)候，在驗(yàn)卡階段，每次驗(yàn)卡都能夠順利完成將需求故事卡片移動進(jìn)入看板中的測試負(fù)責(zé)的泳到中。如果驗(yàn)卡失敗，那么需要開發(fā)完善實(shí)現(xiàn)后，再次驗(yàn)卡，那么這就不算驗(yàn)卡成功，因此驗(yàn)卡成功率是由第一次驗(yàn)卡就可順利進(jìn)入測試負(fù)責(zé)泳道的需求故事卡片數(shù)量除以進(jìn)入驗(yàn)卡的需求故事卡總數(shù)量。這個值越接近1，說明研發(fā)實(shí)現(xiàn)的代碼完善，并且符合需求故事卡片的要求。

• SonarQube技術(shù)債包含缺陷、漏洞、代碼異味，這些都是按照組織級的約定統(tǒng)一承諾要遵守的規(guī)范而制定的，因此出現(xiàn)了類似的技術(shù)債務(wù)，只能說明有沒有遵守組織約定的代碼，因此按照嚴(yán)重級別按照從高到低分為阻塞級、嚴(yán)重級、主要級、次要級、提示級，項(xiàng)目中缺陷、漏洞、代碼異味越少，或者存在的上述技術(shù)債務(wù)級別越低，那說明項(xiàng)目的靜態(tài)質(zhì)量越好。SonarQube技術(shù)債還包含了代碼密度，這主要是說么代碼有多少是重復(fù)的，越多的重復(fù)說明項(xiàng)目應(yīng)該進(jìn)行代碼抽象，因此需要重新設(shè)計(jì)所以代碼密度也是稍微低一點(diǎn)為好，但是也沒必要追求這個指標(biāo)必須是零。圈復(fù)雜度也叫條件復(fù)雜度，是有由托馬斯·J·麥凱布于1976年提出，用來表示程序的復(fù)雜度，它是衡量一個模塊判定結(jié)構(gòu)的復(fù)雜程度，數(shù)量上表現(xiàn)為獨(dú)立現(xiàn)行路徑條數(shù)，也可理解為覆蓋所有的可能情況最少使用的測試用例數(shù)。圈復(fù)雜度大說明程序代碼的判斷邏輯復(fù)雜，可能質(zhì)量低且難于測試和維護(hù)，因此圈復(fù)雜度稍微低一點(diǎn)可以為一個交付更好質(zhì)量的系統(tǒng)的加分。

• 單元測試和代碼覆蓋率，單元測試毋庸置疑是分層測試第一層測試，通過代碼覆蓋率來評價(jià)，在這里行覆蓋和分支覆蓋是比較常用的判定條件，其他覆蓋也并不是不可取，只是既關(guān)注了行覆蓋，也關(guān)注了分支覆蓋也就說明單元測試是一個既能滿足每一行都覆蓋還能滿足每一個邏輯分支都覆蓋了，這是程序?qū)崿F(xiàn)的最基本的兩個角度。在實(shí)際項(xiàng)目中，分支覆蓋比較推薦是100%，除非有一些異常捕獲、預(yù)留代碼、工具生成代碼部分可以放寬一些標(biāo)準(zhǔn)，那么在行覆蓋上，推薦達(dá)到60%到80%的行覆蓋，但是這個也是分不同團(tuán)隊(duì)和開發(fā)的邏輯復(fù)雜度的，也并不是一概而論的一個指標(biāo)。

• 線下缺陷，開發(fā)過程中發(fā)現(xiàn)的缺陷，這里的開發(fā)過程中是在制品中代碼編譯打包后對外提供服務(wù)階段，這個階段的缺陷有致命、嚴(yán)重、一般、建議四個級別，也分按照嚴(yán)重級別分別統(tǒng)計(jì)，這里并不是希望這個過程的數(shù)據(jù)越少越好，這就如同一個測謊指標(biāo)一樣，收集這個數(shù)量重點(diǎn)是為了證明制品過程質(zhì)量保障是行之有效的。

• 線上缺陷，系統(tǒng)上線后系統(tǒng)出現(xiàn)的缺陷，這個階段的缺陷有可能是客戶發(fā)現(xiàn)的也有可能是制品團(tuán)隊(duì)的成員發(fā)現(xiàn)的，同樣采取了線下缺陷的嚴(yán)重程度的級別定義分為致命、嚴(yán)重、一般、建議四個級別，在交付系統(tǒng)過程中，團(tuán)隊(duì)都希望交付出去的系統(tǒng)沒有問題，因此線上缺陷還是一追準(zhǔn)零為目標(biāo)的。

• 發(fā)布失敗率，這是指在發(fā)布新的變更的時(shí)候，無論是人工發(fā)布還是流水線自動發(fā)布，都希望一次發(fā)不成功而不是發(fā)現(xiàn)發(fā)布失敗后再修復(fù)問題后發(fā)布，這里的發(fā)布即包含了一次全量發(fā)布，也包含了灰度發(fā)布，灰度發(fā)布僅僅是提高了客戶感知的系統(tǒng)質(zhì)量，但是并沒有從真正意義上提高發(fā)布成功的次數(shù)，發(fā)布失敗率是由第一次發(fā)布失敗的次數(shù)除以共發(fā)布的版本數(shù)量而計(jì)算得出的，在團(tuán)隊(duì)中當(dāng)然都系統(tǒng)一次交付成功，因此這個指標(biāo)所有的團(tuán)隊(duì)也都在追逐零的目標(biāo)。

• 缺陷探測率，DDP是Defect Detection Percentage的縮寫，這是一個計(jì)算指標(biāo)，是由線下缺陷除以線下缺陷和線上缺陷之和，DDP越高，說明測試者發(fā)現(xiàn)的Bugs數(shù)目越多，發(fā)布后客戶發(fā)現(xiàn)的Bugs就越少，實(shí)現(xiàn)了越早發(fā)現(xiàn)問題解決起來成本越低的改進(jìn)目標(biāo)，達(dá)到了節(jié)約總成本的目的，因此高的缺陷探測率是團(tuán)隊(duì)追逐的目標(biāo)，但是測試在超過95%的探測率，每提升1%的覆蓋率，基本成本翻一倍，因此在具體度量指標(biāo)的選取上還需要更加慎重。

• 線下缺陷解決率，這個是說有測試工程師發(fā)現(xiàn)的缺陷在系統(tǒng)發(fā)布變更前被修復(fù)的比例，通過已經(jīng)修復(fù)的缺陷數(shù)量除以總共發(fā)現(xiàn)的線下缺陷數(shù)量所得的結(jié)果。這個指標(biāo)主要是度量團(tuán)隊(duì)交付制品中遺留一致問題的比例，這個比例是越接近于1越好。

• 線下缺陷遺留數(shù)，這里所指的是一直是問題，但是并不修改，要“帶病上場”的變更，這個數(shù)量主要是為了評估上線風(fēng)險(xiǎn)的，當(dāng)然每個團(tuán)隊(duì)都希望每個迭代這個指標(biāo)是零。

• 平均無故障時(shí)間是指在正常運(yùn)行過程中，系統(tǒng)從一個先前故障到下一個故障之間經(jīng)過的預(yù)期時(shí)間。平均無故障時(shí)間是通過總運(yùn)行時(shí)間除以失敗次數(shù)計(jì)算而來的，主要用于未預(yù)見故障，但不考慮因例行定期維護(hù)或例行預(yù)防性升級而停機(jī)的服務(wù)。平均無故障時(shí)間衡量可用性和可靠性。平均無故障時(shí)間值越高，系統(tǒng)在發(fā)生故障前運(yùn)行的時(shí)間就越長。假設(shè)系統(tǒng)在上線后的100個小時(shí)里，發(fā)生了3次故障導(dǎo)致10個小時(shí)無法對外提供服務(wù)，那么平均無故障時(shí)間等于（100-10）/3，所以平均無故障時(shí)間是30小時(shí)。

• 缺陷密度，常用的千行代碼缺陷率，計(jì)算方法是缺陷數(shù)量除以變更代碼行數(shù)，前面已經(jīng)介紹了這個不好的度量指標(biāo)，這里為什么還要推薦呢？這是因?yàn)樵谡麄€度量指標(biāo)的選取中設(shè)計(jì)了“測謊題”，就是下面的每天向主干合并次數(shù)、發(fā)布分支不可發(fā)布時(shí)間、每人每天修改代碼行數(shù)、每人每天提交次數(shù)等指標(biāo)才會讓這個指標(biāo)變得有意義而且是一個正確方向的度量。

• 平均代碼變更前置時(shí)間，一次代碼變更從提交到部署所需的時(shí)間的總和除以變更次數(shù)，在當(dāng)前自動化流水線的支持下，一般也就需要分鐘級別的時(shí)間就可以完成從提交到部署，一般不會超過30分鐘，如果時(shí)間很長到了小時(shí)級別，那么肯定說明急需改進(jìn)的地方提高效率，這個指標(biāo)也是越小越好，但是肯定不會等于零。

• 平均構(gòu)建排隊(duì)時(shí)間，代碼變更在執(zhí)行構(gòu)建之前的等待時(shí)間，變更提交后排隊(duì)等待構(gòu)建時(shí)間的總和除以提交變更的次數(shù)獲得，這個指標(biāo)高度依賴于組織的規(guī)模，以及同時(shí)并行開發(fā)的特性的數(shù)量。長時(shí)間的排隊(duì)就會造成成本的浪費(fèi)，因此團(tuán)隊(duì)希望這個是指標(biāo)越小越好。

• 每天向主干合并次數(shù)，這個說明了開發(fā)人員完成需求故事卡的速度，這個次數(shù)也并沒有好壞之分，但是還是希望團(tuán)隊(duì)中的數(shù)據(jù)都差不多，這樣可以保證持續(xù)交付變更，這個度量指標(biāo)在很多互聯(lián)網(wǎng)公司也都是小于1的。

• 平均發(fā)布分支不可發(fā)布時(shí)間，這個是指標(biāo)主要是來衡量主干見過多久才可以發(fā)布，也是為研發(fā)效能的提升提供有力的依據(jù)。這個時(shí)間越短說明代碼可發(fā)布的窗口期越長，交付的制品質(zhì)量越好，流水線的流暢度越高。

• 每人每天修改代碼行數(shù)，這種是在衡量團(tuán)隊(duì)平均生產(chǎn)效率，重點(diǎn)是為了其他指標(biāo)的“測謊”而存在，facebook的Android 和 iOS 開發(fā)人員每天每人分別平均生產(chǎn) 70 行代碼和 64.7 行代碼。如果有了大量代碼的增加，那么就要考了是不是有人大面積復(fù)制了代碼，或者加入很多無用代碼。

• 每人每天提交次數(shù)這個指標(biāo)也是一個“測謊題”，facebook的Android 和 iOS 的開發(fā)人員每人每天分別平均提交0.7次和0.8次。

• 制品過程中需求變更次數(shù)，在已經(jīng)進(jìn)入在制品的需求，如果要發(fā)生變更比較會付出一些額外的成本，那么這個次數(shù)可以提升成本浪費(fèi)的次數(shù)。

• 每次發(fā)布包含平均故事卡片數(shù)，這可以衡量團(tuán)隊(duì)每個迭代的制品速率，方便評估團(tuán)隊(duì)的容量。

• 每次發(fā)布包含平均代碼變更行數(shù)，這樣可以評估項(xiàng)目的復(fù)雜程度和維護(hù)難易度，同時(shí)也可以承擔(dān)“測謊題”的作用

• 每次上線補(bǔ)丁次數(shù)，每次發(fā)布版本后到下一次發(fā)布版本前，一共為了修復(fù)缺陷、維護(hù)數(shù)據(jù)，修復(fù)故障等為系統(tǒng)提供補(bǔ)丁的次數(shù)。

• 平均修復(fù)時(shí)間，指修復(fù)系統(tǒng)并將其恢復(fù)到完整功能所需的時(shí)間量。這包括修復(fù)時(shí)間、測試時(shí)間和恢復(fù)正常工作狀態(tài)所需要的時(shí)間周期。平均修復(fù)時(shí)間是通過維護(hù)時(shí)間總和除以維護(hù)次數(shù)得到的。平均修復(fù)時(shí)間用來衡量系統(tǒng)的可用性，時(shí)間越短，說明系統(tǒng)可用性越高。

如上的指標(biāo)，只是一些質(zhì)量度量的常用指標(biāo)，并不是必須的指標(biāo)，那么選取那些應(yīng)該以團(tuán)隊(duì)中適合為主，而不應(yīng)該照本宣科，否則就會出現(xiàn)古德哈特定律和麥克納馬拉謬誤的錯誤了。

超級工程師實(shí)戰(zhàn)營第六模塊【測試模塊】邀請到測試、敏捷及DevOps專家 陳曉鵬老師帶來3小時(shí)大時(shí)段課程分享，主題是《敏捷環(huán)境下的測試自動化實(shí)踐指南》

6月28日（周二）和6月29日（周三）晚上19:30-21:00，線上直播，掃碼立即報(bào)名，精彩內(nèi)容，不容錯過