性能与契约测试

• k6 的脚本模型（VU、迭代）与 HTTP/WS 协议支持
• 阈值的声明式断言与 CI 门禁
• 与 Storybook CSF4 组件性能验证的协作

k6 是面向负载测试的脚本化工具：脚本用 JS（ES2021）编写，通过 VU（虚拟用户）与迭代模型控制压力，内置 http 与 ws 模块支持 HTTP/1.1、HTTP/2 与 WebSocket 压测；thresholds 在脚本中声明式断言（如 p(95) < 500、http_req_failed < 0.01），运行后按阈值判定通过/失败，可无缝接入 CI 作为性能门禁。内置的 metrics（请求耗时、失败率、吞吐）经 summary 输出，配合 InfluxDB/Prometheus 可做趋势分析。

与 Storybook 8 CSF4 的现代协作：CSF4 把 story 定义为可组合的组件规格，团队可在组件开发阶段用 k6 对"以组件为核心渲染的页面/接口"施加压力，验证高并发下的渲染服务与 API 水位；CSF4 的故事矩阵保证压测目标页面与组件文档同源，性能验证与组件演进同步。协作价值：把负载测试从"上线前的专项"变为"组件/页面开发期的常规门禁"，性能问题在最早阶段暴露。

本题为综合题：k6 侧考察脚本、VU 模型、阈值门禁；协作侧考察 CSF4 作为组件规格与压测目标同源的现代实践。

• 消费者驱动契约（CDC）的原理
• Provider/Consumer 双端验证流程
• 边界：复杂交互、版本管理与 mock 局限

Pact 是消费者驱动契约（Consumer-Driven Contracts）工具：前端（消费者）在测试中声明对接口的期望（请求与响应示例），生成契约文件（pact file）；后端（提供者）在 CI 中用契约回放验证自身实现是否满足期望（pact-verifier）。两端各自独立测试、互不联调，契约文件经 Pact Broker 共享与版本管理，实现"前端先行定义、后端按约实现"的并行开发。

边界：Pact 擅长 HTTP 请求/响应结构契约，但对状态相关交互（同一资源不同状态）需用 provider state 管理，复杂真实交互（长连接、流式）支持有限；契约只验证"示例集"而非全部语义，响应字段缺失与格式漂移仍需字段级 matchers 治理；版本兼容验证（can-i-deploy）依赖 Broker 部署，小团队可用文件共享简化。最佳实践：契约覆盖核心接口，契约与 MSW handler、OpenAPI 规范三源对齐，防止描述漂移。

考察 CDC 的完整机制：消费者期望 → 契约 → 提供者验证，回答应点明契约的"示例性"本质与状态管理、版本管理等边界。

• 内存回归：堆快照与增长基线
• FPS/帧率回归：PerformanceObserver 与长任务
• 阈值与 CI 集成的稳定性治理

内存回归测试的核心是测量"稳定状态下的内存基线"：进入/离开关键场景后强制 GC（--js-flags=--expose-gc）取样，比较快照间增长（detached DOM、全局累积），对长会话 SPA 用多次快照对比确认无持续增长；指标可设阈值（如每次导航增长 < 1MB）作为回归门禁。FPS/帧率回归用 PerformanceObserver（frame 事件）、requestAnimationFrame 计数与 Long Tasks（>50ms 任务数）间接度量，直接读取合成器帧率在 Web 层不可得，因此通常以"长任务时长、dropped frame 比例"为代理指标。

实施要点：测试环境必须可控（固定设备仿真、CPU 节流、网络稳定）保证可复现；指标取多次运行的中位数而非单次，设置容差区间（±10%）避免噪声误报；CI 中与视觉/功能测试并行，性能回归作为独立 job 运行，失败时归档性能 trace 供分析。核心原则：回归测试测"趋势与基线"而非绝对性能，检测相对退化比测量绝对数值更有工程价值。

考察性能回归的可测性转化：内存以快照基线、帧率以长任务/掉帧代理指标，回答应强调环境控制、统计口径与趋势检测。

• Bundle 体积门禁的意义与目标设置
• size-limit 的精确测量与开销分析
• 与 CI/PR 检查的集成

Bundle 体积回归测试把"产物体积"纳入自动门禁：构建后测量 JS/CSS 产物大小（总包、首屏关键包、gzip/brotli 压缩后），与预算对比，超限即失败，防止依赖膨胀与无序 import 悄悄拖大包体。size-limit 的差异化能力：按"实际执行开销"（Parse/Evaluate 时间估算）与压缩后体积双重度量，支持按路径拆分检查（imports 分析），并生成体积报告；bundlesize 是更早的纯体积工具（配置 files 与 maxSize），生态相对简单。

实践要点：预算按"当前基线 + 增长缓冲"设定（如总包 gzip ≤ 500KB、首屏包 ≤ 200KB），避免拍脑袋；PR 检查中展示体积 diff（新增 +12KB）让变更透明；对大体积波动（新依赖）自动告警并要求确认；配合 webpack-bundle-analyzer/rollup-plugin-visualizer 定位体积来源。门禁的意义在于"把体积当作一等公民指标"，与 LCP 等运行时指标形成供给侧闭环。

考察体积回归的工程化：预算设定、工具差异（size-limit 的开销度量）、CI 集成，回答应强调预算基线管理与变更透明。

• web-vitals 的指标封装与阈值分级
• PerformanceObserver 的原生测量机制
• 合成回归与 RUM 数据的协作

web-vitals 库封装了 CWV（LCP/INP/CLS）的测量：内部基于 PerformanceObserver（paint、layout-shift、event 等 entryType）监听性能条目，自动处理条目归属（如 LCP 的 last 条目、CLS 的 session window），并提供 onLCP/onINP/onCLS API 与阈值分级（good/needs-improvement/poor）。PerformanceObserver 是原生接口：以 buffered: true 读取注册前的条目、用 observe({ type }) 监听增量，是实验室与字段数据的共同基础。

