产品质量体系——如何度量产品质量？

        测试经理小陈，新入职了一家公司，部门总监老王很重视产品质量，但愿小陈的加入，能给产品质量带来提高。小陈呢，在这样的背景下，被满怀期待地走立刻任了。过了三个月，老王就问小陈：小陈啊，最近产品质量怎样啊？提高了没有啊？小陈呢，心里咯噔一下，心想，我擦，老板查岗了，没有数据告诉老板质量提高了，是否是证实我来和没来，没啥区别哈。我也好歹兢兢业业干了三个月呀，总不能让老王以为我没有价值啊，必定想办法告诉老王，产品质量提高了，即便没有提高，也得告诉他，我已经定位到问题了已经调整中了不是。

　　小陈苦思冥想啊，怎样证实产品质量呢？老板关心什么呢？通过灵魂的几大拷问之后，明白了，老板关心的是　产品是否会出问题？

       那我得证实，我来了之后，产品出问题的次数少了呀，那么，接下来的事情是：怎么证实呢？

       小陈想到，若是上线之后发现的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的影响力了

 小陈，仍是个想作事情的小陈，咱们未完待续吧~