你们公司 bug 的衡量标准是什么

作者小趴菜

---

水或

---

文章源自玩技e族-https://www.playezu.com/246906.html

说起 BUG，我相信各位作为大佬无论作为测试，或者测开，或者研发等各位大佬，都不陌生，但是在自己当前的团队中，你们是如何度量和处理 BUG 的呢？作为菜鸡的我在团队中是这样做的？文章源自玩技e族-https://www.playezu.com/246906.html

质量度量的维度

• 进度度量
• 需求度量
• 代码行度量
• 缺陷度量
• 测试覆盖率度量

BUG 评估标准及处理方案

BUG 分类标准及评估标准

测试 BUG 按照严重等级分为严重、普通、轻微、优化四类，按照 BUG 类别分为功能，界面、数据处理、流程、优化建议、性能、常识七类，对应各种 BUG 情形如下文章源自玩技e族-https://www.playezu.com/246906.html

严重 BUG：

由于程序造成系统崩溃、自身程序崩溃、网络中断、系统内存或文件资源耗尽、破坏或丢失数据库数据文章源自玩技e族-https://www.playezu.com/246906.html

• 功能类：需求功能未达到或与需求功能明显不一致的
• 数据类：数据处理造成后台数据冲突或不一致的
• 数据类：程序运行过程中出现数据丢失的或后台数据乱码的
• 流程类：分支流程不完整或相悖造成分支流程处理错误的，无限循环类的
• 性能类：造成数据库连接资源耗尽的（非大并发量下的情形）

普通 BUG

• 功能类：查看、查询、分页、排序显示数据不正常的
• 界面类：页面编译错误、JavaScript 错误、跳转错误、出现 javaException 页面
• 界面类：页面超时未响应、数据显示不完整或错位、页面未鉴权、页面显示乱码
• 界面类：输入校验不完整及造成的数据处理错误、页面操作提示信息与实际不符
• 性能类：处理大数据量出现程序错误的
• 常识类：明显违背正常习俗习惯的

轻微 BUG

• 功能类：重复或多余的功能，操作不直观、易用性不够
• 界面类：界面排版混乱、控件排列和格式不统一、焦点控制不合理、页面文字和提示信息表达 不清晰、不完整或错别字的

优化 BUG

• 凡以上未提及的不影响正常使用的情形

BUG 应急处理解决方案

• 确认问题，开发流程处理不当还是测试不到位等等，先排除人为原因导致的失误
• 稳住客户：告知客户要稍后回复他们
• 严重程度、影响范围：跟开发沟通，大概定位问题，影响到的相关功能
• 应急方案：是否需要回滚代码，判断修复时间
• 所需人员，资源, 是否需要外援
• 开始修改
• 遇到难点，及时反馈
• 改好以后，并测试成功，及时上线
• BUG 跟进
• 最终结果通知客户
• 复盘总结

缺陷的质量度量指标

统计缺陷相关的度量指标，无外乎几个目的，想知道我们目前的项目或产品的质量怎么样。可能对关心项目和产品的领导来说，只是单纯主观的描述质量好或者不好肯定是不能被接纳的，因此需要量化一些指标。文章源自玩技e族-https://www.playezu.com/246906.html

细化来说大概分为上线前的过程指标以及上线后的结果指标。文章源自玩技e族-https://www.playezu.com/246906.html

• 上线后的指标简单粗暴，即产品上线以后有没有出事故或者线上 Bug，对用户的直接影响是什么。那么事故和线上 Bug 也会定级、定严重程度，以方便衡量具体的质量影响，例如 10 个微小型的用户体验类 Bug，对比一个影响 SLA 的线上事故。肯定是后者影响更大。
• 上线前的过程指标可能会比较多，例如测试人员本身发现的一些问题的个数和严重等级，这里体现出来测试过程是否充分以及代码本身还会不会有一些潜在的坑或者问题。以及问题个数跟开发工作量或者代码行数的占比。一般来说一个需求或功能代码量越大，工作人日占用越多，也代表他越复杂，因此可能引入的 Bug 也相对来说会多一些。当然这个也不是完全可靠，例如一个刚毕业的新开发人员跟资深开发架构师相比，个人的 Bug 率（Bug 个数/工作人日）肯定不是同一个数量级的。因此行业有句黑话叫做，你不是在开发功能，而是在开发 Bug

线上指标

• 事故个数及等级：一般来说等级根据影响情况分为 P0、P1、P2，P3 等。具体细节定义可根据项 目、产品最核心价值来定，例如服务不可用时间、例如影响线上请求的数量等来定级。文章源自玩技e族-https://www.playezu.com/246906.html

• 线上 Bug 率：核心就是看线上发现的 Bug 等级和个数对应于某段时间开发出来的软件代码的占比 关系。个人实践算法，在某个时间周期内（半年或者三个月）线上 Bug 个数乘以对应的 Bug 重要 等级对应的分值（严重 10 分、普通 8 分、轻微 5 分、优化类 3 分）然后除以开发工作人日。文章源自玩技e族-https://www.playezu.com/246906.html

  线上 BUG 率计算公式为 BUG 数 *BUG 等级分/研发工作日/项目数文章源自玩技e族-https://www.playezu.com/246906.html

