什么？线上出bug了？我慌得一皮!!!

从事IT互联网的人都知道，bug是程序员和测试人员最不喜欢面对的东西，很多人对于软件中出现bug这个事情，第一想到的就是测试人员的问题，因为他们都觉得这是测试人员没有测试出软件中存在的bug，导致后续软件上线问题浮出水面。

其实，出现bug这种情况是由很多原因造成的，不仅仅是测试人员一方的问题，切记不要把锅全部甩给测试!出现bug在所难免，也并不可怕，可怕的是互相甩锅推卸责任，导致bug一直留在那里造成其他更大的负面影响和损失。

你可以善良，但你的善良要有原则

壹

有一次，那一带停了电。女子只好点燃了蜡烛，没一会儿，她听到有人敲门，一看才知道原来是邻居家的小孩子，只见他紧张地问：“您家有蜡烛吗？”女子心想：他家竟穷的连根蜡烛都没有吗?千万别借给他，免得被他们依赖了。

于是，大声吼一声说：“没有！”正当她要准备关门时，小孩展开关爱地笑容说：“我就知道你没有，所以，妈妈叫我拿一支给你。”女子被感动地热泪盈眶，一下把小男孩抱在了怀里。　　

让善良温柔以待

贰

软件中bug的出现还有其他原因：比如产品原型不清楚，有歧义。导致产品经理跟客户之间是有歧义的，导致后期交付到项目方手里，被当作了bug。

另外，在项目开发方面，开发人员开发完后并没有先自测，测试在测试回归阶段会因为一些隐秘的东西测不全。再或者是后期更改需求了，开发者加进去了，但是测试并不知道，造成未能及时测试出bug等。

各种各样的因素都会导致bug的出现，有时候bug的出现是整个团队的问题造成的。

那我们应该怎么处理软件上线后暴露的bug呢?

一、即时反馈即时响应

不管是技术团队，还是运营客服团队，在软件上线或提供给客户使用后，都应该定期的去跟踪软件是否在正常工作，如果有客户遇到问题(可能是一个bug)应该及时的做好问题的收集、分析，并作出正确的反馈处理。

问题不可怕，可怕的是这个问题一直留在那里，可能用户多用几次怒火中烧，直接把它打入冷宫，更甚者给软件提供组织带来巨大的负面影响和经济上的损失。

善良很贵请不要随意浪费

叁

二、即时分析即时处理

当收到问题后，应该及时反馈给研发团队，确定是否为BUG，如果非BUG的，那确定问题产生的原因，并让问题对接人知晓后反馈和客户。如果确定为BUG后，则需要对bug的严重等级进行评级。

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

我坚信每一个这些类型的软件缺陷都需要被进一步解释。而且，那是我们现在的确要做的事情：

1.功能缺陷

　　.如果软件是根据客户提供的需求开发的，那么它必须满足需求。功能的任何偏离被录为功能缺陷。

　　根据严重性和优先级功能缺陷被分类。

　　如下是重要的考虑因素：

　　高严重性和高优先级的软件缺陷通常会影响软件的日常使用。这些类型的软件缺陷必须在软件上线前被修复。没有例外。

有时候功能缺陷由于不是原始需求的一部分被划分为需求变更。这些需求变更在软件上线后对业务运作是必须的，因此必须被实现。

软件缺陷的划分和功能缺陷的优先级划分是由UAT协调人员和用户以及需求分析人员共同完成的。通常，客户有一个关于多少比例的软件缺陷可以存在的上线标准。

　　2.性能以及负载缺陷：

　　性能缺陷是软件上线的重要考虑因素，尤其是软件被外部用户使用。

如果用户量达到一定数目时，软件运行很慢。用户会因为加载耗时而避免使用软件。如果软件太慢会导致业务流失，用户会转而使用竞争对手的软件。

有时候，非客户面对的部分程序也会影响软件性能。

　　比如: 如果每天结束时要运行一个批处理任务，程序的响应时间因此而受到影响。那么批处理的性能也是一个考虑因素。

