降本增效大环境下，培养全栈技术能力是测试工程师的“保命符” | 展望测试工程师的 2023

提起软件测试工程师，更多人联想到的是工作轻松，不需要敲代码、工资高、涨薪快，甚至可以发展成为管理层，那么现实真的是这样吗？

刚刚过去的 2022 年，测试工程技术领域又有哪些重要进展？在未来的发展中又面临着哪些机遇与挑战？InfoQ 年度技术盘点与展望栏目特别邀请到了腾讯技术工程事业群，米大师计费测试负责人朱志杰，请他来和大家分享并展望测试工程师的 2023 年。

朱志杰，15 年腾讯米大师计费服务端测试及团队管理经验。专注于米大师分布式计费、营销、风控、账户以及 TDSQL 数据库等产品的高一致性测试能力构建，支持公司游戏、腾讯云、广告、视频号等业务的计费测试工作；牵头构建了计费完整的质量支持体系，建设了基于服务端的自动化功能 / 性能测试、现网引流对比应用、环境治理等测试能力。目前聚焦于基于 DevOps 的研效改进工作。

视频回放地址：
https://www.infoq.cn/video/z0xL4IhkjkFQiWp5eq50

以下内容节选自当天的分享，InfoQ 做了不改变原意的编辑：

朱志杰：其实我选择从事测试岗位是具有偶然性的。我在大学期间主要学习.NET、Java 以及 PHP 等开发，也做过 OA 类的项目，一直想从事应用开发工程师。毕业进入华为后，被内部分配到了华为智能网平台的平台测试部，也是在工作之后才发现原来测试没有想象中的基础、简单。我当时做的是在 Linux 服务器平台上进行大数据量实时处理的系统，而这之后也做过一些跨城容灾性等非常具有挑战性的项目，慢慢地就扎根在测试的行业之中了。

我在华为做了两年测试后，后面来到腾讯。和在华为智能网中做电信的计费测试相类似，我在腾讯也恰好是在一个做聚合支付的内部计费部门。直白点来说就是早期的 Q 币计费，是与我个人蛮契合的产品和项目。

我在腾讯计费团队，从最初没有 DTO 分离，与开发相捆绑，给开发做辅助的测试角色，慢慢地将自己的测试能力、测试流程化都发展了起来。随着公司的业务开展，我也参与了公司开放平台、国际化、腾讯云等产品，渐渐地在这里扎下了根。部门的项目在发展，团队也在发展，我个人收获了很多锻炼和成长。

朱志杰：随着业务的发展，我个人得到了很多锻炼和提升的机会，逐渐获得成长。

同每一位刚进入职场的人一样，刚开始也面对团队缺乏测试方法论、测试能力、测试平台，以及流程规范，这时我就主动站出来推进测试的流程化、工具平台化，完善测试能力，这也是我收获的个人第一阶段成长。

在第二阶段中，随着腾讯的业务做大，我们迎来了开放平台、腾讯云的产品接入，以及王者荣耀等国民级游戏的出现，数据量的增长也给我们带来了非常多的挑战。开放平台的服务质量问题，以及随着王者荣耀所带来的线上最大容量支撑问题，这些涉及到线上拨测、压测等技术，促使我们在这方面能力体系上进一步打磨夯实。随着这些能力的构建和打造，我个人的技术能力在成长，测试团队也随着发展和建设起来。

至于第三阶段，目前我的工作重心主要在于团队的测试效率建设，随着业务服务化发展后，在研发体系上会更倡导测试能力左移、组织效率提升、DevOps 的转变等新模式去契合。

从我个人角度来说，随着业务的发展，我们需要去解决伴随业务出现的问题，去构建测试能力，并在这过程中收获技术上的成长与经验的提升。此外，随着团队规模壮大，也拥有了自己的团队、参与公司测试通道与人才能力的培养，以及公司层面上技术的协同，这一路上持续发现有很多锻炼与发挥的机会。

朱志杰：我们是服务端的测试，因此会更偏向于基础架构上模块化的测试。

从技术层面来说，我认为要想做好这方面的测试，必须要能深刻理解架构。以高并发存储模块为例，我们需要对其架构进行评估：其数据更新应用、缓存能力的设计能否满足高并发的查询？热点是否过于集中？高并发时数据如何防重？如何进行服务降级？是否会发生内存数据错位？在分布式容灾能力下要如何保证数据的一致性？这些都需要对架构有较好的理解。

我们还要考虑应用场景。新老业务的版本迭代中要如何保证向前的持续兼容？团队应保证有自动化的能力覆盖。

