上面说线上 BUG 多，让测试出优化方案，我该怎么做？（我并不觉得多啊）
回顾了下 23 年，
线下 BUG 未统计（存储项目空间太多，未进行统一管理）
线上总记录的 BUG 数为 246 条，其中未完结 11、完结 178、挂起 18、取消 39
完结的 BUG 中：
客服反馈创建 86 条（P1：2 条、P2：23 条、P3:53 条、
二级故障：4 条、三级故障：3 条、四级故障：1 条）
技术内部创建 92 条（P1：1 条、P2：8 条、 P3:72 条、
四级故障：2 条、未分类：9 条、）
ps:本公司无 P0，P0 算故障
你自己看看你写的，除了你们组的谁能看懂实际代表的概念
线上 bug 多少算少：0 肯定算，但是很难做到
线上 bug 多少很难只用数字来计算，如果你出现了最高级别的 bug，那 1 个也是多的；如果你都是非功能性 bug，那一年几十个也不算多
给个比较宽泛的参考就是无重大问题出现，功能性问题小于 10，非功能性问题不重要
ps：这里的问题严重程度也要充分考虑对客户的影响程度
问就是 0。
恒温
回复
我们会分为是发布当季 BUG/历史 BUG
BUG 类型也有分需求设计问题，技术设计问题，功能遗漏，逻辑错误等等
总的问题会归在历史 - 逻辑错误的 BUG 上，情况会分为 2 中：
1.未做改动，发布很长时间后暴露的问题
2.修改后，被暴露出来的
原因：
1.功能现状看不清，都基于需求和个人对业务的掌握能力做事情
2.执行流程不规范（用例不进行评审）、开发不做技术方案
针对原因 1：要求测试按功能做用例沉淀（执行效果不理想，干完就存本地不上传不分类）
针对原因 2：用例评审覆盖 100% 版本，技术方案评审覆盖 100% 版本
执行一段时间后监管力度不够，又会变成原来状态，但是也不可能一直靠人来监管吧
有一些很小很小的版本也要做评审？
脑壳疼的测试人
回复
质量是最容易腐败的东西，持续的人治是逃不掉的，只是过程中可以进行提效。建议流程线上化，数字化，然后形成一个质量模型，按周或者月来给大团队来进行反馈。
处理这类问题的时候我们一般是跨一层解决，上面说线上 bug 多，你要知道是谁告诉他的就是谁在跟上面施压，你做这个方案你上面要拿来给别人交代的
比如是老板或者客服头头反馈，那么出的方案就要忽悠住老板或者客服头头，为什么说忽悠，这只是方案不是结果，无非是看了觉得靠谱，又不是定期存款
客服他不关心你 bug 什么等级优先级他也没必要懂，能减少他的工作量他做的舒服就会少比比，反过来用户高频使用场景问题少他的投诉是不是少
如果是老板，那就要你适当的问你的上面透点口风，是弄的专业点还是高大上就看具体了
从你的描述中就知道你太实诚了，外加你们的领导可能不是技术出身，看不懂 P0 P1 P3 的级别分类意义。你这 bug 数不多，其实流程啥的基本不用改，你只需要把你现有的工作模式报上去忽悠一下，然后下次总结时这样发，依然用你现在的情况：
线上遗留 BUG 数为 0 条-（标红加粗，字体放大）
全年线上无重大 bug 发生（标红加粗，字体放大）
测试组及时跟进解决 bug 数 178 条
- 用户使用体验轻微问题遗留记录 11 条，逐步跟进完善中
脑壳疼的测试人
回复
对于这种问题，常用的做法是你建立一个数据看板，每日自动统计你关注的这个口径（至于需要多少开发量和工作量，得看你们内部系统是怎么样的）。目的是在周会或者什么会议上放出这个数据，表扬头部做得好的，批评尾部做得差的。这样运作一段时间平均水平就会逐渐上来。关键是背后得有老板支撑，老板也要偶尔关注到这个数据，否则也很难做好，因为大家都觉得无所谓。
别人说线上 Bug 多，我觉得就是 2 个问题：要么就是测试没发现；要么就是 Bug 管理没做好
如果是测试过程中没发现的话，就去找原因，为啥测试过程中没发现
如果是测试过程中发现了，觉得不重要，那就是 bug 管理没做好，那就做好 Bug 的分类和整理
测试过程中除了要记录功能逻辑 Bug，还要记录体验不好的 Bug，分类整理好，做好记录，做好优先级严重程度的分类；
发布前把所有的 Bug 跟团队过一遍，确认要改的发布前必须改掉，不改的测试报告做好说明，暂时不修复的原因；
产品上线了，有用户吐槽有 Bug，若刚好有些 Bug 是测试过程中记录了的，团队统一认同暂时不修复的，那就把测试报告搬出来
如果是用户发现了，测试没发现的，就做好记录，完善用例，总结经验，一步步改进测试策略
测试新人
回复
那投入时间是肯定的了，没有什么问题不投入就会自己好，人越多的团队这种方式就越好使。
有数据之后能自证问题，也能持续给老板反馈（现在怎么样，做了改进后怎么样，重点抓哪些地方改）。所以搞测试，本身也要把不少时间在质量运营上。
脑壳疼的测试人
回复
你开头摆的数据对于我们这些外人来说没法理解，思路是先去拆分数据分析，可能你已经清楚怎么做了，为了回答完整我还是补一下：
- 先回捞数据，佐证是不是线上 Bug 是不是真的多（为什么别人感知到多？直觉是客诉反馈多而且有比较严重的级别）
- 假设就是客诉多给了别人线上 Bug 多的感觉，那逐个 Bug 分析归类，找出 Top 原因，常规操作吧
- Top 原因中，对应要什么改进就能解决这些问题。改进动作项对应的评价指标是啥？比如你前面说到【用例评审覆盖 100% 版本，技术方案评审覆盖 100% 版本】，那就得想办法去衡量好，怎么搞要看你们的研发系统是啥，支不支持这么干，或者有没有数据 api 给你们去拉数据。这里没法给你共苦或指标建议，工具依赖于你们的研发系统，指标依赖于你的改进事项
- 建设好持续的度量，同步好这个事情，定期放出数据让大家保持关注。
这些思路我看你的回答都是有的，应该没什么问题。【上面想要我做的是先分析出问题，然后针对问题去考虑动作。直接做动作会被喷】这个是必然的，不然就是盲目在做事情。分析问题是为了能论证出你做的动作是能解决问题，而不是靠直觉或者拍脑袋
86 个 bug，这系统还能用？
