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

  • 3
  • 0
  • 约4.61千字
  • 约 5页
  • 2017-07-05 发布于天津
  • 举报
上海育创带你Bug程序调试.pdf

上海育创带你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 啊?会不会是你弄错了啊?可以重 现么?什么!可以重现!肯定问题

文档评论(0)

1亿VIP精品文档

相关文档