首页 > 代码库 > 测试工作速记3 - 交叉测试
测试工作速记3 - 交叉测试
我如果说有一天我灵机一动想到去执行这个做法，那就是在装。这个方法大家都知道，但是不一定会去做，我们立马去做了，主要也是受了些刺激，被别人找到一些问题。于是我们就在想，我们部门有好几个测试小组，为什么我们不自己来个左右互搏呢？
正好双11刚结束的时候有点时间，那好，我们就做做看。最后的结果远超我的预期，在几天的时间里，我们累积发现了63个问题，确认的有效问题47个。有25个模块参与，14个发现了问题。当然这些问题有多种类型，包括一些体验类的问题，有很多是非常有价值的。这结果真是让人又喜又忧，不过从这个方法的角度，是完全的被证明了。
我称这个方法为“换人如换刀”，实际操作中也有一些思考和考虑，不妨拿出来探讨。
1. 很多时候，我们为了工作的效率，深入的了解业务，以及和对口产品和开发的协作，很长一段时间，每个功能点会有一个比较固定的test owner。
这样的好处显而易见，但是缺点也很明显：
- 会有审美疲劳，一些问题可能觉得不是问题
- 每个人有自己思维的盲点，很多路径考虑不到，测试用例评审也只能帮到一部分。
- 团队成员间对功能模块互相的了解不够，遇到边界的问题容易遗漏
2. 如何来划分范围？
完全的散打，每个人随意挑选自己感兴趣的模块？ or 逐个的制定owner，事先完全的分好？
最后我们选取了中间路线，首选做跨地域（正好我们有两个地域的团队）的切分，两地呼唤，在这个基础上，每个人来挑选对方的模块，先到先得。
背后的思考是需要有一定的覆盖度，但是又有一定的趣味。
3. 按地域切分会引起一些不好的氛围吗？
我其实担心过，但很快不是很担心。异地团队的沟通和融合确实不容易，不过之前已经有了比较好的基础，而且大家都是站在一个比较坚实的想把事情做好的基础上，另外我们的导向上也是完全正向的。
另外， 其实有一定的竞争是一个良性的张力，就像前一篇（http://blog.csdn.net/superqa/article/details/41330225）提到的，是一个发现更多bug的动力。
实际的结果证明，这方面也没有出现问题。
就在刚刚写的时候，我在想，其实还有更多的玩法，就是可以从不同的维度划分，比如M，ipad，android，ios等等。
4. 需要feedback。
收到问题的同学需要像开发接到bug一样，给出是否是问题，如何处理等反馈。这样是跟进问题本身，也是对发现问题的人的尊重，对别人劳动的尊重。
5. 我们还设立了一个奖，发给发现bug最多的人，“乐于助人奖”，帮助别人发现TA的模块的问题，其实就是在帮助别人。 这是个导向的问题。
6. 不要求全
很难每个人都那么彻底的参与，可能因为不理解，可能因为手头有别的事情，可能真的发现不了问题。看大的方面。
7. 不用去挑战
每个正常的被别人发现问题的人都应该会有一些动力去做得更好。
下次再尝试一些不同的细节的操作，这个应该可以作为一个保留曲目。
正好双11刚结束的时候有点时间，那好，我们就做做看。最后的结果远超我的预期，在几天的时间里，我们累积发现了63个问题，确认的有效问题47个。有25个模块参与，14个发现了问题。当然这些问题有多种类型，包括一些体验类的问题，有很多是非常有价值的。这结果真是让人又喜又忧，不过从这个方法的角度，是完全的被证明了。
我称这个方法为“换人如换刀”，实际操作中也有一些思考和考虑，不妨拿出来探讨。
1. 很多时候，我们为了工作的效率，深入的了解业务，以及和对口产品和开发的协作，很长一段时间，每个功能点会有一个比较固定的test owner。
这样的好处显而易见，但是缺点也很明显：
- 会有审美疲劳，一些问题可能觉得不是问题
- 每个人有自己思维的盲点，很多路径考虑不到，测试用例评审也只能帮到一部分。
- 团队成员间对功能模块互相的了解不够，遇到边界的问题容易遗漏
2. 如何来划分范围？
完全的散打，每个人随意挑选自己感兴趣的模块？ or 逐个的制定owner，事先完全的分好？
最后我们选取了中间路线，首选做跨地域（正好我们有两个地域的团队）的切分，两地呼唤，在这个基础上，每个人来挑选对方的模块，先到先得。
背后的思考是需要有一定的覆盖度，但是又有一定的趣味。
3. 按地域切分会引起一些不好的氛围吗？
我其实担心过，但很快不是很担心。异地团队的沟通和融合确实不容易，不过之前已经有了比较好的基础，而且大家都是站在一个比较坚实的想把事情做好的基础上，另外我们的导向上也是完全正向的。
另外， 其实有一定的竞争是一个良性的张力，就像前一篇（http://blog.csdn.net/superqa/article/details/41330225）提到的，是一个发现更多bug的动力。
实际的结果证明，这方面也没有出现问题。
就在刚刚写的时候，我在想，其实还有更多的玩法，就是可以从不同的维度划分，比如M，ipad，android，ios等等。
4. 需要feedback。
收到问题的同学需要像开发接到bug一样，给出是否是问题，如何处理等反馈。这样是跟进问题本身，也是对发现问题的人的尊重，对别人劳动的尊重。
5. 我们还设立了一个奖，发给发现bug最多的人，“乐于助人奖”，帮助别人发现TA的模块的问题，其实就是在帮助别人。 这是个导向的问题。
6. 不要求全
很难每个人都那么彻底的参与，可能因为不理解，可能因为手头有别的事情，可能真的发现不了问题。看大的方面。
7. 不用去挑战
每个正常的被别人发现问题的人都应该会有一些动力去做得更好。
下次再尝试一些不同的细节的操作，这个应该可以作为一个保留曲目。
测试工作速记3 - 交叉测试
声明：以上内容来自用户投稿及互联网公开渠道收集整理发布，本网站不拥有所有权，未作人工编辑处理，也不承担相关法律责任，若内容有误或涉及侵权可进行投诉： 投诉/举报 工作人员会在5个工作日内联系你，一经查实，本站将立刻删除涉嫌侵权内容。