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

lim_raol

请各位帮忙投个票（可以多选哈，多发表意见 ）：
A:  Bug必须是通过“测试用例”发现的
B：大于50%的Bug都是通过“测试用例”发现的
C：大于50%的Bug都是“自由测试”发现的
D：其实用例一般发现的bug很少，都是基本功能，发现bug还是要靠自由测试、压力测试等

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

wangxiwei18

我现在的情况选D

六月天

看是什么开发模型了。
按照传统的V模型，缺陷就应该是用例发现的，哪有什么自由测试，你说的那是野路子。压力测试难道就不写用例了？一样是有用例的。用例庞大是应该的，一个项目4-5千条用例算什么呢？（百万行代码的项目）
如果是敏捷开发，那用例不是用来发现缺陷的，是用来指导开发的，测试人员先写完用例，然后把用例丢给开发，告诉他们做开发的时候以用例为依据，主要就是为了通过用例，开发完了让他们自己先跑跑用例，都过了再提交配置库。

lim_raol

回复 3# 六月天


    我们的项目周期最短20天，长的也超不过2、3个月。我说的自由测试就是test camp。

六月天

回复 4# lim_raol


    20多天，够好好写用例了啊。一点问题没有。所有的测试执行必须有用例，这是毫无疑问的。否则测试部门的积累在哪里？即使你是在执行测试用例的过程中临时想出来的一个测试，你也应该补充一条用例到用例集里面去。

lim_raol

回复 5# 六月天


    20天中，至少有12天在开发。。。

Jackc

其实大可不必纠结于bug是怎么被发现。 反正目前国内的项目，要做到用例发现80%的bug，估计这单子早就被别人抢去了。

所以，不管用了什么样的方法，最终保证客户&用户的 bug发现率低于标准就OK了。
在国内这种拔苗助长的项目开发环境中，只有捉到老鼠的才是好猫。

当然，即使是1个1周的项目，也是可以写好用例，只是看你怎么利用已有资源和测试策略规划而已。

六月天

回复 6# lim_raol


    用例设计是和开发并行的，等他们开发完了再写用例，那不是太迟了吗

lim_raol

回复 7# Jackc


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

lim_raol

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

lim_raol

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

lim_raol

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

luming

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

黑羽祭

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

heaven7253

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，他们对于整个产品的质量贡献也要小的多。

以上  个人意见  仅供参考

lim_raol

回复 13# luming


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

joycienet

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

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

刘顺

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

Nexi

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

wuliangye

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