　　· 软件性能通常用屏幕响应时间来衡量，当特定数量的并发用户使用系统时性能对用户而言就必须考虑。

　　· 性能测试用工具来完成，比如LoadRunner,WebLoad,Neoload等

　　· 特定负载和未来预测负载的软件性能通常记录在合同里，在软件上线前必须要证明。

　　· 用户很少用到的部分程序页面延迟到系统上线后再评估。

　　· 软件性能也依赖于部署软件的硬件类型和网络条件。

　　· 性能测试在特定硬件里使用性能测试工具在UAT阶段完成，性能缺陷以类似于功能测试的方式来追溯。性能缺陷也会被划分优先级，达成一致以符合上线标准。

　　· 通常在UAT阶段的性能和负载测试在用户做完功能测试并且达到功能缺陷交付标准后完成。

3.可用性缺陷:

　　------------

　　软件开发应该易于终端用户使用，比如用不同的快捷键、快捷方式，最少的屏幕切换、换页。软件必须灵活并且直观。

　　如果在移到合适的屏幕之前有太多页面切换，用户通常会对使用这个软件失去信心。

　　· 软件构建前可用性准则被创建。软件必须遵循这些准则。

　　· 软件开发时也可能有工具限制，在软件被终端用户使用前必须克服这个问题。

　　· 用高可用性软件，一个终端用户可以输入常规软件5倍的数据。

　　· 软件的外观和感受必须是新鲜的，同时法律问题必须在软件上线前被列出来。

　　· 很多时候软件可用性顾问被任命来确保用户可以流畅地使用软件。

　　· 必须和软件程序一起交付的文档也必须尽可能合法使用且严格遵循可用性准则。

　　· UAT/外部测试人员录入的可用性缺陷像功能缺陷和性能缺陷一样也被划分了优先级，必须符合上线准则。

4.安全性缺陷:

　　软件的安全性是一个热点问题，因为软件程序可能被黑客攻击，客户敏感数据可能被窃取。

　　因此，可信赖的软件不应该允许甚至一个非常专业的黑客以不合适的权限进入程序。

　　· 安全性测试是在UAT阶段以特定输入来确保软件不被攻击。

　　· 安全性测试由合法黑客来尝试攻击软件以检查软件是否脆弱。

　　· 所有安全性缺陷必须在系统上线前被修复。

　　· 安全性也意味着登录、不同权限的用户（内部和外部）使用程序的不同部分，以及创建和批准数据。

5.与外部软件系统交互性缺陷:

　　通常，一个要在客户方部署的软件程序必须与任何已有软件交互。

　　比如:

　　打印系统，他们已经在使用中或者可能是一个外部系统比如账单程序或者资料荧屏系统。将要部署的软件程序应该与这些外部系统无缝交互。对这些系统的所有输入和输出应该同步工作。当前技术包含了移动应用程序和必须与之兼容的不同软件平台。

　　检查外部系统的交互性应该在系统测试阶段和UAT阶段被广泛执行。必须有一个满意的上线准则。

6.报表缺陷:

　　来自软件程序的报表是表明程序内部数据统计的一种关键方式。

　　比如:所有账单相关数据必须符合借贷额度。

　　· 软件中所有数据必须协调。软件里的这种数据协调通过报表来展现，必须达到期望。

　　· 如果数据从旧系统迁移到新系统是当前版本发布的主要目的，那么更要关注报表数据。

7.数据迁移缺陷:

　　如果一个旧系统要被新系统取代，旧系统里的数据要移到新系统。新系统应该如需求定义的一样支持迁移过来的数据。

　　所有旧数据可能在新系统里不可用；然而旧数据的截图会在新系统中可用。按约定，这个数据应该可用。

　　注意:上述列表并不详尽。根据程序类型，可能有更多的东西需要验证或者并不是上述所有都适用。因此，对软件的全面理解，业务目的，用户期望以及架构或硬件依赖对创建综合的上线准则是必须的。

