智者千虑必有一失，在软件上更是如此。
我们都知道，软件中的bug是不可能杜绝的，哪怕是测试时间较充裕的情况下，更何况往往研发组织预留给测试团队的时间并不充足。所以，当软件发布到线上后，在所难免会出现bug。
出现bug不可怕，可怕的是互相推责，导致bug留在那里造成更大的负面影响和损失。那我们应该怎么处理软件上线后暴露的bug呢？
出现这种情况后，应该快速响应并作处理
1、即时响应是关键
不管是技术团队，还是运营客服团队，在软件上线或提供给客户使用后，都应该定期的去跟踪软件是否在正常工作，如果有客户遇到问题（可能是一个bug）应该及时的做好问题的收集、分析，并作出正确的反馈处理。问题不可怕，可怕的是这个问题一直留在那里，可能用户多用几次怒火中烧，直接把它打入冷宫，更甚者给软件提供组织带来巨大的负面影响和经济上的损失。
2、问题的即时分析及处理
当收到问题后，应该及时反馈给研发团队，确定是否为BUG，如果非BUG的，那确定问题产生的原因，并让问题对接人知晓后反馈和客户。
如果确定为BUG后，则需要对bug的严重等级进行评级。如果是轻微或者不会对用户使用造成太大问题的，可以作为优化项放到后面版本迭代时进行修复。反之严重问题，就应该找到bug所属模块的程序负责人，确定解决方案，并及时发布对应的补丁包或者给出解决措施。同时，问题对接人一定要给用户进行反馈或说明，包括对解决方案的简单说明。
3、问题处理后，我们就应该去查找问题出现的原因了
BUG出现的原因是什么，可能有以下几种情况：
1）测试环境无法重现：可能是线上的环境造成的BUG或者是测试环境无法模拟的情况
解决方法：尽量完善测试方法，尽可能模拟仿真线上测试环境，以及增加上线后的复查确认测试。
2）漏测
A、测试用例裁剪过度：错误预估优先级或者时间过于紧迫裁剪了用例
解决方法：在后续版本或者其他项目启动时重新评估测试时间，要求专家介入对优先级进行评估，避免此类事件再次发生。
B、测试用例执行期间遗漏：由于测试人员疏忽造成测试用例执行遗漏
解决方法：调查该名测试人员的整个测试过程的工作情况，并随机抽测其他模块，对该名测试人员进行综合评估，给出结论，是因为疏忽漏测，还是因为负责模块过多漏测，还是有其他原因。应该及时反馈给测试经理，并对该测试人员后面的工作进行调整和处理。
C、测试用例覆盖不全：需求模糊导致的，由于用例评审的不严格造成的；中途需求变更造成的；由于某些其他因素造成的
解决方法：找到原因，并进行记录，在以后的项目或者下一版本改进。并且要及时增加、补充用例。
3）程序的质量问题
出现bug，肯定是因为程序出了问题。黑盒测试是很难发现逻辑和代码层面的所有问题的。所以也应该从开发的角度去评估bug出现的原因，可能是因为开发粗心疏忽导致的，也可能是开发人员蓄意隐藏出现的。
解决办法：首先确定bug出现的原因，如果是因为粗心，如错误的大小写、错误的参数变量导致的，应该让对应开发人员做出整改。如果是深层次的逻辑问题导致的，那应该在后续项目和版本中加大代码的走查测试。
4）产品实际使用超出想象，导致的bug
这应该是整个团队的问题，应该吸取经验。规划一款新领域、业务的产品，对这个领域可能没有深入的理解，那么可能会导致一些意想之外的BUG。比如我经历过的无人值守停车场的物联网项目，主要依赖于摄像头进行车牌识别然后进行车辆的放行。因为周期短，并且地域的限制没做太过周全的测试，一开始也没有暴露问题。但是实际使用中，发现摄像头外壳因为没有考虑导热设计，导致在高温暴晒下出现摄像机宕机。在阴暗潮湿环境下，车辆如果角度不正对摄像头，导致识别错误等。你能说这是测试的问题，或者开发的问题，或者硬件的问题，工艺的问题。只能是大家经验不足，是团队所有人的问题。
5）产品发布后，在某种操作系统下出现兼容性的问题，是谁的责任？
主流的系统，比如Win10，有兼容性的问题，肯定是测试的问题，没有覆盖主流的系统。后面应该明确需要兼容的系统并进行测试。
历史系统，比如XP，有兼容性问题。但是规格明确写明不支持XP。那么有可能是市场调研、需求的问题，没有搞清楚产品的实际客户和特性。也有可能是用户手册的问题，没有提示不支持XP，导致错误的安装。还有可能是软件的问题，没有做保护，检测到是XP系统，就应该停止安装并提示系统版本太旧。而不是一路走到黑，安装完出现一些兼容性的问题。这都是需要后期进行考虑的。
4、最后说说追责
一般来说，上线的BUG不能完全归咎于某一个人，或者是归咎于测试部、开发部，这是一个团队合作的过程，出了纰漏谁也逃不掉，应该及时止损，吸取经验教训，在今后的版本或者项目中规避类似的问题出现。当然，如果真的是某个人的责任，那么项目组就应该给予警告，让其后续吸取教训杜绝类似问题出现，否则，就应该考虑他的去留了。