51Testing软件测试论坛

标题: 测试了三天，BUG你在那里？ [打印本页]

作者: 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
请参考 http://bbs.51testing.com/thread-76334-1-1.html

作者: 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

原帖由 bzfyhfyh 于 2007-10-29 20:32 发表
有的时候好容易发现个bug，但是当提交后，却得到的回复却是这只是个不足。说不影响软件的正常使用就OK了，所以有的时候让人觉得很是郁闷。

这个需要你去分析需求，看看需求是否有这个功能，有的话就是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

原帖由 bzfyhfyh 于 2007-10-29 20:32 发表
有的时候好容易发现个bug，但是当提交后，却得到的回复却是这只是个不足。说不影响软件的正常使用就OK了，所以有的时候让人觉得很是郁闷。

不足即是 BUG..希望你们公司的这些人能够学习一下什么叫做产品的生命质量..任何不足都属于BUG.即使该版本不解决.那么一定要给出哪一个版本去解决.later的BUG要给出时间的..不知道你们有没有项目经理和QA这些角色..

作者: 淡淡烟草味 时间: 2008-1-8 16:23

原帖由 紫色梦幻 于 2007-9-10 17:41 发表
我是新手,我也很难找出BUG,有些BUG是偶然性的,我都不知道该不该提交哦,每次都很犹豫!

BUG的前提是用例....必须是用例...用例要做到覆盖100%的逻辑(理论上).千行代码至少3个BUG.

作者: kevin_swpi 时间: 2008-1-8 17:00

原帖由 bzfyhfyh 于 2007-10-29 20:32 发表
有的时候好容易发现个bug，但是当提交后，却得到的回复却是这只是个不足。说不影响软件的正常使用就OK了，所以有的时候让人觉得很是郁闷。

你的话说明至少两个问题：一个是什么是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.功能方面确实测不出来,可以从易用性,用户界面等操作性方面着手,先建立自己的小小信心.(不要看到别人测出来了,自己没测出来,心里就急的不行.一定要静,让自己的头脑清晰.)
不知道说的对不对,一点小建议

作者: 测霸 时间: 2008-5-6 15:16
3种可能：
1、软件功能太简单
2、开发人员太牛X了
3、测试人员的经验不足

作者: enya_wly 时间: 2008-5-15 17:35
看到大家的回复真是受益匪浅

作者: caixing801929 时间: 2008-5-23 18:24
你可以套用那些测试方法，和21中障碍模型。

作者: yuwei998877 时间: 2008-6-18 10:18
随机BUG也要提交的

作者: 默默巫1 时间: 2008-11-5 11:49
努力菜鸟

作者: 61168826 时间: 2008-11-7 10:44
继续加油

作者: 10885 时间: 2008-11-14 16:11
质量再高也一定会有BUG，加油，用例很重要

作者: toshiba 时间: 2008-11-18 08:11
很有可能是你的需求分析不全面，不要着急，慢慢来···

作者: hxc21st 时间: 2009-3-18 12:34
功能的流程你清楚了没有？功能对应的标准你掌握了没有，我不相信会没有BUG，除非是后来的回归测试。
我们的新功能BUG非常多的。

作者: xavier_007 时间: 2009-4-21 16:47

看到大家的发言，感觉测试发展的前景
就事论事：
建议：避免测试的随意性，根据需求设计好tc,结合多种方法和测试工具，有机会多看些书籍，最好是英文原版的
同时了解下棋他的知识：业务/管理/技能
厚积薄发，加油

作者: yanjiekay3 时间: 2009-5-11 16:30
开始做测试的时候，一天找一个BUG，就很强啦！
现在，找bug得心应手啦，主要的经验就是，总结，思考，接着总结。

作者: askyahoo 时间: 2009-11-26 13:06
想测么，bug一大堆，只不过有些bug开发不认账

作者: sallytest 时间: 2011-1-31 17:40
要熟悉流程和需求，这样测试时才会用逆向数据来测试，

作者: maojuan110 时间: 2011-2-21 22:53
BUG没那么好找滴！

作者: 楠族开心果 时间: 2011-2-24 17:42
其实bug少有时候是好事，说明开发水平高

作者: kadw85 时间: 2011-3-14 10:45

作者: xiaozuo1010 时间: 2011-3-21 14:48
只要你觉得是BUG就提交。不是也没事

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