由于各种原因，团队人员换了一些人，新到的团队成员，由于对业务不够了解，对系统的代码和架构，也不是很清楚，很多时候测试也不到位，导致了一系列问题和bug。很多问题在我们看来都是不应该发生，或是当时如果仔细测试，是完全可以避免的问题。
针对于这样的情况。我们进行了总结和反思，决定尝试加入交叉测试，来提高系统的质量。
交叉测试的时间和范围
迭代的功能完成之后，开发人员互相检查别人的功能和代码，并进行足够的测试，测试和检查的范围包括系统数据库设计、业务需求、解决方案、代码（注释、代码风格）、数据表等。
交叉测试的流程
开发人员在完成一个功能之后，找到另一个人员，进行交叉测试
1. 讲解业务需求。
2. 讲解解决方案。
3. 功能演示
4. 代码交叉测试
5. 功能测试
期间，交叉测试人员，随时提出问题和看法，尽早发现开发者在业务和设计方面的问题。
交叉测试的优点
1. 对模块的了解不只局限在一个开发人员身上，分担了项目的维护风险；
2. 规范代码，至少在注释和代码风格方面能保障；
3. 避免一个人思考问题和对业务的理解存在的遗漏或盲点，多一个人查漏补缺会避免不必要的bug；
4. 确保所有的功能至少核心功能，都有两个以上的人测试到；
交叉测试的缺点
1. 交叉测试会占用开发时间，熟悉别人的功能和代码都要花不少的时间，我估计测试时间是开发时间的1/4至1/3；
2. 队员水平参差不齐，开发人员和交叉测试人员对业务和代码同样不了解，这样就无法保证交叉测试的质量；
3. 尽管花了很多时间，有可能还是无法保证交叉测试做完之后，测试范围覆盖到全部模块的业务，无法确保需求或是业务的问题；
4. 交叉测试会导致开发者会不关心bug的责任问题。
交叉测试注意的问题
1. 交叉测试者一定要理解开发人员的业务需求和解决方案，这样才能达到了业务讲解和理解的目的，才能提出问题；
2. 避免不讲业务需求和解决方案就直接进行测试，这样无法保证交叉测试的质量；
3. bug应该属于团队所有成员的，不应该由某个人来单独负责，bug也作为一项任务；
4. 关键性模块才进行交叉测试，这样既避免了交叉测试占用太多的开发时间，又避免了核心业务的不稳定；
5. 尽量避免不了解业务的人员去给其他开发人员做交叉测试；