bug生命周期&bug跟踪处理

一、BUG

BUG：软件的缺陷

1.BUG的定义：----与软件测试的目的对应

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

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

2.BUG的类型

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

功能问题、设计缺陷、界面优化、性能问题、配置相关、安装部署、安全相关、标准规范、测试脚本、其他

其他规划：功能类、界面类、性能类、易用性类、兼容性类、其他。

3.BUG的等级

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

如何判断BUG的等级（严重程度1、2、3、4），一般可以参照下面的判断条件

（1）致命错误（1级提BUG需慎重）

常规操作引起的系统崩溃，死机，死循环
造成数据泄漏的安全性问题，比如恶意攻击造成的账户私密信息泄露

（2）严重错误

重要功能不能实现；
错误的涉及面广，影响到其他重要功能的正常实现；
严重操作导致的程序崩溃、死机、死循环；
外观难以接受的缺陷；
密码明文显示；

（3）一般错误

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

次要功能不能正常实现；
操作界面错误（包括数据窗口内列名定义、含义不一致）；
查询错误，数据错误显示；
简单的输入限制未放在前端进行控制；
删除操作未给出提示；

（4)细微错误

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

界面不规范；
辅助说明描述不清楚；
提示窗口文字未采用行业术语；
界面存在文字错误；

三级BUG_未修改成功，又重新打开等级上升一次_二级BUG_二级还是没解决_直接一级BUG

改进建议：可以提高产品质量的建议，包括新需求和对需求的改进。

4.bug的生命周期（管理流程）

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

生命周期中一般缺陷状态：新建（指派）--已解决（待验）--关闭

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

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

BUG的处理流程图（生命周期图）

开发修改BUG也需要备注

操作者：开发
已修改BUG备注修改方案及信息
不是缺陷、不予解决、延期BUG、无法重现、备注处理原因
重复BUG注明重复BUGID

回归验证是测试人员完成的

确认和开发环境是否一致

5.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.

6.BUG的跟踪管理-状态处理

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

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

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

4.不是缺陷----确认开发环境是否分测试环境一致，如果如开发所说不是缺陷则进行关闭；如果确认是缺陷跟开发沟通，沟通未达一致找产品/反馈老大确认，确认是BUG注明情况并在次指派给开发。

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

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

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

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

总结：

1.界面测试：显示数据过长（正常场景会出现的）时，内容溢出边框，错乱？

2.易用测试：在标题部分，写上建议修改或者建议优化，可参考成熟产品做判断。

3.界面发现重复BUG:在BUG管理平台，标题搜索关键字，重复了的就关闭。

4.提交BUG时要描述清晰

5.不要局限在用例上，要发散思维进行测试（细心、耐心）----项目总结完善用例

6.做测试要有怀疑精神（站在用户立场/真实产品运行场景怀疑），参考同类型已成熟产品，觉得不好一定要确认。

7.BUG记得一定要跟踪,催着开发改BUG

8.第一轮测试（版本1.0），提交BUG开发修复BUG，第一轮修复还未完成，开发就提测了（版本2.0）---提测试流程规范。（因为自己是个小罗罗，没有什么话语权，跟老大提意见--第一轮测试完毕，接收新的测试版本，推进流程规范，要是老大也没什么话语权，那测试就被开发牵着鼻子走，测试会比较累）测试完第一个版本后，接收新的版本测试。

9.BUG状态的跟踪----编辑、重复、设计如此等。

巴特西