前言

• 你是否在日常的测试开发工作中遇到过，一位同事向你请教一个问题，沟通了半天，也不知道他到底想问什么，想得到什么答案，好不容易弄明白了他想问的问题，然后顺理成章你给出了答方案，但方案并不能解决他遇到的问题
• 这个就是典型的XY 问题，想做 X，但认为 Y 是实现 X 最好的方法。不问关于 X 的事，反而问起 Y 的事

案例

• 最近在和大佬们规划如何针对某个已经存在多年且非常重要的基础支撑型的系统 A建设接口自动化回归的能力，该系统对于高可用以及数据的严谨层度追求非常高，但系统 A使用基本都是非公司标准统一的技术栈

• 梳理完系统 A 的核心接口，明确了大致的方向，尽可能地低接入成本，低维护成本，看看是否能够接入公司的标准化的接口测试工具，是否可以使用引流生产流量来验证原有接口是否正常 ，于是我一开始就选中了公司的接口回归工具 B，通过引流生产流量到预发环境验证，同时可以 mock 对于中间件，数据库的子调用，从而做到安全隔离，避免数据击穿，要应用到以上能力，对应的中间件及开发技术栈就得标准化，这么看来系统 A或许不满足这一点，当时我就思考如何可以克服这一点

  • 1、从接口梳理时了解到，其实80% 以上的核心接口都是读接口，于是就认为只是读操作，对数据基本不产生影响，不会带来数据击穿问题，写接口就安排其他工具，这么一来接入和维护成本大大降低
  • 2、对于工具 B，认为可以放弃掉原本的中间件和数据库的隔离的能力，只需要原本流量引流的能力，这样就可以不用考虑技术栈和中间件是否标准化的问题，直接应用其引流能力，将生产环境的读流量引流到预发环境进行验证

• 有了这两点思考之后，我就想出了一个看似满足当前系统 A 的自动化回归的方案，就是以读接口接入工具 B，写接口另外通过其他工具编写用例覆盖

• 于是我就找到了负责工具 B 的同学 D，和他阐述我想好的方案，我就和他直接沟通说，目前工具 B 是否能够放弃原来隔离中间件和数据库的能力，给个阉割版给我用一下，同学 D 说可以实现，很简单，我当时以为这么快就找到方案，可以确定下来了，然后我就向我老大反馈，可以这么做，老大听完我反馈之后，他打了个问号，说道之前负责这个项目自动化的同学，说过工具 B 的接入成本很大，要适配非标准的中间件和技术栈，需要工具 B 进行相当大的改造，之后的维护成本也高，然后老大问我当时是怎么和同学 D 沟通的，我就如上文的过程一一复述，老大就坐不住了，和我一起找到了负责工具 B 的同学再一起沟通，后面仔细沟通发现，我设计的那个方案根本不可行，存在的最大的问题为，我理解的所谓的读接口，是否真的只有读操作，不对中间件数据库进行隔离，就算是读操作，也会可能存在写缓存的过程，同时如上文提到，系统 A 是高可用以及数据的严谨层度追求非常高的，只要不是 100% 的保证没问题，这样的方案都会带来非常大的风险，然后同学 D 说他之前就知道系统 A 要接入工具 B 成本非常大，要改造需要很多时间和人力，于是回到座位上老大就和我开始复盘这整个过程，这里老大就和我讲到了XY 问题

分析与思考

• 从案例中可以看到，X 问题其实为是否可以使用工具 B 来建设系统 A 的接口自动化回归能力，而我认为的使用工具 B 的阉割版能力为最好的方案，即 Y，于是我去找到同学 D 讨论问题的时候我只讲了 Y，没提到 X，从而导致了得到不是能够解决核心的问题的答复或方案

• 其实这件事情之后，我整整思考了几个晚上，不断地在给自己复盘这个案例存在的问题：

  • 1、不清楚 X 问题的细节，在我们在进行每个测试开发工作项目时，要问清楚自己是否十分了解你要面对的 X 问题，从上面的案例中的我显然没有做到十分了解，具体地就如没有真正的了解清楚读接口是否真的全部是读操作，从而设计出不合理的方案
  • 2、没有抛出 X 问题，向同学 D 请教沟通时，没有讲述清楚 X 问题，同样从上面的案例中，假设我当时问的是，能不能用工具 B 来建设系统 A 的自动化回归能力，估计同学 D 很快就会和我反馈很难实现，那我就会另外再去设计方案，这才是这个过程中需要获得的正确答案
  • 3、个人经验导致误判，这个是我在这个过程中思考最多的点，在工作 3 到 5 年这个阶段，不管是项目经验还是技术能力都有一定积累，以导致我上面的场景，认为自己设计的方案很合理，看似满足系统 A 的需求，毕竟像对于流量回放的能力，或者是接口自动化回归的方案，都有自己的一套经验和理论，于是就会考虑通过适当的改造变成系统需要的方案，即个人认为的最好方案 Y，然后就会只讨论Y 方案，而不讨论X 问题，从个人感觉好像刚参加工作的同学反而少出现这种场景，认知反而导致误判，其实说到底还是自己想得不够彻底，而被某些表面的现状蒙蔽了眼睛

• 通过这次经历，自己还是醍醐灌顶的，作为一名测试开发，我们会经常为所负责的系统进行质效提升的目标而思前想后，我们会通过建立各种流程规范，设计各种提升质效的技术方案，来保证我们的系统的质量和效率，设计方案的前提是我们能够找到核心痛点，那就避免不了和其他同学的协作沟通，我们需要做到的是抛出 X 问题，共同讨论方案，起码是一人计短，二人计长，反过来也一样，当你作为被请教的同学，别人想你请教方案时，多问深一层，你设计的方案是要解决什么问题，你的根本问题是什么，这样一来能够明确做每一件事的意义和目标，这也是一个提高工作效率的办法，直击核心问题，少走弯路。

最后总结

• 在这次经历中我还是有那么一丢丢运气，起码自己会将这个过程和上层反馈，如果什么都没反馈，就直接开始动手了，后面带来的成本甚至是后果会非常的大
• 通过阐述本次的案例，希望能够给大家带来一点收获，我们在积累提升项目经验和技术经验的同时，不要遗留下工作的软能力，软能力的提高会让你在日常的工作中事半功倍，在讨论方案的时候，多用 XY 问题原则思考，或许会更容易达到实际的目的，谢谢