bug之道这样提bug，开发还会谢谢你。

微信公众号：波小艺

• 标题：这样提bug，开发还会谢谢你。
• 标签：流程优化、软件测试、bug优化、测试效率、经验总结
• 分类：经验总结
• 简介：我们经常会遇到此类尴尬的场景：开发准备修复bug的时候，发现测试提的“bug”描述不清，不知道如何复现，只能自己琢磨或者叫QA来演示一遍，最尴尬的是，可能在测试演示完之后，才发现这个并非bug，而是由于QA的不规范导致的。这样就会引起开发的不满，觉得测试在浪费他们的时间。所以，我们应该怎么做呢？

---

引入问题

相信不少开发看到测试提的bug单都少不了吐槽：这题的是什么玩意啊？

也相信不少测试工程师在测试过程中，遇到问题不做二次确认，直接提个bug单。接下来，让我们作为旁观者，看看张三的问题：

张三在发现bug之后，立马给开发提了bug，不去排查bug产生的原因。这样就会产生三个问题：

• 张三未经过二次验证确认问题的有效性，可能会导致把无效的问题提给开发。
• 张三不去排查问题出现的原因，可能会将问题指给错误的开发。
• 影响彼此工作的效率

好不容易发现了有效的问题，简单一句话将问题描述并提单，又出了问题：

• 在提问题单的时候，如果描述不清楚的话，开发很难复现问题
• 影响彼此工作的效率：开发无法复现问题，又需要花费时间和开发描述问题。

开发为测试列出的几大症状：

不理解需求

错误姿势：总是测一些生产环境中根本不可能存在的情况。甚至有些需求就是如此设计，不管三七二十一直接提bug。

正确姿势：先把需求理清楚，设计用例的时候，把一些实际不可能发生的事情剔除掉。

对bug定位不准

错误姿势：bug瞎指派。前端的bug指给后端，后端的bug指给前端。

正确姿势：分析错误产生的原因，分析是前端还是后端产生的bug，123砸过去😌

问题描述不清

错误姿势：说明bug要么开局一张图，要么一句话，开发复现bug全靠蒙。

正确姿势：问题应该有详情的描述，图文并茂，场景说明，以及bug出现的流程，对应账号密码等。

解决问题

发现问题到提出问题的正确流程应该如下图所示：

• 在发现问题之后，可再次尝试复现。
• 确认是bug之后，分析bug的产生方是前端还是后端。这时候，需要我们根据操作、请求响应、服务日志等分析来确认问题产生方。
• 在保证了bug的有效性之后，接下来我们要怎么让开发知道bug复现流程呢？

提bug之道

bug单主要分为三大块：标题、基本信息、描述。

• 标题

  • [问题方][概括描述]
• 基本信息

  • 问题的严重性：越严重的问题优先处理
  • 问题优先级：优先级高的问题会优先处理
  • bug Type：bug类型
  • 被指派用户（即引入bug的开发）
  • 关联项目：关联到具体的项目，后续可用来做分析
  • 关联的开发（即引入bug的开发）
• 描述

  • 相关测试数据

    • 如测试账号、页面跳转链接以及其他的一些测试数据。
  • 场景描述：如何描述一个场景很重要，也是决定开发是否能够快速定位的关键要素

    • 梳理一下是什么样的操作导致问题的出现
    • 再次尝试按照我们梳理的步骤去复现，将操作按照每个步骤描述出来
    • 场景描述完成之后，需要将预期结果以及实际结果也描述或者展示出来
  • 相关截图

    • ui页面的截图
    • 接口报错的截图
    • 日志相关的截图
    • db结果的截图等等
  • 排查结果[可选]

    • 可以锻炼个人问题排查的能力
    • 开发会谢谢你

案例

案例一

title：[BE] /api/xxx 返回的数据不正确 （注：如果一个需求中出现很多bug或者某个问题是由前端和后端引起的，标注责任方能让我们快速了解问题的责任方）

• 在场景中，我先描述问题的步骤，接着描述实际结果以及期望结果。不过不建议一段写完，建议分点写，会更加清晰（狗头：开发会谢谢你）。接着顺便粘贴一下curl请求，以及响应结果
• 把相关截图放上去，记得是相关的截图。必要的话，需要在图中做一下标注。

  • 图文结合更清晰，必要时在图中做标注

总结

所以在我们发现问题的时候，首先要做的第一件事就是需要确认一下是否是我们本身测试的不规范导致的。若不确定，可再尝试进行复现。bug描述一定要写具体，否则不仅浪费开发的时间，也会浪费自己的时间。当然如果有些bug不太好描述，且当面沟通成本最低的时候，我们可以选择成本较低的那种方式。