51Testing软件测试论坛

标题: 请问你公司有没有制定ＢＵＧ标准？？ [打印本页]

作者: zazah 时间: 2007-11-1 14:56
标题: 请问你公司有没有制定ＢＵＧ标准？？
公司是我一个人测试，我想制定一些ＢＵＧ标准，不知道你们公司有没有制定一些ＢＵＧ标准，
这样在测试过程中有章可循？？请大家在这里说说！

作者: zazah 时间: 2007-11-1 15:07
欢迎大家讨论！！

作者: xianyan8 时间: 2007-11-1 15:41
标题: 经验主意
标准是在经验测试之后形成的,不过在大型软件上是不建议采用的.

作者: zazah 时间: 2007-11-1 15:51
标题: 回复 3# 的帖子
请问为什么呢？
个人认为要有，因为在测试人员测试出ＢＵＧ后，没有标准，开发人员就可以以各种理由不修改ＢＵＧ．

作者: xyxykitty 时间: 2007-11-1 15:58
我个人倒觉得：bug的标准是根据开发的规范来定的

作者: zazah 时间: 2007-11-1 16:15
标题: 回复 5# 的帖子
对，有道理．

目前公司开发还没有规范，所以测试的时候，测试了ＢＵＧ，开发人员不屑，比如输入框字符长度，特别符号，去左值等不处理？？这些应该要做控制吧？？

作者: 开着拖拉机上班 时间: 2007-11-1 16:38
当然有标准了！！
我们公司的标准如下：

****网络科技有限公司BUG定级标准
BUG级别       说明
1级：严重缺陷使系统瘫痪或不能继续使用、主要功能未能实现的缺陷：
1、       需求规格说明书中的重要功能未实现；
2、       造成系统崩溃、死机,并且不能通过其它方法实现功能；
3、       常规操作造成程序非法退出、死循环、通讯中断或异常，数据破坏丢失或数据库异常、且不能通过其它方法实现功能的。
4、       重要功能基本能实现，但系统不稳定、一些边界条件下操作会导致系统异常、数据丢失或破坏等错误；
5、       重要功能不能按正常操作实现，但通过其它方法可实现；
6、       错误的波及面广，影响到其它重要功能正常实现；
7、       客户端某些操作可造成服务端不能继续正常工作的。
2级：比较严重的缺陷次要的功能不能实现，界面不友好、给用户反感的内容。
1、       次要功能不能正常实现；
2、       操作界面错误（包括数据窗口内列名定义、含义不一致）；
3、       打印内容、格式错误；
4、       查询错误，数据错误显示；
5、       简单的输入限制未放在前台进行控制；
6、       删除操作未给出提示；
7、       数据库表中有过多的空字段；
8、       因错误操作迫使程序中断；
9、       数据库的表、业务规则、缺省值未加完整性等约束条件；
10、       经过一段时间运行后，系统性能或响应时间会变慢；
11、       重要资料，如密码未加密存放（包括配置文件中的密码），或其它存在安全性隐患的；
12、       硬件或通讯异常发生恢复后，系统不能自动正常继续工作（需要过多的人工干预才行）；
13、       系统兼容性差，与其它支持系统一起工作时容易出错，而没有充分理由说明是由支持系统引起的；
14、       UI风格不统一,设计不合理，文字错误，标点错误，给予的提示模糊不详,响应速度太慢；
15、       辅助说明描述不清楚；
16、       输入输出不规范；
17、       长操作未给用户提示（或长操作结束后提示没有消失）；
18、       提示窗口文字未采用行业术语；
19、       可输入区域和只读区域没有明显的区分标志；
3级：一般缺陷缺少相应icon提示,画面颜色偏淡, 画面颜色偏深,测试人员给予的建设性的建议或需求未明确的内容。
4级：需求变更可以提高产品质量的建议，
包括新需求和对需求的改进。

注：
1级缺陷必须立即进行处理。
2级缺陷在下次更新必须给予处理，如历史遗留问题难以解决的，需要会同部门经理、需求经理及技术委员会共同研究后进行裁决。
3级缺陷项目组内需要给出相应处理意见。
4级缺陷需要需求部门进行确认，由项目经理、需求经理和部门经理商讨后决定需求变更的时机（本次修改变更或下一版本实现）。

作者: zazah 时间: 2007-11-1 16:56
标题: 回复 7# 的帖子
谢谢楼上的分享

作者: xukcect 时间: 2007-11-1 17:31
太感谢7楼的朋友啦，最近一直想找些这方面的资料。呵呵

作者: cxunxun 时间: 2007-11-1 17:38
当然要有了呀，至少呀，而且第个项目的bug都应该有专门的档案室，已便将来查询是吧！！！
呵呵

作者: 11034 时间: 2007-11-1 17:47
这个标准是要看具体项目或产品的，不能一概而论的。

还是要和PM协商制定

作者: rainbow111 时间: 2007-11-1 18:40
7楼说得很全面，呵呵，楼主可以根据自己公司的情况进行选择，调整了。
可以和PM或者开发部经理一起制定，更加有说服力，执行起来少一些异意。

作者: stjd139 时间: 2007-11-1 20:30
需要标准的

作者: chech28 时间: 2007-11-1 21:18

原帖由 zazah 于 2007-11-1 16:15 发表
对，有道理．

目前公司开发还没有规范，所以测试的时候，测试了ＢＵＧ，开发人员不屑，比如输入框字符长度，特别符号，去左值等不处理？？这些应该要做控制吧？？

很简单，他如果不改，那么在那个bug上他要留下resolution后者reject的理由，然后你可以要求把这个加入DDS和文档。比如“不支持特殊符号+=-”。然后你就算进到责任了，留给这个bug的stakeholder决定了。

作者: testcat 时间: 2007-11-2 10:28
我觉得Bug确实要有一个参考标准，谢谢7#提供的

作者: muyang327 时间: 2007-11-2 12:07
还是有标准好一点.

作者: cqy08 时间: 2007-11-2 13:18

我们也还没制定标准，但是随着公司的逐渐规范，会慢慢有一套标准的

作者: elan27 时间: 2007-11-2 14:29
我们也是这样,这边开发很成熟了
测试才起步呢
不过公司比较重视测试的,慢慢正规起来了

作者: zazah 时间: 2007-11-2 18:08

原帖由 chech28 于 2007-11-1 21:18 发表

很简单，他如果不改，那么在那个bug上他要留下resolution后者reject的理由，然后你可以要求把这个加入DDS和文档。比如“不支持特殊符号+=-”。然后你就算进到责任了，留给这个bug的stakeholder决定了。

你说得有道理，可是难过的是：公司现在还没有BUG管理工具，到现在还是用文档记录BUG。。。很不正规。。。。

作者: I_hui 时间: 2007-11-2 20:43
应该说没有规矩不成方圆，我就觉得7#的说的很全面。
就照测试书籍上的那些bug 标准也就分了五个等级。
所以在加上一点点的见解就可以成为你们的标准了！

作者: dqar 时间: 2007-11-5 17:22
没有

作者: h5y6w8 时间: 2007-11-7 02:37
每次逛论坛都有收获
感谢7楼的提供

作者: tanshanghua 时间: 2007-11-7 11:21
学习

作者: dahema 时间: 2007-11-8 14:34
标题: 回复 7# 的帖子
感谢七楼提供的好东西!
DING

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)