自动化回归应用：在 Playwright/Cypress 页面流程中注入 web-vitals 采样，导航后断言指标在预算内（如 LCP p75 < 2.5s）；PerformanceObserver 可直接读取 navigation-timing/resource-timing 做细粒度断言（TTFB、资源耗时）；两者结合把"性能预算"变成可执行的测试断言，与 RUM 字段数据（CrUX）互为校验——实验室回归测改动影响、字段数据测真实分布，形成"开发期回归 + 生产期验证"闭环。

考察性能测量的两层工具：web-vitals 的高层封装与 PerformanceObserver 的原生能力，回答应说明其在实验室回归与 RUM 中的分工。

• 消除联调等待与并行开发的可行性
• 回归安全网与接口变更的提前暴露
• Pact 与 OpenAPI 两种形态的取舍

契约测试让前后端不再依赖"联调环境"：前端按契约 mock 开发，后端按契约自测，接口一致性在双方 CI 中分别验证，并行开发、独立发布，把联调从"人肉对齐"变为"自动化校验"。回归价值：后端改字段/删字段时，契约验证立即暴露不兼容；前端升级调用方式时，本地契约测试同样拦截，接口变更风险在合并前收敛，配合 Pact Broker 的 can-i-deploy 实现安全发布决策。

两种形态：Pact 是消费者驱动（前端声明期望，贴近真实使用）；OpenAPI 是提供者驱动规范（schema 定义接口，配合 contract testing 工具做响应校验），前者更关注"使用方契约"，后者更关注"接口规范"，实践中常双轨并用（OpenAPI 做设计文档与 codegen、Pact 做使用契约）。工程价值总结：加速并行、拦截回归、驱动设计（API First），是接口质量的体系化保障。

考察契约测试的联调与回归价值：并行开发、回归安全网、发布决策，回答应对比 Pact 与 OpenAPI 两种形态的互补。

• Jest 30 的演进（ESM、速度、运行器）
• Playwright 1.5x 的测试范围（单测到 E2E）
• 按测试层次选择的工程策略

Jest 30 聚焦传统单测运行器的现代化：完善原生 ESM 支持、改进 mock 语义与运行器性能（向 Rust 迁移的实验项目），保持庞大的匹配器与断言生态，适合存量 JS/TS 项目的渐进升级。Playwright 1.5x 则是"全栈测试平台"：以浏览器驱动为基础，从 E2E 延伸到组件测试与性能测试，Web-First 断言与自动等待贯穿所有层次，测试风格统一。

取舍策略：按测试层次而非品牌选择——纯函数与组件逻辑用 Vitest/Jest（快、无浏览器开销）；组件交互与 E2E 用 Playwright（真实浏览器）；若团队希望"一套 API 到底"，Playwright 1.5x 可承担组件+E2E 层，Jest 30 专注单测层，两者在测试金字塔中各司其职。迁移考量：Jest 30 对 ESM 与 TS 的配置仍比 Vitest 复杂，新项目通常优先 Vitest；存量项目以 Jest 30 升级为主，E2E 层逐步引入 Playwright。

考察两大工具的最新定位：Jest 30 是单测运行器演进、Playwright 1.5x 是全栈浏览器测试平台，回答应给出按层次组合的选型建议。

• 手写 mock 的重复与漂移问题
• Fishery 的工厂定义与按需覆盖
• 类型推导与关联构建

手写 mock 对象的问题：每个测试复制一份对象字面量，字段增减时难以同步、类型易失真（any/Partial 滥用）、结构漂移难以发现。Fishery 等 fixture factory 以工厂函数声明"默认对象"，测试中按需覆盖（userFactory.build({ role: 'admin' })），默认值与覆盖值分离，字段变更只需改工厂一处；由于工厂从真实类型构建（build()），TypeScript 全量推导，类型错误在编译期暴露。

进阶能力：关联构建（userFactory.build() 内嵌 postFactory）、序列化构建（buildList(n)）、异步构建（buildAsync）与参数化默认值（按索引生成唯一数据），支持复杂测试数据的声明式组装。与手写 mock 相比，工厂把"数据规格"集中化、类型化、可复用，显著降低测试数据的维护成本与漂移风险，是大型项目测试数据管理的标准实践。

考察 fixture 工厂的类型安全与维护性：集中定义、按需覆盖、类型推导、关联构建，回答应对比手写 mock 的漂移与重复问题。

• 基础 handler 的领域组织与共享
• 场景 override 的按需覆盖机制
• 用例间隔离与重置策略

MSW handler 分层组织的第一层是"基础 handler"：按领域模块（user/order/product）集中定义正常路径的接口响应，作为团队共享的默认行为；第二层是"场景 override"：单个测试在 setupServer 实例上追加或覆盖特定接口（server.use(http.get('/api/user', ...))），模拟错误、空数据、慢响应等边界场景。分层让"默认正常、按需特殊"成为组织原则，避免每个测试重复声明完整接口集。

隔离策略：beforeAll 启动 server、afterEach 调 server.resetHandlers() 恢复基础 handler（清除用例内 override）、afterAll 关闭；并行执行时每个 worker 拥有独立 server 实例；handler 工厂支持按测试传入参数（延迟、数据量）动态构建。实践要点：override 命名清晰（如 'scenario: user-not-found'）、禁止在测试中直接修改共享 handler 对象、基础 handler 与契约数据（Pact/OpenAPI 示例）对齐，保证描述一致性。

考察 MSW handler 的工程化组织：基础层 + 覆盖层 + 生命周期隔离，回答应强调"默认正常、按需覆盖、用完重置"的三原则。

• 体积预算与 PR 检查的集成
• size-limit 的度量维度与配置
• Bundlewatch 的 CI 对比机制

PR 阶段的体积门禁把"产物是否膨胀"变成合入条件：构建产物测量后与预算或基线对比，超限时 PR 检查失败并展示 diff。size-limit 在 package.json 或配置文件声明 limit（如 { path: 'dist/index.js', limit: '200 kB' }），支持 gzip/brotli 压缩后体积与执行时间（parse/evaluate）双维度，通过 imports 分析定位体积来源，作为 CI 步骤（npx size-limit --ci）返回状态码。

