查看完整版本: 大家在项目的测试过程中进行交叉测试吗？效率好不好？

大家在项目的测试过程中进行交叉测试吗？效率好不好？

交叉测试我觉得是一种很好的方式，因为在一个测试员在长时间测试一个模块的过程中，很可能被模块开发者的思想所同化，从而产生了思维定势，虽然在某种条件下可以依据对系统的熟悉程度下发现流程性以及业务性的bug，但由于对某一系统操作熟悉，却很少能发现一些易用性、校验、数据等方面的错误，有时候在这种情况下有些测师人员也懒得在去动自己的脑子去发现此类问题，觉得只要流程正确，其他的都是小问题，其实不然！
   在这种情况下进行交叉测试时提高测试质量的一种很好的方法，同时也是提高士气的一种有效错误，由于对新接手的模块进行测试，首先，最少可以让测试人员可以积极的发挥自己的想象力，充分的对新模块进行测试。其次，新的测试者或许跟以前的模块测试者占的角度不一样，关注点不一样，也能发现很多以前没有发现的错误。
   所以，我觉得在一定条件下进行交叉测试也是一种很好的方法。

没有。
原因：
好像是忙、也好像是懒、好像公司没有这样要求、好像怕影响关系 。。。

其实交叉测试还是很不错的，有一个前提就是测试用例要步骤详细，否则是浪费大家的时间，步骤详细也不是那种繁琐型的，这个也是因人而异，团队的水平（指的理解能力）都不错的话可以稍稍的简单一点；交叉测试可以集多个人的思路去考虑某一个模块，使测试更加完善

先前的项目中确实有过交叉测试，但是好像最后起的作用不是很大，要是每个人负责的模块比较多的情况下，大家交叉起来光熟悉的时间就会很长，所有效果也就不是很明显了:)

在我们测试组中，我就实施过交叉测试，一个测试员在一个测试模块中，已经形成了固定思维，很难发现新bug，而且容易造成厌倦心里，觉得枯燥乏味，没新鲜感，甚至有时候有些测试用例结果直接填写pass的情况，所以我会让测试其他模块的测试员跟这个测试员交换测试，两个人都能发现新的bug，也可以检验出test case的不完善，很有用的方法。

有利有弊

时间富裕的情况下，可以实现交叉测试；时间金基德情况下，根本来不及；
交叉测试 容易让人推卸责任，但有利于发现更多的Bug， 利弊各半

我们没有实施这个。

为什么不在需求评审、测试用例review方面多下功夫呢？

另外，交叉测试的责任后逃逸的BUG 该谁负责呢？什么时候让B交叉测试A 的工作呢？

呵呵，项目本身是短、急的、且2个人不是互相熟悉业务的，这个交叉测试意义不大。

时间充足的情况下可以这样做，但是时间紧迫的情况下，一般没有做交叉测试。