上海育创带你Bug程序调试

《上海育创带你Bug程序调试》由会员分享，可在线阅读，更多相关《上海育创带你Bug程序调试（5页珍藏版）》请在金锄头文库上搜索。

1、上海育创带你 Bug 程序 调试 复杂系统总是源于简单系统的演化， 软件开发 作为一个复杂的系统，从开始 的编写 到 最 后一次 的 运行 ， 不是 一蹴而就 的 过程 ，不论你 如何 费尽心机， bug 总是对我们一往情深 ， 原因就是： Because when you fix one, you create two. 虽然 编写高质量的、没有 bug 的程序，是每位程序员所追求的目标。但随着软件规模越来越大，功能日趋复杂， 可能存在的 bug 就越多， “ 没有 bug” 这一目标 也就 变得越来越困难。 当然， 如果一个软件不增加新功能，后续工作就是只要一有用户上 报 bug 就修复掉

2、，那么最后做到几乎没 bug 甚至完全没有 bug 是可能的。 比如，你写一个 “ hello world” 是几乎不可能搞出 bug 来的。 问题是，这样的模式存在极大的浪费 本来可以加入新功能的 ， 新功能往往也 就 意味着新bug 。 那么现在问题来了 不停地加入新功能（同时修复 bug），不停地修复 bug 和撒手不管哪个收益更高？ 在这里我们先划分下 Bug 缺陷等级 和 缺陷优先级 。 1、 Bug 缺陷等级 这个划分也比较灵活，有分三级 、 四级 的 ，也有分五级的 ，这里我把他分为了五级： （ 1） 致命 ： 一招毙命的缺陷，使你的系统 无法运行，有造成数据泄漏的安全性问题。

3、（ 2） 严重 ： 可以引起易于纠正的异常情况、可能引起易于修复的故障或对产品外观难以接受的缺陷。 （ 3） 一般 ： 指不影响产品的运转和运行、不会成为故障起因，但对产品外观和下道工序影响较大的缺陷 （ 4） 轻微 ： 轻微缺陷是指对产品外观和下道工序可能会有轻微影响的缺陷 （ 5） 建议 ： 增加用户使用体验的建议性问题。（一般情况下，建议也为做为缺陷的一种 ，这个跟系统的类型与需求有关） 2、 缺陷优先级 当问题处理人员在面对许多问题需要处理进，就需要问题进行优先级排序。我们做事情的安排，操作 系统有处理进程等都在使用着优先级 。 表 1 优先级的划分 严重程度 低 中 高 紧急 优先级

4、 延迟处理 正常排队 优先处理 紧急处理 Bug 的严重程度和优先级是含义不同但相互联系密切的两个概念，它们从不同的侧面描述了软件缺陷对软件质量和最终用户的影响程序和处理方式。 一般地，严重程序高的软件缺陷具有较高的优 先级。严重程度高说明缺陷对软件造成的危害性大，需要优先处理，而 严重程序低的缺陷可能只是软件不太尽善尽美，可以稍后处理。 但是： 严重程度高 的 优先级不一定高： （ 1） 如果某个严重的软件缺陷只在非常极端的 条件下产生，则没有必要马上处理。 （ 2） 如果某一个软件缺陷，需要重新修改软件的整体架构，可能会产生更多的潜在缺陷，而且软件由于市场的压力必须尽快发布，此时即使缺陷的

5、严重性很高，是否需要修正，需要全盘考虑。 严重程度 低的 优先级不一定低 ： 如果是软件名称或公司名称的拼写错误，虽然说其属于界面错误，严重程度不高，但其关系到软件和公司的市场开解，必须尽快修正。 因此， 对于 极为重要 的，例如涉及国防安全时 ，功能相对简单的程序才会符合 “零 bug” 的要求。 但一般来说，在当今的社会生活中，不停地修复 bug 这个选项，只有在对新 功能需求极低，维护收益极高的前提下才是划算的，一般的的性能优化，平时接触还是很 多 的。 虽然知道这些道理，但我们的 程序员发现 Bug 时 ， 内心 活动还是 蛮 丰富的。对多数程序员而言，情绪的好坏与 代码是谁写的、 b

6、ug 是 被谁发现 的直接 呈正相关的 关系 。 1、他人写的代码有 bug （ 1） 问题 重新指派 ， 找他人代码中的 bug 时 “好艰难啊，这大撒比不会自己发现 bug 吗？” （ 2）发现他人 代码有 bug 时 “卧槽，这货会操作吗？ 写出这么个烂代码，幸亏有哥这样神一样的存在才发现，哥真是救世主！ ” 2、 自己写的代 码有 bug （ 1） 运行很久 的代码 被 别人发现 bug 时 傲娇者：“，这个程序运行很久了，是不是真有 bug 啊？会不会是你弄错了啊？可以重现么？什么！可以重现！肯定问题也不大，要不用户早投诉了，瞧你那惊慌失措的样子，真是没见过世面。” 认命者：“好吧，

7、你给我重现一下，我看看是什么问题？” 自己发现 bug 时 心虚 者： “他妹的 ， 怎么又来 bug 了，还让不让人活了 ？ ” 傲娇者：“这个 bug 隐藏的很深啊，还好哥犀利犀利，没有被 QA 们发现，我得默默修正之，再赞美下自己，最后再鄙视下 QA 们。 ” （ 2） 新上线程序 被别人发现 bug 时 “这个程序刚上线还处于调试阶段，有 bug 很正常，谁的程序没 bug，连操作系统都有 bug。” 自己发现 bug 时 “哥就是犀利，自己开发自己测试，看测试那帮撒比什么也不会干，这么明显的 bug 都测不出来，真是一群废物！” 当然，这 些 只是笑话，真发现 bug 时，还是要认真

