51Testing软件测试论坛

标题: 最近找不到bug了~~ [打印本页]

作者: small_mouse    时间: 2006-6-30 13:23
标题: 最近找不到bug了~~
测试阿测试,最近发现都是好的,没有什么bug。自我感觉模块运行正常。可是越是这样感觉,越是觉得里面肯定还有bug,只是我没有发现,是不是视觉疲惫了?
有高手指教下,谢谢!
作者: yangkinki    时间: 2006-7-3 12:14
测试有个退出标准,如果符合了测试退出准则,那么楼主就不会有以上的困惑了
作者: songfun    时间: 2006-7-3 12:23
找不到bug 是否跟测试用例的设计有关?如果在已有的用例上不停的run,那得考虑一下了。
作者: Salanganezhou    时间: 2006-7-13 16:32
"测试退出准则",有明确的规定和定义吗?
作者: Salanganezhou    时间: 2006-7-13 16:39
对于Windows开发环境下的软件全面的测试有哪些方面?我已经对他做了基本的功能测试及内存的使用测试,觉得这样的测试太肤浅,偶是新手知道的很少,望大家多多指教!!
作者: Salanganezhou    时间: 2006-7-13 16:56
标题: 找了一点关于“测试结束的标准”
When to stop testing 的5个基础标准:(Lee Copeland "A Practitioner's Guide to Software Test Design")

1。 是否达到原先定义的覆盖标准。
        比如原先定义测试95%的功能条目,测试100%的需求条目,只对接口类做集成测试等等。达到标准了就停。

2。 所发现的缺陷 (bug或者功能不足等等)低于预先定义的上限。
        比如定义每周发现的缺陷少于5个,即可停止。

3。 找到缺陷耗费的代价超过这个缺陷可能导致的损失

       这个的依据是:权限开始好找,越到后面越难找。具体操作的时候可以根据公司实际情况来定义什么样的情况算是“花费的代价大”

4。 团队集体同意(开发,管理,测试,市场,销售人员)

     由于利益和市场的原因,必须推出产品了。哪怕有bug也得上了。

5。 老板叫停

      他嘴大,不能不停。

前三条针对技术层面。后两条针对管理层面。从技术层面上说事先定义标准很重要。从管理层面说,头头们要把握好软件交付的时间表。
作者: kelefage    时间: 2006-7-20 20:10
楼上的有参考价值啊
作者: hayerk    时间: 2006-7-23 15:18
原帖由 Salanganezhou 于 2006-7-13 16:56 发表
When to stop testing 的5个基础标准:(Lee Copeland "A Practitioner's Guide to Software Test Design")

1。 是否达到原先定义的覆盖标准。
        比如原先定义测试95%的功能条目,测试100%的需求条目 ...

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
这句话不明白.功能条目不是写在需求里的吗?需求都覆盖100%了,功能怎么会只覆盖95%.
另外,如果原先定义的覆盖标准是95%的标准的话,那么怎么选择这5%呢?
作者: 小李美刀    时间: 2006-8-1 19:17
如果你有多年的测试经验, 当找不到BUG, 有感觉肯定还有BUG 的情况下, 那就要想到换位思考, 肯定还能发现新的BUG. 因为BUG 是永远也找不完的, 也是一定存在的.
作者: wgs0923    时间: 2006-8-14 16:57
BUG是肯定还会有的,只是目前的测试手法,手段,用例等,发现不了而已,如果现在的α测试已经通过的话,也可以进入下一轮的β测试,甚至是第三方的测试评估等!
一个成熟和比较完善的产品,需要经过长时间的考验,才可以获得和稳定的!
作者: wheetle    时间: 2006-8-16 20:17
原帖由 hayerk 于 2006-7-23 15:18 发表

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
这句话不明白.功能条目不是写在需求里的吗?需求都覆盖100%了,功能怎么会只覆盖95%.
另外,如果原先定义的覆盖标准是95%的标准的话,那么怎么选择这5%呢?


首先,这里不是说功能只覆盖95%,而是说只测试95%的功能条目。关于5%的选择,就是公司具体要求了。比如今天老板说,我们只有2天时间测试了,不可能全都测,就这重要的95%测试一下吧,剩下不中要的5%算了。