Bundlewatch 的核心机制是"与基线比较"：记录每次构建的产物体积（bundlewatch 配置 + 上传），在 CI 对比上一次（基准分支）体积，输出 +X KB 的 diff 并支持 maxSize/maxPercentChange 门禁，体积增长透明可见。实践要点：预算先宽松后收紧（先记录基线再设阈值）、关键包（首屏）单独设限、大体积变更强制人工确认、门禁失败时展示分析报告定位新增来源。

考察体积门禁的两种模式：绝对预算（size-limit）与相对对比（Bundlewatch），回答应说明配置、CI 集成与变更治理。

• Lighthouse CI 的运行模式（staticServer/pa11y 集成）
• assertions 预算与阈值配置
• 与 CI 流程的集成及波动治理

Lighthouse CI（LHCI）把 Lighthouse 审计变成 CI 步骤：以 static server 或 URL 方式对页面运行 Lighthouse，产出性能、可访问性、SEO 等类目评分与详细审计项。性能门禁通过 assertions 声明（如 'categories:performance' >= 0.9、'largest-contentful-paint' < 2500ms、'total-blocking-time' < 200ms），未达标即失败；lighthouserc.json 可配置收集（numberOfRuns 多次取中位数）、断言与上传（Lighthouse CI 服务器/存储）。

治理实践：环境必须固定（设备仿真、CPU 节流 4x、网络 throttling 固定）保证可比性；多次运行取中位数抑制波动；预算分级（warning vs error）避免偶发抖动直接阻断；失败时归档报告与截图供分析；与 performance-budget.json（资源大小预算）配合形成"指标 + 资源"双门禁。核心原则：门禁要"稳"（低误报）也要"严"（真回归必拦），通过基线调整与分级阈值实现。

考察 LHCI 的门禁机制：收集-断言-上传三步配置、环境固定与波动治理，回答应体现"稳与严"平衡的治理思路。

• k6 的脚本化压测模型与指标
• 对 SPA 加压的挑战（浏览器执行 vs 协议请求）
• 与真实浏览器压测的协作边界

k6 以脚本（JS）定义压测：options 中声明 stages（渐进加压曲线）、vus（并发数）与 durations，内置 http/ws 模块按协议层发请求，采集吞吐、延迟分布、失败率等指标，配合 thresholds 自动判定是否达标。对传统服务端接口压测，k6 高效且资源占用低，是容量评估与性能基线的标准工具。

对 SPA 加压的挑战：SPA 的页面渲染、JS 执行与客户端状态发生在浏览器内，k6 的协议层请求无法覆盖"浏览器视角"的交互负载（k6 的 browser 模块基于 Playwright 可实现真实浏览器加压，但成本高、并发受限）。工程价值与协作：用 k6 压测 API/数据层容量（后端瓶颈），用真实浏览器测试（Playwright 并发、Lighthouse 合成）验证前端渲染与交互性能，两者结合覆盖"服务端容量 + 客户端体验"两个维度；k6 的阈值与 CI 集成使容量回归常态化。

考察负载测试的层次认知：k6 协议层压测服务端容量，SPA 的客户端体验需真实浏览器配合，回答应说明双维度协作边界。

• performance-budget.json 的资源预算声明
• LHCI 对预算的收集与断言
• 预算与指标门禁的配合

performance-budget.json 是 Lighthouse 的资源预算文件：按资源类型（first-party-javascript、total-javascript、images、font、third-party）声明最大体积与数量（如 total-javascript: 400KB、requests 上限），Lighthouse 收集阶段会解析预算并输出 budget 审计结果（每个资源类目的实际值 vs 预算）。Lighthouse CI 中可对该审计做断言（'performance-budget' 通过率），或直接以 resource-summary 审计的数值断言，实现"PR 中新增依赖/大图立即告警"。

与指标门禁的配合：performance-budget 管"供给侧"（发送多少字节），Lighthouse 指标断言管"体验侧"（LCP/TBT 表现）；两者结合形成完整预算体系——预算超限是根因、指标劣化是结果，PR 检查同时展示两者 diff。实践要点：预算按当前基线 + 缓冲设定并定期复审、第三方脚本单独设限防止默默膨胀、失败时报告资源明细（哪个文件超限）方便定位。

考察资源预算的落地机制：performance-budget.json 声明、LHCI 断言、与指标门禁的供给侧/体验侧配合。

• Ladle 的轻量架构与速度优势
• 在组件测试、文档与视觉回归中的角色
• 大型项目 CI 资源与维护成本收益

Ladle 基于 Vite 实现 CSF story 生态的轻量子集：支持 args、play 函数、decorators 与 addons 体系，但依赖极少、启动与构建秒级完成，在大型仓库（上千组件）中构建 Storybook 可能耗时数分钟，Ladle 可将组件开发服务器与测试构建压缩到数秒。它是"以速度换生态"的选择：核心 story 能力（渲染、交互、测试挂载）保留，重型 addon（文档站、依赖图）舍弃。

测试金字塔中的价值：作为组件层的稳定渲染与测试入口——Vitest 组件测试、Playwright 组件级 E2E 都可直接导航到 Ladle story URL；CI 中轻量构建降低每次提交的资源与时间成本，性能预算测试、视觉快照（对接 Percy/自建截图）均可复用同一 story 源；同时作为开发期的组件文档中心，团队以低开销获得"文档 + 测试 + 开发"一体化。取舍：需要完整文档站与丰富 addon 时仍选 Storybook，Ladle 适合以测试为核心的工程化团队。

考察轻量组件工具在金字塔中的定位：以速度换生态、story 作为统一测试入口、CI 资源收益，回答应包含与 Storybook 的取舍。

• CSF4 的元数据与可组合 story 结构
• story 驱动的测试在 CI 中的并行执行
• 与 Chromatic、Test Runner 的流水线协作

CSF4 是 Storybook 8 的组件规格标准：meta 支持更丰富的 tags 与配置，story 以对象导出（args/render/play）声明，支持 story 组合（组合多个 story 的状态）与命名导出矩阵，让"组件行为规格"结构化、可被工具链批量消费。CI/CD 价值：同一份 CSF 描述同时驱动视觉回归（Chromatic）、交互测试（Test Runner/Vitest plugin）与文档生成，测试资产单一来源，流水线各阶段（静态检查、组件测试、E2E、发布）共享同一组件语义。

