作为一个软件开发人员，如何高效地解决BUG，有没有方法，有没有捷径，说没有也是没有，但也有一定的流程可以一个新人理解如何面对一个BUG，如何解决BUG才是不浪费时间，不走弯路。
作者：Younger Liu，
本作品采用知识共享署名-非商业性使用-相同方式共享 3.0 未本地化版本许可协议进行许可。
1 理解问题
好的测试人员在提报BUG时，会包括如下信息：
1) 标题：主要简明扼要地描述了Bug；可以让人快速了解问题
2) 测试环境：什么环境下发现的，软件和硬件系统，什么版本，如果需要，还应注明哪个、硬件平台
3) 前提条件：用户测试步骤前的系统环境信息
4) 测试步骤：在执行什么操作时，发现的问题
5) 实际结果：在测试软件的过程中，软件所表现出来的特征或者行为
6) 预期结果：软件设计所要求达到的结果或者目标
当然也有不负责任的测试人员，仅仅留下简单的问题现象的描述。
无论是哪种情况，BUG定位人员都要找到并理解上述描述的BUG六要素。
注意：
1．测试人员观察到的实际结果，认为是不符合预期的。有的时候可能是测试人员对需求的理解和开发人员不一致，而提出了bug。这个时候需要找产品经理来确认，判断是不是一个BUG。
2．不要完全相信测试人员的描述。对于测试人员来说，系统就是个黑盒，她做出的一些主观判断可能并不精确，这就需要开发人员批判的看待bug单中的信息，分离出有价值的信息。
只有梳理正确的BUG六要素，才能明确自己要解决的是什么，要达到什么结果。
2 重现问题
BUG定位人员已经理解BUG 六要素后。搭建与问题软硬件版本相同的环境，进行问题复现。
梳理出最窄的重现步骤。
1. 要保持软硬件环境和项目版本相同
(a) 环境差异: 可能B版本的代码在A版本的环境也会出问题，但是在开发环境可能就不能复现；
(b) 代码变更：也许是其他的代码引起的bug，B版本时其他开发已经修改，此类可以归纳为相关联功能引起的bug；
(c) 两版本进行复现的前置条件及步骤已不同。
2) “疑难杂症”要通力配合复现
在自己负责的那部分代码确定完没有问题，这时候就需要考虑到接口，是否在接口数据处理上的问题，就需要其他开发人员配合。
3) 保持关注
通过各种的努力，仍然不能复现的bug一定是优先级不高的，那就再评估重要度，若通过项目组决定不影响版本发布，就密切关注此bug，在发布后验证时也重点关注下。
而且该bug不能关闭，依次往以后版本中顺延，并且每轮测试时都要尝试再次复现。那何时可以关闭呢？也许3，5个版本发布后，没有出问题就可以决定关闭它了。
3 寻找问题根源
重现问题后，就可以通过调试手段来定位问题所在。不同的问题有不同的调试手段
1．打断点：这可能是最方便的调试手段了。
2．打日志
……
不够什么样的调试手段，一定是通过可以观察的现象，给提示信息。
了解问题发生的根本原因，而非表面原因或中层原因。
4 设计解决方案
问题重现了，通过调试手段也寻找到了问题根源，下面就是考虑如何解决问题了。这里就考察你的老本行，设计的能力了。
1．如果修改老系统，一定要了解清楚之前的运作原理，才能设计方案。
2．对与影响比较大的解决方案，建议进行解决方案评审，请其他同事把把关，并邀请测试人员。
开发人员的老本行——设计能力
5 方案实施(修改问题)
问题根源找到了，设计方案也有了，到了表现程序员基本能力——编码开发的时候了。
1. 代码开发完成，必须经过代码检视。
2. 进过开发自测
程序员的基本能力——编程开发
6 方案测试
按照步骤2的最窄复现步骤，进行多轮测试，验证问题是否真正的解决。
特别注意的一点就是，任何一个bug的解决，一定会经历以上几步，如果没有按照上述几步来做，就失去了做事的条理性。
作者：Younger Liu
本作品采用知识共享署名-非商业性使用-相同方式共享 3.0 未本地化版本许可协议进行许可。