我们希望同事们能成为更全栈的工程师，去了解更多、更广的方面。
-
业务相关能力。由于我们是基于服务端的业务，如 Linux、Docker 容器、Kubernetes、MQ 或卡夫卡消息队列等组件，这些都是我们需要掌握的服务器组件。
-
测试开发的能力。针对 Go、C++、Python，以及 Java 等业务服务做自动化时，要根据业务的测试需要去应用，熟悉相关开发语言及其 IDE。
-
熟悉 JMeter、CPP check 等市面上常见的测试工具，以及针对特定业务场景所需的工具，如数据库 ACID 场景的测试方法。
-
流程管控。掌握代码库 Git 的管理、流水线，甚至是 Excel 的度量分析等技能。
朱志杰：我认为优秀的测试人员需要具备三个通用素质。
-
沟通与思辨能力。作为开发与后端运维间承前启后的角色，测试要积极对开发运维与产品进行沟通协调。此外，也要能快速把握业务需求，明确业务需求从开发端传递的是否准确，要如何从前往后进行信息传导，抓住问题本质及需求改造点，评估其可能造成的影响。
-
快速学习能力。无论是校招还是社招，学习能力对测试都是非常重要的。面对业务测试时要能快速熟悉架构、掌握需求，快速将复杂场景环境构建起来。如果新业务需要用到卡夫卡或 RabbitMQ 消息队列，测试人员要能快速掌握对应工具。
-
主动性。成绩突出的人往往拥有更强的主动性。主动思考所负责项目产品的痛点，主动发现问题，找到解决问题的机会点。此外，在交付版本或业务后，要有将其中的能力或问题提炼出来，作为公共能力或公共模块的意识。
InfoQ：工程师常常要与产品经理及同僚交流，但很多技术人实际并不擅长沟通。您是如何看待沟通能力对技术人的重要性呢？我们又要如何提升自己的沟通能力？
朱志杰：我在回答前面问题时，将沟通思辨放在了第一位。我认为沟通会影响很多方面：
-
有效沟通可以快速把握需求，把握改动。
-
快速准确地将所发现的问题同步给相关人员。
-
推动问题或改进流程化需要通过沟通调用开发、PM，及相关业务人员的配合完成。
-
有利于合作关系的维护，互利互补开发与测试的关系。
-
个人能力的呈现。
InfoQ：您认为测试开发工程师在 2023 年所面对的最大技术挑战是什么呢？
朱志杰：技术上可能没有什么太大的挑战。从大环境而言，近两年行业上都在关注降本增效，这对测试而言也是较大的挑战。大厂相对会看得更全面，但对中小公司或团队而言，如果测试左移、开发自测，或者产品运维自测上线，那么我们是否还需要测试呢？这个问题我觉得关键在于测试的价值与产出的呈现，在于项目对测试的依赖。
举例来说，项目的左移意味着开发要在较好的测试环境中进行测试，但这对开发而言是具有困难的，如果测试可以提供平台化工具、保持流程通顺，并提供验证、引流的能力，协助项目左移，那这不失为一个很好的解法。
测试的价值也体现在 Ops 运营类的项目中。测试可以为运营的灰度减少问题出现，提供上线后除监控外的其他测试手段快速发现问题，通过拨测、上线后压测、容量评估等手段，对 Ops 环境右移的能力给予有力支持。
在 2023，甚至是 2024 年，测试人员可能都要面临这一挑战，但我们也可以借此重新定位自己的价值，调整提供价值或服务能力的方向，主动适应环境。
InfoQ：您从事多年测试行业，是如何从普通工程师成长为资深工程师的，中间又付出了那些努力呢？
朱志杰：随着业务的发展，我个人得到了很多锻炼和提升的机会，逐渐获得成长。
同每一位刚进入职场的人一样，刚开始也面对团队缺乏测试方法论、测试能力、测试平台，以及流程规范，这时我就主动站出来推进测试的流程化、工具平台化，完善测试能力，这也是我收获的个人第一阶段成长。
在第二阶段中，随着腾讯的业务做大，我们迎来了开放平台、腾讯云的产品接入，以及王者荣耀等国民级游戏的出现，数据量的增长也给我们带来了非常多的挑战。开放平台的服务质量问题，以及随着王者荣耀所带来的线上最大容量支撑问题，这些涉及到线上拨测、压测等技术，促使我们在这方面能力体系上进一步打磨夯实。随着这些能力的构建和打造，我个人的技术能力在成长，测试团队也随着发展和建设起来。
至于第三阶段，目前我的工作重心主要在于团队的测试效率建设，随着业务服务化发展后，在研发体系上会更倡导测试能力左移、组织效率提升、DevOps的转变等新模式去契合。
从我个人角度来说，随着业务的发展，我们需要去解决伴随业务出现的问题，去构建测试能力，并在这过程中收获技术上的成长与经验的提升。此外，随着团队规模壮大，也拥有了自己的团队、参与公司测试通道与人才能力的培养，以及公司层面上技术的协同，这一路上持续发现有很多锻炼与发挥的机会。
InfoQ：在刚才提到的许多测试工程的细分方向，您平时的工作内容，或者说最具有挑战的是哪些部分呢？
朱志杰：我们是服务端的测试，因此会更偏向于基础架构上模块化的测试。
从技术层面来说，我认为要想做好这方面的测试，必须要能深刻理解架构。以高并发存储模块为例，我们需要对其架构进行评估：其数据更新应用、缓存能力的设计能否满足高并发的查询？热点是否过于集中？高并发时数据如何防重？如何进行服务降级？是否会发生内存数据错位？在分布式容灾能力下要如何保证数据的一致性？这些都需要对架构有较好的理解。
我们还要考虑应用场景。新老业务的版本迭代中要如何保证向前的持续兼容？团队应保证有自动化的能力覆盖。
此外，在业务方面，将业务从旧模块割接到新架构时，要如何做到百分百的兼容？人工测试是否会导致的场景覆盖不充分？是否会有场景遗漏？其中的数据多样性与真实性要如何考虑？一个很好的方法是借助线上场景的对比模拟来解决这些问题。
以上这些都是我们在模块测试中会更多考虑的方面。
InfoQ：我们平时提起测试岗位可能都会觉得很厉害，是需要掌握很多技术的。那么作为多年从业的老开发者，您觉得实际是如此吗？
朱志杰：其实在互联网行业中，测试都是蛮苦逼的。我们的定位是项目中承前启后、非常重要的助手，不仅要支撑研发交付高质量的版本及功能，同时也要协助线上运营，提前排查相关风险及问题。因此，我们的工作就是解决问题，是非常务实的。
InfoQ：工程师常常要与产品经理及同僚交流，但很多技术人实际并不擅长沟通。您是如何看待沟通能力对技术人的重要性呢？我们又要如何提升自己的沟通能力？
朱志杰：我在回答前面问题时，将沟通思辨放在了第一位。我认为沟通会影响很多方面：
-
有效沟通可以快速把握需求，把握改动。
-
快速准确地将所发现的问题同步给相关人员。
-
推动问题或改进流程化需要通过沟通调用开发、PM，及相关业务人员的配合完成。
-
有利于合作关系的维护，互利互补开发与测试的关系。
-
个人能力的呈现。
InfoQ：测试开发工程师要如何做好职业规划？职业的发展路径又是怎样的呢？
朱志杰：腾讯有设计技术与管理两个能力提升通道，我个人同绝大多数人一样是走技术通道。但如果公司没有较强的职业指引或规范化工程师培养，可先以全栈的能力做自我要求。
测试理论只是个非常基础的概念，我们要在此基础上深刻掌握所负责的业务。要能从开发或产品的角度掌握业务，也要从运维的角度使用业务，我们才能在评审会议上提出有价值的问题，才能发现项目潜在的问题和风险点。
我们也要能结合业务需求，在具体问题解决上深入掌握相关技术。在遇到问题时，不能死读书，而是要从公司内部或外界同行中寻找好的解决方案。以数据库产品为例，我们要参考并尝试完善别人在面对 ACID 或高一致性问题上的方案，研究 ACID 场景上的差别，最终用其解决了实际问题，才能算是真正掌握了一项技术。
从长期来看，我们个人也需要打造自己的专长。可以深入研究自动化，做服务端接口自动化、基于接口协议自动化生成、通过模型化场景生成用例，甚至可以做流量自动化，将线上流量引入测试环境中进行回放。我们也可以将自己打造为效能专家，通过全流程进行效能分析，从而推动提升效能。
标签：沟通,工程师,业务,能力,问题,全栈,测试,朱志杰 From： https://www.cnblogs.com/zhaoruixiao/p/17070445.html