BUG的跟踪管理

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

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

一、****bug的类型

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

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

    ·代码（功能）错误

    ·界面优化

    ·设计缺陷

二、****bug的等级

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

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

1、致命错误：------blocker

1. 常规操作引起的系统崩溃、死机、死循环、闪退
2. 造成数据泄漏的安全性问题，比如恶意攻击造成的账户私密信息泄露
3. 涉及金钱计算
4. 阻断性测试，所有测试工作进行不下去（冒烟测试）

*2、严重错误*：------**critical

1. 重要功能不能实现
2. 错误的波及面广，影响到其它重要功能正常实现
3. 非常规操作导致的程序崩溃、死机、死循环、闪退
4. 外观(界面)难以接受的缺陷
5. 密码明文显示（界面+数据库）
6. 偶现的致命性bug（备注复现率：复现次数/总测试次数）

3、一般错误：------major

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

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

4、细微错误：------minor

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

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

5、改进建议:------enhancement

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

6、bug类型及等级判断

1.用户输入正确的用户名和密码不能登录网站---分析软件qq致命的 爱奇艺腾讯视频严重错误

2.客户需求要有充值功能，但是网站没有做---重要的功能严重错误

3.网站充值后，出现金额错误---分析延时后正确2 延时还是错误 1

4.在某购物APP上进行商品搜索时，闪退回到手机桌面 ---1

5.在某购物APP上进行商品搜索时，手机卡死----1

6.关闭按钮在弹窗左侧 ----3

7.APP某个图标显示太小或者像素失真----3

8.某个提示语需要改进一下，用户对专业术语不太懂 ----4

9.忘记密码，功能没有实现----次要功能没有实现3

三、****bug的生命周期(重点)

    这个是面试/笔试过程中经常会被问道的问题。bug的生命周期，就是一个bug被发现到这个bug被关闭的过程。

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

                    new--->assigned--->resolved-fixed--->verified/to be verified--->closed

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

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

1、bug的跟踪管理-流程

（1）发现bug,一定要确定bug(环境问题、操作问题)，提交bug(缺陷管理工具)----new

（2）指派给开发/开发老大----assigned(指派)

（3）研发确认bug

    1）重复的bug(提交的bug已经有人提交,要求开发重复的bug编号加入备注)

            确认bug是否重复?

            ①是的话 bug关闭(避免提交重复bug，搜索bug)

            ②不是重复的bug 加备注描述不是重复bug原因，重新激活bug

    2）不是缺陷 ---invalid（无效缺陷）

    常见面试题:开发说不是bug，你认为是bug，怎么办?

            ①确认bug

            ②对照需求，站在用户的角度，参考成熟产品，与开发沟通，说服开发

            ③产品/项目经理做最后的确认

                    结果一:要修复bug重新激活，加备注(要修复的保留证据)

                    结果二:不修复保留证据，加备注

    3）无法复现 -----unreproduced

            确认bug是否可以重现

            ①可以重现，帮开发进行重现

            ②自己的环境也不能重现 跟踪3-5个版本，加备注--关闭

            ③不能稳定复现，偶现bug 这种bug一定要提交，写出bug的复现率

                    出现bug次数/总的测试次数

（4）研发解决bug

    1）不予解决 wont fix

            bug优先级(界面bug，建议性)----争议，尝试沟通无果--产品确认 =====加备注，关闭

    2）延期---delay

            ①建议性

            ②优先级低

            ③改动太大，影响太大(分析 1、bug是否影响用户的使用 2、衡量一下时间，bug影响程度 3、产品经理做最后的确认 ===加备注，bug状态为挂起)

（5）研发已解决bug -----resolved-fixed

（6）解决的bug回到测试这边 -----verified 待验 回归测试验证bug

    1）验证通过  bug完美的解决，关闭---closed

    2）验证不通过

            测试版本环境正确，问题依然存在，重新bug指派开发，开发继续修复

            注意:bug验证需要在开发修改的版本里面进行验证

2、bug的跟踪管理-状态

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

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

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

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

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

    常见的缺陷管理平台:

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

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

    bugfree:

    Readmine

    easybpg:免费开源，在线网站类型的

    Mantis:这个还可以用

    QC(QualityCenter)、TD

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

4、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，如何处理?

    4、你在发现bug并确认bug的过程中,对于复现率不高的bug怎么处理?