51Testing软件测试论坛

标题: 当测试时间有限，不可能找出所有bug时，该怎么做？ [打印本页]

作者: wangwei_0201 时间: 2006-5-22 13:23
标题: 当测试时间有限，不可能找出所有bug时，该怎么做？
当测试时间有限，不可能找出所有bug时，该怎么做？就是说假如本来有100个bug要找出来，但是只有找出30个的时间，那要怎么去找出这30个？

[ 本帖最后由 archonwang 于 2006-5-23 22:23 编辑 ]

作者: wangwei_0201 时间: 2006-5-22 13:23
有人说加班当然很对，但从技术上来说该如何做呢？

作者: rockday 时间: 2006-5-22 14:18
只有经验能帮你了吧

作者: simplicity 时间: 2006-5-22 16:39
软件是不可能完美的,无论怎么认真地进行测试,总还会有bug的,所以谁也不能确认一个软件到底有多少bug.如果你们公司规定你要找多少bug的话,你只有加班了.

作者: Tender 时间: 2006-5-23 09:19
你怎么知道有100个？假设的吗？那我假设只有30个，你不是成了很出色的测试人员？

作者: Leon 时间: 2006-5-23 13:12
如果你知道有多少BUG的话，那不成了捉米藏的游戏？？
你要做的是选择最重要的，与客户利益最相关的测试用例来执行，而忽略一些相对不太重要的，而不应该考虑找到的BUG数。假设你找到了50个无关痛痒的BUG，相比之两个重要的BUG，显然后者要有意义的多。

作者: 卡卡西 时间: 2006-5-25 13:32
明白楼主的意思，假设100个bug只是个假设，言下之意是有很多问题，但是时间有限，无法完全测试，只能发现其中的一部分。那怎么去发现这最重要的30个bug呢？

这就是“风险管理”需要出场的时候了，所谓“风险”通俗的说就是打赌，当然这个赌是要有技术，经验，合情合理作为基础的。分析过以后，判断哪些模块的问题可能比较大，就把主要力量放在上面，哪些模块的试用频率最高，也要特别注意这些地方。因为时间有限，所以只能在认为最可能出错的地方和最重要的地方找问题。

以后即使在那些不是很重要的模块中发现了问题，对于项目的影响也不是很大。

好了，现在最关键的问题是：那么究竟哪些模块或者功能最容易出问题？哪些模块最重要呢？这个就需要技术贮备和经验积累了。这个就是资深软件测试和新手最大的差别。

作者: 肚子 时间: 2006-5-25 14:14
什么叫“所有BUG”
那么是多少个呢？
你的标准是什么？

没有软件是完美无缺的
你不可能知道这个软件到底有多少BUG
但也不能盲目的去测试

顶楼上二位朋友的回复

作者: langzi1209 时间: 2006-5-25 14:38
建议不写测试用例就开始测试，如果前期已经设计了测试用例，那就只能捡重要的测了

作者: swallow0918 时间: 2006-5-25 16:31
一个软件产品测试之前是不知道到底存在多少bug的。（可能可以根据以往的经验得出大概的数字）

所以在时间不够的情况下，要挑重点部分测试。例如：主要流程能否走通？主要功能（新增、修改、删除等功能）是否都实现？正常情况下系统运行是否有问题等。

作者: 舞の月 时间: 2006-5-26 09:48
既然有找出30个的时间那还担心什么捏，找BUG一个是用例在一个就是经验喽，况且LZ也只是假设有100个，正向Tender说的那样要是只有30个BUG呢，那LZ会很受人崇拜D

作者: cybercop 时间: 2006-5-26 16:51
同意7楼的,有些风险是甲乙双方共同承担的,其中就包括BUG

作者: xiaoming-01 时间: 2006-5-29 22:44
偶觉得应该走主要的流程，按你的说法，30/100，保证软件的最常用的部分你测到了，最短时间内的测试才能称为有效的。。。

作者: guolm1225 时间: 2006-5-30 20:45
时间有限就该从重点开始测试吧。。。

今天看到一句话：如果测试人员一味的追求BUG的数量而不注重BUG的“质量”，测试便会消亡。

作者: lgs0540 时间: 2006-5-31 12:09
1 对于该项目的用途而言，哪种功能最重要 ?
2 哪种功能对用户最明显 ?
3 哪种功能对安全影响最大 ?
4 哪种功能对用户最有用 ?
5 对客户来说，该应用软件的哪个部分最重要 ?
6 在开发过程中，该应用软件的哪个部分可以最先测试 ?
7 哪一部分代码最复杂，容易导致出现错误 ?
8 哪一部分的应用程序是在急迫或在惊恐的情况下开发出来的 ?
9 哪一部分程序与过去项目中引起问题的部分相类似 / 有关 ?
10 哪一部分程序与过去项目中需要大量维护的部分相类似 / 有关 ?
11 需求和设计的那些部分不清楚或不容易读 ?
12 开发人员认为在应用软件中哪些部分是高风险的 ?
13 哪些问题能造成最差的发行 ?
14 哪些问题最能引起用户抱怨 ?
15 哪些测试可以容易地覆盖多种功能 ?
16 哪些测试在覆盖高风险部分的测试时使用时间最少 ?

