很多公司都有一些项目的交接问题存在，有从商务外包团队将项目交接给公司自建团队的，也有因为公司的一些组织架构的调整导致的项目交接。（有些公司叫项目闭环，为什么叫闭环我其实也不清楚啊，就是本来A团队在AA部门做AAA项目，调整后就是A团队在BB部门做AAA项目的一部分或者全部）

不管因为什么，如果发生了项目交接，你做为项目承接团队中测试工程师，要如何完成测试部分的交接呢？我们都是知道很多项目连代码都是一团乱麻，就更别提测试了，那么面对一团乱麻的项目，我们应该如何开始承接对应的测试呢？

第一步：是否有测试资产的移交

最开始我们要搞清楚是否有一些测试资产可以承接过来，那么确定可以继承的测试资产，我们可以从如下三个问题开始：

• 1、是否有自动化测试
• 2、测试用例什么时候会被执行
• 3、测试代码覆盖率（强烈建议业务测试也需要统计代码覆盖率）

我相信很多项目对于上面的问题很难给出准确的答案，尤其是最后一条。如果你将要接手的项目没有自动化测试，那么你就要将测试重点放到业务测试用例上，关注业务测试用例如何如何被执行的，是否分级以及执行过程历史上发现的BUG和被修复情况。最后，你还是要把所有业务测试用例执行一遍，这时候我特别建议你使用代码覆盖工具统计代码覆盖率，我相信你会看到大面积没有被覆盖的代码段。这说明原来的业务测试用例设计并不完善。

第二步：制定一个接手后的计划

在拟定这个计划的时候，要站在原项目的测试基础之上，给出一个从混乱状态到有序的可控状态的时间表。那么这个计划中既要包含测试工程师的任务和时间也要包含开发工程师Codereview的流程、静态代码扫描等实施时间，但是切记不要太过急躁，希望接手那一天就完全走入正规，每一个项目从无序到有序都是一个过程，没有办法一口吃成个胖子。

第三步：实施落地

按照你的计划开始一步一步落实，最开始还是要以业务测试为主，并且配合一些测试手段，提高测试的精准度。例如通过增量代码覆盖情况，从而指导业务测试用例设计；推行静态代码扫描建立质量门禁；引入API自动化测试，降低手动测试工作量，如果测试团队技术成熟度较高，那么可以推行UI自动化，实现E2E的质量保证。

第四步：为重构建立单元测试

重构不得不说是任何一个团队接手一个老项目的时候，每一个技术负责人的心结。每个人都想重构，都想把系统打上自己的印记，但是又不怕不是最合适的时期。但是无论如何，重构是早晚的事情，但是在开始重构之前，测试工程师一定要督促单元测试的覆盖度，当单元测试覆盖度足够完善的时候才能开始重构，而不能随随便便就满了研发重构的心愿，否则你就会将团队带入一个不断修复BUG、不断救火的痛苦状态中。