由于各种原因，团队人员换了一批，新到的团队成员，由于对业务不够了解，对系统的代码和架构，也不是很清楚，很多时候测试也不到位，导致了一系列问题和bug。很多问题在我们看来都是不应该发生，或是当时如果仔细测试，是完全可以避免的问题。

　　针对于这样的情况。我们进行了总结和反思，决定尝试加入交叉测试。来提高系统的质量。

　　交叉测试的时间和范围

　　 迭代的功能完成之后，开发人员互相检查别人的功能和代码，并进行足够的测试，测试和检查的范围包括系统数据库设计、业务需求、解决方案、代码（注释、代码风格）、数据表等。

　　交叉测试的流程

　　开发人员在完成一个功能之后，找到另一个人员，进行交叉测试

　　1. 讲解业务需求。

　　2. 讲解解决方案。

　　3. 功能演示

　　4. 代码交叉测试

　　5. 功能测试

　　期间，交叉测试人员，随时提出问题和看法，尽量弥补开发者的不足。

　　交叉测试的优点

　　1. 对模块的了解不只局限在一个开发人员身上，分担了项目的维护风险；

　　2. 规范代码，至少在注释和代码风格方面能保障；

　　3. 一个人思考问题难免会有遗漏或盲点，多一个人查漏补缺会避免不必要的返工；

　　4. 确保所有的功能，都有两个以上的人测试到；

　　交叉测试的缺点

　　1. 交叉测试会占用开发时间，熟悉别人的功能和代码都要花不少的时间，我估计测试时间是开发时间的1/4至1/3；

　　2. 队员水平参差不齐，开发人员和交叉测试人员对业务和代码同样了解，这样就无法保证交叉测试的质量；

　　3. 还是无法不能保证交叉测试做完之后，测试范围覆盖到模块的业务；

　　4. 交叉测试会导致开发者会不关心bug的责任问题。

　　交叉测试注意的问题

　　1. 测试者一定要理解开发人员的业务需求和解决方案，这样才能达到了业务讲解和理解的目的，才能提出问题；

　　2. bug应该属于团队所有成员的，不应该由某个人来单独负责，bug也作为一项任务；

　　3. 关键性模块才进行交叉测试，这样既避免了交叉测试占用太多的开发时间，又避免了核心业务的不稳定。

循序渐进的敏捷-交叉测试