测试用例和工作量.

guo780329

测试的本身不太复杂, 但是如果只是一味的运行测试运例, 工作会越来越枯燥. 如果以开发的观点做测试的话, 会发现不少有创意性的 bug .

大部分人人为测试用例是测试比较中要的一部分, 测试人员应该严格按照测试用例来执行测试. 其实测试用例并不能覆盖所有的测试点. 重复不断的运行测试用例只会造成时间和金钱的浪费. 还容易使测试人员产生一种依赖情绪, 我只要在运行测试用例是没有发现问题, 就算通过测试了. 这属于被动测试.效果不是太好. 其实测试用例只是一个说明书, 告诉有那些功能可以用, 参数范围. 做为测试人员应该基于这些理解从自己的角度出发去设计一些测试. 不同的参数组合, 不同的操作方法, 只要你觉的作为用户可以用到的地方就可以去试一下. 测试人员应该从超级用户的观点出发去做测试. 要敢于脱离测试用例. 要想做一个好的测试工程师, 那就必须去发现一些别人没有发现的问题.

还有的规定测试人员每天必须发现多少个问题. 这也是一个误区. 软件产生的 bug 和时间是不成正比的. 发现的问题只能是越来越少. 如果定性的规定每天发现多少个, 势必大大打消测试人员的积极性, 今天发现了 10 个 bug , 应该发现5 个, 剩下 5 个明天提交. 这样一来, 硬性规定的作用适得其反了. 随着软件开放进程的推进, 问题肯定会越来越少, 应该在测试的初期发现比较多的一般性的问题, 后期一般性的问题少了, 应该做一些 adhoc 的测试, 发现比较多的一般用户难以发现的问题.

个人看法....

shanxi

人员素质 本来就很难保证

tongke

运行用例多了可以发现用例也有不完善的地方,可以逐步完善.......

pulamu

ding

millionaire

楼主写的不错,顶一个
其实对于很多测试团队,如何评价每位员工的工作成绩,确实需要商榷... 仅仅用BUG的数量肯定是不对的.
大家看呢.

ahjian699

我感觉通过BUG数量来衡量工作量的方法的确值得商榷，测试用例为通过为一个BUG，但是测试用例通过同样也是很重要的，虽然我们没有发现BUG，但是我们可以保证客户在使用这个测试用例所涉及到的功能时不会出现BUG，同样我们执行通过的测试用例也应算作测试人员的工作量。这就对测试用例的编写提出了更高的要求，只要编写的测试用例覆盖率增加了，那么测试人员的工作就会在无形之中得到别人的认可。（个人意见，仅供交流…………）

aks_lg

在测试刚开始的时候，发现的BUG会比较多。随着测试用例的重复运行，后期发现的BUG会越来越少，这时可以制定一些奖励制度（奖励的形式可以是多样的），给发现BUG的人一些奖励，这样可以调动大家的工作积极性，同时也有助于提高整个项目的测试质量。呵呵！（个人意见，仅供参考）

cgoods

我也参给组员这么讲,一味执行用例会固化思维,(当然认真执行几遍用例是应该的),测试主要靠发散思维和想象力,"跟着感觉走"的测试也是一种不错的方法哦