测试中发现的bug必须是通过用例发现的吗

lim_raol · 发表于 2012-9-12 15:47:58

请各位帮忙投个票（可以多选哈，多发表意见

）：
A: Bug必须是通过“测试用例”发现的
B：大于50%的Bug都是通过“测试用例”发现的
C：大于50%的Bug都是“自由测试”发现的
D：其实用例一般发现的bug很少，都是基本功能，发现bug还是要靠自由测试、压力测试等

我们现在要求bug都通过用例发现，这样的话用例太庞大，而且写用例时产品都没出来，只有产品交互文档和功能说明书，容易遗漏。
但是我们测试说的开发不理解，所以请大家帮个忙，看实际情况软件测试到底是怎样的。谢谢。

123-123-123 · 发表于 2012-9-26 15:29:48

个人认为，bug不一定都要通过用例来发现。探索性测试也很重要。但是如果在探索性测试中发现了bug，一定要做重现步骤地记录。这些重现步骤既是bug描述的部分，也是用例补充的内容。

hongstarw · 发表于 2012-9-25 16:05:48

C或D吧
A肯定不对
大多数bug是在执行测试用例的时候发现的，但是没有写到用例里面；有些bug是因为一些偶然因素，如果全补充到测试用例里面，费时费力，到时候还不一定用得到。

yang1061 · 发表于 2012-9-22 17:31:11

没必要纠结这些，只要顺利保证产品上线，尽量不要出现BUG就OK了

panm123 · 发表于 2012-9-21 15:48:39

其实是由“测试案例”和“自由测试”发现的，有些操作如果按正常的操作方式是发现不了的，这个时候就需要“自由测试”来进行非正常的操作方式。

ygmmlcy · 发表于 2012-9-20 13:59:36

C
用例覆盖的是基本功能、性能外+经典压力、并发、经验用例

用例库是一步步积累而成非一日而成

huilin.gao · 发表于 2012-9-20 12:02:14

我觉得这种东西是没有必要纠结的，要根据团队规模，项目实际情况（简单还是复杂、项目周期长还是短），团队人员情况等等因素综合考虑的。

lim_raol · 发表于 2012-9-20 11:35:05

回复 15# heaven7253

欢迎多来点高人指导下

wuliangye · 发表于 2012-9-17 15:53:48

同意15#所说
测试用例是不断更新不断丰富的，它是一个过程，测试人员设计测试用例的参考文档是SRS，主要覆盖的是核心业务和一些根据测试人员的经验总结出来的测试用例，测试人员的经验有限，没有哪个测试人员在设计阶段就能将测试用例设计的很完整。一般的做法都是在测试过程中不断完善用例，将每个版本中发现的bug补充到用例中，将现场发现的而测试未能发现的issue补充到用例中。
如果开发人员要求是A，Bug必须是通过“测试用例”发现的，那么最终产品上线时就会发现DDP的值会小很多，到时候客户不满意，老板发飙，所有人员，不管是开发还是测试都要忙于救火了。

Nexi · 发表于 2012-9-17 11:48:58

C吧，深圳的小公司，用例也写了不少，测试的过程中会不断修改用例

刘顺 · 发表于 2012-9-14 13:40:52

在实际的项目进行中没有太多的时间去写测试用例即使写了大部分都是正确功能的测试用例对于异常情况的用例较少而发现bug最多的用例是异常用例用例都在测试人员的脑子中

joycienet · 发表于 2012-9-13 11:15:15

确实，bug全部由通过执行测试用例来发现，实际不可能，是一种理想的状态。
如果测试用例发现所有缺陷，测试用例设计将是一个非常严谨而且耗费资本的工作，对于敏捷开发模型来说，研发周期1个月到3个月，测试用例在产品做出来之前就已写好，产品研发好后测试期间自由操作空间比较大，加上需求变更，还需要及时更新测试用例，这个要求更不切合实际。

不过，好的测试用例就是最少的用例发现最多的bug。这是一个度，一个范围，测试用例可以发现60%甚至80%或者更高的缺陷，但是再好的用例也不可能发现100%的缺陷。
测试的目的，说俗了，就是发现缺陷，减少遗漏的缺陷。测试能发现大量的缺陷就行，没必要纠结而且要求通过测试用例来发现，对吧？可以要求测试用例发现缺陷率在一个范围从而提高测试用例的质量，总的目标是产品的质量，尽可能多的发现缺陷，这个才是目标。