并行执行：Test Runner 与 Chromatic 均按 story 粒度并行（TurboSnap 按依赖只测变更 story），大型组件库的验证时间随 story 矩阵可控；CI 中按 tags 划分测试集（smoke/visual/a11y 分层并行 job），失败按 story 精确定位组件与状态。工程价值：组件质量门禁前移、变更影响面自动收窄、发布流水线以组件为单位独立验证，是现代组件驱动开发的基座。

考察 CSF4 作为组件规格标准的工程化收益：单一描述源驱动多工具、story 粒度并行与按依赖增量测试。

• lighthouserc.json 的 collect/assert/upload 三段
• 断言与预算的层次（类别、审计项、资源）
• 基线演进与波动治理

lighthouserc.json 是 LHCI 的配置入口，三段结构：collect——定义采集目标（staticDistDir 静态目录或 url 数组）、运行次数（numberOfRuns）、设备与节流设置；assert——声明断言（preset: 'lighthouse:recommended' 或自定义 categories/audits 阈值、minScore）；upload——报告存储（LHCI 服务器、S3 或 target: 'filesystem' 输出 artifact）。CLI 流程（lighthouseci autorun）按此执行：启动静态服务 → 采集 → 断言 → 上传。

预算治理要点：断言分级（assertions 的 warning/error 两档，warning 不阻断）抑制偶发波动；多次运行取中位数（或最低）作为稳定口径；预算随优化演进定期"重新基线"而非永远固定；收集环境严格固定（CPU 节流、网络节流、设备模拟）保证跨 PR 可比；失败报告归档（HTML/JSON + 截图）供根因分析。治理目标是"门禁稳定、误报趋零、真实回归必拦"。

考察 LHCI 配置的三段模型与治理实践：采集/断言/上传、分级阈值、基线演进与环境固定。

• 契约驱动开发的流程（契约先行）
• Mock 与契约的生成与消费关系
• 双轨落地：开发期 mock、验证期契约

契约驱动开发（CDD）以"契约先行"为核心：前后端先就接口达成一致（OpenAPI 规范或 Pact 契约），前端据此用 mock 开发，后端据此实现，双方 CI 中按契约校验，避免"实现完再对齐"的高成本返工。API Mock 是开发期的执行工具：前端按契约生成 mock（OpenAPI codegen mock server 或 MSW handler），界面开发不依赖后端可用性；契约测试是验证期的安全网：后端响应必须通过契约回放（Pact verifier）或 schema 校验。

配合机制：契约是"单一事实源"——mock 从契约生成（保证开发期与最终一致）、测试从契约派生（断言接口形状）、文档从契约导出（API 文档自动同步）；契约变更走评审流程，变更后 mock、测试、文档同步再生成。工程要点：契约粒度（字段级 matchers/格式校验）、版本管理（Broker 或 Git 化）、变更通知（can-i-deploy）；CDD 让"联调"退化为"契约对齐"，从流程上消灭接口类缺陷。

考察契约驱动开发的完整闭环：契约先行、mock 生成、契约验证、变更治理，回答应强调契约作为单一事实源的地位。

• WebPageTest 的多地点多设备真实网络测试
• 瀑布图、视频回放与诊断报告
• 与 Lighthouse 的定位差异

WebPageTest（WPT）是基于真实浏览器的性能测试平台：可指定全球多地点的真实网络（含 3G/4G/光纤）、多种设备（移动/桌面）与浏览器版本执行加载测试，输出完整瀑布图（每资源时序）、视频回放（视觉加载过程）、Lighthouse 评分与自定义脚本（登录、交互流程）。其核心价值是"真实条件"：地理位置、网络特征、设备能力共同决定真实用户体验，实验室默认环境无法覆盖。

与 Lighthouse 的差异：Lighthouse 是合成审计（固定模拟环境、评分体系、类别齐全），适合 CI 门禁与对比；WPT 侧重真实条件与深度诊断（连接时间、DNS、缓存命中、第三方影响），适合上线前的多地域验证与复杂问题定位（如区域 CDN 回源慢）。实践上两者互补：LHCI 做日常门禁，WPT 做发布前多地点全流程验证与根因分析。

考察真实场景测试的定位：WPT 以多地点、真实网络与深度诊断见长，与 Lighthouse 合成审计形成互补。

• 通过 evaluate/注入脚本采集 CWV
• 与合成监控的差异
• 性能断言与预算集成

Puppeteer 与 Cypress 都能在真实浏览器流程中注入 Web Vitals 采集：Puppeteer 通过 page.evaluate 动态加载 web-vitals 库并调用 onLCP/onINP/onCLS 收集（或通过 PerformanceObserver 读 entry），Cypress 用 cy.window() 注入脚本与 cy.intercept 计时；采集的指标值在测试中做阈值断言（如 LCP < 2500ms），实现"交互流程级性能回归"——不同于 Lighthouse 的单页合成审计，可以测真实用户路径（登录→列表→详情）上的性能表现。

工程价值与差异：这类测试把性能断言嵌入现有 E2E，覆盖"真实交互路径 + 真实浏览器"，与 Lighthouse（单页、模拟）和 RUM（生产、真实分布）形成三极：E2E 注入测"路径性能回归"、LHCI 测"页面合成基线"、RUM 测"生产真实分布"。实践要点：注入与断言封装为 fixture/命令复用、指标取多次运行的中位数、环境固定（节流）保证可比、失败时归档性能明细（LCP 元素、资源列表）。

考察在 E2E 流程中嵌入性能测量：注入 web-vitals、路径级断言、与合成/RUM 三极互补。

• PactFlow 的契约托管与发布决策
• Mock Server 按契约生成模拟服务
• 微前端多团队契约治理

PactFlow 是 Pact 契约的托管平台：存储契约版本、展示消费者/提供者依赖矩阵、执行 can-i-deploy（校验目标版本与已部署消费方兼容）、通知变更与验证结果，是多团队协作的契约枢纽。Mock Server（如 Pact 的 pact-mock-service 或基于 OpenAPI 的 Prism）按契约描述动态生成模拟接口，供消费者本地/CI 开发使用，让"契约 → 可运行 mock"自动化。

