第69讲 | 茹炳晟：QE 团队向工程效能团队转型的实践之路

适用范围：测试团队负责人、QA/QE 从业者、研发效能团队负责人、技术管理者，以及正在经历或计划进行测试团队转型的团队。适用于组织架构转型、测试执行环境架构演进、质量保障体系升级等场景。

更新摘要（v2 · 2026-08 更新）：

• 结构化升级为 6 节骨架（导言 / 核心方法论 / 关键流程 / 工具与实战 / 常见误区 / 进阶延展）
• 整合原"AI 时代升级注解（2026）"内容，将 QE 转型升级为 AI 驱动的"智能工程效能"新时代
• 本文原文无 Mermaid 图，v2 以表格与结构化方式呈现
• 补充 AI-Native 转型路径、团队角色重新定义、质量保障机制
• 将原"作者简介"融入导言，原"结语"融入进阶延展

1. 导言

1.1 工程效能问题与 QE 转型趋势

在软件开发和项目执行中，工程效能问题一直是技术管理者考量的关键。加快研发效能和提升工程师团队效率及质量，需要在软件智能化上迈出创新步伐。

目前，包括 Google、eBay 等跨国互联网公司的研发团队都在经历"去除 QE（Quality Engineer 质量工程师）"的组织架构转变，为此 Google 也暂停了 2017 GTAC 并寻求向 Engineering Productivity 即工程效能的转型。相应地，QE 团队也正在逐渐向工程效能团队转型。

1.2 工程效能团队的价值

工程效能团队的好处在于，假如你的研发团队规模为 100 人，那么工程效能团队可能需要 15 个人，但当你的开发团队翻了 10 倍，达到 1000 人规模的时候，工程效能团队的人数可能仍旧是 15 个到 20 个之间。

所以，随着开发团队人员的增多、规模的增大，工程效能团队的输出和价值会越来越大，这也是为什么很多大型互联网公司、尤其是全球性的互联网公司都热衷于采用这种模式。

1.3 作者简介

茹炳晟，eBay 中国研发中心测试基础架构技术主管，具有超过 12 年的软件测试经验和 3 年开发经验，和丰富的测试框架设计与自动化测试经验。另外，他还在【极客时间】开设了专栏"软件测试 52 讲"，系统梳理软件测试的知识体系。

1.4 2026 年 AI 时代新背景

2026 年，GPT-5.5 和 DeepSeek V4 让 AI Agent 能力达到新高度，84% 的开发者使用 AI 编程工具。QE 向工程效能的转型正在进入**"AI 增强的智能工程效能"新阶段**。

2. 核心方法论

2.1 测试策略的变化：从传统到工程效能模式

传统的测试由 3 个部分组成，底层是单元测试，中间是 API 测试，最上面是 GUI 测试，是一个类似金字塔的三角形。其中，单元测试由开发人员来负责，API 测试和 GUI 测试都由专职的 QE 或 QA 来做。

但到了工程效能模式下，除了单元测试，API 测试和 GUI 测试也将由开发人员来做。这意味着，开发人员需要兼任测试的角色，克服从开发到测试的思维局限性。同时，还需要一个很高效的测试平台基础架构，提供一个便捷的测试执行环境，以支持开发人员方便的获得测试数据、执行测试。

原本的功能测试团队则蜕化成现在比较热门的探索式测试，测试开发人员则转变成工程效能开发的角色，去做测试平台相关的开发。

2.2 测试执行环境的四个要求

为了提升工程效能，一般会对测试执行环境提出以下要求：

第一点，对使用者而言，测试执行环境的"透明性"。所谓透明是指，假如要用测试环境跑一个 Mobile 的 Native 测试，需要某个版本、某个分辨率甚至某个品牌的手机，但这些设备不需要自己准备，只要提供相关的参数，后台就会帮我把其他事情准备好，并且把相应的测试分发过去。

第二点，对维护者而言，测试执行环境的"易维护性"。所谓易维护是指，不希望有上千甚至上万台机器的测试执行环境需要人工维护。因此，我们引入了容器化技术，用 Docker 来准备整个测试执行环境。

第三点，对于大量测试用例的执行而言，执行能力的"可扩展性"。引入容器化技术之后，可扩展性自然而然就解决了。我们会根据单位时间内测试用例的排队数量，通过算法来决定这个集群里需要多少台机器才能在规定的时间内执行完全部测试用例。

第四点，Mobile 移动终端的多样性与碎片化，这使得搭建一个包含各种 iOS 和 Android 设备的集群成为挑战。

2.3 工程效能转型的 AI-Native 演进

3. 关键流程

3.1 测试执行环境架构演进历程

第一版：基于 Jenkins 触发测试执行。这是最早也是最典型的测试执行环境。我们把测试用例放在 Github 中，Jenkins 会去获取这些用例，再在远程固定的测试执行环境中去跑这些用例。

第二版：基于 Test Runner / Test Execution System。因为 Jenkins 中跑测试的脚本会越来越多，我们在 Jenkins 脚本的基础上，封装了一个 Test Execution Service，这个服务会对 Jenkins 中的 Job 进行版本管理、用例管理等，不仅提供 UI 界面以方便开发的使用和对用例的管理，还提供 Restful API 接口用于与 CI/CD 的无缝集成。

