测试(7) - bug篇下文章目录测试(7) - bug篇下1. bug级别bug级别分类崩溃严重一般次要2. bug的生命周期3. 因为 bug 与开发产生争执怎么办高频面试题3.1 回答方式1. 先检查自身是否 bug 描述不清楚2. 站在用户的角度抛出问题3. bug的定级要有理有据4. 提升自身技术和业务水平做到不仅能够提出问题最好能够给出解决方案5. bug评审3.2 总结4.总结如果你是第一次看这篇博客可以看一看我软件测试–bug篇的上一篇博客介绍博客链接 测试(6) - bug篇上1. bug级别通过定义 bug 的级别能够明确看出问题的严重程度。工作中开发人员通常需要按照 bug 的级别来分配优先级来处理 bug。除此之外通过 bug 级别也能够体现出开发人员的开发质量。例如程序员A写的功能有 10个严重bug3个次要bug程序员B写的功能有 3个严重bug10个次要 bug那么程序员B 的能力就要比 程序员A 的能力更好。而且程序员的年终奖也是和 bug 的数量息息相关的。而测试人员是提出 bug 的人一个测试人员提出来的有效 bug数量 越多他的测试质量和测试能力越强年终奖也和他的能力息息相关。所以开发人员和测试人员会因为 bug 的数量问题发生矛盾所有会有一道高频的面试题你作为测试人员与开发人员产生争执怎么办bug级别分类bug级别一般分为崩溃、严重、⼀般、次要大部分企业举个例子来理解一位女生有一位男朋友对于她男朋友的行为男朋友多看了几眼美女次要男朋友跟美女加微信聊天一般男朋友跟美女私下去吃饭严重男朋友跟美女出轨了崩溃坚决踢了直接分手那么哪些bug怎么分类为 崩溃、严重、⼀般、次要崩溃阻碍开发或测试工作的问题造成系统崩溃、死机、死循环导致数据库数据丢失与数据库连接错误主要功能丧失基本模块缺失等问题。如代码错误死循环数据库发生死锁重要的一级菜单功能不能使用……崩溃级别的bug一般是直接阻塞测试的主流程了。在测试中较少出现一旦出现应立即中止当前版本测试严重系统主要功能部分丧失、功能设计与需求严重不符模块无法启动或调用程序重启、自动退出关联程序间调用冲突安全问题、稳定性等。如软件中数据保存后数据库中显示错误用户所要求的功能缺失程序接口错误数值计算统计错误……bug等级为严重时不影响其他功能测试的情况下可以继续该版本测试一般功能没有完全实现但是不影响使用功能菜单存在缺陷但不会影响系统稳定性。如操作时间长查询时间长格式错误边界条件错误删除功能没有确认框数据库表中字段过多……一般级别的bug实际测试中存在最多次要界面、性能缺陷建议类问题不影响操作功能的执行可以优化性能的方案等。如错别字界面格式不规范页面显示重叠不该显示的要隐藏描述不清楚提示语丢失文字排列不整齐光标位置不正确用户体验感受不好可以优化性能的方案……此类问题在测试初期较多处理的优先程度较低这里仅作参考出来工作之后公司内部会有明确的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评审主要解决两个问题决定如何处理bug分析缺陷产⽣的原因找出预防的对策bug评审除了你和某一位开发人员至少需要项目组各个方面的代表参加测试代表开发代表产品代表产生 bug 的那个需求的产品同学注意这里的各个代表不是指一个人可以是多个人。但是一般来说都是你的直接上级也就是领导。总的来说绝大部分情况没人这么干的因为有争议的bug第一时间就应该在线上办公软件和产品的同事沟通了。产品确认这是一个bug需要改那就是bug了。一个需求的总指挥就是负责这个需求的产品。正所谓遇事不决问产品3.2 总结前面 4 个解决方案讲述的顺序不重要但是 bug 评审一定是放到最后去说这是工作中出现问题的最后手段。虽然bug评审并没有直接批评那位开发人员但是开 bug评审会间接地给那个开发人员造成了巨大的工作压力和心理负担。4.总结这篇博客主要讲述了bug级别bug的生命周期面试题因为 bug 与开发产生争执怎么办最后如果这篇博客能帮到你的请你点点赞有写错了写的不好的欢迎评论指出谢谢下一篇博客测试(8) - 测试分类篇