Bug描述应注意的问题

类别:Java 点击:0 评论:0 推荐:

最近在工作中注意到了这样一个现象,我们测试小组的人员经常会去给开发人员解释自己写的Bug是什么意思,一个Bug来来回回的改了好几遍,于是我大致的浏览了一下测试人员添加的一些Bug,发现了一些比较有意思的描述,现列出几个:

1.××模块:如果把打开公文附件,而下点一下“关闭”按钮,然后再点“保存“,则页面条转到空白页面,并且无任何出错提示。

这个描述我在看时也如丈二和尚般迷茫了半天,仔细看看原来是里面的错别字在捣乱。如:“而下点一下关闭按钮”应为“而且点一下关闭按钮”;“则页面条转到空白页面”应为“则页面跳转到空白页面”;打开公文附件那句中多了个“把”字,这样以来再看看就明白是什么意思了。为什么会这样?因为测试人员在输入完后没有检查就提交了,为什么不检查呢,在我们强调开发人员加强自测的同时,自己也应对自己提交的Bug负责。

2.××模块:新增后,“合同金额”过大时不应用科学技术法来显示。

为了找到究竟是那里用了科学计数法显示数字,我分别在记录列表页面、浏览页面、修改页面进行了查看,最终定位在了修改页面而其余2处都没有这种错误,那么明明有具体位置为什么当初在描述中不写具体?如果每个Bug都要让修改者如此定位的话,是不是很耗时呢?另外“合同金额过大”,这个过大究竟是多少?输入的数字超过了几位就会出现这种现象,测试时输入的数据是多少这里都没有明确的说明。Bug描述不清晰,开发人员在修改时势必要找测试人员问个究竟,这样一来大家的时间不就都浪费了么?(这里面也有错别字:“科学技术”应为“科学计数”)。

那么该如何描述一个Bug呢?过去上学老师在教大家写议论文时都会强调论点、论据、论证三要素,只要这三样齐备了那么写出的文章总归是不差的。同样我们的Bug描述中同样也要包括以下三要素:位置、操作、现象。具体来说:

1.位置:首先应说明操作进行的位置,通常是系统中的某一模块。另外是具体的出错位置,可能是某一字段、某一页面...

2.操作:详细的、有次序的、每一步的操作步骤,包括输入的数据

3.现象:具体的错误描述,包括界面显示、错误信息

      

Bug记录是测试人员工作的基本内容,也是测试和开发交流的基础,确保了Bug描述的有效性,即可提高Bug的修改速度,也可提高Bug的修改质量。而作为测试人员在Bug描述中出现错别字就如同开发人员在程序中出现界面上的Bug一样,完全是不细心造成的,对于测试人员来说是不应该出现的。

本文地址:http://com.8s8s.com/it/it14197.htm