测试工作速记3 - 交叉测试

我如果说有一天我灵机一动想到去执行这个做法，那就是在装。这个方法大家都知道，但是不一定会去做，我们立马去做了，主要也是受了些刺激，被别人找到一些问题。于是我们就在想，我们部门有好几个测试小组，为什么我们不自己来个左右互搏呢？
正好双11刚结束的时候有点时间，那好，我们就做做看。最后的结果远超我的预期，在几天的时间里，我们累积发现了63个问题，确认的有效问题47个。有25个模块参与，14个发现了问题。当然这些问题有多种类型，包括一些体验类的问题，有很多是非常有价值的。这结果真是让人又喜又忧，不过从这个方法的角度，是完全的被证明了。

我称这个方法为“换人如换刀”，实际操作中也有一些思考和考虑，不妨拿出来探讨。
1. 很多时候，我们为了工作的效率，深入的了解业务，以及和对口产品和开发的协作，很长一段时间，每个功能点会有一个比较固定的test owner。
这样的好处显而易见，但是缺点也很明显：
- 会有审美疲劳，一些问题可能觉得不是问题
- 每个人有自己思维的盲点，很多路径考虑不到，测试用例评审也只能帮到一部分。
- 团队成员间对功能模块互相的了解不够，遇到边界的问题容易遗漏

2. 如何来划分范围？