【测试基础】五、这样提bug单,开发小哥还会怼你么?

简介: 【测试基础】五、这样提bug单,开发小哥还会怼你么?

提bug单,应该是我们测试人员与开发人员交流沟通的重要渠道了。既然涉及交流沟通,自然就有沟通成本。


我们都是希望可以与开发小哥们愉快高效沟通的。要做到高效沟通,除了要注意语言上的技巧之外,bug单的内容描述也是需要额外注意的。


1268169-20210711105841838-1658164258.png

一、bug单


其实,之所以要提bug单(缺陷报告),最主要还是希望可以通过这份文档,把发现的缺陷准确无歧义地表达清楚。


开发小哥可以根据缺陷报告快速理解缺陷,并精确定位问题。同时,通过这个缺陷报告,开发经理可以准确预估缺陷修复的优先级、产品经理可以了解缺陷对用户或业务的影响以及严重性。


此外,缺陷报告本身的质量将直接关系到缺陷被修复的速度以及开发工程师的效率,同时还会影响测试人员的信用、测试与开发协作的有效性。


二、高效的缺陷报告包含内容


在工作中,通常我们会用一些现成的工具,比如 JIRA、Bugzilla、BugFree等等。这些工具通常对于缺陷会有整套的功能,以供我们开箱即用。


工具只是提供了我们一些模板,具体内容该如何填写呢?


首先,要先记住:好的缺陷报告绝对不是大量信息的堆叠,而是以高效的方式提供准确有用的信息


1. 标题


标题是很重要的,是对缺陷的概括性描述。另外,通常在bug列表里,第一眼展示的也是标题。所以,尽量做到:


1)清晰简洁,足够具体


缺陷标题不易过长,对缺陷更详细的描述应该放在“缺陷概述”里。


通常描述形式可以是:在什么情况下发生了什么问题


注意描述不能过于笼统,比如“搜索功能有问题”。这种描述给人感觉说了等于没说,很容易引发开发人员的反感和抵触情绪。


另外,对测试人员的工作也是有影响的。比如你提bug之前想去确认下有没有被其他人提过,结果搜索一下都是这种标题形式的,你还得一个个地点进详情里去查看确认,同样也降低了我们自己的工作效率。估计这会自己心里都要MMP了,更何况开发呢?


2)尽可能描述问题本质,避免只停留问题表面


同样的一句话描述问题,描述表面跟描述本质,让人的感受是截然不同的:


  • 描述表面:商品金额输入框,可以输入英文字母和其他字符。
  • 描述本质:商品金额输入框,没有对输入内容做校验。


是不是觉得第二种看起来最直观。


2. 缺陷概述


缺陷概述就是细化标题,提供更多概括性的缺陷本质与现象的描述。


缺陷概述还可以包括缺陷的其他延伸部分,比如列出同一类型的缺陷可能出现的所有场景;再比如,描述同样的问题是否会在之前的版本中重现。


总之,缺陷概述的目的是,清晰简洁地描述缺陷,使开发工程师能够聚焦缺陷的本质


3. 缺陷影响


我们测试人员如果要做到精准的描述缺陷影响,前提还是需要对软件的应用场景以及需求有深入的理解


4. 前置条件


目的是减少缺陷重现步骤的描述。


比如,前置条件:用户已完成登录。那么在接下来的重现步骤中,无须对于登录进行多余的描述。


5. 重现步骤


核心来了。


缺陷重现步骤是整个缺陷报告中最核心的内容,其目的在于用简洁的语言向开发工程师展示缺陷重现的具体操作步骤


不过在此之前,我们测试人员还是应该确认这个问题的可重现性


  • 反复执行多次。
  • 找到最短的复现路径,过滤掉非必要步骤。


接下来,就要描述重现步骤了,注意避开这 3 个问题


  1. 过于笼统,缺乏可操作的具体步骤。
  2. 出现与缺陷重现不相关的步骤。
  3. 缺乏对测试数据的相关描述。


6. 期望结果和实际结果


期待结果来自于对需求的理解,而实际结果来自于测试执行的结果。


一句话:你应该说明发生了什么,而不是什么没有发生


7. 优先级 和 严重程度


通常这里作为系统里的选项出现。


在此之前,我们一般会对于bug的优先级和严重程度进行一些等级的划分,并且同步到项目成员,让大家对此有统一的认知。


严重程度是缺陷本身的属性,通常确定后就不再变化,而优先级是缺陷的工程属性,会随着项目进度、解决缺陷的成本等因素而变动:


  • 缺陷越严重,优先级就越高。
  • 缺陷影响的范围越大,优先级也会越高。
  • 有些缺陷虽然从用户影响角度来说不算严重,但是会妨碍测试或者是自动化测试的执行,这类缺陷属于典型的严重程度低,但是优先级高。
  • 有些缺陷虽然严重程度比较高,但是考虑到修复成本以及技术难度,也会出现优先级较低的情况。


