企业官网建设流程全解析

测试(7) - bug篇（下）

如果你是第一次看这篇博客，可以看一看我软件测试–bug篇的上一篇博客介绍：
博客链接： 测试(6) - bug篇（上）

1. bug级别

通过定义 bug 的级别，能够明确看出问题的严重程度。
工作中开发人员通常需要按照 bug 的级别来分配优先级来处理 bug。

除此之外，通过 bug 级别也能够体现出开发人员的开发质量。

例如：
程序员A写的功能，有 10个严重bug，3个次要bug
程序员B写的功能，有 3个严重bug，10个次要 bug

那么，程序员B 的能力就要比 程序员A 的能力更好。
而且，程序员的年终奖也是和 bug 的数量息息相关的。

而测试人员，是提出 bug 的人，一个测试人员，提出来的有效 bug数量 越多，他的测试质量和测试能力越强，年终奖也和他的能力，息息相关。

所以，开发人员和测试人员，会因为 bug 的数量问题，发生矛盾，所有，会有一道高频的面试题：你作为测试人员，与开发人员产生争执怎么办？

bug级别分类：

bug级别一般分为：崩溃、严重、⼀般、次要（大部分企业）

举个例子来理解：一位女生，有一位男朋友，对于她男朋友的行为
男朋友多看了几眼美女：次要
男朋友跟美女加微信聊天：一般
男朋友跟美女私下去吃饭：严重！！！
男朋友跟美女出轨了：崩溃！坚决踢了，直接分手！！！

那么，哪些bug，怎么分类为 崩溃、严重、⼀般、次要？

崩溃：

阻碍开发或测试工作的问题；

造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题。

如：

1. 代码错误
2. 死循环
3. 数据库发生死锁
4. 重要的一级菜单功能不能使用
5. ……

崩溃级别的bug，一般是直接阻塞测试的主流程了。
在测试中较少出现，一旦出现应立即中止当前版本测试

严重：

系统主要功能部分丧失、功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出，关联程序间调用冲突，安全问题、稳定性等。

如：

1. 软件中数据保存后数据库中显示错误
2. 用户所要求的功能缺失，程序接口错误
3. 数值计算统计错误
4. ……

bug等级为严重时，不影响其他功能测试的情况下可以继续该版本测试

一般：

功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。

如：

1. 操作时间长
2. 查询时间长
3. 格式错误
4. 边界条件错误
5. 删除功能没有确认框
6. 数据库表中字段过多
7. ……

一般级别的bug，实际测试中存在最多

次要：

界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等。

如：

1. 错别字
2. 界面格式不规范
3. 页面显示重叠
4. 不该显示的要隐藏
5. 描述不清楚，提示语丢失，文字排列不整齐
6. 光标位置不正确
7. 用户体验感受不好
8. 可以优化性能的方案
9. ……

此类问题在测试初期较多，处理的优先程度较低

这里仅作参考，出来工作之后，公司内部会有明确的bug级别描述文档。

2. bug的生命周期

测试人员在执行测试的过程中，如发现 bug，需在对应的 bug 管理平台（例如：Jira）创建 bug。

创建完成的 bug 需由开发人员进行修复，并由提出该bug的测试人员持续跟踪与测试回归。

• New：新发现的 Bug，未经评审决定是否指派给开发人员进行修改。
• Open：确认是 Bug，并且认为需要进行修改，指派给相应的开发人员。
• Fixed：开发人员进行修改后标识成修改状态，有待测试人员的回归测试验证。
• Rejected：如果认为不是 Bug，则拒绝修改。
• Delay：如果认为暂时不需要修改或暂时不能修改，则延后修改。
• Closed：修改状态的 Bug 经测试人员的回归测试验证通过，则关闭 Bug。
• Reopen：如果经验证 Bug 仍然存在，则需要重新打开 Bug，开发人员重新修改。

bug的生命周期，用流程图表示：

什么是无效bug？

在实际工作中，测试人员创建的bug不一定是有效的，有可能是操作失误导致的 无效bug。

无效bug越多，一定程度上，也反映测试人员个人的能力不高。

3. 因为 bug 与开发产生争执怎么办（高频面试题）

为什么测试人员会与开发产生争执，经过上面的讲解，你应该清楚了。

bug是测试人员提出来的，而对于开发人员来说， bug的数量，会直接影响到他们的年终奖。
一旦牵扯到 钱，就不可避免的产生矛盾了。

而一旦产生争执，你作为测试人员，如果开发人员现在心情不好，很急躁，你先要安抚他的情绪，坐下来好好聊。
一定要针对 事情，进行讨论，就事论事。出于处理问题的目的去讨论。

3.1 回答方式：

这个问题，不是一个技术问题，而是一个情商问题，能力问题。

要考察的是大家的专业能力，情商，处理问题的能力。

1. 先检查自身，是否 bug 描述不清楚

首先就是要反省自己，是不是在测试过程中，出现了什么失误操作，导致产生了无效bug，或者是 bug描述不清楚。

2. 站在用户的角度，抛出问题

站在用户角度考虑问题，应让开发人员了解Bug对用户可能造成的困扰，从而促使开发人员更加积极、高质量地修改Bug。

在产生争执时，可反问一句：如果你是用户，你可以接受吗？

3. bug的定级，要有理有据

如果是开发人员，对于 bug 的级别有疑惑，我们要把 bug定级描述文档拿出来，然后将 bug 的表现和 bug 的定级描述文档进行匹配，说服程序员。

4. 提升自身技术和业务水平，做到不仅能够提出问题，最好能够给出解决方案

测试小白，还是提出问题就行。
测试大牛：除了能够提出问题（bug），也能够定位到问题，并给出解决方案。

这里还要注意一点，如果你确实是技术牛逼，能够看出问题的所在，并能够给出解决方案。
但你是测试人员，不要以 命令式 的口吻，去要求开发人员，必须按照你的解决方案去解决。
这样会造成开发人员来自内心对你的抵触，这不仅不能解决矛盾，还会加深矛盾。

你可以建议，但是你不要命令。

5. bug评审

如果你针对 bug 的问题，和程序员讨论，你动之以情，晓之以理，程序员很犟，还是没法说服程序员，那是一个 bug。

那就需要开 bug评审会议了。

bug评审主要解决两个问题：

1. 决定如何处理bug
2. 分析缺陷产⽣的原因，找出预防的对策

bug评审，除了你和某一位开发人员，至少需要项目组各个方面的代表参加：

1. 测试代表
2. 开发代表
3. 产品代表（产生 bug 的那个需求的产品同学）

注意，这里的各个代表，不是指一个人，可以是多个人。
但是，一般来说，都是你的直接上级，也就是领导。

总的来说，绝大部分情况，没人这么干的，因为有争议的bug，第一时间就应该在线上（办公软件）和产品的同事沟通了。
产品确认这是一个bug，需要改，那就是bug了。

一个需求的总指挥，就是负责这个需求的产品。
正所谓：遇事不决问产品

3.2 总结：

前面 4 个解决方案，讲述的顺序不重要，但是 bug 评审一定是放到最后去说，这是工作中出现问题的最后手段。

虽然，bug评审，并没有直接批评那位开发人员，但是，开 bug评审会，间接地给那个开发人员，造成了巨大的工作压力和心理负担。

4.总结：

这篇博客，主要讲述了：

1. bug级别
2. bug的生命周期
3. 面试题：因为 bug 与开发产生争执怎么办

最后，如果这篇博客能帮到你的，请你点点赞，有写错了，写的不好的，欢迎评论指出，谢谢！

下一篇博客：测试(8) - 测试分类篇