測試經理小陳，新入職了一家公司，部門總監老王很重視產品質量，希望小陳的加入，能給產品質量帶來提升。小陳呢，在這樣的背景下，被滿懷期待地走馬上任了。過了三個月，老王就問小陳：小陳啊，最近產品質量怎樣啊？提升了沒有啊？小陳呢，內心咯噔一下，心想，我擦，老板查崗了，沒有數據告訴老板質量提升了，是不是證明我來和沒來，沒啥區別哈。我也好歹兢兢業業干了三個月呀，總不能讓老王覺得我沒有價值啊，一定想辦法告訴老王，產品質量提升了，即使沒有提升，也得告訴他，我已經定位到問題了已經調整中了不是。
小陳苦思冥想啊，怎樣證明產品質量呢？老板關心什么呢？經過靈魂的幾大拷問以后，明白了，老板關心的是 產品是否會出問題？
那我得證明，我來了以后，產品出問題的次數少了呀，那么，接下來的事情是：怎么證明呢？
小陳想到，如果上線以后發現的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的影響力了
那么，一個產品的質量度量，到底以哪些維度來平衡呢？