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
[quote]原帖由 [i]Salanganezhou[/i] 于 2006-7-13 16:56 发表
When to stop testing 的5个基础标准：（Lee Copeland "A Practitioner's Guide to Software Test Design"）
1。 是否达到原先定义的覆盖标准。
比如原先定义测试95％的功能条目，测试100％的需求条目 ... [/quote]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
这句话不明白.功能条目不是写在需求里的吗?需求都覆盖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
[quote]原帖由 [i]hayerk[/i] 于 2006-7-23 15:18 发表
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
这句话不明白.功能条目不是写在需求里的吗?需求都覆盖100%了,功能怎么会只覆盖95%.
另外,如果原先定义的覆盖标准是95%的标准的话,那么怎么选择这5%呢? [/quote]
首先，这里不是说功能只覆盖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
:victory:
bzfyhfyh 2008-1-25 22:25
:o
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
试试换位思考，不从常理出发或许会有新的发现~~
即用所谓的探索性测试：）
页:
[1]