一 什么是Bug
Bug简单来说，就是指应该发生的事情没有发生，或者是不该发生的事情发生了。
构建一个系统，相当于是重新创造了一个世界。
如果把我们所在的世界，当成是一部巨大的玄幻小说，每一个系统都可以被称之为一个密境，或者是游戏里常见的副本。
而产品经理就是密境的设计者：
你可以去定制这个密境运行的规则，展示出来的样子，通常由程序员们去按照你预期的样子去构建。
但是程序员小哥哥们往往会出很多问题，在上一节我们讲到过：
环境是要分成开发，测试和线上的。
而测试人员工作的平台就是测试环境。
在测试环境，我们的职责就是尽可能的找出超出我们预计之外的问题。
这种问题，我们称之为Bug。
为什么叫做Bug？
大概和打扫房间时发现屋子里面有蟑螂一样。
程序员们需要耐心，细致的找遍屋子里的每一个角落，找到蟑螂存在的痕迹，并消除掉。
我们来看一下，跟Bug相关的几个问题。
1.Bug是不是可以被完全消除？
2.是不是程序员的水准越高，写出来的Bug就越少？
3.应该在什么阶段去测试？
4.什么样的Bug可以上线？
第一个问题
Bug是不是可以不被写出来？为什么程序员总是会写出来各种各样的Bug？
做为一个曾经的程序员，也是现在的程序员，同时也是未来的程序员，我可以负责任的告诉你：
Bug一定存在，多熟练的工程师都没用。
Bug就像是宿命一样，伴随着程序员的终生。
而这也是人类最有意思的事情，它不像程序世界里一样充满了确定性，人是会犯错的，会漏掉各种各样的细节。
各种分支条件，极端运行情况，大多数程序员只能保证在大多数情况下不出意外。
可是Bug可以被消除，已经发现的Bug，除非特别难复现的，正常来讲都可以消除掉。
当然那些因为一开始系统构造的错误架构问题产生的Bug特别难修复。
在这个问题上，我想表达的含义就是：
正确的认知Bug，不要因为Bug的存在而产生困惑。
我们想做的，能做的，就是尽可能的减少Bug，以及在测试环境发现Bug后，快速的修复Bug。
第二个问题
是不是程序员的水准越高，写出来的Bug就越少？
答案是肯定的。
反过来说，其实更好理解，当一个程序员写出来的Bug很少的时候，他往往水平很高。
这是一件很有意思的事情，程序员之所以会犯错，很大的可能性是他不知道自己在犯错，而不是故意在犯错。
在这种情形之下，如果能够有快速的反馈，他会修复自己犯下的错误，并且提醒自己不要再犯同样的错误。
Bug的修复史其实是程序员的成长史。
好的程序员，会有足够多的经验做出预判，另外，在他们交付测试之前，往往会比测试人员测试的更仔细，以便提前发现自己的问题。
“让其他人发现自己写的程序有Bug，是程序员的耻辱。” -by 暗灭大人
作为产品和测试，很多时候并不太懂技术，不知道谁的水平高低，但是他们的感受很直接：
谁做的项目容易出问题，谁负责的模块总是出故障，谁花的时间更少，心里会很清楚。
第三个问题
应该在什么阶段去测试？
不要在开发阶段就进入测试，除非是开发人员的请求。
测试人员必须明确这一点，也需要向开发人员明确的提出自己的要求。
开发阶段进驻测试阶段，关键的环节就在于是Demo，我应该会在第四节讲到Demo的事情。
在这里需要明确的，就是测试人员工作的环境，就应该是测试环境，一个不被打扰的，稳定的环境。
不是开发，也不是线上。
第四个问题
什么样的Bug可以上线？
这其实就是今天想要描述的Bug的优先级。
产品经理和测试人员需要明确的是：
什么时候我应该发布系统，什么时候我应该放弃发布系统，什么时候我应该舍弃一些功能。
在后续的敏捷开发中，我会介绍到Story的优先级，这是通常用来解决上线问题的重要决策支持。
而在测试阶段，Bug的级别往往是我们决定是否能够上线的关键因素。
正常来说，不影响主要功能使用，仅仅影响用户体验的非关键业务逻辑，是可以上线之后再发布的。
这是一个权衡，在时间和体验之间选择一个最佳的平衡点，每一家的系统要解决的问题不一样，情形不一样。
通常都是看产品经理和测试人员和公司主要负责人共同的决定。
这也是Bug要区分优先级的重要原因，另一个原因就是开发人员要按顺序修复Bug。
对事情进行轻重缓急的分类，是人类生存史上的重要支柱。
Bug的优先级用来标志Bug的严重程度，以便用于在Bug修复和上线之间提供决策支持。
通常会分成以下几种。
critical
block
major
normal
minor
五种级别的划分，并不是单纯的12345分级这么简单，而是分别对应有它自己的含义。
Critical的Bug是最严重的，代表着系统崩溃，完全不可用。
这种Bug出现，就是最严重的事故，完全打不开，比如说，网站无法访问，点击出现系统错误，直接跳转到404页面。
要注意的就是，Bug的严重程度和它易于修复的程度并不总是一致。
举个例子，当用户打开修真院网址的时候发现打不开，这是非常严重的，Critical级别的Bug。
最后发现原因很简单，域名过期，解决方案也很简单，就是交钱续费而已。
一个系统是否能正常运行，并不在于导致它不能运行的问题复杂或简单。
Block的Bug也是非常严重的，它的含义是，用户的操作被卡住了，无法进行下一步。
系统并没有大规模的崩溃，而是无法进行到下一步。
拿12306来说，当你选好车票的时候，想要点击购买，这个时候却发现购买按钮点击之后无法使用，而其他的一切功能都正常。
这就是Block级别的Bug，一个地方卡死，导致你无法进行下一步的操作。
通常，在线上出现的Critical和Block，都可以称之为事故了。
Major的Bug是严重的，也是在Bug体系里的一个分界线。
绝大多数团队在初期的目标，都应该是在提交测试之前，完全消除Major级别的Bug，减少Normal级别的Bug数量。
Major的Bug通常是指流程可以走的通，但是关键的业务或者是数据错误，影响用户的正常使用。
比如说，在修真院的师兄弟体系中，你加入了班级，按理来说应该分配一个师兄。
你按提示完成操作，但是却没有被分配到任何师兄。
这种级别的Bug往往是不没有任何操作流程上的问题，但是就是和预期的结果不对，而且影响了用户的正常使用，特别是在关键业务逻辑上。
Normal的Bug就比较常见了，像一些分支业务逻辑里，偶尔会出现的问题，又或者是一些不太重要的地方出现的错误。
通常我们知道他是一个Bug，但是对大部分用户来说都无关紧要，可以用，可以不用。
我们知道他有Bug，噢，没关系，我可以等等。
Normal的Bug应该被控制数量，我们建议的数量，是在开发人员提交测试之后，不超过3个。
Normal的Bug通常情况下都很容易被发现，不需要花太大的力气去寻找。
Minor的Bug，指那些无伤大雅的小问题。
通常是指兼容性，不重要的文案错别字，样式错误等。
这种Bug上原则上的修复时间看开发人员的空闲期。
以上五种Bug级别，分别对应了在系统中对用户使用时候的影响度。
需要特别指出的是，很多人在时间特别赶，或者是不好的开发流程习惯中，喜欢用一个词来描述：主逻辑。
主逻辑先跑通，再去看其他的细节问题。
在时间特别紧，非常极端的情况下，允许这种情景出现。但是大多数时间里，我们都不赞成这种做法。
开发人员在Demo之前，不存在主逻辑跑通的问题，应该是交付所有的正常可使用的功能。
在这个前提下，才会有测试人员去测试环境测试的价值和意义。
我们刚刚提到过，当Bug的优先级划分出来之后，对我们修复Bug和规划上线提供了决策的依据。
这个依据，就是以Major的Bug为分界线。
通常而言，有Major以上的Bug是不允许上线的——都跑不通流程，你发布上线干嘛呢？
在开发人员安排修复Bug的时候，一定是优先安排Major的Bug，而不是先去修复Normal和Minor的Bug。
常犯的一个错误是，单独给开发人员留一个修复Bug的时间。
当然开发流程并不是由产品经理来决定，虽然这是面向产品经理的教程，但是我还是想说一下，在正常的项目管理中，不存在单独修复Bug的时间点。
这一点，在和研发团队交流的过程中格式的重要，我可能会在讲到敏捷开发的时候提到这些。
在当前，产品经理和测试人员需要明确的就是，守好Demo这一关，做好Bug优先级的处理工作。
另外，在提Bug的时候，要注意，一定要描述清楚Bug出现时间的
操作步骤（关键点附截图）
使用环境（操作系统，手机型号，浏览器版本，上下文）
预期结果（正确的结果是什么）
同时标明是偶现，还是必现，以及提供重现的数据。
这对于开发人员来说，非常重要。毕竟他们天生会说：
在我这里没问题啊（是你这个SB不会用吧）。
一旦出现Major的Bug，开发人员应当停掉手上的项目开发，第一时间将Major Bug修复，并提交到测试环境。
而关于系统能否发布上线的一个非常重要的依据就是，是否还存在Major级别以上的Bug。
如果存在了，能否把这个模块去掉，先去上线没有问题的模块。
在App的发版上更复杂一些，频繁的发布版本不是一个好的用户体现。
第一章第二节的内容就到此结束
下节预告：
【BUG的生命周期】，敬请期待
欢迎来交流群与大家一起学习讨论，在里面进行实时的沟通答疑
微信分享人：
暗灭，出身搜狐，葡萄藤创始人/CEO，10年敏捷开发最佳实践
驻场大神：
搜狐产品大神张春源：10年+产品开发经验，高屋建瓴
冰秀大神：出身搜狐，连续创业，创业者的产品即是公司：一家被收购，一家上市，匠心独运
想进群的请加大师姐微信邀请进群：
记得备注学产品哟
“职业选择、求职辅导、学习规划、困难答疑、技术交流等，可以加IT交流群828691304
欢迎访问我们的官网：技能树.IT修真院
“我们相信人人都可以成为一个工程师，现在开始，找个师兄，带你入门，学习的路上不再迷茫。
这里是技能树.IT修真院，初学者转行到互联网行业的聚集地。"
网友评论