软件开发人员解决bug的方法？

每个软件开发人员都会遇到bug，那bug是什么呢?当软件开发人员能够测试标准后发掘的问题成为bug。那么解决bug的方法有哪些呢?电脑培训建议首先软件开发人员需要掌握怎样快速定位，之后修改程序就可以了。

一、断点调试：

1、打断点：打断点、清除断点。

2、启动调试模式的两种方式：一是通过debugas启动调试程序二是在程序运行时，DDMS视图下选取要调试的程序，启动调试模式。

3、调试：可使用F5、F6、F7、F8快捷键。

4、通过watch查看成员变量。

二、打印调试：

？打印调试对于循环、JNI等代码段很有效，循环时越发管用。

三、目视法：

？适用codereview，但毕竟人为的，多打一个点，都会出现问题，不过代码量少的时候很好用。

四、自动化测试：

？Android程序开发自动化测试工具有：monkey、Robotium、Appium、云端测试。

五、排除法：

？当遇到随机问题时可使用排除法检验，先大概定位问题点，再用代码一点点注释，查看变化，渐渐缩小问题范围。

整个流程分为两大类：测试环境和线上环境。

把两种环境又分为两种情况：web和Java、APP。

所有bug，被指派的开发人员在两个小时确定。不是自己的bug，找各组leader，另行指派。

线上发现Major以上bug，停下手头工作，两个小时以内进行解决。

若bug3天之内没有修复完成，请点解决，解决方案选择“ 延期处理 ”，并备注原因，说明解决时间。

bug级别

严重程度由高到低依次为：

1.critical

2.block

3.major

4.normal

5.minor

critical：是说项目中某一块功能因为这个bug而导致测试无法进行下去，此critical级别，该等级问题出现在不影响其他功能测试的情况下可以继续该版本

block是说项目中有闪退情况，崩溃情况。此为block级别，出现这种级别的问题此版本停止测试

major：是说一些功能没有实现，但是不影响使用，功能菜单缺失，但不会影响系统稳定。此为major，这种问题应该合理安排时间进行修改

normal：是说界面等UI问题显示错误，比如字体大小，颜色，间距等问题。此类问题在测试初期较多，优先程度较低；在测试后期出现较少，应及时处理）

minor：是说界面、性能缺陷，建议类问题，不影响 *** 作功能的执行，可以优化性能的方案等。

测试环境

web、Java

1、测试人员发现bug

2、测试人员确认bug

3、测试人员提交bug（major以上@相关人员）

4、相关开发人员禅道确认bug

5、开发人员对bug进行修复

6、开发人员点击已解决

7、开发人员把修改的问题给测试人员进行演示

8、开发人员发申请测试环境的邮件 ，说明修改了哪些问题，邮件写明WIKI网址，通知相关人员， 并登记WIKI ---- （201X.XX测试）

9、相关的 运维人员 部署测试环境，并 回复邮件，登记WIKI ---- （201X.XX测试）

10、测试人员复测bug

11、测试人员关闭bug，并在 WIKI“ 测试人员确认 ” 进行 登记 ---- （201X.XX测试）

12、测试人员有问题重新激活。

13、重新激活后从第4条继续走流程。

线上环境

web、Java

1、测试人员复现bug

2、测试人员提交bug

3、开发人员确认bug

4、开发人员修复好后，点击已解决

5、开发人员把解决的bug给测试人员进行演示，演示无误后。

6、修改bug的 开发人员 写 申请发布测试环境的邮件， 并将相关内容 登记到WIKI ---- （201X.XX测试）

7、相关的 运维人员 部署测试环境，并 回复邮件 ，并在 WIKI 登记 ---- （201X.XX测试）

8、测试人员test环境复测bug，复测无误后，在 WIKI “测试负责人”进行 登记 ---- （201X.XX测试）

9、测试人员test环境进行回归测试

10、回归测试无误后，测试人员在 WIKI 进行发布 线上登记 ，等 周二、周五 正常流程，发 申请线上的邮件 ，告知相关运维人员，并在 WIKI 登记 ---- （201X.XX线上）

11、 运维人员 发布线上， 回复邮件 ，并在 WIKI 登记 ---- （201X.XX线上）

12、 测试进行 线上测试， 回复邮件说明结果，并在WIK I “测试人员确认结果 ” 进行 登记 -----（201X.XX线上）

13、如需 紧急发布 ， 测试人员 发布申请线上 紧急发布邮件 ，并说明紧急发布原因，同时 WIKI登记 ---- （201X.XX紧急发布）

