測驗經理小陳，新入職了一家公司，部門總監老王很重視產品質量，希望小陳的加入，能給產品質量帶來提升，小陳呢，在這樣的背景下，被滿懷期待地走馬上任了，過了三個月，老王就問小陳：小陳啊，最近產品質量怎樣啊？提升了沒有啊？小陳呢，內心咯噔一下，心想，我擦，老板查崗了，沒有資料告訴老板質量提升了，是不是證明我來和沒來，沒啥區別哈，我也好歹兢兢業業干了三個月呀，總不能讓老王覺得我沒有價值啊，一定想辦法告訴老王，產品質量提升了，即使沒有提升，也得告訴他，我已經定位到問題了已經調整中了不是，
小陳苦思冥想啊，怎樣證明產品質量呢？老板關心什么呢？經過靈魂的幾大拷問以后，明白了，老板關心的是 產品是否會出問題？
那我得證明，我來了以后，產品出問題的次數少了呀，那么，接下來的事情是：怎么證明呢？
小陳想到，如果上線以后發現的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數量也是不行的，事故頻率也得考慮進來哈，看來，質量作業光靠我一個人的力量是不行的……
小陳再次陷入了沉思，腦子盤算著幾個問題：
- 生產bug的統計，誰去統計呢？回憶殺不靠譜哈，要是我沒統計到，別人發現了的怎么辦？打臉哈
- 老板對我期望很高，質量提升，偶爾殺出個事故來，咋整？一個重大抵得上100個prod bug的影響力了
那么，一個產品的質量度量，到底以哪些維度來平衡呢？
轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/2452.html
標籤：其他
上一篇：cenos7搭建gitlab
下一篇：領導一個技術開發團隊