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