当测试时间有限，不可能找出所有bug时，该怎么做？

wangwei_0201 · 发表于 2006-5-22 13:23:07

当测试时间有限，不可能找出所有bug时，该怎么做？就是说假如本来有100个bug要找出来，但是只有找出30个的时间，那要怎么去找出这30个？

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

wangwei_0201 · 发表于 2006-5-22 13:23:58

有人说加班当然很对，但从技术上来说该如何做呢？

rockday · 发表于 2006-5-22 14:18:07

只有经验能帮你了吧

simplicity · 发表于 2006-5-22 16:39:00

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

Tender · 发表于 2006-5-23 09:19:30

你怎么知道有100个？假设的吗？那我假设只有30个，你不是成了很出色的测试人员？

Leon · 发表于 2006-5-23 13:12:02

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

卡卡西 · 发表于 2006-5-25 13:32:49

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

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

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

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

肚子 · 发表于 2006-5-25 14:14:51

什么叫“所有BUG”
那么是多少个呢？
你的标准是什么？

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

顶楼上二位朋友的回复

langzi1209 · 发表于 2006-5-25 14:38:27

建议不写测试用例就开始测试，如果前期已经设计了测试用例，那就只能捡重要的测了

swallow0918 · 发表于 2006-5-25 16:31:09

一个软件产品测试之前是不知道到底存在多少bug的。（可能可以根据以往的经验得出大概的数字）

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

舞の月 · 发表于 2006-5-26 09:48:41

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

cybercop · 发表于 2006-5-26 16:51:28

同意7楼的,有些风险是甲乙双方共同承担的,其中就包括BUG

xiaoming-01 · 发表于 2006-5-29 22:44:41

偶觉得应该走主要的流程，按你的说法，30/100，保证软件的最常用的部分你测到了，最短时间内的测试才能称为有效的。。。

guolm1225 · 发表于 2006-5-30 20:45:04

时间有限就该从重点开始测试吧。。。

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

lgs0540 · 发表于 2006-5-31 12:09:12

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

ivylisia · 发表于 2006-5-31 14:54:41

楼上的，讲得很好

crazysusan · 发表于 2006-5-31 16:01:27

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

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

很正确的一句话。

恢恢 · 发表于 2006-5-31 17:30:30

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

Nio · 发表于 2006-6-1 12:49:24

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

wangwei_0201 · 发表于 2006-6-1 16:15:12

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

		自动登录	找回密码
密码			(注-册)加入51Testing

[讨论] 当测试时间有限，不可能找出所有bug时，该怎么做？

相关帖子

站长推荐 /1