liweilirui 2007-6-26 11:00
测试了三天，BUG你在那里？
功能测试了三天，郁闷怎么就没有bugsdlkfj9
liuwei8558 2007-6-27 15:00
测不出来不代表没有BUG,可能是你的用例对需求的覆盖率不够.
zhangyong 2007-6-27 15:48
重新分析需求
需要对原始需求进行系统的分析，只有懂得了真正的需求才能够有效的测试
zhangyong 2007-6-27 15:49
恶意破坏性测试
xwxw 2007-6-30 12:05
不是吧 软件质量这么高bug都没有呀
yt1985cncn 2007-7-3 19:57
时间多的话,再仔细阅读下需求,看有没有什么功能没实现或多实现了,然后再仔细测一遍,换一种测法.换一种思路,继续加油吧~~
hollyzhao 2007-7-17 00:47
SRS重新深入理解，加油！
limmar 2007-7-19 15:33
重新分析需求，逆向思维，确保测试用例覆盖全面
walker1020 2007-7-20 00:04
请参考 [url]http://bbs.51testing.com/thread-76334-1-1.html[/url]
cangmang 2007-8-28 11:03
换位思考和逆向思维都可以试一下,这个时候千万不要迷惑要有耐心..再检查一下你所用的测试用例是否覆盖全面呢.
紫色梦幻 2007-9-10 17:41
我是新手,我也很难找出BUG,有些BUG是偶然性的,我都不知道该不该提交哦,每次都很犹豫!
anranqingqing 2007-9-11 12:39
偶然性的也该提交的，提交了开发人员可能会知道是什么原因的
我爱大熊 2007-9-16 21:52
不是吧 软件质量这么高bug都没有呀
狩猎者 2007-9-17 13:42
你的功能测试是不是只是走了正常的流程呢？多用些测试方法bug一定会有的！
zhouzxcv 2007-9-17 21:44
o(∩_∩)o...，可以试试别的测试方法，例如白盒sdlkfj1
hellen_ma 2007-9-19 11:55
逆向思维看看,
yagame 2007-9-21 17:52
你的项目组太强了，我还没测呢，BUG自动来找我了。
zhyly101 2007-9-24 13:16
好东西呀。
zhang88614 2007-9-29 21:06
回复 18# 的帖子
呵呵，换个角度考虑，换个测试用例！！多根别人讨论
lsf1007 2007-10-8 15:48
建议去看看以前别人的测试出来的问题 说不定会有启发
dabeixiong 2007-10-8 23:55
思维。。。注意思维。。。不可能没有bug的。。。
qiufeng 2007-10-10 17:10
软件还是会存在BUG的，不可能没有BUG的
willpoi 2007-10-11 20:47
任何软件都不会没有BUG ，这是一个测试人员一定要了解并知道的
注重思维 别老是按照之前的思维模式去进行操作
注重逆性思维 别局限死
bzfyhfyh 2007-10-29 20:32
是软件的不足，还是bug
有的时候好容易发现个bug，但是当提交后，却得到的回复却是这只是个不足。说不影响软件的正常使用就OK了，所以有的时候让人觉得很是郁闷。
julyjin_1 2007-10-31 17:03
复杂的操作一定会出现问题的！
复杂的操作一定会出现的！例如：对手机JAVA下载过程中来电话不接听，再来电话，接听过程中来短信。
julyjin_1 2007-10-31 17:03
边界值也很容易出问题
用边界值测试方法进行测试也很容易出现问题
elan27 2007-11-14 18:08
前期测试的时候发现的BUG很多,也很容易
到后期我等菜鸟就不行了,发现不了什么BUG,要测试经理出手才搞定
rting 2007-11-15 18:02
在看下测试用例，有什么地方没测试到的，或者是测试疲劳了先干干其他事情，
hotivy 2007-11-19 16:26
打开你的待测系统，看看哪里你以前没有点过，没有认真看过，问题就在那里
mallonpsy 2007-12-19 17:43
[quote]原帖由 [i]bzfyhfyh[/i] 于 2007-10-29 20:32 发表 [url=http://bbs.51testing.com/redirect.php?goto=findpost&pid=770443&ptid=80858][img]http://bbs.51testing.com/images/common/back.gif[/img][/url]
有的时候好容易发现个bug，但是当提交后，却得到的回复却是这只是个不足。说不影响软件的正常使用就OK了，所以有的时候让人觉得很是郁闷。 [/quote]
这个需要你去分析需求，看看需求是否有这个功能，有的话就是BUG，没有就不是BUG！
测试出来的BUG不能一味的听人开发人员的定论，自己要心里有数才行。
wzstar2008 2008-1-7 17:23
以现在大多数的开发人员的开发水平而言，没有bug几乎是不可能的，而且bug肯定还是一堆一堆的。
如果测不出bug一般有以下的一些可能：
1、测试用例设计把关不严：也就是说测试用例的覆盖率、和设计思路、以及侧重点有问题；
2、某些bug不是单纯的在系统测试环节可以发现的，很多的bug在单元测试环节和集成测试环节发现起来更容易，成本更低。系统测试的功能测试用例往往是覆盖不到一些特殊情况的，或者说是很难用手工或是自动化脚本来模拟来发现的；
3、测试思路已经形成定势，可以考虑交叉模块进行测试；
欢迎大家补充；
jayees 2008-1-8 16:14
回复 11# 的帖子
做的时候要注意记录步骤
一定要稳定重现的bug才可以提交，不然没有说服力
淡淡烟草味 2008-1-8 16:17
[quote]原帖由 [i]bzfyhfyh[/i] 于 2007-10-29 20:32 发表 [url=http://bbs.51testing.com/redirect.php?goto=findpost&pid=770443&ptid=80858][img]http://bbs.51testing.com/images/common/back.gif[/img][/url]
有的时候好容易发现个bug，但是当提交后，却得到的回复却是这只是个不足。说不影响软件的正常使用就OK了，所以有的时候让人觉得很是郁闷。 [/quote]
不足即是 BUG..希望你们公司的这些人能够学习一下什么叫做 产品的生命质量..任何不足都属于BUG.即使该版本不解决.那么一定要给出哪一个版本去解决.later的BUG要给出时间的..不知道你们有没有项目经理和QA这些角色..
淡淡烟草味 2008-1-8 16:23
[quote]原帖由 [i]紫色梦幻[/i] 于 2007-9-10 17:41 发表 [url=http://bbs.51testing.com/redirect.php?goto=findpost&pid=709073&ptid=80858][img]http://bbs.51testing.com/images/common/back.gif[/img][/url]
我是新手,我也很难找出BUG,有些BUG是偶然性的,我都不知道该不该提交哦,每次都很犹豫! [/quote]
BUG的前提是用例....必须是用例...用例要做到覆盖100%的逻辑(理论上).千行代码至少3个BUG.
kevin_swpi 2008-1-8 17:00
[quote]原帖由 [i]bzfyhfyh[/i] 于 2007-10-29 20:32 发表 [url=http://bbs.51testing.com/redirect.php?goto=findpost&pid=770443&ptid=80858][img]http://bbs.51testing.com/images/common/back.gif[/img][/url]
有的时候好容易发现个bug，但是当提交后，却得到的回复却是这只是个不足。说不影响软件的正常使用就OK了，所以有的时候让人觉得很是郁闷。 [/quote]
你的话说明至少两个问题：一个是什么是BUG，二是如何处理BUG
什么是BUG就不再多说，就说说怎么处理BUG吧，根据你说的提交后被打回并回复为这仅仅是个不足。OK，也就是说程序员不承认这个是个BUG，那么这样的情况你该作什么？
第一，那这个BUG和需求进行核对，如果开发提交的程序明显和需求有出入，则你应该很肯定的理直气壮的再打给开发人员，如果需要则引用出需求来作证。这个时候你一定要坚持自己的立场，如果不修改就坚持不让BUG记录变为CLOSE
第二，如果你发现的这个你认为的BUG在需求上没有明确定义，但你又觉得这样作出来的效果确实不恰当或者说是从另外一层意思上违背了需求，那么在和开发沟通无效的情况下，和你的LEADER进行沟通，然后让LEADER出面来进行协调。如果再有必要，那么LEADER就再和开发的LEADER进行沟通
作测试是应该有自己的立场和处理问题的流程，因为你就是产品的最后一个守门将，不能说开发说什么就什么，对吧：）当然这些都要建立在一个公司有着良好的质量体系的基础上～
red-hat 2008-1-8 23:56
可怜的人,找不到bug的确很郁闷, 建议你多多熟悉一下你的产品(业务),与开发人多交流一下,重新评审和分析需求.重新审视你的case,住院早日找到bug ,找到多多的bug !!好运
asai-oyh 2008-1-21 16:57
重新看需求，确定下用例方面有没什么遗漏或者错误。。。
应该不会找不到bug。。。
adinQueen 2008-1-24 15:00
好好理一遍思路，将功能点罗列清楚，以功能点为单位，将输入条件进行分类，再将输出结果进行分类，遇到条件判断时注意边界值，遇到循环时注意是否会造成死循环，不要只想着正常的输入会产生什么结果，要多想想一些特殊情况的输入数据，多想想不按照常理输入时对异常情况的处理是否正确。然后再考虑下可能还会有什么风险点，也可以请教下同事，看他们测试类似功能时是否出现过一些异常的情况。如果可以看到源代码，自己也懂一些，不防一遍进行功能测试，一遍对代码中的函数进行测试，因为功能性一般都体现再表面，一些内在的实现，比如算法上出现错误，但是却结果正确，不去看代码中的实现就很难察觉了。另外一定要细心，不要因为是已经测试过几遍的功能点，就疏忽大意。往往一个功能点的修改都很有可能引发其它功能的bug。总之，加油！
shineshin 2008-2-1 18:35
测试了3天都没有bug
那就要考虑下是自己不够细心
还是项目实在是质量太高了？
wang_jxiang 2008-3-25 16:29
1.分析需求,了解业务流程.
2.耐心+细心+逆向思维.确实测不出来,不要着急,可以看看其他测试人员的BUG或和他们交流,看测试同样的产品,他们从哪些方面考虑以及着手.
3.功能方面确实测不出来,可以从易用性,用户界面等操作性方面着手,先建立自己的小小信心.(不要看到别人测出来了,自己没测出来,心里就急的不行.一定要静,让自己的头脑清晰.)
不知道说的对不对,一点小建议:)