思维。。。注意思维。。。不可能没有bug的。。。

软件还是会存在BUG的，不可能没有BUG的

任何软件都不会没有BUG ，这是一个测试人员一定要了解并知道的  
注重思维   别老是按照之前的思维模式去进行操作
注重逆性思维   别局限死

有的时候好容易发现个bug，但是当提交后，却得到的回复却是这只是个不足。说不影响软件的正常使用就OK了，所以有的时候让人觉得很是郁闷。

复杂的操作一定会出现的！例如：对手机JAVA下载过程中来电话不接听，再来电话，接听过程中来短信。

用边界值测试方法进行测试也很容易出现问题

前期测试的时候发现的BUG很多,也很容易
到后期我等菜鸟就不行了,发现不了什么BUG,要测试经理出手才搞定

在看下测试用例，有什么地方没测试到的，或者是测试疲劳了先干干其他事情，

打开你的待测系统，看看哪里你以前没有点过，没有认真看过，问题就在那里

引用:

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

这个需要你去分析需求，看看需求是否有这个功能，有的话就是BUG，没有就不是BUG！
测试出来的BUG不能一味的听人开发人员的定论，自己要心里有数才行。

以现在大多数的开发人员的开发水平而言，没有bug几乎是不可能的，而且bug肯定还是一堆一堆的。
如果测不出bug一般有以下的一些可能：
1、测试用例设计把关不严：也就是说测试用例的覆盖率、和设计思路、以及侧重点有问题；
2、某些bug不是单纯的在系统测试环节可以发现的，很多的bug在单元测试环节和集成测试环节发现起来更容易，成本更低。系统测试的功能测试用例往往是覆盖不到一些特殊情况的，或者说是很难用手工或是自动化脚本来模拟来发现的；
3、测试思路已经形成定势，可以考虑交叉模块进行测试；

欢迎大家补充；

做的时候要注意记录步骤

一定要稳定重现的bug才可以提交，不然没有说服力

引用:

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

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

引用:

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

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

引用:

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

你的话说明至少两个问题：一个是什么是BUG，二是如何处理BUG
    什么是BUG就不再多说，就说说怎么处理BUG吧，根据你说的提交后被打回并回复为这仅仅是个不足。OK，也就是说程序员不承认这个是个BUG，那么这样的情况你该作什么？
     第一，那这个BUG和需求进行核对，如果开发提交的程序明显和需求有出入，则你应该很肯定的理直气壮的再打给开发人员，如果需要则引用出需求来作证。这个时候你一定要坚持自己的立场，如果不修改就坚持不让BUG记录变为CLOSE
     第二，如果你发现的这个你认为的BUG在需求上没有明确定义，但你又觉得这样作出来的效果确实不恰当或者说是从另外一层意思上违背了需求，那么在和开发沟通无效的情况下，和你的LEADER进行沟通，然后让LEADER出面来进行协调。如果再有必要，那么LEADER就再和开发的LEADER进行沟通

     作测试是应该有自己的立场和处理问题的流程，因为你就是产品的最后一个守门将，不能说开发说什么就什么，对吧：）当然这些都要建立在一个公司有着良好的质量体系的基础上～

可怜的人,找不到bug的确很郁闷, 建议你多多熟悉一下你的产品(业务),与开发人多交流一下,重新评审和分析需求.重新审视你的case,住院早日找到bug ,找到多多的bug !!好运

重新看需求，确定下用例方面有没什么遗漏或者错误。。。

应该不会找不到bug。。。

好好理一遍思路，将功能点罗列清楚，以功能点为单位，将输入条件进行分类，再将输出结果进行分类，遇到条件判断时注意边界值，遇到循环时注意是否会造成死循环，不要只想着正常的输入会产生什么结果，要多想想一些特殊情况的输入数据，多想想不按照常理输入时对异常情况的处理是否正确。然后再考虑下可能还会有什么风险点，也可以请教下同事，看他们测试类似功能时是否出现过一些异常的情况。如果可以看到源代码，自己也懂一些，不防一遍进行功能测试，一遍对代码中的函数进行测试，因为功能性一般都体现再表面，一些内在的实现，比如算法上出现错误，但是却结果正确，不去看代码中的实现就很难察觉了。另外一定要细心，不要因为是已经测试过几遍的功能点，就疏忽大意。往往一个功能点的修改都很有可能引发其它功能的bug。总之，加油！

测试了3天都没有bug
那就要考虑下是自己不够细心
还是项目实在是质量太高了？

1.分析需求,了解业务流程.
2.耐心+细心+逆向思维.确实测不出来,不要着急,可以看看其他测试人员的BUG或和他们交流,看测试同样的产品,他们从哪些方面考虑以及着手.
3.功能方面确实测不出来,可以从易用性,用户界面等操作性方面着手,先建立自己的小小信心.(不要看到别人测出来了,自己没测出来,心里就急的不行.一定要静,让自己的头脑清晰.)
不知道说的对不对,一点小建议