另外,还可以注意下对于问题是否有变通方案


变通方案是提供一种临时绕开当前缺陷而不影响产品功能的方式。如果有,还要看下实施起来的难易程度。


如果某个严重的缺陷没有任何可行的变通方案,那么不管修复缺陷代价有多大,优先级一定会是最高的,但是如果该缺陷存在比较简单的变通方案,那么优先级就不一定会是最高的了。


8. 根原因分析


根原因分析,是最能体现测试人员个人能力和魅力的地方。


如果你能在发现缺陷的同时,定位出问题的根本原因,然后反馈给开发,那么开发人员修复缺陷的效率就会大幅提升,而且你的技术影响力也会被开发认可


不过,要做到这一点并不容易。通常需要开发背景,或者至少有较好的代码阅读以及代码调试的能力。


所以,要成为一个优秀的测试人员,学习主流的开发语言还是必不可少的。


我个人推荐是 python 和 java。因为 python 用来写脚本爽到飞起。然后目前国内大多公司主流开发语言还是java,学 java 是为了更好的理解你所测试的系统,以及定位开发的问题。


当然了,要做好根原因分析要学习的也不止是语言,对于开发框架(比如springboot),项目的系统架构等也都要涉及。


9. 附件


通常是为缺陷的存在提供必要的证据支持,常见的附件有界面截图、测试用例日志、服务器端日志、GUI 测试的执行视频等等。


三、总结


高效的bug单,并不是说一定具备上面这种形式,但是核心的内容是一样的。

只要你提的报告能让开发快速并且准确的理解,就是好的报告。

相关文章
|
3月前
|
测试技术
测试提交的bug开发不认可怎么办?
测试提交的bug开发不认可怎么办?
|
4月前
|
测试技术 开发者
开发认为过度测试了该怎么办?
开发认为过度测试了该怎么办?
开发认为过度测试了该怎么办?
|
4月前
|
程序员
面试高频题:开发人员说不是bug,测试如何答复?
面试高频题:开发人员说不是bug,测试如何答复?
|
3月前
|
Java 测试技术 C#
什么样的自动化测试开发是合格的?
什么样的自动化测试开发是合格的?
|
1天前
|
SQL DataWorks Java
DataWorks操作报错合集之在阿里云 DataWorks 中,代码在开发测试阶段能够成功运行,但在提交后失败并报错“不支持https”如何解决
DataWorks是阿里云提供的一站式大数据开发与治理平台,支持数据集成、数据开发、数据服务、数据质量管理、数据安全管理等全流程数据处理。在使用DataWorks过程中,可能会遇到各种操作报错。以下是一些常见的报错情况及其可能的原因和解决方法。
13 1
DataWorks操作报错合集之在阿里云 DataWorks 中,代码在开发测试阶段能够成功运行,但在提交后失败并报错“不支持https”如何解决
|
4天前
|
测试技术 开发者
【专栏】测试驱动开发(TDD)与行为驱动开发(BDD)的比较与选择
【4月更文挑战第27天】本文探讨了测试驱动开发(TDD)和行为驱动开发(BDD)的核心概念与实践。TDD强调先写测试用例,通过测试推动设计,确保代码质量与可维护性。BDD侧重软件行为和业务价值,提倡使用通用语言描述行为,减少沟通障碍。选择TDD或BDD取决于项目复杂性、团队技能和业务需求。理解两者差异有助于团队做出合适的选择,发挥测试的最大价值。
|
5天前
|
JavaScript API
【vue】分环境构建(开发/测试/生产)配置
【vue】分环境构建(开发/测试/生产)配置
11 1
|
2月前
|
XML Java 测试技术
【Java优化实战】「微基准系列」带你脚踏实地的进行开发和使用JMH测试和提升应用程序和服务指南
【Java优化实战】「微基准系列」带你脚踏实地的进行开发和使用JMH测试和提升应用程序和服务指南
44 1
|
4月前
|
自然语言处理 测试技术
测试驱动开发(TDD)与行为驱动开发(BDD)的比较与选择
在软件开发中,测试驱动开发(TDD)与行为驱动开发(BDD)是两种常见的开发方法。虽然它们都强调测试在开发过程中的重要性,但是两者之间存在一些差异。本文将对TDD和BDD进行比较,分析它们各自的优点和缺点,以及在实际开发中如何选择最适合的方法。
|
4月前
|
测试技术 网络安全 Windows
本地开发和测试环境为什么一定建议用127.0.0.1或者localhost
在本地开发和测试时建议使用127.0.0.1或localhost,因为它们能确保与本地Web服务器直接、快速且安全地通信,不受网络防火墙限制,便于在无外部网络依赖的情况下进行调试和测试。
31 0

热门文章

最新文章