您还未登录! 登录 | 注册 | 帮助  

您的位置: 首页 > 软件测试管理 > 缺陷管理 > 正文

你会靠谱的进行Bug错误报告吗?

发表于:2017-08-07 作者:做工程师不做码农 来源:

  我们知道,在软件项目中经常会有各种或大或小的Bug,更甚一点出现Error。那么如何清晰无异议的提出Bug呢?是不是经常遇到别人给你说某某地方有个Bug,然后就没有然后了…你是什么反应?或者一个功能表面上看起来都是正常的,但他说结果错了,然后呢,然后也没然后了,你去看了一下,好像都正常,没有报错什么的,这时候你是什么反应?
  常见的两种提Bug的情况:
  第一种,只说错误现象。在没有明显的错误情况下,报告错误而不说正确的结果应该是什么,没有应该正确的结果(预期结果)对比,光说错误相当于污蔑。
  第二种,描述笼统。
  第三种,Bug point缺乏上下文。比如说,某个页面里的一个功能按钮有bug,如果直接报告这个功能按钮,你是一下子反应不过来的,你的系统分为很多大模块,然后下面有小模块,然后下面有很多页面,这个页面里有很多功能按钮,甚至很多页面都有相同的按钮,那么到底是说哪个页面的功能按钮有Bug呢?
  下图是我司禅道项目管理系统中今天分配给我的一个真实任务:

  部分具体是指哪些?位置从哪调整到哪?新增的薪资模块又是什么,放哪?有没有想骂人的冲动?? 如果不想详细表达好歹可以来一张示意图吧….
  又比如,张三创建了一个Bug给李四
  标题:挂了
  内容:我今天在玩XXXX网的时候,发现XXXX网站挂了。
  这个Bug对问题的描述太过笼统,开发人员根本无从下手。李四拿到这个Bug,也是哭笑不得,试了试网站的各个页面,好像也都正常。他于是把这个Bug又推给张三,“哪里挂了?”
  过了一会儿,张三回复“在我的机器上挂了”。
  李四跑到张三的座位上,想看看“犯罪现场”。
  张三:我刚重启了机器……
  两人等到启动完毕,打开网页,发现一切正常。
  张三:(纳闷了)昨天晚上的确是挂了。网页上还有一些错误信息。我当时正在干什么来着,好像是在留言或在论坛上发帖子,我现在也记不清了。让我再玩玩,等碰到了再叫你。
  李四:这样九条浪费了两个人各一个小时的时间,最后什么进展也没有。一个好的Bug报告应该是这样的:
   标题:购物网站的某个具体页面(URL),在回复中提交大于100KB的文字时会出错内容有以下几点:
  环境:
  在Windows XP下,使用IE7。允许Cookie。购物网的版本是1.2.40。
  重现步骤:
  1)用[用户名,密码]登录。这一用户在系统中是一般用户。
  2)到某一产品页面(链接为:……)。
  3)选中一个帖子,例如:帖子号为579。
  4)回复帖子,在内容中粘贴100KB的文字内容(文本内容见附件)。
  结果:网站出错,错误信息为:[略]
  预期结果:网站能完成操作,或者提示用户文本内容过大。[在附件中加入100KB的文本文件]。
  测试人员还可以附上其他分析,团队应该鼓励测试人员追根溯源。如果看到测试人员发来这样的Bug报告,那么开发人员就能够很快地重现这一问题,从而有效地分析和解决问题。
  那么,靠谱受欢迎的Bug报告要怎么提?
  软件项目管理工具通常支持多种类型的记录,“任务(Task)”和“缺陷(Bug)”是最基本的两种记录,任务=要做的事情,缺陷=意外发生的故障。当软件工程师完成了预定的任务,达到“代码完成”之后,团队的成员主要用Bug这种类型的记录来交流。在一定规模的软件项目中,一份好的错误报告,至少要满足以下几点。
  ●Bug的标题,要能简要说明问题。
  ●Bug的内容要写在描述中,包括:
  测试的环境和准备工作。
  测试的步骤,清楚地列出每一步做了什么。
  实际发生的结果。
  (根据软件功能说明书和用户的期望)应该发生的结果。
  ●如有其他补充材料,例如相关联的Bug、输出文件、日志文件、调用堆栈的列表、截屏等,应保存在Bug对应的附件或链接中。
  ●还可以设置Bug的严重程度(Severity)、功能区域等,这些都可以记录在不同的字段中。
  在实际生活中,在没有规范的前提下,请尽量做的规范一点。