提Bug给开发的正确姿势

发表于:2022-12-08 09:47

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:波小艺    来源:掘金

分享:
  引入问题
  相信不少开发看到测试提的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不太好描述,且当面沟通成本最低的时候,我们可以选择成本较低的那种方式。
  本文内容不用于商业目的,如涉及知识产权问题,请权利人联系51Testing小编(021-64471599-8017),我们将立即处理
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号