bug的概念和分类

大家好，我是十一。

前面篇我们都在讲测试用例设计的案例、设计方法、工具。本篇呢我们来聊聊bug，程序里的小虫子。

所谓“（Bug）”，是指程序中隐藏的错误或者缺陷。

早在 软件测试的工作周期 一文附录中我们就已经对bug来源做了解释，感兴趣的点击链接回顾。

一条Bug记录最基本应包含：

※bug编号：bug的唯一id，以方便尽快找到此bug。

※bug标题：bug摘要，阐述bug大体内容。

※bug严重级别，优先级：作为缺陷是否修复以及缺陷修复优先级的决定性因素。

※bug产生的模块：记录bug所属模块，方便开发定位问题。

※bug对应的版本：bug对应的软件版本，方便后续的统计归档以及开发定位问题。

※bug描述：bug的产生环境、详细步骤，期望结果、实际结果。

※附件：包括但不仅限于截图、日志、录像、所用到的示例文件以及应用；同样是方便复现解决缺陷的。

以上是上报bug（创建）bug必须的，在后续我们还会对bug进行修复、复测等工作，那在为了记录后续工作，bug还应该包含：

※bug状态：开始、修复中、修复完成、提测、测试中、测试通过/失败、关闭等，后续bug周期中会讲到。

※bug修订人：bug修订人员。

※bug复测人：通常是谁报的bug最后返回给谁测试，但是在某些情况下比如bug报告人任务积累太多/不在的情况下也会分给其他人，所以通常会记录bug复测责任人。

※bug修订说明：由bug修订人来写，说明bug产生原因，修改思路等。

※bug复测说明：由复测人员来写，说明复测过程，复测结果等。

※bug备注：备注，以便记录一些额外信息。

俗话说，事有轻重缓急。生活如此，工作亦如此。软件缺陷也并不是平等的，根据当前环境我们将不同的缺陷按照严重程度以及优先级进行分类，开发通过这个分类来决定bug是否修改以及bug修改的先后顺序（“缺陷的轻重缓急”）。

具体划分方法各个公司不尽相同，但是通用原则大体一样：

※ 严重性 ：表示软件缺陷的恶劣程度，当用户碰到该缺陷时影响的可能性和程度。

※ 优先级 ：表示修复缺陷的重要程度和紧迫程度。

下面我们给出严重性和优先级的常用划分方法，需要注意的是，我们这个只是示例，每个公司划分方法也都不尽相同，多多少少有些改变，大家作为参考即可。

严重性：

    a系统崩溃、数据丢失、数据毁坏、安全性被破坏、核心功能未实现（比如QQ 没有做聊天功能）、主体功能实现与需求不符（比如QQ聊天功能只能发消息不能收消息）

    b *** 作性错误、结果错误、功能模块的某个点未实现（比如QQ没有做消息提醒）,兼容性错误

    c小问题、拼写错误，UI布局不美观、特定情况下的罕见bug

    d一些易用性的建议（也可以归为3）

优先级：

    a立即修复，阻止了进一步测试

    b在产品发布之前必须修复

    c如果时间允许应该修复

    d可能会修复，不影响发布。

再次重申，上述清单只是范例，具体的缺陷划分规则还要依据实际项目、应用场景来制定。比如：通常我们认为毁坏用户数据的缺陷比简单的拼写错误缺陷严重。但是如果数据毁坏仅在用户几乎用不到的罕见特例中出现，而拼写错误导致所有用户安装软件产生问题呢？此时数据毁坏与拼写错误的优先级和严重性就不言而喻了，必然是拼写错误的严重性和优先级高于数据毁坏的。

严重性和优先级对于审查缺陷报告并决定哪些软件缺陷应该修复，以何种顺序修复的人员极为重要。如果一个程序员受命修复10个缺陷，他就应该先从严重性为1 、优先级为1这样的缺陷着手，而不是优先修复简单的，有简到难。

同样，两个项目经理--一个管理广告门户网站/游戏软件，一个管理医院检测仪/性能检测类软件，对待同样的问题就会做出两种选择，比如同样都是页面美观问题，在前者那优先级可能就是2，在后者那可能就是3或者4了。

好了，今天到此结束。如有任何问题请留言及时与我沟通，我会尽快回复大家！谢谢大家~我们下次再见！

正常。

bug的修复时间取决于它的复杂程度，如果是一个特别复杂的bug，可能需要很长的时间来解决，所以改一个月属于正常情况。

改bug是一个复杂且需要细心的过程，所以为了避免改错或者出现更多的bug，可以适当放慢步伐慢慢修改。

1、编程习惯

种⽠得⽠种⾖得⾖，好的编程习惯可以⼤⼤降低Bug数量。譬如有if必须写else，即使else是个空语句 。

2、写代码的时间问题

对于程序员⽽⾔，千万别熬夜写代码。⼀些程序员在晚上11点，仍然在敲代码。

虽然你⾃⼰觉得头脑其实很清醒，但是第⼆天⾃测，或者QA测试的时候你有可能就会发现问题很多。

我们⼀般不提倡长期加班写代码，因为那样会导致Bug率直线上升。

3、验

在提交测试前要多验，其中包括⾃动化测试、⼿动跑⽤例等。

有句话说得好，千万别怕烦，不然你会烦辈。

4、仔细的设计

在程序员编写代码之前，必须对代码的整个结构以及逻辑结构胸有成⽵。

5、避免⼲扰

有部分的程序员敲代码的时候，经常会⼀边听⾳乐⼀边敲代码，这样效率不仅仅低，⽽且也更容易产⽣Bug。

6、注释

写注释，写注释，写注释。重要的事情说三遍。

因为前期的注释有利于后续开发的时候容易减少bug。

⾃从修改了注释模板，整个⼈精神多了，bug也明显少了。

7、利用工具

另外为了尽早发现Bug，CoCode开发了评审分析工具，通过缺陷移除率评估，评估项目评审效果，从而尽早发现项目里的缺陷，提高项目开发质量。

作为一名码农、程序员，加班算是家常便饭了。周一至周五晚上加、周末加、办公室加、回家加、有偿加、无偿加……确实让人看见就怕。

但是你加班的原因是什么呢？让我们一起来看看下面两个例子。

01 程序员踩点下班，领导：不想干的请办理离职，我这里不养闲人与废物

在职场上加班不是目的，加班是为了完成工作，当员工能在正常上班时间内完成工作，无需加班，这时候作为领导也就没有必要让其留下来加班。

然而也有一些公司领导不看产出只看员工加不加班，就有一领导经过几天的观察，发现新来的几名程序员每天晚上不到八点就早早的下班走了。

对此这名领导很生气，想管管这群新来的程序员，于是在群里通知称：

都是干嘛使的？八点不到都 TM 走了！不干的直接说，现在就表态度，我这里从来不养闲人，也不养废物！不干的不想干的都去人事那里办理离职。

其实员工有这种心态实在人之常情。但退一步想，为何老板却能做到 5+2、白+黑呢？难道老板们都是铁打的？都是超人？非也，只因他们是经营者，他们为企业负责，为自己负责。

员工往往拿的是固定工资，所以这就导致了老板与员工焦点矛盾的局面：老板只关心利润，员工只关心工资。

当别人向程序员报一个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个未读消息：

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

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

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

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

以上就是关于bug的概念和分类全部的内容，包括:bug的概念和分类、程序员一个bug改一个月正常吗、有哪些最大限度降低bug率的办法等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！