14、相关的 运维人员回复邮件 ，并在 WIKI 登记 ---- （201X.XX紧急发布）

15、 测试人员 进行线上测试， 回复邮件说明结果， 并在WIK I “测试人员确认结果 ” 进行登记-----（201X.XX紧急发布）

当别人向程序员报一个bug，直到程序员把bug完整的修复好，整个过程是一个怎样的经历？

下面用一个维修工的故事类比一下，相信会很多程序员都会感到似曾相似！

假如你是一个电灯维修工程师。

一天晚上，有人想你反馈了一个bug：“18楼会议室的灯亮着，你要去把它熄灭”。bug的备注里还写到：这个bug很简单，你只需要按一下开关就可以关掉了，你应该在5分钟内修复这个bug。

你上到了18楼的会议室，灯的确是亮着，但是房间里没有这盏灯的开关。

怎么办？这时候你打算安装一个开关，然后通过开关把灯关掉，完美！

这个时候设计师会跟你说，它会破坏房间的美感。另外，墙壁是混凝土做的，你得有合适的工具和其他人的配合才能安装。但此时此刻，你找不到这些工具和人员来帮你。

如果没有这些辅助工具，安装开关，保守估计要2天时间。但是他们希望你只花5分钟就把灯关掉，因为他们害怕CEO哪天会经过18楼会议室，问为什么灯是亮着的，怕被问责。

5分钟过去了，你的手机响个不停，他们反复问你为什么灯还亮着，为什么按一下开关就能关掉这么简单的事你要弄这么久？

为了尽快解决问题，你实在没办法，所以，你设法进到了 18 楼走廊的天花板里，找到了会议室灯的电线，一刀切断，灯关掉了，问题解决了，你告诉了他们：你把先切掉了，灯就关了。

你的手机也安静了，但好景不长。

他们又有了新的疑问：线被你切掉了，如果哪天我们想开启会议室的灯，怎么办？因此，他们要求你把这盏灯的线牵引到地下室去，因为那里有开关，等他们需要开灯的时候，就通知你去地下室帮他们开灯。

你抗议这个荒谬的解决方案。但是你的上司说：“是的，这个解决办法不理想，但是现在是唯一的解决方案”。

这个时候你心里骂了他们一句：SB！

现在你要么按照他们的“荒谬”要求来做，要么辞职另谋高就，但你想了想，一旦到了新的工作环境，也难免会遇到这种荒谬的事情。

你咬咬牙，把18楼会议室的线牵引到了地下室，你发现已经有10几条线是从其他地方牵引过来的，这种荒谬的做法，你不是第一个做。你小心翼翼地把线牵引号，并尽人事地给左右地线做好了标记。

终于，你回到了你的办公桌，把bug标记成：“已修复”。

可刚过不久，测试员又重新开启了bug，并备注说：“会议室还是亮着的”。

你回到 18 楼的会议室。灯是灭着的。你返回办公桌前，关闭了 bug，注明你已经亲自检查过了。

测试员再次重新开启了 bug：“房间还亮着”。再次亲眼确认灯泡灭着后，你将情况汇报给了上司。

他建议你去地下室检查电线和开关。你抗议说你正直盯盯地看着灯，它就是灭着的。 “我知道，但去检查一下。这样一来你就可以告诉测试员你确认了所有流程。”

你叹了口气，前往地下室检查了电线和开关。它们不可能以任何你能理解的方式导电。 你向测试员反馈，你检查了电线和开关，它们不可能通电，你正看着灯泡，它是熄灭的。

“我不是指灯泡，”测试员说。 “bug 里描述的是房间里的光。房间现在仍然不够暗，你应该拉下窗帘。“你回应说窗帘的事不归你管。测试员不相信你说的话，亲自去询问你的领导。

经过一番激烈的讨论之后，他们终于同意将窗帘的问题提交给其他部分去解决，太好了，灯光的问题暂时到此为止了，bug可以顺利地关闭掉了。

现在，CEO突然决定要去18楼会议室开会。你接到通知，要赶去地下室，开启18楼会议室的灯。

你以最快的速度去到了地下室，连上电线，按下开启按钮。回到了办公桌，此时你的手机有了26个未读消息：

“出问题了，灯还是熄灭的！”

“有个问题，灯没有亮。”

“为什么这么久还没有亮灯？”

......

而最新的一条消息则是：“没事了，灯是亮的，辛苦了哈”。

---