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

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

从接口梳理时了解到，其实80%以上的核心接口都是读接口，于是就认为只是读操作，对数据基本不产生影响，不会带来数据击穿问题，写接口就安排其他工具，这么一来接入和维护成本大大降低。

对于工具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问题原则思考，或许会更容易达到实际的目的。

专为规模化敏捷研发设计：精益化研发、敏捷化研发是应对激烈市场竞争的有效手段之一，尤其在大规模研发的过程中，灵活性变得尤为重要。开发测试云解决方案服务的流程设计主要基于规模化敏捷的项目实践，可以适合并引导多个敏捷团队在小到中型规模研发中实现良好的协同。

多级管理视图：得益于高度集成的项目协同系统，可以方便的将研发相关的各个数据收集整理，并在任意组织、项目层级上进行展示。使研发过程以数据化、可视化的方式展现给管控层，使决策更有依据，使风险更易于识别。

Smart Sense 智能感知：研发数据的另一用途，即是大数据分析。除了完整的视图展示，还可以通过大数据和人工智能分析实现辅助决策，甚至关键决策。通过Smart Sense功能，我们能够轻松得到各类业务感知以及事态感知信息。就像一个永不停歇的项目经理，24小时全天候守护项目组，感知项目组状态，并适时发出决策辅助信息(预警、预测等)。

配套代码托管服务：不仅仅基于流行的git代码变更管理系统(SCM)，而且支持久经验证的分支管理模型，使研发工作变得井井有条，减少不必要的冲突，使代码变更分化变得清晰易懂，降低研发工作量，也间接提升代码质量。

持续测试与质量保证：提供完善的测试用例以及执行系统，并可以对接自动化测试系统结果报告，使得测试结果可以按照测试设计那样进行分组和排列，通过测试设计的优先级展示其问题的分布，根据缺陷分布理论预测问题的重点区域。可支持TDD等先进的DevOps方法论，使质量保证真正从需求开始。

基于流水线的CI/CD模板：CI/CD流水线一般是基于代码描述的构建、发布方法，其使用繁杂冗长。CI/CD模板可以使常见构建任务经过简单的鼠标拖拽和点击，就可以从模板蓝图开始，定制出属于项目自己的CI/CD流水线，大大简化研发步骤，提高工作效率。