由于要从老版本拉出一个分支做新产品研发提升，因此想要移植老版本的ZTP自动化用例做质量保证，但是在移植的过程中遇到不少问题，在此做个总结。
先说一下被移植用例的背景，原用例是测试团队创建并维护的，用例很多大约有1500个，用例执行慢完整跑一遍要8个小时左右，由于部分用例设计不合理或环境等因数每次都无法保证用例100%执行通过，需要二次甚至多次执行没通过的用例，最后人工介入排查没通过的原因，因此这些用例只能用于每次发版本执行一次做回归，第二天再投入一个测试团队分析失败原因。而我们团队主要是开发构成，希望移植后的用例可以在开发每次提交代码后尽快发现问题，可以比单元测试慢一点，但是最好不要超过1小时。
开始移植，一开始我们新建了环境发现问题很多，后来直接复制了所有机器的虚拟机，只通过修改IP等必要配置把老版本自动化环境复制过来，版本也保持不变，希望先把移植过来的用例保证稳定的100%执行通过，再更新版本检查新版本的问题。
在移植了一定数量的用例后，有很多用例单独执行可以通过，批量执行就不行，结果不太稳定，并且执行一遍的用例要5个小时左右，调试反馈周期太长。
于是开始优化时间，首先优化CD流程，把开发团队不需要关注的QMDB等产品检测去掉，用dbug并行编译，shell脚本去掉不必要的sleep和备份，优化脚本确保环境可以稳定执行不受磁盘等系统资源限制，其次ZTP用例执行按业务和时间拆成四个job，每个job执行时间控制在50分钟以内。经过以上几个步骤一个CD流程执行下来基本控制在1小时左右，这样调试整个流程反馈就快了很多。
接着开始分析失败或不稳定的用例，首先把重启平台重启进程等影响并行的脚本改掉，识别出这些用例移到非并行job中，其次大概分析失败的用例并修复，需要深度分析耗时较长的先记录挂起执行后续再处理，经过多伦这样的处理后基本可以保证用例稳定的运行并在较短的时间内得到反馈。