此外，在业务方面，将业务从旧模块割接到新架构时，要如何做到百分百的兼容？人工测试是否会导致的场景覆盖不充分？是否会有场景遗漏？其中的数据多样性与真实性要如何考虑？一个很好的方法是借助线上场景的对比模拟来解决这些问题。

以上这些都是我们在模块测试中会更多考虑的方面。

朱志杰：其实在互联网行业中，测试都是蛮苦逼的。我们的定位是项目中承前启后、非常重要的助手，不仅要支撑研发交付高质量的版本及功能，同时也要协助线上运营，提前排查相关风险及问题。因此，我们的工作就是解决问题，是非常务实的。

朱志杰：每个岗位都有各自的压力，侧重点不一样而已。我们作为互联网服务端的测试，和一般业务测试不同。简单点点鼠标、理解测试理论、设计测试用例，这些对于我们来说都是非常基础的。

我们希望同事们能成为更全栈的工程师，去了解更多、更广的方面。

• 业务相关能力。由于我们是基于服务端的业务，如 Linux、Docker 容器、Kubernetes、MQ 或卡夫卡消息队列等组件，这些都是我们需要掌握的服务器组件。

• 测试开发的能力。针对 Go、C++、Python，以及 Java 等业务服务做自动化时，要根据业务的测试需要去应用，熟悉相关开发语言及其 IDE。

• 熟悉 JMeter、CPP check 等市面上常见的测试工具，以及针对特定业务场景所需的工具，如数据库 ACID 场景的测试方法。

• 流程管控。掌握代码库 Git 的管理、流水线，甚至是 Excel 的度量分析等技能。

朱志杰：我认为优秀的测试人员需要具备三个通用素质。

• 沟通与思辨能力。作为开发与后端运维间承前启后的角色，测试要积极对开发运维与产品进行沟通协调。此外，也要能快速把握业务需求，明确业务需求从开发端传递的是否准确，要如何从前往后进行信息传导，抓住问题本质及需求改造点，评估其可能造成的影响。

• 快速学习能力。无论是校招还是社招，学习能力对测试都是非常重要的。面对业务测试时要能快速熟悉架构、掌握需求，快速将复杂场景环境构建起来。如果新业务需要用到卡夫卡或 RabbitMQ 消息队列，测试人员要能快速掌握对应工具。

• 主动性。成绩突出的人往往拥有更强的主动性。主动思考所负责项目产品的痛点，主动发现问题，找到解决问题的机会点。此外，在交付版本或业务后，要有将其中的能力或问题提炼出来，作为公共能力或公共模块的意识。

朱志杰：可以是加分项，但对技术岗位而言，测试开发能力也是很重要的加分项。

朱志杰：腾讯有设计技术与管理两个能力提升通道，我个人同绝大多数人一样是走技术通道。但如果公司没有较强的职业指引或规范化工程师培养，可先以全栈的能力做自我要求。

测试理论只是个非常基础的概念，我们要在此基础上深刻掌握所负责的业务。要能从开发或产品的角度掌握业务，也要从运维的角度使用业务，我们才能在评审会议上提出有价值的问题，才能发现项目潜在的问题和风险点。

我们也要能结合业务需求，在具体问题解决上深入掌握相关技术。在遇到问题时，不能死读书，而是要从公司内部或外界同行中寻找好的解决方案。以数据库产品为例，我们要参考并尝试完善别人在面对 ACID 或高一致性问题上的方案，研究 ACID 场景上的差别，最终用其解决了实际问题，才能算是真正掌握了一项技术。

从长期来看，我们个人也需要打造自己的专长。可以深入研究自动化，做服务端接口自动化、基于接口协议自动化生成、通过模型化场景生成用例，甚至可以做流量自动化，将线上流量引入测试环境中进行回放。我们也可以将自己打造为效能专家，通过全流程进行效能分析，从而推动提升效能。

朱志杰：我在回答前面问题时，将沟通思辨放在了第一位。我认为沟通会影响很多方面：

• 有效沟通可以快速把握需求，把握改动。

• 快速准确地将所发现的问题同步给相关人员。

• 推动问题或改进流程化需要通过沟通调用开发、PM，及相关业务人员的配合完成。

• 有利于合作关系的维护，互利互补开发与测试的关系。

• 个人能力的呈现。

好的沟通不一定需要出口成章的能力，我个人的沟通能力也不算很好，关键是要能表达清楚问题和做事的思路，这是非常值得从日常工作中锻炼和提炼的。

朱志杰：这受个人性格方面的影响，自驱力很强的人会强迫自己进行表达，或许很有帮助，但对我而言却不一定要这样。在工作的小团体中，大家都非常熟悉、没有太多戒备，我们能将事情讲清楚，在向上级表达问题时有很好的呈现，就是一个很好的沟通形式了。