8、对待的，否则， 重现 当年 “因为一个 bug ， 炸弹 在 关键 点被引爆 ，直接导致 公司损失 400 亿” ，到那时程序员能喊冤吗 ？ 程序员最主要的职责 就是学会如何处理 Bug，以及优化算法提高程序性能。因此，该调试时，还是不容马虎的。 那 如何调试 bug 呢 ？ 先 推荐 两 本书 Debugging Windows Programs 和编程精粹 。 Debugging Windows Programs 里面写了一些关于调试心理学的 内容 ，现在节选一章内容：1、 错误调试的五部曲 伊丽莎白 -库伯勒 -罗斯（ 1969 著作“ On Death and Dying” ，大陆译本

9、叫论死亡和濒临死亡）观察到病人面对死亡等灾难时有着不同的反应，她把这些反应划分为五个阶段，这 五个阶段也就是错误调试的态度。 （ 1） 否认（ Denial）：这是一个 Bug 吗？是我的吗？ （ 2） 愤怒（ Anger）：测试人员为什么挑刺。 （ 3） 讨价还价（ Bargaining ）：是否在下个版本修正。 （ 4） 沮丧（ Depression ）：我不合适做程序员 （ 5） 容忍（ Acceptance ）：下个版本也许就消失了 只有勇于面对错误 ， 才能成为一个有尊严程序员而生存下去。 2、 修复 bug 时 ，第一步就是重现问题，然后你得确保修复之后，问题能够彻彻底底地消失。这

10、样一个简单的规则可以确保你不会误将“非问题”当作 “是问题”，并确保解决方案真的能够奏效，最好能够做成可以快速故障排除、修复 bug 和部署修复的系统。 因此， 正确调试的五部曲 应该是这样的： （ 1） 确定错误的存在 :通过调试代码，单元测试，联合调试，集成测试确认问题。 （ 2） 收集错误信息：收集问题的原因，不要放过任何细节。 （ 3） 分析错误原因：通过分析收集的错误信息，定位问题的原因。 （ 4） 消除错误：通过修正代码解决问题 （ 5） 验证相关的修改：验证修改是否解决了问题 编程精粹 书中内容主要针对 C 语言 的 ，但其中的思想对目前的各主流语言编程也完全适用 ： 关于 调试

11、， 一个 至关重要的 态度问题 ： （ 1） 不要责怪测试员为你发现了错误。 （ 2） 错误几乎不会“消失”， （ 3） 马上修改错误，不要推迟到最后 （ 4） 尽量编写和测试小块代码。 （ 5） 修改错误要治本，不要治表。 （ 6） 养成好的编码习惯和调试习惯，建立自己的原则，并且坚持。 （ 7） 决不允许同样错误出现两次 最后，分享 程序员处理 bug 的一些经验 吧： 1、 如何积累解决 bug 的经验？ （ 1） 首要的也是 最重要的一条是 ： 善于记录和解决问题方案。 遇到 bug 并解决了，详细 地 把 bug 表现描述出来，并把解决经过写出来，做成笔记，就算 以后不翻看，这样至少

12、会加深你对类似 bug 的印象，下回就会知道类似的问题如何解决 ？ （ 2） 程序执行缓慢，首先应该检查数据结构是否合理？ 然后检查遍历这个数 据结构的遍历语句是否写复杂了？ 能不能把遍历降低 ？ （ 3） 遇到 bug 可以与周围的同事或朋友进行探讨，别人的思路可能会给你帮助，也可能别人曾经遇到过类似的问题。 2、 其它 一些 bug 解决经验以及测试方面的分析： （ 1） 输入的内容，是否有最短或最长数据限制； （ 2） 可能会产生多个数据的，尽量试试非常多的数据进行测试； （ 3） 写遍历的时候，特别是多重遍历，考虑是否会产 生无限的遍历计算（非常大的计算量）； （ 4） 做数据库删除的

13、时候，考虑数据删除条件是否完全正确，修改和查询同样如是； （ 5） 存入数据的时候，验证数据格式，以及考虑换行或特殊字符会造成前端 json 解析错误，此处不仅仅是指 html 层面的代码或 JavaScript 的代码造成注入漏洞； （ 6） 更改了程序之后，尽量考虑周到有哪些地方会受到影响，最好是在写注释的时候注明有哪些地方会产生调用数据操作的时候一定要验明权限，验证当前用户是否有权限做修改，包括当前数据是否属于当前用户等； （ 7） 对一个数据操作之前，不要凭着想法， 觉得是对的，一定要用程序验明是否存在，并对验明的结果进行用户提示或者是报错处理；此处分为用户存数据到数据库之前验证，另一

14、个就是取数据并进行操作的时候进行验证，特别是没有规定用户必填，但是在显示或者操作时候却需要用到的数据，一定要验明； （ 8） 浮点数的计算丢失精度的问题，这个做稍微复杂的项目会遇到，此处把参加计算的数据都进行浮点型格式化并把得到的结果按需求四舍五入或其他方式取值，这种做法一般不会造成精度丢失； （ 9） 两个数参与除法运算，必须检查除数是否会存在为 0 的情况，这种业务逻辑一般可能涉及到计算用户好评率 ，计算用户平均评星的情况，虽然这个除数不能为 0 是小学的知识点，但是开发过程中可能会漏掉监测，造成程序运算错误。 结语 ： 以上内容都是脱离工具直达核心的干货，希望在大家处理 bug 时起到一定的辅助作用吧。