如何编写高质量的缺陷报告(一)

目录

一、报告缺陷注意事项

二、如何编写缺陷报告



在一些项目中,缺陷报告是测试工程师最主要的工作输出。一份好的缺陷报告可以帮助开发人员快速定位问题,帮助产品经理了解缺陷的严重性及用户质量信息,同时可以快速确定修复优先级;项目周期的例会中,可以有效提高会议效率;如果是在测试作为第三方公司提供时,项目组会以缺陷报告的质量来评估该测试人员的工作能力和职业素养。所以,编写出高质量的缺陷报告是测试人员重要基本功之一。

首先,报告缺陷的目的是解决缺陷,但是由于项目组中每个角色分工不同,对待缺陷站的立场也不同,做出具有说服力且完善的缺陷报告非常重要。

  1. 提交缺陷时描述清楚问题产生步骤及严重级别。

测试过程中,测试人员经常遇到的问题是提交的缺陷被开发以无法重现打回,或者提交的用户建议被需求标注为不予修复。测试人员不能清楚描述出问题步骤或没有标出具体发生环境或工具时,开发按照自己的环境去复现很可能失败,而提的用户建议若未说明其对用户的影响程度时,也会因工期原因被产品不予修复。

每个公司对缺陷报告的评审人不尽相同, 这就需要测试人员从多个角度向评审人来传递正确有效的信息。使用Bug管理工具时,特别注意选择好优先级,如果是自己本地提交,也需要注明优先级,测试时, 我们要始终站在用户的角度去思考,而不是由开发人员自己去给Bug定义是否重要。其次测试人员需要关注测试的网络服务是否输出了足够的日志,长远来看,更多的日志有利于测试更快地发现错误并定位问题。而不是一直让自己保持在黑盒状态。另外,如果发现了兼容性问题,比如执行特定操作时,在弱网情况下会发生页面异常,类似的问题需要测试人员自己评估严重性、阅读需求规格说明书、询问相关需求人员,该特定操作可能出现的频率及特定用户使用习惯等等。

2.尽早提交缺陷报告

项目周期临近结束时,如果再有新的Bug提交 ,开发会评估可能引入新的缺陷,而且修复完成测试需要回归整个Module,或者对于风险较高的缺陷暂不修复。所以测试人员需要做的是,做测试计划时制订好测试策略,尽量在项目前期发现严重级别的Bug;同时编写的缺陷报告尽早提交 。

3.对于难以重现的Bug也要全部提交

  • 如果一个项目同时多个测试的话,尽量避免提交重复Bug;
  • 一轮测试通过后,可以在Bug管理系统中检索下Bug分布情况,如按模块、按功能、按类型看哪部分问题分布相对多,则很可能该处会隐藏更多Bug。
  • 测试人员不能判断是否是Bug时,可以先记录下,如果涉及到核心功能,可以及时询问需求人员。但不能遗漏。
  • 对于难以重现的Bug, 测试人员需要尽早记下所有相关信息,并标注重现频率 。尽可能多试几次 ,由哪些特殊因素触发。
  • 针对难以重现的Bug, 一来可以利用服务器日志来查询报错内容,二来在测试之前可以部署相应的录屏工具来解决。

原文地址:http://blog.51cto.com/hongz/2068257

时间: 2024-10-29 02:46:48

如何编写高质量的缺陷报告(一)的相关文章

编写高质量代码–改善python程序的建议(二)

原文发表在我的博客主页,转载请注明出处! 建议七:利用assert语句来发现问题断言(assert)在很多语言中都存在,它主要为调试程序服务,能够快速方便地检查程序的异常或者发现不恰当的输入等,可防止意想不到的情况出现.其语法如下: assert expression1 ["," expression2] 其中expression1的值会返回True或者False,当值为False的时候会引发AssertionError,而expression2是可选的,常用来传递具体的异常信息. 不

编程精粹--编写高质量C语言代码(3):自己设计并使用断言(二)

