產品質量體系——如何度量產品質量？

        測試經理小陳，新入職了一家公司，部門總監老王很重視產品質量，但願小陳的加入，能給產品質量帶來提高。小陳呢，在這樣的背景下，被滿懷期待地走立刻任了。過了三個月，老王就問小陳：小陳啊，最近產品質量怎樣啊？提高了沒有啊？小陳呢，心裏咯噔一下，心想，我擦，老闆查崗了，沒有數據告訴老闆質量提高了，是否是證實我來和沒來，沒啥區別哈。我也好歹兢兢業業幹了三個月呀，總不能讓老王以爲我沒有價值啊，必定想辦法告訴老王，產品質量提高了，即便沒有提高，也得告訴他，我已經定位到問題了已經調整中了不是。

　　小陳苦思冥想啊，怎樣證實產品質量呢？老闆關心什麼呢？通過靈魂的幾大拷問之後，明白了，老闆關心的是　產品是否會出問題？

       那我得證實，我來了之後，產品出問題的次數少了呀，那麼，接下來的事情是：怎麼證實呢？

       小陳想到，若是上線之後發現的bug比之前更少了，是否是能夠證實呢？小陳巴拉巴拉翻出了近三個月，每次上線之後直接或者間接收到的 prod bug信息，發現，9月 4個，10月4個，11月居然5個。小陳腦子瞬間蒙了，尼瑪，不但不能證實本身質量好了，豈不是證實本身更壞事了？可是本身進來之後三個月愈來愈忙了啊，有時候都加班到10點11點才能回去。

　　小陳是一個矜矜業業的小陳，通過一番冷靜的思考之後呢，以爲，不能這樣，咱們仍是要看看每月迭代的工做量的。小陳就翻出了，這幾個月開發過程當中bug總數，發現，9月份 210；10月，320；11月，570。開發這幾個月的開發質量，怎麼辣麼差，我得和老闆說道說道。小陳轉念一想，一來盲目告狀，不利於團隊協做，第二個，開發的質量真的會連續幾個月忽高忽低嗎？咱們不能以開發過程當中的數聽說明問題。他琢磨着，若是開發中bug總數多，是否是出現prod bug的機率也就高呢，小陳仍是一個理智的小陳。

　　

月份	9月	10月	11月
prod bug數量	4	4	5
開發過程當中bug數量	210	320	570
prod bug/開發過程當中bug數量	1.9%	1.25%	0.88%

　　

　　因而乎，小陳羅列了以上的一個表格，算了下prod bug/開發過程當中bug數量，按照每月的這個趨勢，這個結果，小陳仍是挺滿意的。他心滿意得地給這個公式取名爲：bug逃逸率。

　　　　所謂bug逃逸率，就是迭代過程當中，未發現的bug的機率。

　　　　bug逃逸率=prod bug/開發過程當中bug數量。

　　小陳，志得其滿地想，終於能夠和老闆彙報了。這個時候，有同事反饋，產品訪問出現50X錯誤。影響線上全部用戶了，小陳的心啊，翻江倒海，數聽說不上話，事故是真的啊，別想了，先解決問題吧。和devops的同事一塊兒一頓研究，發現數據庫磁盤滿了，沒有及時擴容，devops那裏也沒有提早收到告警。趕忙的吧，devops的同事一頓騷操做，問題解決了。看來，光看bug數量也是不行的，事故頻率也得考慮進來哈。看來，質量工做光靠我一我的的力量是不行的……

　　小陳再次陷入了沉思，腦子盤算着幾個問題：

1. 生產bug的統計，誰去統計呢？回憶殺不靠譜哈，要是我沒統計到，別人發現了的怎麼辦？打臉哈
2. 老闆對我指望很高，質量提高，偶爾殺出個事故來，咋整？一個重大抵得上100個prod bug的影響力了

 小陳，仍是個想作事情的小陳，咱們未完待續吧~