• 线上漏测率：分析一段时间内发现的所有线上 Bug，如果跟测试过程强相关的，例如没有用例覆 盖、或者有用例覆盖但是未执行，这种属于漏测问题，将漏测问题除以总的线上问题数，就可以 得出线上漏测率。如果跟用例没有强相关，可能是设计层面或需求层面的问题、或者是运维或配 置引入的不可测试出来的问题则认为非漏测。也有可能有另外一种定义，就是拿线上 Bug 除以线下 Bug，以代表即使测出来这么多线上 Bug，仍然有未评估到遗漏到线上的问题比例。这个指标最终 是为了改进我们的测试过程质量，将测试用例设计弥补的更加完善，在不影响上线效率的情况下 尽最大可能挖掘软件质量方面的 Bug。文章源自玩技e族-https://www.playezu.com/246906.html

线下指标

• 线下 Bug 率 - 项目维度：跟线上 Bug 率算法差不多，在某个时间周期内（一个季度或者一个月）线 下 Bug 个数乘以对应的 Bug 重要等级对应的分值然后除以开发工作人日。如果不想算的那么繁琐 也可以单纯统计某个时间周期内服务或项目维度线下 Bug 的个数。如果线下 Bug 比较多，那么一 定程度也代表了代码质量不佳，也很可能造成部分遗漏问题到线上。这个指标经过基线对比或观 察一段时间的波动能反映出一个项目或产品的质量变化。 BUG 率计算公式为 BUG 数 *BUG 等级分/研发工作日/项目数
• 线下 Bug 率 - 个人维度：可以按个人的线下 Bug 个数乘以对应的 Bug 重要等级对应的分值除以工作 人日统计，也可以统计某个时间周期内个人维度线下 Bug 的个数。可以小范围项目维度统计，用 于横向对比，发布数据时需要考虑到开人员个人的情绪，也可以只面向项目的管理者发送该数 据。 个人 BUG 率计算公式为 BUG 数 *BUG 等级分/研发工作日/项目数
• 线下 Bug 跟测试类型或阶段的关系：根据线下 Bug 的发现阶段或标签可以分类统计个数，例如发 现阶段可能包含功能测试、专项测试、演练验收、交付验收等。一个比较健康的项目测试活动应 该是 Bug 逐步收敛，如果演练验收、交付验收发现的 Bug 反而比功能测试和专项测试还多，那么 就要重点关注并改进。

个人实践落地经验

实践背景

本人生产与 96 的小白鼠，今年跳槽踏入一家小公司，公司主要做 TOB 的业务，公司有 A,B 两个测试团队
A 团队负责标准产品研发的测试
B 团队负责对客相关的交付测试
本人就在 B 团队做一个小管理，复制组建 B 团队和 B 团队交付的质量建设等系列工作

在这里请大家考虑 3 个问题：
上面科普这么多缺陷方面的指标，也说了统计的一些规则，建议的公式等
1. 那么如何降低质量度量的人工成本呢？
2. 统计周期定在多久统计一次合适呢？
3. 线上线下人肉统计和工具统计比例如何分配呢？

• 极端考虑，如果统计周期为一天，那么每天就会疲于收集和统计数据，对比效果也不好，因为很 难说今天比昨天的度量数据变好了就说明软件质量就变好了，因为很有可能今天就没有在做测试 执行的活动，或者今天运气比较差，一下子来了好几个线上 Bug，也不能说明今天的软件质量就比 昨天的差。建议线下的指标统计周期跟项目交付周期关联，例如有些服务一个月一个版本，有些 一个 月两个版本，或者一周一个版本，都比较合适作为度量数据拉取的一个时间周期。而线上 的指标 可以更加长一些，可以考虑跟绩效评估周期强相关，例如三个月或者半年为一个度量周 期，可以 更加有参考性，也可以将部分指标作为项目整体打分或者个人绩效的一些参考指标

• 工具/平台，如果所有的统计工作都人肉完成，那么有两方面的弊端，一个是统计成本高，另外一 个就是数据不完全可靠，有可能存在偏差。建议使用平台或者工具来完成统计。一方面需要源数 据填写准确，基于 Jira 和禅道以及公司内部 ASANA 或者其他缺陷管理平台的字段要准确。另一方 面平台和工具需要支持 可以定时拉取数据以及人工触发拉取数据并且自动计划预设好的各种指 标

  举个栗子

  研发单月背负 BUG 指标为 60，超过 60，需要给出说法，低于 60 什么都不干，修复 BUG 就行
  例如公司最近一个项目单月统计如下

  项目维度统计

研发人员月度统计

BUG 相关统计 bug 统计

总结

总体来说，无论线上线下出现问题后应先把问题都收集起来，把原因了解清楚，责任人分清楚。总之：“应急方案” 处理得很好，先稳住客户或者用户，告知客户或者用户要稍后回复他们，然后去找技术同事解决，而且解决的方法的确可以缓解了一时之急，遇到问题的时候不要慌张就好了。急的问题就先应急，然后再跟踪问题