交叉测试，最终结果不是会产生新的用例补充到用例中么？因此可以给该阶段补充用例打标签，分别出当前的补充的用例么？漏测的也会补充进去，也打标签，这样的话，一份相对比较完整的用例就出来了，有自己写的，交叉补充进去的，漏测的，比例肯定也不一样，一定程度上能反应这位同学自己写的时候是否偷懒，优秀，另外因为交叉的时候用例补充这块儿同学做了比较多的工作和努力，给予一定绩效上的奖励和关注，就是个良性的行为，大概就是这样，另外项目的熟悉程度，每个人理解程度都不一样，这个一般就是你上面说的那种扯皮的行为，如果内部大家都不是和和气气的去沟通而是去扯皮，我认为交叉的意义就不大了，因为这样的产出结果其实并不好，可以摒弃掉，这个跟人强相关。

交叉个锤，平时都点不过来了

楼主的问题有点凌乱，要解决的问题我理解是：系统模块间逻辑复杂，项目过程中，可能存在人员请假，导致项目存在风险吗？
首先：我们理解下交叉测试，一般交叉测试在瀑布流模式中的二轮测试，功能相对比较稳定了之后，大家进行交叉测试，避免一些人员太过熟悉的漏测问题，是在任务下发之后。楼主理解的交叉测试是指模块功能间的交叉测试。
第二：如果是模块间的功能交叉测试，那就属于任务分配，测试人员应该按照测试负责人总体安排，测试负责人在排任务时，就需要考虑到功能不熟悉这块，对于测试人员请假这块，需要在任务排期时，作为一个风险项考虑进去，二是业务熟悉，也是作为风险项，但是可以降低，比如通过对用例的维护（用例是测试的核心产物），或者用例设计过程中的用例内审解决这块问题，尽量在解决业务不熟悉、排期时间不够问题。
第三：楼主说的问题解决，也可以通过技术手段，比如接口自动化，提升效率。

需要解决什么问题，有针对措施，如果没有目标，做的过程肯定会冒出其他问题。

首先，你说的这种交叉测试是有必要的，保证组内不止一个人熟悉对应的功能模块。我们的解决方案是：每个产品/模块有一个专门的负责人，这个人会主要测试该产品/模块，但不一定在每个版本都负责测试该产品/模块，他会参与到该产品/模块新需求评审，负责相应用例的维护，业务流的梳理与面向组内共享培训。相当于给每个模块安了一个唯一责任人，他需要搜集平时该模块的发测版本，每个版本测试中的问题，及时修正补充，根据需要给其他组员定期分享该模块的业务（内容不限，可以是新的功能，新版本增加的用例，问题定位总结等）。测试中遇的问题需要向这个负责人请教，这样也能保证及时了解到版本测试以及漏测情况。

交叉测试的重点, 要筛选出 精英/技术优秀/业务经验丰富 的人员.
有了这些人员后, 在版本迭代过程中 安排他们对重要/敏感/复杂的模块系统进行交叉测试.
理想中的情况下, 大家都是 精锐, 可以承担切换模块后熟练度的损耗, 但实践中, 还是要有所权衡.

哈哈，是的，理论永远跟现实有差距，现实是各种业务功能庞大复杂，测试时间紧张，哪有时间做交叉测试

1、交叉测试适用场景，我也认为应该是功能比较稳定的时候才适用的场景。而我们现在是功能场景还在不断迭代的时候，就已经开始进行这种测试方式了。
2、目前我们对测试用例的重视程度不够，没有内审，只有项目评审，项目评审的作用也没有被发挥出来。 属于是交叉测试学了样子，没学到里子

我认为你说的这种方式会更加合理一些，会比我们现在的策略更加合理。我们只是单纯的采用了交叉，没有采用其他配套的方式：指定负责人，用例重视及完善的呢个等

冲你这个 ID 给你点赞

我们是分工的时候就交叉了，让你测不同模块的。