善良的本性在世界上是最需要的

三、问题处理完毕，查找问题原因

BUG出现的原因是什么，可能有以下几种情况：

1、测试环境无法重现

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

解决方法：尽量完善测试方法，尽可能模拟仿真线上测试环境，以及增加上线后的复查确认测试。

2、漏测

A、测试用例裁剪过度：错误预估优先级或者时间过于紧迫裁剪了用例

解决方法：在后续版本或者其他项目启动时重新评估测试时间，要求专家介入对优先级进行评估，避免此类事件再次发生。

B、测试用例执行期间遗漏：由于测试人员疏忽造成测试用例执行遗漏

解决方法：调查该名测试人员的整个测试过程的工作情况，并随机抽测其他模块，对该名测试人员进行综合评估，给出结论，是因为疏忽漏测，还是因为负责模块过多漏测，还是有其他原因。应该及时反馈给测试经理，并对该测试人员后面的工作进行调整和处理。

C、测试用例覆盖不全：需求模糊导致的，由于用例评审的不严格造成的;中途需求变更造成的;由于某些其他因素造成的

解决方法：找到原因，并进行记录，在以后的项目或者下一版本改进。并且要及时增加、补充用例。

3、程序的质量问题

出现bug，肯定是因为程序出了问题。黑盒测试是很难发现逻辑和代码层面的所有问题的。所以也应该从开发的角度去评估bug出现的原因，可能是因为开发粗心疏忽导致的，也可能是开发人员蓄意隐藏出现的。

解决办法：首先确定bug出现的原因，如果是因为粗心，如错误的大小写、错误的参数变量导致的，应该让对应开发人员做出整改。如果是深层次的逻辑问题导致的，那应该在后续项目和版本中加大代码的走查测试。

4、产品实际使用超出想象，导致的bug

这应该是整个团队的问题，应该吸取经验。规划一款新领域、业务的产品，对这个领域可能没有深入的理解，那么可能会导致一些意想之外的BUG。比如我经历过的无人值守停车场的物联网项目，主要依赖于摄像头进行车牌识别然后进行车辆的放行。因为周期短，并且地域的限制没做太过周全的测试，一开始也没有暴露问题。但是实际使用中，发现摄像头外壳因为没有考虑导热设计，导致在高温暴晒下出现摄像机宕机。在阴暗潮湿环境下，车辆如果角度不正对摄像头，导致识别错误等。你能说这是测试的问题，或者开发的问题，或者硬件的问题，工艺的问题。只能是大家经验不足，是团队所有人的问题。

5、产品上线后，在某种操作系统下出现兼容性的问题，是谁的责任？

主流的系统，比如Win10，有兼容性的问题，肯定是测试的问题，没有覆盖主流的系统。后面应该明确需要兼容的系统并进行测试。

历史系统，比如XP，有兼容性问题。但是规格明确写明不支持XP。那么有可能是市场调研、需求的问题，没有搞清楚产品的实际客户和特性。也有可能是用户手册的问题，没有提示不支持XP，导致错误的安装。还有可能是软件的问题，没有做保护，检测到是XP系统，就应该停止安装并提示系统版本太旧。而不是一路走到黑，安装完出现一些兼容性的问题。这都是需要后期进行考虑的。

四、追责

一般来说，上线的BUG不能完全归咎于某一个人，或者是归咎于测试部、开发部，这是一个团队合作的过程，出了纰漏谁也逃不掉，应该及时止损，吸取经验教训，在今后的版本或者项目中规避类似的问题出现。当然，如果真的是某个人的责任，那么项目组就应该给予警告，让其后续吸取教训杜绝类似问题出现。

五、避免同样的错误

第一次出现的问题处理好了，这事可以过去了，但是出现过的问题最好不要再次出现，否则一而再再而三的出现同样的问题，会让boss和领导怀疑整个团队或个人的能力及责任感。所以，记得汲取教训，避免以后跳进同一个bug坑里。

脚本：猪圈子

图片：猪圈子

来源：猪圈子