接着上一遍文章<<编程精粹--编写高质量C语言代码(2):自己设计并使用断言(一)>>,继续学习如何自己设计并使用断言,来更加容易,更加不费力地自动寻找出程序中的错误. 首先看一个简单的压缩还原程序: byte* pbExpand(byte *pbFrom,byte *pbTo,size_t sizeFrom) { byte b, *bpEnd; size_t size; pbEnd=pbFrom+sizeFrom; while(pbFrom<pbEnd) { b=*pbFr

编写高质量代码改善java程序的151个建议——[110-117]异常及Web项目中异常处理

原创地址:http://www.cnblogs.com/Alandre/(泥沙砖瓦浆木匠),需要转载的,保留下! 文章宗旨:Talk is cheap show me the code. 大成若缺,其用不弊.大盈若冲,其用不穷.  <道德经-老子>最完满的东西,好似有残缺一样,但它的作用永远不会衰竭:最充盈的东西,好似是空虚一样,但是它的作用是不会穷尽的 Written In The Font 摘要: 异常处理概述 学习内容: 建议110: 提倡异常封装 建议111: 采用异常链传递异常 建议

编写高质量代码改善C#程序的157个建议[用抛异常替代返回错误、不要在不恰当的场合下引发异常、重新引发异常时使用inner Exception]

原文:编写高质量代码改善C#程序的157个建议[用抛异常替代返回错误.不要在不恰当的场合下引发异常.重新引发异常时使用inner Exception] 前言 自从.NET出现后,关于CLR异常机制的讨论就几乎从未停止过.迄今为止,CLR异常机制让人关注最多的一点就是"效率"问题.其实,这里存在认识上的误区,因为正常控制流程下的代码运行并不会出现问题,只有引发异常时才会带来效率问题.基于这一点,很多开发者已经达成共识:不应将异常机制用于正常控制流中.达成的另一个共识是:CLR异常机制带来

编写高质量代码改善C#程序的157个建议——建议78:应避免线程数量过多

建议78:应避免线程数量过多 在多数情况下,创建过多的线程意味着应用程序的架构设计可能存在着缺陷.经常有人会问,一个应用程序中到底含有多少线程才是合理的.现在我们找一台PC机,打开Windows的任务管理器,看看操作系统中正在运行的程序有多少个线程. 在笔者当前的PC机上,线程数最多的一个应用程序是某款杀毒软件,它一共拥有116个线程数:其次是Windows自身的System进程,当前共有104个线程:第三多的进程是Sqlservr.exe,锐减到了35个线程:剩下还有63个进程,估计它们平均约

编写高质量代码改善C#程序的157个建议——建议79:使用ThreadPool或BackgroundWorker代替Thread

建议79:使用ThreadPool或BackgroundWorker代替Thread 使用线程能极大地提升用户体验度,但是作为开发者应该注意到,线程的开销是很大的. 线程的空间开销来自: 1)线程内核对象(Thread Kernel Object).每个线程都会创建一个这样的对象,它主要包含线程上下文信息,在32位系统中,它所占用的内存在700字节左右. 2)线程环境块(Thread Environment Block).TEB包括线程的异常处理链,32位系统中占用4KB内存. 3)用户模式栈(

编写高质量代码改善C#程序的157个建议——建议70:避免在调用栈较低的位置记录异常

建议70:避免在调用栈较低的位置记录异常 并不是所有的异常都要被记录到日志,一类情况是异常发生的场景需要被记录,还有一类就是未被捕获的异常.未被捕获的异常通常被视为一个Bug,所以,对于它的记录,应该被视为系统的一个重要组成部分. 最适合记录异常和报告的是应用程序的最上层,这通常是UI层.假设存在这样一个应用程序,它的BLL层可能被一个WinForm窗体调用,也可能被一个控制台应用程序调用,那么要在BLL模块向管理员报告异常的时候,你可能会不知道该使用MessageBox方法还是使用Consol

编写高质量JAVA程序代码的建议

--------------------------------------------------------------------------------------------------- 前言:原著<改善JAVA程序的151个建议>有151个建议,我在拜读的过程根据自己的理解合并了其中的几个,并将每个建议的核心要义进行了一次纯手工提炼,以方便想阅读这本书的同行能够更快的掌握这本书的所有核心内容. -------------------------------------------

如何编写高质量的 JS 函数(3) --函数式编程[理论篇]

本文首发于 vivo互联网技术 微信公众号 链接:https://mp.weixin.qq.com/s/EWSqZuujHIRyx8Eb2SSidQ作者:杨昆 [编写高质量函数系列]中, <如何编写高质量的 JS 函数(1) -- 敲山震虎篇>介绍了函数的执行机制,此篇将会从函数的命名.注释和鲁棒性方面,阐述如何通过 JavaScript 编写高质量的函数. <如何编写高质量的 JS 函数(2)-- 命名/注释/鲁棒篇>从函数的命名.注释和鲁棒性方面,阐述如何通过 JavaScri