测试经理小陈，新入职了一家公司，部门总监老王很重视产品质量，希望小陈的加入，能给产品质量带来提升。小陈呢，在这样的背景下，被满怀期待地走马上任了。过了三个月，老王就问小陈：小陈啊，最近产品质量怎样啊？提升了没有啊？小陈呢，内心咯噔一下，心想，我擦，老板查岗了，没有数据告诉老板质量提升了，是不是证明我来和没来，没啥区别哈。我也好歹兢兢业业干了三个月呀，总不能让老王觉得我没有价值啊，一定想办法告诉老王，产品质量提升了，即使没有提升，也得告诉他，我已经定位到问题了已经调整中了不是。
小陈苦思冥想啊，怎样证明产品质量呢？老板关心什么呢？经过灵魂的几大拷问以后，明白了，老板关心的是 产品是否会出问题？
那我得证明，我来了以后，产品出问题的次数少了呀，那么，接下来的事情是：怎么证明呢？
小陈想到，如果上线以后发现的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的影响力了
那么，一个产品的质量度量，到底以哪些维度来平衡呢？