朱志杰：技术上可能没有什么太大的挑战。从大环境而言，近两年行业上都在关注降本增效，这对测试而言也是较大的挑战。大厂相对会看得更全面，但对中小公司或团队而言，如果测试左移、开发自测，或者产品运维自测上线，那么我们是否还需要测试呢？这个问题我觉得关键在于测试的价值与产出的呈现，在于项目对测试的依赖。

举例来说，项目的左移意味着开发要在较好的测试环境中进行测试，但这对开发而言是具有困难的，如果测试可以提供平台化工具、保持流程通顺，并提供验证、引流的能力，协助项目左移，那这不失为一个很好的解法。

测试的价值也体现在 Ops 运营类的项目中。测试可以为运营的灰度减少问题出现，提供上线后除监控外的其他测试手段快速发现问题，通过拨测、上线后压测、容量评估等手段，对 Ops 环境右移的能力给予有力支持。

在 2023，甚至是 2024 年，测试人员可能都要面临这一挑战，但我们也可以借此重新定位自己的价值，调整提供价值或服务能力的方向，主动适应环境。

朱志杰：持有“测试比开发简单、轻松”想法的人，所能做的测试内容是有限的，在测试中产生的价值也是有限的。我们也要将自己培养为全栈工程师，找出项目的问题所在，并随时准备为其提供解决问题的能力。

朱志杰：每个人大概都要找到合适自己的工作。我前面的建议对刚毕业，或刚刚走上测试工程师的人而言会更合适。如果你具有沟通推动，以及很好的组织协调能力，那么转职 PM 未尝不是一个好的方向。如果你对产品比较敏感，那么产品方向也是可以的。但如果你只想做业务测试，也可以走交付测试的方向。因为我个人主要关注服务端模块化测试，因此会更强调全栈的能力，要求有更高的平台化能力。

朱志杰：我做过的很多事情都是微不足道的。比较有成就感: 一是在过去大环境动荡的 2022 年中，我们团队上下二十余人整体都比较稳定，大家携手共进攻克挑战、提升效能，没有因为过多的冲击而动摇想法或信心。

二是我们在去年成功承担了腾讯广告计费能力下沉项目。我们通过完备的测试方案、测试引流对比、反向对比验证，完成了系统架构和计费能力的合并融合，整体构建过程没有出现故障，我认为是非常了不起的。项目历时一年半，从 2021 年下半年直到 2022 年上半年完成的主要项目进展，并在 2022 年下半年完成了收尾工作。在这一年半的时间中，大家心里的弦一直都没有放下来。

朱志杰：我认为测试首先需要有一个很好的抗压能力，其次也要能正确地分析工作，让团队成员在面对问题时有章法，有思路。在确定方案与策略后，按照节奏推进，大家都会心里有底。

此外，我们其实负责了腾讯收入的百分之七十的虚拟计费，每分每秒都有很高的交易量，因此基于我们测试保障体系、自动化能力、引流能力、代码安全性能力，包括线上拨测与压测等比较完备的保障能力，让大家还是比较放心的，没有感到特别大的压力。

最后，我也会给团队一些宽松度，让大家能较好地劳逸结合，不会产生过多的疲惫感。不会紧盯进度，但如果成员告诉我卡进度了，去协调人力，涉及较大的方案时协助拉相关的专家一起评审，帮助给出建议。

朱志杰：前面提到过技术基础，那么《Linux 从入门到精通》这本我十年前看过的书还是很值得看的。此外，《谷歌软件测试之道》这本书中介绍的很多谷歌测试的思想也很值得借鉴。达里欧的《原则一》我看过，《原则二》还没看，但书中介绍的关于工作透明化、管理方式也很具有启发性。

朱志杰：在未来两年中，我个人会更侧重于测试支持研效的建设，通过提高测试效率帮助研发提效。不止腾讯，对业界内很多公司来说，我觉得在这个方向上都可能在做一些事情，我觉得往这个方向可以去努力一下。比如你怎么样把自动化变得更简单一些，将自动化的成本降得更低 ; 怎么样把一个线上的流量用起来。

通过用流量建设减少自动化，或者说怎么样去除了满足自己的测试需要，去帮助开发去做测试左移，开发自测，支持他在测试环境，自动化的能力，支持他一些工具化的能力，帮他把整个理顺拉通。这个也是我个人 23 年要去做的一个方向。

朱志杰：2023 年是新的一年，祝大家能在测试的工作中找到自己的成就感，找到让自己变强的方法和钥匙，也希望 2023 年测试人员们能更自信。最糟糕的时候已经过去了，未来是美好的，我们要充满憧憬。

点击底部阅读原文访问 InfoQ 官网，获取更多精彩内容！