在微前端集成中的边界：微前端拆分了页面所有权，共享数据接口常由不同团队维护，PactFlow 负责跨团队契约版本治理（A 团队的消费者升级需验证所有相关提供者）；Mock Server 支撑各微应用独立开发测试，但 mock 无法覆盖状态耦合（同一资源在不同微应用的共享状态）、时序与真实数据语义；因此集成验证仍需环境级联调与 E2E 兜底。协作要点：契约变更在 PactFlow 上评审、mock 数据与契约示例一致、微前端之间接口同样纳入契约矩阵。

考察契约平台与 mock 服务的分工：PactFlow 管版本与兼容、Mock Server 管开发期供给，回答应点明微前端场景的状态耦合边界。

• 合成工具的环境差异（地点/设备/网络）
• 多地点测量的 CDN 与地域洞察
• 双工具的组合应用策略

Lighthouse 默认在本地固定环境（桌面模拟、预设节流）运行，同一测试在不同机器可复现性好，适合基线对比与 CI 门禁，但它代表"一种模拟环境"。WebPageTest 可选择全球测试地点与真实网络（3G/4G/5G）、移动设备与浏览器组合，能暴露地域性问题：CDN 覆盖不足地区的 TTFB 高、区域缓存策略差异、移动端处理器性能导致的 JS 执行慢。多地点多设备测量回答"不同用户在哪里、用什么设备访问，体验是否一致"。

工程价值：发布前用 WPT 做多地点矩阵（如北美/欧洲/亚太各选代表点）验证 CDN 与边缘策略；用真实移动设备验证设备性能影响；把结果与 Lighthouse 基线对比定位"环境差异 vs 真实问题"。组合策略：LHCI 管日常回归（快速、可复现），WPT 管发布前多地域体检（深度、真实），RUM 管生产持续监控，三层数据交叉验证，避免"本地满分、远端劣化"的盲区。

考察合成测量的环境维度：Lighthouse 可复现、WPT 多地点真实，回答应体现三层组合的监控策略。

• PerformanceObserver 的字段数据采集能力
• Lighthouse 的实验室数据属性
• RUM 体系的组合设计

PerformanceObserver 是浏览器原生接口，以观察者模式订阅性能条目（paint、layout-shift、longtask、resource、navigation 等），配合 buffered: true 可读取注册前条目、设置 buffer 上限防溢出；它是 RUM 采集的底层设施——前端代码在页面运行时订阅指标并上报（web-vitals 库即构建其上），数据反映真实用户设备、网络与使用路径，构成字段数据（Field Data）。Lighthouse 是合成工具：固定环境下单次审计，输出结构化评分与诊断，属于实验室数据（Lab Data）。

RUM 中的分工：PerformanceObserver 负责"真实分布"——采样、聚合、上报（批量、抽样、避免丢条目），回答"真实用户体验如何"；Lighthouse 负责"可复现基线"——每次部署前后对比、门禁判定、诊断归因，回答"这个版本到底改了什么"。组合设计：RUM 定分布与告警（p75 阈值、分设备分地区）、LHCI 定回归门禁、CrUX 做第三方基准校验；实验室指标（如 TBT）与字段指标（INP）对应关系用于桥接两类数据。

考察 Lab 与 Field 数据的采集机制差异：PerformanceObserver 支撑字段采集、Lighthouse 产出实验室审计，回答应给出 RUM 组合设计。

• V8 代码缓存与启动快照原理
• Node 测试中的启动开销构成
• Jest worker 复用与快照的边界

Node.js 的启动开销包括模块解析、编译与 V8 初始化，v8 snapshot（如 Node 的 startup snapshot / SEA 与 test 场景下的 --node-snapshot 实验）把预热后的堆序列化为快照，进程启动时直接恢复，跳过重复的模块加载与编译，可显著缩短高频次启动（如大量测试文件各自起进程）的总时间。测试框架中，worker 进程复用（Jest 28 的 worker 池、Vitest 的 forks/threads 池）是另一种加速：进程/线程常驻、测试文件循环执行，避免每文件冷启动。

边界：v8 snapshot 要求启动路径确定性（序列化时机、依赖加载一致），动态依赖、环境变量敏感代码难以快照；Jest 28 worker 复用受限于"同一环境复用"，环境变化（不同 env、不同参数）需新建 worker，且 worker 数量与内存配额需平衡。实践组合：worker 池消除重复进程启动 + V8 缓存（Node 的 code cache）减少编译 + 测试内避免重量级全局初始化，三管齐下把启动开销压到最低。

考察测试启动性能的两条路径：v8 快照（编译/堆恢复）与 worker 复用（进程常驻），回答应说明各自边界与组合策略。

• matchers 的类型与用途（like/eachLike/term）
• 动态字段（id、timestamp）的匹配策略
• 匹配精度与验证强度的平衡

接口响应中的动态值（自增 id、时间戳、随机 token）无法用字面量做契约匹配，Pact 提供 matchers：like（类型匹配，如 like('123') 只要求字符串）、eachLike（数组元素结构匹配，任意长度）、term（正则匹配，如 term({ matcher: '\d{4}-\d{2}-\d{2}', generate: '2026-08-04' })）以及整数/十进制等专用匹配器。消费者在期望中声明 matcher，提供者验证时按类型/正则而非字面量比对，从而对"值可变、形不变"的字段稳健匹配。

匹配策略：区分"结构契约"（类型、嵌套、必选字段）与"值契约"（枚举、固定响应码），动态值用 matcher 声明结构、稳定值用字面量声明精确值；matcher 组合（eachLike + 嵌套 like/term）表达复杂结构；注意 matcher 使用要克制——全 matcher 会弱化验证（什么都匹配）、全字面量会因动态值误报，按字段性质选择匹配强度。验证时 provider 状态（provider state）配合生成符合 matcher 的数据，保证契约可回放。

考察契约匹配的精度设计：matchers 让契约在"形"上验证而非"值"上死磕，回答应强调匹配强度与字段性质匹配的平衡。

• 双工具的组件可视化验证能力
• 同一 story 描述的双工具复用
• 按团队结构选择与协作

