已经上线的系统怎么还有bug

软件测试面试中被问的问题有时候会是形形色色的，不会局限在你会哪些测试技术？测试流程是怎么样的？

就比如你会遇到这种问题：已经上线的系统怎么还有bug？

这就是一个比较细节、考察你既往经验积累、总结的一个问题了。

对于这个问题的回答，我们可以从三个层次展开：一个是如何保护好自己，二是及时复现并跟进缺陷的修复，三是基于缺陷的内因分析，实现持续改进。

一、优先选择保护好自己

从事IT行业的人都知道，测试人员发现一个bug会异常惊喜，但是漏掉一个bug又异常恐慌。

上线后的系统被客户发现了bug，就有被投诉的风险，对公司影响也会比较大。

出现这种问题，项目负责人的第一个想到的肯定是测试人员的问题（测试是软件质量交付的人），因为他们都觉得这是测试人员没有测试出软件中存在的bug，导致后续软件上线问题浮出水面。

其实，出现bug这种情况是由很多原因造成的，不仅仅是测试人员一方的问题，切记不要把锅全部甩给测试，自己也不要太任性的去接锅！

出现bug在所难免，也并不可怕，可怕的是互相甩锅推卸责任，导致bug一直留在那里造成其他更大的负面影响和损失，当然作为测试工程师，也不能无故背锅，遇到这种问题，适时撇清关系，保护好自己也是人之常情，条件反射之举。

软件中bug的出现还有其他原因：

• 产品原型、需求不清楚，有歧义，导致后期交付到项目方手里，被当作了bug

• 在项目开发方面，开发人员开发完后并没有先 自测 ，测试人员在回归阶段会因为一些隐秘的东西测不全

• 后期更改需求了，开发者加进去了，但是测试并不知道，造成未能及时测试出bug的问题

• 上线的系统软硬件环境与测试环境还是有差别的

• 运维人员做的配置和测试环境不相同导致的

总之，上线后系统的BUG不能完全归咎于某一个人或者是归咎于测试部、开发部、产品部等，我们是一个团队合作的过程，出了纰漏谁也逃不掉，应该及时止损，吸取经验教训，在今后的版本或者项目中规避类似的问题出现。

当然，如果真的是某个人的责任，那么项目组就应该给予警告，让其后续吸取教训杜绝类似问题出现。

二、快速响应缺陷修复

1、即时响应

在软件上线或提供给客户使用后，如果发现有bug，我们应该第一时间进行响应（不管是不是，客户是上帝），问题不可怕，可怕的是这个问题一直留在那里，给系统开发公司带来巨大的负面影响和经济上的损失。

2、快速复现bug

当收到问题后，测试人员应及时复现，确认是否为BUG：

• 如果是BUG的，及时提交给开发，并督促开发尽快修复，最后反馈给客户。

• 如果非BUG的，那分析 误报 的原因（用户和开发团队对需求的理解不一致），并让问题对接人知晓后及时反馈给客户。

3、复盘bug

如果是bug，需要对其进行复盘，对bug的严重等级进行评级，如果是轻微或者不会对用户使用造成太大问题的，可以作为优化项放到后面版本迭代时进行修复。反之严重问题，就应该找到bug所属模块的程序负责人，确定解决方案，并及时发布对应得补丁包或者给出解决措施。

同时，问题对接人一定要给用户进行反馈或说明，包括对解决方案的简单说明。

三、分析bug内因、持续改进

BUG已经处理完了，剩下的就是我们要进行bug事件（为什么会出现这个bug的事件）出现的内因分析了，避免再次出现类似问题，做到持续改进，常见的原因如下。

• 时间压力：在项目开发周期紧张的情况下，测试团队没有足够的时间展开全面测试，漏测在所难免。

• 技能和经验不足：测试人员可能缺乏足够的技能和经验发现有深度的bug。

• 沟通不畅：缺乏与开发团队和其他相关团队的有效沟通，导致需求理解不一致、业务把控不准确。

• 工具和资源不足：没有合适的工具和资源来支持深入的BUG探索。

• 缺乏反馈机制：没有及时的反馈机制，测试人员可能难以得知bug分析结果和解决方案（开发写的）。

• 没有进行缺陷根本原因的分析，只是关注大量的表面问题，难免有遗漏。

• 环境差异：可能是线上的环境造成的BUG或者是测试环境无法模拟的情况。

• 漏测：原因有好多，用例对模糊需求的覆盖不全、执行时候过度筛选漏测、时间因素、测试人员能力差异因素等

• 软件质量原因：这个也很常见，开发新手出现问题的概率就非常大，导致软件整体质量偏低（缺陷集群现象）

• 需求理解不透彻：规划一款新领域、业务的产品，对这个领域可能没有深入的理解，那么可能会导致一些意想之外的BUG

• 兼容性问题：主流、非主流系统、浏览器的兼容性问题导致

• .....

总之，第一次出现了问题，按照上述三步处理好了，这事就可以过去了。

这样就有效避免同类型的问题，一而再、再而三的出现。

记得汲取教训、对bug进行内因分析，避免以后跳进同一个bug坑里。