交叉测试的必要性和遇到的问题

　　在软件测试过程中，每个项目一般由多名测试工程师组成，分别负责不同模块的测试。对同一个模块进行多轮测试，测试人员对手中的模块无论从整体到细节都有了非常深刻的掌握，但同时存在的定向思维，测试疲态也影响了bug的发现。这种测试模式不但影响了产品的最终质量，同时测试人员对产品整个逻辑和功能的了解也受到了限制。

　　鉴于上述问题，在测试的过程中引入交叉测试是非常有必要的。所谓交叉测试，是指在测试的某一阶段，测试人员相互交换测试的模块，这样不但可以使不同的测试人员保持测试的新鲜感，还可以进一步发掘测试的未知领域，发现交叉测试的模块和之前测试的模块间的联系，甚至可以构建更多的测试场景，对提高产品的质量也起到了很大帮助。

　　那么，交叉测试在什么时候引入比较合适呢。第一轮测试是每个测试人员和对应功能模块的第一次接触，有很强的新鲜感，在对模块的初步了解后可以快速发现较多bug，但是对功能模块逻辑的不熟悉，导致测试时间比较紧张，所以一般不采用交叉测试。在经过第一轮测试后，一般的bug都会被揪出来，功能渐渐趋于稳定，产品逐渐定型，但是可能会存在一些bug，由于受到测试惯性的影响，在眼前也可能发现不了，引入交叉测试可以集中精力和时间发现一些遗漏的bug，同时发现和之前测试模块之间的联系，构建新场景，所以在第二轮测试中引入交叉测试比较合适。由于第二轮测试交换了测试模块，在时间的预估上，第一轮测试的时间和第二轮交叉测试的时间是相当的。

　　交叉测试也会碰到一些问题，如看不懂对方写的测试用例，当然这不一定是测试用例写的不好，也有可能是对功能逻辑的不了解，对测试环境的不熟悉。解决办法可以在每个模块测试用例的前面增加“测试须知”，里面包含了该模块的客户端逻辑，和服务端的交互逻辑、测试环境的配置和需要注意的事项等等，写得越详细越好，这样在对方测试前先有个大概了解，可以节省很多沟通时间;另外，在交叉测试的过程中，可能会出现bug重复提交的问题，一种解决办法是提交bug前问一下第一轮测试的同学有没有提交过。另一种是先提交，如果重复，在bug库中置duplicate，当然这浪费了提bug的时间，一般不建议这么做。

原文转自：http://www.ltesting.net