bug生命周期_一篇文章读懂bug的生命周期

1、bug的定义

    你们觉得bug是什么？举个例子来说明一下

    软件的bug，狭义概念是指软件程序的漏洞或缺陷，广义      概念除此之外还包括测试工程师或用户所发现和提出的软件可改进的细节、或与需求文档存在差异的功能实现等。

我们的职责就是，发现这些bug，并提交给开发，让开发去修改。

2、bug的类型

要确定一个bug的类型，需要对项目(或产品)有比较深的理解，这个划分对于开发定位问题影响很小，但对于问题类型的统计就比较重要了。

常见的bug类型划分(禅道系统为例，可自定义)：

代码(功能)错误：产品功能没有实现，有这个功能，但是功能没有生效

界面优化：UI界面测试

设计缺陷：需求中要求有XX功能，但实际上开发并未将此功能完成

3、bug的等级

要bug等级，这个划分有分三级或四级，也有分五级的。如果是等级越高，那么可能被修复的等级也会高一些，然后有些公司还会根据你提的bug数量和bug等级来考察你的绩效。很多情况下，我们提交bug大致的等级差不多即可，没有严格区分。

如何来判断bug的等级(严重程度)，一般可以参照下面的判断条件。

(1)致命错误：

   1、常规操作引起的系统崩溃、死机、死循环、闪退

   2、造成数据泄露的安全性问题，比如恶意攻击造成的账户私密信息泄露

   3、涉及金钱计算

   4、阻断性测试，所有测试工作进行不下去(冒烟测试)

(2)严重错误：

    1、重要功能不能实现：====需要去分析需求

    2、错误的波及面广，影响到其它重要功能正常实现：功能交互

例如点了题目收藏 结果题目没有收藏到，反而把题目弄丢了

    3、非常规操作导致的程序崩溃、死机、死循环、闪退

    4、外观(界面)难以接受的缺陷：

    5、密码明文显示：(界面+数据库)******

    6、偶现的致命性bug

(3)一般错误：

    不影响产品的运行、不会成为故障起因，但对产品外观和下道工序影响较大的缺陷

    1、次要功能不能正常实现:

    2、操作界面错误(包括数据窗口内列名定义、含义不一致)

    3、查询错误，数据错误显示：==排除产品是做搜索引擎的

    4、简单的输入限制未放在前端进行控制：(格式限制)长度

    5、删除操作未给出提示：==防止误操作

    6、偶现的严重性bug

(4)细微错误：

    程序在一些显示上不美观，不符合用户习惯，或者是一些文字的错误

    1、界面不规范：    

    2、辅助说明描述不清楚；

    3、提示窗口文字未采用行业术语；

    4、界面存在文字错误；

改进建议：可以提高产品质量的建议，包括新需求和对需求的改进。====功能是没有问题的。

练习：bug的类型及等级判断

  1.用户输入正确的用户名和密码不能登陆网站==代码(功能)错误，1or2

  2.客户需求要有充值功能，但是网站没有做==设计缺陷，1

  3.网站充值后，出现金额错误==代码(功能)错误，1

  4.在某购物APP上进行商品搜索时，闪退回到手机桌面==代码(功能)错误，1

  5.在某购物APP上进行商品搜索时，手机卡死==代码(功能)错误，1

  6.关闭按钮在弹窗左侧==UI页面错误，4

  7.APP某个图标显示太小或者像素失真==UI页面错误，4

  8.某个提示语需要改进一下，用户对专业术语不懂==UI页面错误，4

  9.忘记密码，功能没有实现==代码(功能)错误，3

  ====如果忘记密码这个功能，你觉得对于你们的产品是很重要的，那就是2等级，  严重错误

  ====如果忘记密码这个功能，你觉得对于你们的产品不是很重要的，那就是3等  级，一般

4、bug的生命周期(管理流程)

这个是面试/笔试过程中经常会被问到的问题。bug的生命周期，就是一个bug被发现到这个bug被关闭的过程。你们觉得这个过程有哪些步骤？