Storybook + Chromatic 是组件可视化回归的主流组合：story 矩阵驱动多浏览器快照与像素 diff，基线审批流成熟；Cypress Component Testing 也可做组件视觉验证（cy.screenshot 捕获、配合 Percy 等视觉服务 diff），且与交互测试共享 Runner 与命令生态。两者可协作：组件团队用 Storybook 管理 story（文档、矩阵、Chromatic 视觉回归），Cypress Component Testing 承载交互逻辑测试，或反向——把 Storybook story 挂载进 Cypress（mount 的 story 封装）复用同一描述。

取舍考量：Storybook 侧重"组件资产化"（文档、设计协作、视觉回归中心），Cypress CT 侧重"测试工程化"（与 E2E 统一语法、CI 集成、交互断言）；组件库/设计系统优先 Storybook 生态，业务应用内组件优先 Cypress CT 与 E2E 同栈。实践建议：明确"一份 story 描述、按需消费"的原则——视觉回归选一个工具为主（避免双份快照维护），交互测试选与团队主测试框架一致的工具，避免两套组件测试体系并行造成维护分裂。

考察组件可视化测试的双工具分工：Storybook 组件资产化 vs Cypress CT 测试工程化，回答应给出"单一描述、按需消费"的治理原则。

• 微基准测试的方法论（预热、循环、统计）
• benchmark.js 与 tinybench 的取舍
• 微基准的失真风险与边界

微基准测试（microbenchmark）测量单个函数/热路径的性能：benchmark.js 与 tinybench 通过多次迭代采样、预热（JIT 编译稳定）、统计中位数/百分位输出结论，tinybench 更轻量（零依赖、TS 原生、异步支持）。用于高频路径（debounce/throttle 的调度开销、日期/数字格式化、字符串拼接）的优化验证：改动前后同环境对比，量化收益，防止"感觉更快"的主观优化。

边界与风险：微基准易失真——JIT 优化（死代码消除、内联缓存热态）使孤立函数性能与真实调用环境差异巨大；GC 干扰、时钟精度、环境差异（CPU 频率缩放）带来噪声；测得的是"合成场景"而非真实负载。现代实践：微基准只做"相对对比"不做绝对断言、同进程内交替测量（A/B/A）抵消环境漂移、关键路径用真实数据（真实格式样本）测、把微基准结果与真实指标（INP/Long Task）关联验证。结论：微基准是优化决策的输入之一，不是唯一依据。

考察微基准的方法论与局限：预热统计、相对对比、JIT 与噪声失真，回答应强调"辅助决策而非绝对真理"的边界意识。

• Broker 的契约存储与版本标记
• can-i-deploy 的兼容性决策
• 多版本并存时的验证矩阵

Pact Broker 是契约的中央仓库：消费者发布契约版本（关联应用版本与分支、tag 标记环境如 main/prod），提供者验证结果回传并发布版本信息；Broker 记录每个版本的"已验证关系"（verification matrix），形成应用间依赖与兼容图谱。can-i-deploy 是核心决策工具：发布前询问 Broker"目标版本与已部署/待部署的消费方（或提供方）版本是否已验证兼容"，Broker 依据矩阵返回 yes/no，将"契约兼容"变成发布门禁。

跨服务版本兼容的协作：契约是"消费者对提供者的期望"，因此提供者升级时必须验证所有已部署消费者版本的契约（多消费者验证矩阵），消费者升级前验证目标提供者版本；tag（环境映射）让 Broker 知道"哪个版本在生产"，据此判断安全部署顺序。工程要点：契约只增不删的演进（新契约先行）、版本回滚时的契约兼容回查、Broker 与 CI/CD 平台深度集成（发布流水线自动 can-i-deploy），实现"契约级的安全发布"。

考察契约版本治理的机制：Broker 矩阵、tag 环境映射、can-i-deploy 决策，回答应说明多版本并存时的验证关系。

• Lab 数据的测量口径与固定环境
• CWV 在 Lab 中的对应指标与代理
• Lab 数据的工程应用与局限

Lab 数据（实验室数据）在受控环境中测量：Lighthouse 固定设备仿真（桌面/移动）、CPU 节流与网络节流，多次运行取中位数，保证跨环境可复现——这是它与 RUM 字段数据的本质区别。CWV 在 Lab 中的对应：LCP/CLS 可直接测量，INP 需要合成交互（Lighthouse 的 TBT 作为代理，模拟输入延迟）；因此 Lab 门禁通常用 TBT 代表交互性能，用 LCP/CLS 直接约束视觉与稳定体验。

应用价值：开发/CI 阶段的门禁（LHCI 断言）、版本对比（部署前后评分差异）、回归根因诊断（审计项定位具体资源/脚本问题）；局限：Lab 是"一种模拟环境"，无法覆盖真实网络分布、设备多样性、用户交互模式，Lab 好不等于真实好。工程实践：Lab 数据管"改没改坏"（回归门禁），Field 数据管"真实如何"（CrUX/RUM 阈值），发布决策以 Field 为主、Lab 为辅，两者结合避免"实验室满分、线上翻车"。

考察 Lab 数据的本质：固定环境可复现、TBT 代理 INP，回答应明确 Lab 用于回归门禁、Field 用于真实评估的分工。

• GraphQL 契约的形式：schema 与操作（query/mutation）
• introspection 与 codegen 的契约派生
• 双端一致性验证

GraphQL 的契约由两部分构成：schema（服务端类型定义）与客户端操作（query/mutation 及 fragment）。schema introspection 暴露运行时 schema，客户端 codegen（graphql-codegen）从 schema 生成 TS 类型与 hooks，实现"schema 即契约"的类型安全消费。契约测试协作：服务端用 schema 校验（graphql-validator、mock schema 测试）与 resolver 测试保证实现符合 schema；客户端验证操作在真实（或 mock）schema 上的合法性（graphql codegen 的 loadSchema 校验、操作测试用 typed document）。

关键机制：schema 变更时 introspection 同步更新，codegen 重新生成类型，类型不匹配在编译期暴露（消费端字段删除、参数变更）；契约测试验证"操作与 schema 兼容"（操作 lint、文档校验）与"响应形状与操作选择集一致"。边界：GraphQL 的强类型 schema 让"接口形状"契约自动成立，剩余风险在解析逻辑（resolver 错误处理、字段 nullability 违背）、权限与数据语义，需行为级契约（类似 Pact 的 example 验证）补充，实现"类型契约 + 行为契约"双层。