lim_raol · 发表于 2012-9-13 10:52:42

回复 13# luming

嗯，确实是。BCD都可选可不选，不是死规定，因产品而异。个人觉得用例复现30%到60%的bug是正常的，太少或者太多都不合理。

heaven7253 · 发表于 2012-9-13 10:38:22

A:  Bug必须是通过“测试用例”发现的
B：大于50%的Bug都是通过“测试用例”发现的
C：大于50%的Bug都是“自由测试”发现的
D：其实用例一般发现的bug很少，都是基本功能，发现bug还是要靠自由测试、压力测试等

A 完全不可能。
能想把所有的bug都通过预先想好的测试用例发现的人是个理想主义者。活着是个不切实际者。空想家。
测试用例首先就是一个可持续发展的集合，大到整个社会，小到开发测试，没人能未卜先知，没人能考虑到100%。测试是整个社会的一个缩影。摆脱那些空想家，请现实些。

B大于50%的Bug都是通过“测试用例”发现的
这个可以实现，但是要有一个漫长的过程。而且要话费巨大的成本
大于50%的bug，意味着测试方案测试覆盖率已经很高了，而测试方案的成熟还有测试覆盖率的提高，完全是依靠一点一点的测试积累。能当上名将的，哪个不是从小兵一步一步走不来的？举个例子吧，上次有个很小的手机小程序，只有三个界面，两个button，结果光健壮性测试用例，是 4*4*3*4*3*107=61632（未做合并同类项的初步判断表），要执行的话要两个人执行一个月。覆盖率很高了吧，但是也就只有40%相对于整个社会环境。回归正题，但是这样值得么？话费巨大的人力物力来提高测试覆盖率，但是能提升的质量也才只有5%不到。  这个社会是讲究成本与质量的平衡的。一切从项目实际出发吧，还是举例一个手机程序，知道不，每个星期有多少个新程序出来？每个周有多少个程序淘汰，一个手机程序，一个产品的生命周期如次，我们何必做超过整个产品生命周期的事情，吧所有精力放在质量主干上，也许跑一轮case连一个bug也没出来，但是我们测试可以100%确定，这个产品的质量基本属性，例如功能性完整性是没问题的，质量至少能保证60。有闲暇的时候再去在一定的effort下做一定的提高。切莫转牛角尖。

C：大于50%的Bug都是“自由测试”发现的
这个是目前很多项目的实际情况。
没啥好说的，只是这些发现问题的自由测试，一定要合并整理到测试用例中去。

D：其实用例一般发现的bug很少，都是基本功能，发现bug还是要靠自由测试、压力测试等
这个是现实  （压力测试应该在基本用例集合之中）
这句话我感觉主要就是在说  何为质量
bug 的多少根质量有关，但是一定要分清  用例以及free Testing 提供的质量。
能写成衰弱性测试的都是最基本最主要的用例集合，他们就是这个软件产品的大部分生命和脊梁所在。没有这些用例，哪怕free test里面测出1亿个bug，他们对于整个产品的质量贡献也要小的多。

以上  个人意见  仅供参考

黑羽祭 · 发表于 2012-9-13 09:34:54

一般D能发现的BUG比较多
用例是用来检测已发现的问题
如果发现了新的BUG，会将复现步骤加至测试用例库中

luming · 发表于 2012-9-12 19:23:41

A肯定不对，BCD可以选也可以不选。

lim_raol · 发表于 2012-9-12 17:42:44

大家帮忙答复下选哪个就好了，我也不是专业人士，只想说明“是不是所有bug都是用例跑出来的”，讨论其他的没用。

lim_raol · 发表于 2012-9-12 17:42:38

大家帮忙答复下选哪个就好了，我也不是专业人士，只想说明“是不是所有bug都是用例跑出来的”，讨论其他的没用。

lim_raol · 发表于 2012-9-12 17:40:07

回复 8# 六月天
用例是在开发出产品之前，根据产品文档写的。

lim_raol · 发表于 2012-9-12 17:39:30

回复 7# Jackc

嗯，我觉得也是，只要质量过关，最后没有bug遗漏就好了。

		自动登录	找回密码
密码			(注-册)加入51Testing

[求助] 测试中发现的bug必须是通过用例发现的吗

相关帖子

站长推荐 /1