Bug的定义&生命周期

1、bug的定义

你们觉得bug是什么?
软件的Bug狭义概含是指软件程序的漏洞或缺陷，
广义概念除此之外还包括测试工程师或用户所发现和提出的软件可改进的细节(增强性，建议性)、或 与需求文档存在差异的功能实现等。

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

2、bug的类型–了解

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

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

代码（功能）错误：–最常见–优先级偏高
界面优化— UI测试：优先级偏低
设计缺陷-- 优化建议：需求上就是不合理–优先级偏低–慎重一点（跟产品确定好）
按照公司具体的规定来分类！！！

3、bug的等级 --优先级（会影响开发的处理）

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

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

(1)致命错误: — blocker
1、常规操作引起的系统崩溃、死机、死循环、闪退 --P1
2、造成数据泄漏的安全性问题，比如恶意攻击造成的账户私密信息泄露
3、涉及金钱计算–公司巨大损失，业务
4、阻断性测试，所有测试工作进行不下去(冒烟测试) --登录
5、权限问题-爱奇艺资源会员? ?

(2）严重错误:一critical
1、重要功能不能实现:
2、错误的波及面广，影响到其它重要功能正常实现; --12306购票系统<–咨询
3、非常规操作（负面异常的操作）导致的程序崩溃、死机、死循环、闪退 —连续10次点击登录按钮
4、外观(界面)难以接受的缺陷;
5、密码明文显示: 前端处理bug后端-服务器(数据库验证) --安全
用抓包工具抓包发送到服务器，在抓包工具看到密码明文，也算bug （抓包抓得是交互数据）

前端：用户直接操作的界面 （用户名+密码）
|||
传递数据（截取数据 – 用户名，密码）
|||
后端：账号数据发送后端（数据库）进行匹配 --是，登陆成功；–否，登录失败

6、偶现的致命性bug

(3)一般错误: --major ==遇到最多
不影响产品的运行、不会成为故障起因，但对产品外观和下道工序影响较大的缺陷
1、次要功能不能正常实现:
2、操作界面错误(包括数据窗口内列名定义、含义不一致) ;
3、查询错误，数据错误显示;
4、简单的输入限制未放在前端进行控制;
5、删除操作未给出提示; --友好型
6、偶现的严重性bug

（4）细微错误: - minor
程序在，些显示上不美观，不符合用户习惯，或者是一些文字的错误 --用户体验
1、界面不规范:
2、辅助说明描述不清楚;
3、提示窗口文字未采用行业术语:
4、界面存在文字错误:

(5)改进建议–enhancement: -新需求下一一个版本
可以提高产品质量的建议，包括新需求和对需求的改进。

4、bug的生命周期(管理流程) --重点! ! !

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

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

如果待验的bug在验证时没有解决好，我们需要重新打开(激活) -指派->已解决->待验，循环这个过程。中间其他状态:拒绝、延期等

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

5、bug的跟踪管理流程

1、发现bug:—确认：防止环境问题，操作问题等外因—被开发认为无效bug 专业性
2、New(新建)–>（提bug本人、测试老大）指派–>开发、开发老大 ： 跟进（3天没人管，push(推进)开发修改）
3、重复bug (duplicated)：别人开过了–>要求开发备注一下重复bug编号（ID）–>测试确认–是重复的–>加备注–>关闭，–不是重复的–>重新激活–>指派给开发
4、不是缺陷（invalid）：by-design（设计如此）、
有可能是因为操作问题，环境问题，对产品理解错误一定要避免的!【==充分理解产品|确认并复现-- 不是bug – 备注关闭;依然是一个bug–加备注，重新激活–>开发修复;

“开发认为不是bug，你该怎么办?”
争论：1、分析需求。列举需求文档里的证据
2、从用户角度出发找到证据 --> 尝试说服开发;
3、产品（项目经理）–>拍板–>是bug–>开发修复；不是bug–>不要纠结，留好证据（邮件截图，聊天记录，备注bug）
5、无法复现（un-reproduced）：
1、开发无法复现：确认一下测试环境能不能复现出来== 可以–>帮助开发复现，测试环境调试定位
2、测试和开发环境都无法复现：尝试跟踪3-5个版本（每个版本10+）–>加备注（复现次数，跟踪版本数）–>关闭 =记录下来，研究
3、偶现bug == 偶现率（3/10）–影响到开发修复bug的优先级
6、不予解决（wontfix）:1 .bug级别低（UI、minor、enhancement），处理方式：1、从用户角度出发找到证据->尝试说服开发; 2、产品（项目经理）->拍板–>是bug–>开发修复；不是bug-> 不要纠结，留好证据（邮件抠图，备注bug）
7、延期（dalayed）:建议性（feature/enhancement）–作为下一个版本需求；1、马上上线，时间不够2、bug修复影响比较大，回归成本太高 | 1、确认bug的严重级别，会不会影响达到用户使用->一定要修复，版本延后发布，加班修复；2、如果不是特别影响用户，真的修复成本、风险太高–可以不修 === 找产品、项目经理最后确认 --风险+情况说明不修复，备注（留证据）=不关闭，挂起
8、已修复（resolved-fixed）：再次进行测试验证（bug步骤重新作一遍、结果再检查一遍）=
1、拿到正确的版本验证bug（包含了开发修复代码的版本）2、确认bug跟你之前开的bug步骤一致–验证关闭；–扩展有了新的问题–开成给一个新的bug 回归测试
9、没有修好同样的步骤，还存在==重新激活–reopened 影响开发绩效
10、修复好了-- verified（验证完毕）= closed

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

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

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

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

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

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

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

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

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

7、bug的跟踪管理缺陷管理工具

常见的缺陷管理平台:（标红的是常用的）
禅道(zentao) ，我们现在做项目用的就是这个
bugilla, jira: 都还不错，也比较强大。但是搭建起来很困难
bugfree:
Readmine
easybug:免费开源,在线网站类型的
Mantis:这个还可以用
QC(QualityCenter). TD

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

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

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

bug标题——标题要清晰简洁，写明bug描述;如果没有选择功能模块，最好在标题中标注功能模块。让查看bug的人员清楚知道你所表达的意思。bug的功能模块+bug的操作+bug的结果
重现步骤——详细写下发现bug的测试过程。能指导开发重现这个bug。附上测试数据
实际结果——出现bug的结果，粘贴bug截图、日志截图–文字+截图 == 1、直观2、无图无真相
预期结果——记得写清楚预期 == 测试用例预期结果 – 修复bug的依据
bug类型和严重程度——便于后续测试结果分析，bug的统计
bug测试环境——例如:什么系统，哪个版本等。兼容性问题、难以重现问题
附件——日志文件，文件测试数据。图片、崩溃日志文件等