考察 GraphQL 契约体系：schema/introspection/codegen 构成类型契约，行为契约仍需示例验证补充。

• @axe-core/playwright 的注入与扫描
• 扫描时机与动态内容
• 结果处理与 CI 门禁

Playwright 通过 @axe-core/playwright 集成 axe-core：new AxeBuilder({ page }).analyze() 在页面执行规则扫描，返回 violations（违规）、passes、incomplete（待人工）；可配置 include/exclude 选择器（只扫主内容区、排除第三方 iframe）、withTags 限定 WCAG 等级（wcag2a/wcag2aa）、disableRules 排除已知误报规则。扫描时机关键：应在内容稳定后扫描（等待动态渲染完成、骨架屏消失），SPA 场景对每个路由状态扫描，避免"扫了个空页面"。

工程实践：封装自定义 fixture（expect(await new AxeBuilder(page).analyze()).toHaveNoViolations()）复用；CI 中对关键页面（登录、结算、导航）强制扫描，critical/serious 违规阻断合入、minor 允许降级处理；违规结果映射缺陷流程（自动生成 issue）；incomplete 项人工定期复核。边界：axe 覆盖约半数 WCAG 规则（结构性），键盘流程与真实读屏体验需人工测试补充，测试定位是"规则级持续回归网"。

考察 axe 在 Playwright 中的集成细节：注入、时机、配置与门禁，回答应强调动态内容扫描时机与人工复核边界。

• 测试中注入 web-vitals/PerformanceObserver 的指标采集能力
• 测试环境指标与生产 RUM 数据的口径对齐
• 采样与上报的一致性策略

Cypress 没有内置的 cy.performance API，工程上通过 cy.window() 注入 web-vitals 库或 PerformanceObserver 读取性能条目，在 E2E 中采集性能指标，配合自定义采样可覆盖页面加载与交互路径的性能。与 RUM 数据同步的关键是"口径一致"：测试环境（固定网络、模拟设备）与生产环境（真实分布）指标定义必须相同——使用同一测量代码（web-vitals 库 + 相同的 PerformanceObserver 配置），确保 LCP/INP/CLS 的计算、归属与阈值语义一致，否则测试通过/失败与生产数据不可比。

同步策略：生产 RUM 采样在真实流量中按比例抽样并批量上报（web-vitals reportHandler + 批量 API），测试环境用同一上报链路"回放"验证（断言上报载荷、指标计算正确）；建立"测试指标 vs 生产分布"的对照基准（如测试 LCP 中位数应落在生产 p50~p75 区间），测试回归检测"相对劣化"而非绝对数值。边界：测试环境的固定化使绝对值偏离生产，重点是趋势与相对变化的一致性，通过"同一口径 + 相对基线"实现 Lab 与 Field 的可比性。

考察测试性能数据与生产 RUM 的打通：同一测量口径、回放验证、相对基线对照，回答应强调"口径一致"这一核心。

• 测试账号与租户的隔离设计
• 种子数据的幂等创建与清理
• 并行执行下的数据冲突避免

E2E 数据隔离的常用模式：专属测试租户/环境（staging 的独立测试环境、每环境一套测试账号），避免污染真实数据；账号矩阵（普通用户/管理员/无权限）按用例需求注入（storageState 或登录步骤）；种子数据通过 API 幂等创建（idempotent seed：先查后建或固定 ID upsert），测试内建数据、测试内清数据，避免依赖"预先存在"的脆弱假设。

并行冲突避免：每 worker 使用唯一命名空间（测试前缀 + worker 索引）区分数据（如租户/用户 ID 后缀），避免共享唯一键互踩；数据清理用 afterEach 挂钩（API 删除、数据库清理任务）或环境定期重置；关键用例使用事务性环境（每用例独立 schema/数据库）彻底隔离；对只读共享数据（配置表）保持不可变。治理要点：数据生命周期与测试生命周期绑定（创建→使用→清理）、清理失败告警、避免"等待固定种子数据"的时序耦合。

考察 E2E 数据治理：租户/账号隔离、幂等种子、并行唯一命名与生命周期清理，回答应体现"数据随测试生灭"的原则。

• 事务回滚的隔离性与速度
• 独立 schema/数据库的彻底隔离
• truncate 的清理成本与风险

三种策略的取舍：事务回滚——每个测试在事务内执行、结束后回滚，速度快且无需清理逻辑（数据从未提交），但要求被测代码与测试共享连接（同库同连接），对跨服务/异步写入（消息队列、外部 API）不适用；独立 schema/数据库——每 worker 创建独立 schema（如 schema_worker_0），彻底隔离互不干扰，可并行，代价是创建/迁移成本（按需初始化、迁移复用）与资源占用；truncate——用例或套件结束后清空相关表，简单直接，但并发下会误删他人数据（须在独立库内用），且外键约束、自增序列重置需处理。

工程取舍原则：单库单服务的测试优先事务回滚（快、净）；多 worker 高并发优先独立 schema（隔离彻底）；truncate 只用于"独占环境"或与独立 schema 组合（清空本 schema 的表）；数据量大的表用 TRUNCATE 而非 DELETE（快、低日志）。组合实践：独立 schema + 事务回滚/truncate 双层，迁移在 schema 创建时执行一次，测试数据随用例生命周期管理，冲突与清理成本达到平衡。

考察数据库隔离策略的工程权衡：事务回滚（快但受限）、独立 schema（彻底但贵）、truncate（直接但需独占），回答应给出组合方案。

• Pact 与 OpenAPI/AsyncAPI 的定位差异
• 规范驱动的生成（mock、测试、文档）
• API First 的流程与工具链