在比如一个软件有15个窗口,共100个菜单选项,交给测试人员前,开发部已经做了冒烟测试。测试部又没那么多时间测试全部100个选项了。怎么办呢,其中的15个“About"项就不测了。
作者: yuxuan555269    时间: 2007-11-28 15:11
又来学习了
作者: 海盗卉子    时间: 2007-11-29 16:23
首先,bug是不可能穷尽的,而且开发在fix bug的过程中,很有可能带来新的问题。所以测试是不可能一直持续下去,而是应该有一个阶段。每个mile stone都应该有一系列的标准,达到要求则可以通过,进行下面的工作。

在接近既定的mile stone的时候,更需要控制代码的更改,以免带来比fix bug更严重或者不可估计的结果。这个时候需要做risk 的分析,影响不是很大的问题可以defer到下一个release,而严重的问题则必须要fix。

测试了一段时间,必然会出现测试的盲区,这个时候cross test是一个比较好的方法。
作者: calm0911    时间: 2007-12-10 16:07
我最近也是一样,今天一天没发现BUG,感觉有点小麻木,就是不放心我测试的系统
我得换个思路思考问题
一个成熟和比较完善的产品,需要经过长时间的考验,才可以获得稳定的!
这句不错
作者: jiangly    时间: 2007-12-18 14:46
恩,的确,找不到bug很郁闷,找到bug 开发人员又说是数据问题引起的,现状如此不修改.......
怎么才能换位思考呢?
作者: yanfangcheng    时间: 2008-1-15 15:50

作者: bzfyhfyh    时间: 2008-1-25 22:25

作者: webview    时间: 2008-2-14 17:29

作者: webview    时间: 2008-2-14 17:31
看看产品设计文档,说不定能被你抓出几个漏洞,要不跑服务器去敲命令做几个小动作看
作者: tiger_86    时间: 2008-2-28 17:07
要重新的思考,重新的来过
作者: pride    时间: 2008-4-23 16:30
标题: opionion
这是心理得原因,该从心理去克服了
作者: yhfeifei    时间: 2008-4-23 21:26
我 最近也有这样的感觉
觉得没什么测的
不知道是不是不想按流程走。。。看到那么多测试用例。好晕
作者: yidianxing    时间: 2008-4-24 13:44
是不是已经作为产品发布了?
而且又是好久没有什么大 的改动啊??
作者: linuxsky2008    时间: 2008-6-25 10:59
个人认为还是重点看看测试用例,是不是还有什么没想到的用例,因为就算按需求走的话,应该也会有遗漏的,需求也是人写的!    可以换个思路,想想! 呵呵!   至于测试停止标准,每个公司都不太一样,但大致都和上面那位五条仁兄说的差不多!
作者: wendiwu    时间: 2008-7-10 20:16
试试换位思考,不从常理出发或许会有新的发现~~
即用所谓的探索性测试:)
作者: daijianfeng    时间: 2008-8-13 13:35
需要换位思考了,可能你在你测的模块已经思维定势了,在软件产品中是不可能没有bug 的
作者: 阿七    时间: 2008-8-14 18:07
汗   这坟挖的真深
作者: warriorstar    时间: 2008-8-19 11:52
呵呵,按测试计划和上级安排的测哈,虽然BUG是没有穷尽的,但是我们测试是有结束的时候的
作者: 燕子东南飞    时间: 2008-8-26 10:11
关键是测试的覆盖率决定,在一开始的测试用例的设计和测试计划的设计中以对这些做了系统测试结束的标准,到最后的回归测试要看的是bug的在系统中的严重程度来决定测试的范围和标准。
作者: 蜜香豆810    时间: 2008-8-27 11:23
难道测试之前没有测试计划吗?
测试的入口和出口准则都没有吗?
做测试流程也是相当重要的   测试计划  测试用例  测试报告是比较基本的
什么时候开始易用性测试   什么时候开始功能测试  安全性测试 以及性能测试
易用性测试  之前的调研报告  测试报告 等
。。。。。
作者: ruanyongjie    时间: 2008-8-27 11:28
只要用心找, bug到处都是,就差bug在喊你我在这里!!




欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/) Powered by Discuz! X3.2