上海育创带你Bug程序调试.pdfVIP

上海育创带你Bug 程序调试 复杂系统总是源于简单系统的演化，软件开发作为一个复杂的系统，从开始的编写到最后一 次的运行，不是一蹴而就的过程，不论你如何费尽心机，bug 总是对我们一往情深，原因就 是： Because when you fix one, you create two. 虽然编写高质量的、没有bug 的程序，是每位程序员所追求的目标。但随着软件规模越来越 大，功能日趋复杂，可能存在的bug 就越多，“没有bug ”这一目标也就变得越来越困难。 当然，如果一个软件不增加新功能，后续工作就是只要一有用户上报bug 就修复掉，那么最 后做到几乎没bug 甚至完全没有bug 是可能的。比如，你写一个“hello world ”是几乎不可 能搞出bug 来的。 问题是，这样的模式存在极大的浪费——本来可以加入新功能的，新功能往往也就意味着新 bug 。 那么现在问题来了——不停地加入新功能（同时修复bug ），不停地修复bug 和撒手不管哪 个收益更高？在这里我们先划分下Bug 缺陷等级和缺陷优先级。 1、Bug 缺陷等级 这个划分也比较灵活，有分三级、四级的，也有分五级的，这里我把他分为了五级： （1）致命：一招毙命的缺陷，使你的系统无法运行，有造成数据泄漏的安全性问题。 （2 ）严重：可以引起易于纠正的异常情况、可能引起易于修复的故障或对产品外观难以接 受的缺陷。 （3 ）一般：指不影响产品的运转和运行、不会成为故障起因，但对产品外观和下道工序影 响较大的缺陷 （4 ）轻微：轻微缺陷是指对产品外观和下道工序可能会有轻微影响的缺陷 （5 ）建议：增加用户使用体验的建议性问题。（一般情况下，建议也为做为缺陷的一种， 这个跟系统的类型与需求有关） 2 、缺陷优先级 当问题处理人员在面对许多问题需要处理进，就需要问题进行优先级排序。我们做事情的安 排，操作系统有处理进程等都在使用着优先级。 表1 优先级的划分 严重程度 低 中 高 紧急 优先级 延迟处理 正常排队 优先处理 紧急处理 Bug 的严重程度和优先级是含义不同但相互联系密切的两个概念，它们从不同的侧面描述了 软件缺陷对软件质量和最终用户的影响程序和处理方式。 一般地，严重程序高的软件缺陷具有较高的优先级。严重程度高说明缺陷对软件造成的危害 性大，需要优先处理，而严重程序低的缺陷可能只是软件不太尽善尽美，可以稍后处理。 但是： 严重程度高的优先级不一定高： （1）如果某个严重的软件缺陷只在非常极端的条件下产生，则没有必要马上处理。 （2 ）如果某一个软件缺陷，需要重新修改软件的整体架构，可能会产生更多的潜在缺陷， 而且软件由于市场的压力必须尽快发布，此时即使缺陷的严重性很高，是否需要修正，需要 全盘考虑。 严重程度低的优先级不一定低： 如果是软件名称或公司名称的拼写错误，虽然说其属于界面错误，严重程度不高，但其关系 到软件和公司的市场开解，必须尽快修正。 因此，对于极为重要的，例如涉及国防安全时，功能相对简单的程序才会符合“零bug ”的 要求。但一般来说，在当今的社会生活中，不停地修复bug 这个选项，只有在对新功能需求 极低，维护收益极高的前提下才是划算的，一般的的性能优化，平时接触还是很多的。 虽然知道这些道理，但我们的程序员发现 Bug 时，内心活动还是蛮丰富的。对多数程序员 而言，情绪的好坏与代码是谁写的、bug 是被谁发现的直接呈正相关的关系。 1、他人写的代码有bug （1）问题重新指派，找他人代码中的bug 时—— “好艰难啊，这大撒比不会自己发现bug 吗？” （2 ）发现他人代码有bug 时—— “卧槽，这货会操作吗？写出这么个烂代码，幸亏有哥这样神一样的存在才发现，哥真是救 世主！” 2 、自己写的代码有bug （1）运行很久的代码 1被别人发现 bug 时—— 傲娇者：“我操，这个程序运行很久了，是不是真有bug 啊？会不会是你弄错了啊？可以重 现么？什么！可以重现！肯定问题