一. 项目背景

回片联调期间，可能涉及在ASIC/FPGA间切换，甚至在开放环境/屏蔽环境间切换，以定位芯片问题，在环境紧张的情况下，无法满足每人多套环境的条件，故需要大家共享平台，切换分时使用。

在问题定位过程中，常涉及如下几个问题：

1. 对于某个问题的定位过程，通常可能涉及到要切换N个平台环境，以确认是否与平台相关；
2. 根据习惯将组合的配置命令合并为某个按钮，而按钮与平台是绑定的；
3. 某个流程的配置命令组合，会因平台不同而略有差异；
4. 配置命令更新可能导致非问题的问题疑问。

二. 实例回放

由于上联调平台联调芯片问题处于 ES asic 与 CS FPGA 并行阶段，又适逢出差同事端午节返家歇息，前后两周左右的时间，人力处于严重不足情况，所以需要每个人承担多个芯片问题的定位。

期间为了最大程度地快速进入状态，预先对 上板加载 及 各个特性 在 ES FPGA/ ES asic 平台上的 配置命令 做了详尽的记录，以便于定位时快速复现场景。

实际执行时，首先是要切换的平台较多：
在空口环境下问题复现，需要验证是否与干扰相关，随即切换到屏蔽环境复测，而屏蔽环境是另一个同事搭建的，配置文件、执行脚本等不尽相同，同一套流程的配置命令也需要随着平台切换而切换，此间难免会有因配置等失误导致的时间浪费；
其次，屏蔽环境若仍可出现，证明与干扰无关，如果最终可在FPGA平台上复现，则可以与芯片同事一同抓线最终锁定芯片问题根因，因此问题复现平台又将切换到FPGA上，启动脚本一般会不同，特性的配置命令也可能会不同，再加上配置文件等的切换，错误引入点将更多。
最后，随着特性的演进，配置命令可能面临着变化，流程顺序变化或参数增减等，每个人可能不会及时地更新，引入非问题的问题疑问。

如果每个人都有一套 FPGA + 屏蔽环境 + 空口环境，那么平台切换带来的代价几乎可以忽略不计；如果大家每次都重新拉取配置命令及脚本，也是不现实的。

三. 解决措施

根据前述提出的种种背景条件限制，可称其为 联调一致性限制因素 ，将限制因素进行抽象，可抽象为两大类：跨平台 及 配置命令演进导致版本与配置命令不匹配。

归总起来，上述问题有着相似的共性需求：需要 一致的 信息源，外加 根据可变参数自动生成匹配的特性配置命令。

信息源的一致性，保证了所有脚本的时效性与一致性，可根据可变参数自动生成特性配置命令 这一特性，使得跨平台测试变得容易实现且不易出错。

信息源一致性的实现方式有很多，比如将脚本都存放到同一台服务器等等，但如果仅仅是用于存储，那么将无法实现方才阐述的便捷功能，因为固有的脚本无法根据参数变化；
根据可变参数自动生成匹配的特性配置命令，这个需求才是最核心的功能，可视为根据可变参数而产生代码的功能，该功能的实现载体，应该是一款应用程序，细思之下，它应该是一款服务器端的应用程序，能够保证每个人都能随时使用到最新版本而不需升级或更换版本等操作。

用户访问服务器端应用程序，根据可变参数及平台类型，导出最新的启动脚本及特性配置命令等，进而只需将导出的启动脚本导入平台，启动后根据最新的配置命令进行配置，即可实现极低成本的跨平台且一致的特性配置命令，降低跨平台或更新配置命令造成的成本浪费。