最近在和大佬们规划如何针对某个已经存在多年且非常重要的基础支撑型的系统 A建设接口自动化回归的能力，该系统对于高可用以及数据的严谨层度追求非常高，但系统 A使用基本都是非公司标准统一的技术栈
梳理完系统 A 的核心接口，明确了大致的方向，尽可能地低接入成本，低维护成本，看看是否能够接入公司的标准化的接口测试工具，是否可以使用引流生产流量来验证原有接口是否正常 ，于是我一开始就选中了公司的接口回归工具 B，通过引流生产流量到预发环境验证，同时可以 mock 对于中间件，数据库的子调用，从而做到安全隔离，避免数据击穿，要应用到以上能力，对应的中间件及开发技术栈就得标准化，这么看来系统 A或许不满足这一点，当时我就思考如何可以克服这一点
有了这两点思考之后，我就想出了一个看似满足当前系统 A 的自动化回归的方案，就是以读接口接入工具 B，写接口另外通过其他工具编写用例覆盖
于是我就找到了负责工具 B 的同学 D，和他阐述我想好的方案，我就和他直接沟通说，目前工具 B 是否能够放弃原来隔离中间件和数据库的能力，给个阉割版给我用一下，同学 D 说可以实现，很简单，我当时以为这么快就找到方案，可以确定下来了，然后我就向我老大反馈，可以这么做，老大听完我反馈之后，他打了个问号，说道之前负责这个项目自动化的同学，说过工具 B 的接入成本很大，要适配非标准的中间件和技术栈，需要工具 B 进行相当大的改造，之后的维护成本也高，然后老大问我当时是怎么和同学 D 沟通的，我就如上文的过程一一复述，老大就坐不住了，和我一起找到了负责工具 B 的同学再一起沟通，后面仔细沟通发现，我设计的那个方案根本不可行，存在的最大的问题为，我理解的所谓的读接口，是否真的只有读操作，不对中间件数据库进行隔离，就算是读操作，也会可能存在写缓存的过程，同时如上文提到，系统 A 是高可用以及数据的严谨层度追求非常高的，只要不是 100% 的保证没问题，这样的方案都会带来非常大的风险，然后同学 D 说他之前就知道系统 A 要接入工具 B 成本非常大，要改造需要很多时间和人力，于是回到座位上老大就和我开始复盘这整个过程，这里老大就和我讲到了XY 问题
其实这件事情之后，我整整思考了几个晚上，不断地在给自己复盘这个案例存在的问题：
通过这次经历，自己还是醍醐灌顶的，作为一名测试开发，我们会经常为所负责的系统进行质效提升的目标而思前想后，我们会通过建立各种流程规范，设计各种提升质效的技术方案，来保证我们的系统的质量和效率，设计方案的前提是我们能够找到核心痛点，那就避免不了和其他同学的协作沟通，我们需要做到的是抛出 X 问题，共同讨论方案，起码是一人计短，二人计长，反过来也一样，当你作为被请教的同学，别人想你请教方案时，多问深一层，你设计的方案是要解决什么问题，你的根本问题是什么，这样一来能够明确做每一件事的意义和目标，这也是一个提高工作效率的办法，直击核心问题，少走弯路。