第三版：基于 Selenium Grid 提高测试并行执行能力。原本远程测试执行环境是固定的 VM 环境，在这个版本中，我们用 Selenium Grid 搭建了一个 Hub，可以容纳上百台机器，下面挂了很多包含不同 OS 和浏览器版本的 Node。Selenium Grid 通过一个中央节点来接收所有的测试请求，再去查看自己的节点里面有没有相应的机器，如果有，就发到机器上去执行。

第四版：基于 Jenkins Cluster 提高测试并行执行能力。随着测试用例变多，原本远程测试执行这块的瓶颈已被 Selenium Grid 解决，但所有测试用例都开始在 Jenkins 上面排队，Jenkins 的单节点就成为了瓶颈。基于这个问题，我们把 Jenkins 打造成了一个集群，解决掉了系统的瓶颈点。

第五版：基于测试负载，用 Docker 实现 Selenium Grid 的动态扩展与收缩。在 eBay 内部有个很现实的问题，即一套测试用例可以在全球各个站点上执行测试，同一个测试用例如果乘上支持的国家数量之后，用例数据就会爆增。我们的做法是，用 Docker 实现 Selenium Grid 的动态扩展与收缩，做了一个 Auto Scaling 的服务，根据前面的用例排队情况来决定需要多少 Node，动态的去扩张整个 Node 的数量级。

3.2 移动终端测试执行集群

通过 Appium 和 Selenium Grid 搭建了一个移动终端的测试执行集群，集群里面放了各种各样的手机设备。开发人员指定要哪个品牌哪个型号的机器，测试系统就会自动到这个集群中搜索，如果有符合要求的机器，系统就会自动把测试发上去，执行完成之后再自动结束。开发人员都不需要知道这个集群搭建在哪里，他只要调用服务就可以使用。

这样一来，对于开发人员来说，他们做测试时就完全不需要考虑测试执行环境的问题，整个测试执行环境对他们而言是非常透明的。同时，这样一个基础架构的维护成本也非常低，只需要工程效能团队定期维护就可以了。

3.3 架构演进的核心经验

五版架构演进的核心逻辑是：逐一解决测试执行环境的瓶颈——从 Jenkins 单节点，到 Test Execution Service 封装，再到 Selenium Grid 并行、Jenkins Cluster 集群，最后用 Docker 实现动态伸缩。每一步都针对上一个版本的瓶颈点进行优化，最终实现透明、易维护、可扩展的测试执行环境。

4. 工具与实战

4.1 ⭐ 2026 可执行建议

1. 分阶段引入 AI 能力

• 第一阶段（1-3 个月）：部署 AI Code Review 工具
• 第二阶段（3-6 个月）：引入 AI 测试用例生成工具
• 第三阶段（6-12 个月）：构建 AI 驱动的智能测试平台

2. 重新定义团队角色

• 传统 QA → 质量策略师
• 测试开发 → AI 平台工程师
• 新增：AI Quality Engineer

3. 建立 AI 质量保障机制

• 制定《AI 生成测试用例的审核标准》
• 建立 AI 测试效果评估体系（漏检率、误报率等）

4.2 关键技术选型

5. 常见误区

5.1 认为 AI 会消除 QE 角色

误区：认为 AI 时代 QE 团队会被完全消除。

正确认知：AI 不是要消除 QE，而是让 QE 进化为"智能质量保障"。未来工程效能 = 人的专业判断 + AI 的海量计算。

5.2 忽视测试执行环境的可扩展性

误区：搭建固定的测试执行环境，不考虑用例规模增长带来的瓶颈。

正确认知：应通过容器化（Docker）实现测试执行环境的动态扩展与收缩，根据用例排队情况自动调整 Node 数量，同时解决易维护性问题。

5.3 让开发人员兼任测试却无平台支撑

误区：要求开发人员兼任测试角色，却不提供高效的测试平台基础架构。

正确认知：工程效能模式下，开发人员需要兼任测试角色，但前提是有高效、透明的测试平台基础架构，提供便捷的测试执行环境，支持开发人员方便的获得测试数据、执行测试。

5.4 忽视 AI 测试质量的审核

误区：直接使用 AI 生成的测试用例，不做质量审核。

正确认知：应制定《AI 生成测试用例的审核标准》，建立 AI 测试效果评估体系（漏检率、误报率等），确保 AI 测试质量可控。

6. 进阶延展

6.1 关键洞察

6.2 结语

为了进一步提高软件开发效率，测试环节也是需要技术管理者们重点关注的方向。如今，测试正在经历去除 QE，向工程效能转型的过程，在这一过程中，开发人员将更多的介入测试环节，因此如何提供给开发团队简单、易用、高效的测试基础架构就变得尤为重要。本文分享了测试执行环境架构的演进过程，希望能给有意向转型的团队提供参考。

核心观点：AI 不是要消除 QE，而是让 QE 进化为"智能质量保障"；未来工程效能 = 人的专业判断 + AI 的海量计算。

6.3 延伸阅读

• 茹炳晟专栏"软件测试 52 讲"（极客时间）
• QE 向工程效能转型系列文章（《技术领导力 300 讲》）

本内容基于 2026 年 6 月的技术环境编写，随着 AI 技术的快速发展，部分具体工具和建议可能需要定期更新。适用对象：测试团队负责人、研发效能团队负责人、技术管理者。