第6章 规模化执行

第6章 规模化执行

本章要回答的三个问题：同一套用例，凭什么保证在五个主流浏览器上都站得住？几百条用例串行跑要两小时，怎么安全地并行起来压进十分钟？流水线机器又慢又挤，网格与容器怎么把执行环境变得又快又干净？前三章的功夫让用例"单发可靠"，本章让它们"齐射可控"——规模化是自动化投资回报的分水岭。

为什么会有这一章

自动化套件的价值公式里有两个乘数：覆盖面与反馈速度。只用一个浏览器验证的套件，兜不住内核差异带来的真实故障；串行两小时的套件，永远赶不上交付节奏——跑不完就被跳过，跳过的回归等于没有回归。规模化就是把这两个乘数一起拉高的工程动作。

但规模化不是开关一按。并行会放大一切隐藏问题：用例间共享一个账号会互踢下线，共享一个下载目录会互相覆盖文件，一条用例改了全局配置会让同批用例集体翻车——这些在串行世界被时间顺序掩盖的耦合，在并行世界全部现形。兼容矩阵同理：哪些浏览器组合值得测、版本跟多紧、补不补边缘内核，都是成本与风险的配平题。本章把这两条线一起讲透，先定"测什么"，再解"怎么快"，最后给"在哪跑"。

读完能解决什么

读完本章，你应当能：为产品定一份有理由、可裁剪的浏览器兼容矩阵，并让同一套代码按矩阵参数化执行；识别并消除用例间的共享状态，用运行器与网格把套件安全地并行化，让执行时间随并行度近线性下降；用容器把执行环境标准化，做到"流水线与本地同构"；判断什么时候该上云平台、怎么选、怎么把花费管住。四样能力对应三节——矩阵与并行是主菜，容器与云是基础设施。

各节怎么分工

这张时序图是本章的终局画面：触发器提交矩阵，网格分发会话，节点并行执行，结果汇总成门禁依据。三节的内容就是把这幅图的每个参与者依次讲清楚——6.1 定矩阵（图中"目标矩阵"从哪来），6.2 管并行（分发与互不踩踏），6.3 搭环境（节点集群的形态）。

常见疑问

问：套件只有几十条用例，需要关心规模化吗？ 需要"半步"：矩阵分层与零共享的设计现在就该做（成本几乎为零），网格与云平台可以等量到了再上。规模化的设计决策要提前，基础设施投入可以滞后——本章的读法正建议这个节奏。

问：并行后报告会不会乱成一团？ 运行器的并行插件会把各进程结果合并成统一报告，按用例分列；真正的风险不在报告，在共享状态——这也是本章把"清共享"放在"配并行"前面的原因。

问：云平台要不要现在就开通试用？ 可以小成本试用验证接入流程（端点、能力声明、结果回收），但分层用云的策略先想清楚再上量——云的费用曲线很陡，策略先行的团队才租得起覆盖面。

常见疑问

问：并行与矩阵应该先做哪个？ 先矩阵参数化（6.1 的夹具改造），它决定了"一份代码跑多环境"的形态；并行化的前提是零共享，恰好也在这份改造里一并完成。两者就绪后，网格与云只是换端点。

问：规模化的终点是什么形态？ 触发即执行：提交触发冒烟、夜间全量矩阵、发布候选全量加门禁——执行环境弹性伸缩、结果自动进入度量看板。第 7 章会把这个形态接入流水线闭环。

先决条件

本章需要一个已经完成第 4 章结构改造的工程：用例走夹具托管、数据与配置已外置——并行的前提是"用例之间无共享"，而这些正是结构改造的产物。6.3 的容器部分需要本机安装容器运行时并对镜像构建有基本概念；云平台一节只需要决策视角，不需要预先开通账号。

往下走到哪

规模化的执行能力就位后，最后一公里是"结果可信"：并行的红屏怎么判定是真缺陷还是环境抖动、失败现场怎么自动取证、报告怎么让人一眼信服、流水线门禁怎么定级。下一章稳定性与持续集成，把规模化跑起来的套件变成团队敢信、敢用的质量门禁。