作者: ivylisia 时间: 2006-5-31 14:54
楼上的，讲得很好

作者: crazysusan 时间: 2006-5-31 16:01

原帖由 guolm1225 于 2006-5-30 20:45 发表

今天看到一句话：如果测试人员一味的追求BUG的数量而不注重BUG的“质量”，测试便会消亡。

很正确的一句话。

作者: 恢恢 时间: 2006-5-31 17:30
我还没听说过一定要找BUG达到一个规定的数目的！
如果非要找BUG凑数，没有一个软件可以做到没有BUG或者来说是完美的！
BUG而且分等级，有的BUG可以归纳为一个方面，提交问题可以当做一个来提交
但公司一定要凑数，我只能拆散开来！
这样下去恶心循环，倒闭不至于！我一定走人！

作者: Nio 时间: 2006-6-1 12:49
楼主的说法，是一种推托之词。
可以设想一下背景：软件经过测试后，依然存在很多（显而易见的）BUG。这时楼主的这句就有了用武之地……
至于楼上诸位的发言，就显得多余了……

作者: wangwei_0201 时间: 2006-6-1 16:15
看来大家都有很多意见，我说了只是一种假设，关键在于如何找出最重要的。说实话，这是面试时考官问我的问题，想请大家给点意见而已

作者: unknow-ask 时间: 2006-6-2 08:54
我个人认为要重点测试，如客户最常用的模块．这个软件重点要完成的功能等．

作者: jihuli5 时间: 2006-6-2 09:54
这就是优先级的问题了，把最常用最重要，失效后对系统影响最大的那部分先测试，然后根据优先级从高到底的顺序依次测试。

作者: yang119345 时间: 2006-6-2 13:14
找出所有bug是不可能的。在时间紧迫的时候先将常用的，重要级别比较高的测试

作者: zfj2006 时间: 2006-6-7 09:42
有主次的进行测试
根据SRS先测试一级需求（此产品一定要具有的功能），再测试2级需求依次类推

作者: garyyes 时间: 2006-6-8 23:15

原帖由 wangwei_0201 于 2006-5-22 13:23 发表
当测试时间有限，不可能找出所有bug时，该怎么做？就是说假如本来有100个bug要找出来，但是只有找出30个的时间，那要怎么去找出这30个？

听说过RBPM吗？Risks Based Project Management ：基于风险的项目管理。在做测试design之前，要做风险分析。大致也像楼上几位所说的差不多。

作者: 云层 时间: 2006-6-9 10:14
处理对用户产生严重影响的，忽略对用户影响小并且使用少的问题

其实就是把所有问题排个优先次序，在有限的时间内处理等级高的

作者: cy6481 时间: 2006-6-9 14:56
同意14楼的,先找到优先级,最常用的和最容易出现BUG的地方先测吧

作者: linvsfen00 时间: 2006-6-9 16:47
标题: 说得真好

原帖由 wangwei_0201 于 2006-5-22 13:23 发表
当测试时间有限，不可能找出所有bug时，该怎么做？就是说假如本来有100个bug要找出来，但是只有找出30个的时间，那要怎么去找出这30个？

说得真好

作者: dlimin2006 时间: 2006-6-9 17:52
标题: 哈哈
经验之谈，

sdlkfj3

作者: 网络游侠 时间: 2006-6-11 16:30
这些你应在你的测试计划中应说明吧，应明确指出测试的入口，测试执行，测试结束这些条件什么时间发生，都应有明确的定义，以及对待工作中异常的事处理办法，而不是真定到了要测试时，才想这些！！！

作者: Lero 时间: 2006-6-13 15:13
优先级
重要程度

作者: kkrt20032003 时间: 2007-7-28 20:57
呵呵这个正规的公司会有一套完整的标准吧

作者: 张翔0325 时间: 2007-7-30 20:32

原帖由 swallow0918 于 2006-5-25 16:31 发表
一个软件产品测试之前是不知道到底存在多少bug的。（可能可以根据以往的经验得出大概的数字）

所以在时间不够的情况下，要挑重点部分测试。例如：主要流程能否走通？主要功能（新增、修改、删除等功能）是否 ...

用美女头像的这位同学所言很有道理，记得上课时老师说过，当时间比较紧张的时候，我们要先挑系统的主要功能进行测试，把级别高的用例先测，级别底的就可以往后推！！！！

作者: xiongxing 时间: 2007-8-2 20:38
感觉ＢＵＧ永远是找不完的，也是未知的，只有尽力多地把它们找出来，你又怎么知道它们确切有多少个呢？那你如果知道不就是已经被找出来了吗？

作者: 藍色飛揚 时间: 2007-8-2 22:05
先保证主要功能的测试通过，再考虑其他的。

作者: pigpigpig444 时间: 2007-8-2 22:14
bug是测不完的　只要完成用户需求说明书上所要求的功能不出错　基本就可以了

作者: dinah968 时间: 2007-8-3 08:46
测试是不可能找到所有的bug的，只能是尽量多的找出而已。

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