OpenAPI 描述 HTTP/REST 接口的规范（schema、参数、响应），AsyncAPI 描述事件驱动/消息接口（topic、消息 schema），两者是"设计期规范"；Pact 是"运行时验证"的消费者驱动契约。协作关系：OpenAPI/AsyncAPI 定义接口标准（API First 的设计产物），Pact 契约记录真实使用期望（消费方视角），规范驱动生成——从 OpenAPI 生成 mock server（Prism）、客户端类型（codegen）、文档（Swagger UI）与测试数据，Pact 验证实现与使用期望一致；规范变更时契约同步更新。

API First 落地流程：先定义 OpenAPI/AsyncAPI 规范并评审（契约先行）→ 前后端并行开发（前端用规范生成 mock，后端按规范实现）→ CI 中规范校验（lint/语义校验）与 Pact 验证双轨 → 规范作为文档与代码生成源自动同步。工程要点：规范即单一事实源（代码、文档、mock、契约同源）、变更走评审（breaking change 检测）、事件契约（AsyncAPI）纳入消息测试（schema 校验与消费方验证），实现 HTTP 与事件双协议的契约治理。

考察规范生态的分工：OpenAPI/AsyncAPI 管设计标准、Pact 管消费契约，API First 以规范为单一事实源驱动全链路。

• 环境变量分层与校验（dotenv、schema 校验）
• service mock 的统一声明
• secrets 的安全注入（CI secret、本地 .env 不提交）

环境配置一致性从"分层与校验"开始：基础默认值（config 模块默认）→ 本地 .env（不提交 git）→ CI 环境变量 → 运行时注入，各层按优先级覆盖；配置读取统一入口（如 zod 解析 env 并校验类型与必填），缺失立即失败而非运行中炸；dotenv 负责加载本地文件，CI 平台注入相同键名的变量，保证"同名同义"。service mock 的一致性：mock 描述（MSW handler、契约）与配置解耦——测试代码不因环境不同而写不同 mock，统一从共享模块引入。

secrets 管理：本地 .env 加入 .gitignore、提供 .env.example 模板（占位符）；CI 用平台 secret 存储（GitHub Actions secrets），测试环境用非敏感测试值（测试 token），生产密钥永不进测试；对多环境敏感差异（如第三方服务 key），用环境化配置注入而非代码硬编码。治理目标：任何人在任何环境 clone 后，一条命令（setup + npm test）即可运行，配置差异不产生行为差异。

考察测试环境配置工程化：分层覆盖、统一校验、mock 解耦、secrets 隔离，回答应强调"本地与 CI 一键一致"的目标。

• 工厂模式的数据规格集中
• 类型推导（build 结果类型精确）
• 关联构建与序列化生成

Factory Bot 模式把"测试数据规格"集中为工厂：前端对应实现如 Fishery、FakeIt、自研工厂，声明默认字段并通过 build()/buildList() 生成数据，覆盖时类型完整推导（userFactory.build({ age: 30 }) 中 age 必须是 User['age'] 类型），消除手写对象字面量的类型漂移与 any 滥用。类型推导的关键是工厂参数与返回类型的强类型映射（泛型推导默认值类型、覆盖值类型、关联类型），IDE 补全与编译检查把数据错误前置到编码期。

关联数据构建：工厂支持嵌套关联（postFactory.build() 生成关联用户）、参数化关联（build({ author: userFactory.build() })）、异步构建（buildAsync 处理异步字段）与序列化生成（buildList(n, overrides) 批量不同数据）；复杂场景用"工厂注册表 + 按需组合"组织（关系图清晰、可复用）。实践要点：工厂与领域类型同源（从真实接口类型生成）、默认值语义化（避免魔法数字）、覆盖值显式化，测试数据可读性与类型安全兼得。

考察前端测试数据的工厂化：集中规格、全量类型推导、关联与序列化构建，回答应强调类型安全与可维护性的统一。

• 迁移与种子在 CI 阶段的执行时机
• 迁移缓存的复用与失效
• 种子数据的幂等与并行安全

CI 中测试数据库的准备分为迁移（migration：结构）与种子（seed：数据）：典型时机是测试 job 的 before 阶段——先跑迁移（prisma migrate deploy / typeorm migration:run）建立 schema，再执行种子（幂等 seed 脚本）灌入基础数据；若流水线有多个测试 job（单元/E2E/组件），共享数据库时只执行一次并复用（前置 job 产出就绪标记），独立数据库时各自执行。缓存策略：数据库实例按迁移版本缓存（schema 指纹），迁移未变时恢复快照（如 PostgreSQL 的 template 或容器镜像缓存）跳过重复执行；种子按"幂等 upsert + 版本号"设计，重复执行无副作用。

并行安全：多 job 共用数据库时种子需支持并发（唯一键冲突处理、每 worker 命名空间），或按 job 拆分库；迁移在并发下需要锁或串行执行（避免同时改 schema）。治理要点：迁移文件不可变（已上线的迁移禁止修改）、种子数据版本化、CI 缓存失效条件明确（迁移变更 → 重建缓存），把"数据库就绪"从分钟级压到秒级。

考察 CI 中测试数据库的工程化：迁移/种子时机、快照缓存与幂等、并发安全，回答应体现"结构版本化 + 数据幂等 + 缓存复用"。

• API 快照的适用场景（结构稳定、防意外变更）
• 动态值导致的脆弱性
• 治理：normalizer、粒度控制与补充断言

API 响应快照适用于"结构稳定、变化受控"的接口：序列化层（REST/GraphQL 响应形状）、配置类数据、稳定的第三方响应，用于防止字段意外增删与格式漂移，回归成本低。边界：高频动态值（id、时间戳、token、随机数）会让快照频繁失败，响应体庞大时 diff 难以审查，接口语义变化（排序、分页参数）也会造成噪声。

脆弱性治理：normalizer 归一化动态值（快照前替换 id/时间为占位符：JSON.stringify(data, replacer) 或自定义 serializer）；控制快照粒度（只快照关键字段子集而非全量响应）；更新走评审（不盲目 -u，diff 必审）；配合针对性断言（字段存在、类型、枚举合法）替代"全文比对"；对语义断言（业务规则）用独立用例而非快照。原则：快照用于"防意外"，断言用于"验正确"，动态内容绝不进快照。

考察 API 快照的适用性判断：稳定结构适合、动态值需归一化，回答应给出治理手段与"快照防意外、断言验正确"的原则。