Bug多是灾难，Bug少是惊悚片

上周上班时候，听到对面一个小姐姐惊呼：“我的天呐，这个需求怎么测下来没几个bug，我好慌！”

其实不少人应该都体验过这种感觉，而且对于开发来说心里更加没底，跟测的时候焦急地等待，却没等来几个bug，总感觉上线要爆雷。

为什么没bug反而让人不安？

bug的存在，属于是软件开发的物理定律了。需求理解偏差、代码逻辑遗漏、边界条件漏考虑、环境差异等等任何一个环节出错，bug就冒出来了。

几十个文件的修改，却没bug，不符合规律。

1. 是不是根本没测到？

可能一直在测happy path，异常、边界等情况压根没覆盖。

2. 环境覆盖不够？

测试环境的数据太干净了？生产环境什么数据都有，脏数据、历史遗留数据的问题在测试环境可能根本无法暴露。

3. 测的代码真的是新代码吗？

别笑，真有可能。对于一些不太影响功能的技术改动，测完发现开发代码忘合了/忘记发布了，根本没有测到新代码。

4. bug还在潜伏期？

数据一致性问题、内存泄漏等，基本上都要流量上来才会炸。

bug多代表有问题，bug少不代表没问题。

可能是什么原因导致测试阶段bug少？

我整理了一些自己遇到的情况。

1. 需求理解不到位

首先是开发的需求理解就没到位，然后如果测试跟开发共振了而不是和产品共振，那就要出事了。

2. 测试覆盖不充分

测试用例本身就有问题，异常、边界、权限、并发的场景根本没覆盖。

3. 开发自测质量高

有些开发同学很靠谱，自测非常充分。这种时候，如果时间够，测试要往深了挖，进一步降低风险。

4. 业务逻辑太简单

这个一般很容易判断，如果业务逻辑很简单，没bug倒是正常。不过不能因为简单就放松验证，最简单的改动也可能炸。不过，有条件的团队对于非常简单的业务逻辑可以推开发自测。

5. 环境和数据不够真实

测试时候也许一切正常，上线后发现有难以预料的数据状态，导致爆雷。根据我的经验，这种情况与其耗费大量精力去覆盖特殊数据，不如多思考生产环境出问题后如何快速恢复。

6. 测试人员选择性忽视

有时候业务压力大，时间紧，小bug就不提了；偶现bug难以复现，就不追了；开发说这个不算bug，想想马上下班了，就算了。

到底是真没bug还是假平安？

1. 做一次覆盖回溯

“扔掉”用例，把需求文档捞出来，逐条确认，都测全了吗？每条功能点的异常路径、边界值等也都测全了吗？

2. 代码diff分析

看看代码变更了哪些文件哪些方法，看看调用方有哪些，改动的影响范围都覆盖了吗？现在有 AI 了，就更方便了，可以让 AI 直接出一个分析。当然，别忘了还可以直接找开发问：“这次的改动，影响范围是什么？”

3. 做一下“轻量故障注入”

狂点按钮、疯狂滑动、同一个请求并发10次等等，看看系统会怎么反应。

4. 找其他人轻度测试一下

自己很容易陷入自己固定的思维模式里，找另一个人帮忙花个10-30分钟轻度测试一下，也许能发现很容易暴露却一直没发现的问题。

总结

“零bug”的测试结果，先假设“我没测到”，而不是“真的没问题”。宁可多花点时间补测，不要上线后报警。