请问你公司有没有制定ＢＵＧ标准？？

zazah

公司是我一个人测试，我想制定一些ＢＵＧ标准，不知道你们公司有没有制定一些ＢＵＧ标准，
这样在测试过程中有章可循？？请大家在这里说说！

zazah

欢迎大家讨论！！

xianyan8

标准是在经验测试之后形成的,不过在大型软件上是不建议采用的.

zazah

请问为什么呢？
个人认为要有，因为在测试人员测试出ＢＵＧ后，没有标准，开发人员就可以以各种理由不修改ＢＵＧ．

xyxykitty

我个人倒觉得：bug的标准是根据开发的规范来定的

zazah

对，有道理．

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

开着拖拉机上班

当然有标准了！！
我们公司的标准如下：

****网络科技有限公司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

谢谢楼上的分享

xukcect

太感谢7楼的朋友啦，最近一直想找些这方面的资料。呵呵

cxunxun

当然要有了呀，至少呀，而且第个项目的bug都应该有专门的档案室，已便将来查询是吧！！！
呵呵

11034

这个标准是要看具体项目或产品的，不能一概而论的。

还是要和PM协商制定

rainbow111

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

stjd139

需要标准的

chech28

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

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

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

testcat

我觉得Bug确实要有一个参考标准，谢谢7#提供的

muyang327

还是有标准好一点.

cqy08

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

elan27

我们也是这样,这边开发很成熟了
测试才起步呢
不过公司比较重视测试的,慢慢正规起来了

zazah

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

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

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

I_hui

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