生命周期中一般缺陷状态：新建(提bug)->指派->已解决->待验->关闭。

如果待验的bug在验证时没有解决好，我们需要重新打开(激活)->指派->已解决->待验，循环这个过程。

中间其他状态：拒绝、延期等

我们来看一个bug的处理流程图(生命周期图)，让大家更深刻地理解周期中bug的状态及相应处理。

5、bug的跟踪管理-状态处理

1.已经指派的bug----已经指派给开发的，请大家注意自己bug的走向，随时关注并进行跟踪！如果一直未修复，提醒开发修改，以免开发忘记；如果已经修复等待测试环境更新后进行验证。催着改bug

2.已解决的bug----等待测试环境更新后进行验证，验证通过则关闭；验证不通过则重新打开指派给开发

3.重复bug----先去查看下是否跟开发指定的bug重复？如果确定是重复则关闭；如果不重复，说明原因，重新打开指派给开发

4.不是缺陷----再次依据需求确认，是否是bug，如果依然觉得是缺陷跟开发沟通，列举出来觉得是bug的点，沟通未达一致找产品确认，确认是bug注明情况并再次指派给开发，产品确认不是bug，就不纠结，直接关闭bug，但是，会拿小本本把这个bug记录下来，等到测试任务结束后，再次研究研究。

5.无法重现----确认开发环境是否跟测试环境一致？包括操作步骤、浏览器、环境、特定账号、输入数据等，如果多个版本验证之后，如开发所说重现不了，依据bug的严重程度跟产品、开发一起确认关闭；如果找到重现原因，注明清楚并再次指派给开发

6.不予解决----找产品经理进行确认。确认不予解决进行关闭；确认需要解决请备注原因并打开指派给开发

7.设计如此----找产品经理进行确认。确认设计如此进行关闭；确认是问题，备注原因重新指派给开发

8.延期修改----请看下bug严重程度，是否影响当前版本发布？与产品经理进行确认。不予延期请根据情况进行激活与情况说明；确认延期则做好记录，后续版本进行关注——不关闭

6、bug的跟踪管理-缺陷管理工具

常见的缺陷管理平台：

禅道(zentao)，我们现在做项目用的就是这个

bugzilla、jira：都还不错，也比较强大。但是搭建起来很困难

bugfree；

readmine

Mantis：这个还可以用

QC(QualityCenter)

不管是开源还是商业的缺陷管理工具，他们本质都是一样的，用来管理bug的生命周期。掌握其中一款工具，自然就会用其他的，稍微有一点点区别的，别人加以指点，就可以明白了。

7、bug的跟踪管理-如何让提交bug

发现bug后，接下来你提交到bug管理平台，提交一个bug包含哪些内容？

bug标题——标题要清晰简洁，写明bug描述；如果没有选择功能模块，最好在标题中标注功能模块。让查看bug的人员清楚知道你所表达的意思。bug的功能模块+bug的操作+bug的结果

重现步骤——详细写下发现bug的测试过程。能指导开发重现这个bug。附上测试数据

实际效果——出现bug的结果，粘贴bug截图、日志截图

预期结果——记得写清楚预期

bug类型和严重程度——便于后续测试结果分析，bug的统计

bug测试环境——例如：什么系统，哪个版本等。兼容性问题、难以重现问题

附件——日志文件，文件测试数据。图片、崩溃日志文件等

常见的笔面试题

1：有没有你印象深刻的bug？bug的原因/bug当时怎么解决？

2：bug的生命周期？(笔试)

3：当你开了一个bug，但是开发不认为是bug，如何处理？

                                      ==99%面试会问道

4：你在发现bug并确认bug的过程中，对于复现率不高的bug怎么处理？

  ==必须要提

  ==必须要写明，这个bug是偶现的

  ==截图，拍摄视频，日志，统统都要提交

快来关注我们吧!