BUG编写之我见

上一篇 / 下一篇  2007-04-29 09:22:11

BUG编写之我见

以下的内容一定要写清楚,目的只有一个,就是为了节省时间,节省一切可以节省下来的时间,不让浪费时间成为我们加班的理由。

1.             选择操作系统:我做的多数系统都是跨平台的,如果写BUG的时候没把这个选上,那开发人员一定会问你,“为什么你说的这个问题我这里没有出现吗?”然后你在你的环境下操作,BUG还再,你告诉开发人员“在啊,为什么不在呢?”于是……,终于你们达成共识,原来只是在某个操作系统上才出现这样的问题。于是时间就这样浪费了。

2.             选择数据库:此选项一定在存在的原因和操作系统存在的原因一样。

3.             选择BUG的等级:在选择等级的确存在很多主观的原因,但是如果你在测试前期给你的TEAM作过培训的话,我想主观的问题会大大的减少,在一般BUG的定义有五级。第一级出现为重要的模块功能不能实现;有颠覆重大需求的实现,一而再再而三出现的BUG,解释一次什么才是重要功能比如电子商务里的注册功能就是重要功能,如果用户不能注册,那我想这个系统没有存在的意义。那什么是颠覆重大需求的实现呢?比如说我注册一个普通用户系统却给我超级用户的权限,如果出现这样的情况那危害性有多大是可能而知的。为什么给一而再再而三的BUG也定义为一级呢?想想一个相同的BUG出现了三次,浪费的时间是可想而知的,也说明了开发人员对他工作的重视程度不足,如果给这样的BUG定一级,我想这个开发人员应该会记得一辈子,而且今后应该不会再犯这样的错误。第二级是一些主要功能不能实现,除重要功能外出现在USE CASE里的所有功能都是主要功能。第三级,次要的功能不能实现,比如一张页面里的某些BUTTON不能用啊,还要就是输入框不能用之类的问题。第四级,文字表达有错,界面问题之类的。第五级,需求问题,这个可以根据不同BUG管理工具的情况来定义,我只是我们的项目因为常常会出现需求文档没有明确后存在的一些问题,把它定义为五级。

4.             BUG的内容:尽量把内容写得傻瓜一些,这里的傻瓜只的是简单、浅显易懂,所以一定要加入操作步骤。想想看不会有人因为内容太简单而看不懂你的BUG吧。

5.             BUG的内容:一定要写清楚操作的角色,如果你是使用普通用户操作出来的问题,开发人员用超级用户去操作,还能出现选择操作系统时的情况。那又是一个浪费时间的过程。

6.             BUG的内容包括实现结果:出现了什么问题,把问题写在这里。

7.             BUG的内容包括期望结果:把期望结果写清楚,那就不会有开发人员会来问你,那我这个BUG应该什么改的问题了。

   当然了,还有一些必写的选项,这里就不一一说明了,反正这些书本上都说得清清楚楚。我强调上面的几点,那是在做一个美国项目时发现这些重要性的,开发TEAM在美国,测试TEAM在中国,一个BUG编写出一点问题的话,开发TEAM就会发EMAIL过来:“I don’t know……”,然后你又发EMAEL过去:“I mean……”,加上时差,一个问题两天时间才能解决。如果你认真做到以上几点,省下的时间,没事你就看着别的TEAM加班,然后你就偷着乐吧。


TAG:

坚持测试工作 引用 删除 funly   /   2007-05-21 16:28:08
希望大家不要理解错了,我只是把我想要说明的拿出来说明,没说明的不是说这部分就不存在了。还有很多必写的内容。只是很多书上都有了,所以我就没有一一说明
Angel sky 引用 删除 chanygu   /   2007-04-29 10:47:31
title
steps:
expect result:
actual result:
Severity:
found in version
 

评分:0

我来说两句

Open Toolbar