bug管理流程

1、bug的定义

软件的Bug，狭义概念是指软件程序的漏洞或缺陷
广义概念除此之外还包括测试工程师或用户所发现和提出的软件可改进的细节(增强性，建议性)、或与需求文档存在差异的功能实现等。
我们的职责就是，发现这些Bug,并提交给开发,让开发去修改。

2、bug类型

要确定一个bug的类型， 需要对项目(或产品) 有比较深的理解。这个划分对于开发定位问题影响很小，但对于问题类型的统计就比较重要了。—测试报告
常见的bug类型划分(禅道系统为例，可自定义) :
代码功能)错误— 最多，最常见的bug
界面优化— U|测试，易用性兼容性
设计缺陷— 不符合用户的习惯，修改设计–满足用户需求= ==增强建议性的bug
按照公司具体的规定来分类! ! !

3、Bug等级–优先级

如何来判断bug的等级(严重程度)， -般可以参照下面的判断条件。
(1)致命错误:
1.常规操作引起的系统崩溃、死机、死循环、闪退
2、造成数据泄漏的安全性问题，比如恶意攻击造成的账户私密信息泄露
3.涉及金钱计算
4、阻断性测试，所有测试工作进行不下去(冒烟测试)
5.权限问题.

(2)严重错误: — critical
1.重要功能不能实现;1
2、错误的波及面广,影响到其它重要功能正常实现;
3.非常规操作导致的程序崩溃、死机、死循环、闪退
4、外观(界面)难以接受的缺陷;
5、密码明文显示;
6、偶现的致命性bug

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

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

(5)改进建议–nhancement
可以提高产品质量的建议，包括新需求和对需求的改进。— 本次发布不会修复,放到下面个版本修更

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

bug的生命周期，就是一个bug被发现到这 个bug被关闭的过程。

这个过程有哪些步骤?
生命周期中-般缺陷状态:发现-新建(提bug) ->指派->E解决->待验->关闭。–正常
如果待验的bug在验证时没有解决好，我们需要重新打开(激活) ->指派~>已解决->待验，循环这个过程。
中间其他状态:拒绝、延期等

1.发现bug–确认bug:有可能是因为操作问题。环境问题–提交bug —bug管理工具
**2.指派bug开发/开发老大测试—开发
3.重复bug-- duplicated :别人开过了–公司里尽量避免(浪费时间) :确认开发有添加重复bug ID (开发添加bugid) —bug确认是否中重复:是–加备注，关闭:否: 加备注–重新教活-修复: 加备注= =方便后续织踪
4.不是缺陷: invalid (无效) — 有可能是因为操作问题，环境问题，对产品理解错误—定要避免的! ! ! --充分理解产品 确认并复现-不是bug–备注美闭;依然是一个bbug–加备注，重新激活开发修复: --开发认为不是bug. 你该怎么办?”–需求理解不致–处理步骤: 1.列举需求文档里的证据2.站在用户角度出发—证据说服开发修复bug; 3.找产品确认，项目经理—是–开发修复:否-- 加备注关闭—聊天记录，邮件截图–证据，贴到bug里; =责任划分:
5.无法重现–unreproduced: 1)测试开究bug,开发无法复现_-- a.确认测试环境是否依然可以复现，帮助开发复现: b.测试环境无法复现(偶现) — 尝试跟踪多个版本的测试，每个版本10次，连续5 6版本—加备注关闭(做了哪些尝试，结果) ;偶现bug=偶现率(3/10) — 影响到开发修复bug优先级;
6.不予解决一wontfx: （1）级别的不高，小bug 2)建议性bug I处理方式: 1)站在用户角度，列举证据。说服开发修每一无果: 2) 产品+项目经理–确认=结果一记录到bug里作为备注
7.延期:延后后续版本修复: 1)马上上线了，时间不够了 2) bug修复影响太大了， 回归测试成本太高|测试确认: 1)确认bug的严重级别，会不会影响用户使用- -定修复，版本延后发布，加班修复2) 如果不是特别影响用户，真的修复成本，风险太高-可以不惨==产品和项目经理确认–风险+情况说明= =决定–备注里再bug
8.修复之后(resolved-fixed) 开发一>测试 :验证bug: 1)拿到正确的版本验证bug (包含了开发修复代码的版本) 2)确认bug跟你之前开bug 的步骤是一致–验证关闭:一扩展新的为难题-开成给一个新的bug = =回归测试
9.没有修好：同样的步骤，还存在= 重新打开–reopened
10、修复好了- verifed :关闭dosed

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的跟踪管理-如何提交bug。发现bug后,接下来你提交到bug管理平台,提交-个bug包含哪些内容?

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