opencode 手动性能测试套件基于 Playwright 与 Chrome Trace 的 App 性能诊断实践【免费下载链接】opencodeThe open source coding agent.项目地址: https://gitcode.com/GitHub_Trending/openc/opencode本文围绕 packages/app/e2e/performance 目录下的手动性能测试套件manual performance suite展开它是 opencode 桌面应用packages/appSolid Vite 构建的渲染进程用来量化高负载交互性能的诊断体系被刻意排除在常规本地与 CI 的 Playwright 发现流程之外。读完后你将掌握如何构建并运行生产包下的基准场景、如何理解benchmarkfixture 的指标上报契约BENCHMARK/BENCHMARK_PAGEJSON 行、如何用 Chrome DevTools Trace 做渲染进程级剖析以及套件遵循的只断言场景完成与指标采集、不设定机器相关性能预算的设计原则。一、套件定位与运行机制应用的高负载性能诊断集中在packages/app/e2e/performance与常规回归测试物理隔离。它被排除在正常本地和 CI 的 Playwright 发现之外原因是基准测试运行时间长、且依赖生产构建不适合混入快速反馈回路。基准配置的核心行为定义在 playwright.config.ts它继承主 Playwright 配置将testDir锁定到 performance 目录本身unit/**被排除在 Playwright 发现外并在webServer中强制使用生产构建// packages/app/e2e/performance/playwright.config.ts节选 webServer: { ...config.webServer, command: bun run build bun run serve -- --host 0.0.0.0 --port ${port} --strictPort, reuseExistingServer: false, }即先bun run build构建应用、再以vite preview托管生产包然后串行执行场景fullyParallel: false、workers: 1。这与 AGENTS.md 中对生产构建运行基准串行运行基准以避免跨测试竞争的原则一一对应。1.1 运行方式从packages/app目录显式运行bun run test:bench在 packages/app/package.json 中该脚本展开为两步test:bench: bun test ./e2e/performance/unit playwright test --config e2e/performance/playwright.config.ts先跑e2e/performance/unit下的纯单元测试指标计算、探针、trace 写出等模块的确定性验证再跑 Playwright 浏览器基准。Windows PowerShell 下需要显式设置单 worker$env:PLAYWRIGHT_WORKERS 1 bun run test:bench此外还有一组配套的显式入口# 运行指定场景可配合 trace 目录见下文 bunx playwright test --config e2e/performance/playwright.config.ts \ timeline/session-tab-switch-benchmark.spec.ts1.2 场景覆盖范围套件当前的基准场景覆盖五类高价值交互可在各 spec 文件中逐一核对冷/热会话标签页切换计时session-tab-switch-benchmark.spec.ts 对 cold/hot 各跑 5 轮可用SESSION_TAB_SWITCH_RUNS覆盖v2 布局下再按 review 面板开/关分拆统计firstDestinationObservedMs、firstCorrectObservedMs、stableObservedMs的 min/median/max首页会话点击计时home-tab-navigation-benchmark.spec.ts 将打开首页会话并绘制标题栏 tab拆分为 content 与 titlebar-tab paint 两段测量单会话标签关闭计时关闭唯一会话 tab 后经由稳定的 home 恢复路径绘制首页缓存会话重绘与变更追踪session-tab-flash.spec.ts 采样点击后缓存会话的重绘并验证所有已打开会话 tab 的预取行为流式时间线吞吐诊断session-timeline-benchmark.spec.ts 度量流式渲染的吞吐、RAF 回调间隔分布、长任务、几何稳定性与重挂载诊断并按新布局开关 × review 面板开/关 × 是否携带 diff组合出多个场景。已提交的 smoke 与 regression 测试则继续负责分页、tab 绘制、上下文调整、折叠状态、composer 间距等正确性覆盖——基准套件不重复承担正确性断言。二、benchmark fixture统一的上报契约所有基准共享同一个benchmarkfixture定义在 benchmark.ts。一个新基准应当看起来像一个普通 Playwright 测试import { benchmark, expect } from ../benchmark benchmark(measures one interaction, async ({ page, report }) { // Only scenario-specific setup and interaction belong here. report({ durationMs: 42 }) })fixture 的行为约束对照 benchmark.ts 源码强制report()report只允许调用一次重复调用直接抛错Benchmark reported metrics more than oncebenchmarkResult是auto: true的钩子测试结束时若没有上报且测试状态与预期一致会以Benchmark did not report metrics让该测试失败——这是断言指标采集完成而非断言数值的关键实现自动命名与关闭 trace通过覆写pagefixture为每个页面安装observePerformancePage诊断结束时调用reportPerformancePage停止 trace 并输出诊断行导航历史捕获与失败附载framenavigated事件记录主框架导航 URL 序列当testInfo.status ! testInfo.expectedStatus时把导航历史以performance-navigations附件挂到测试报告上便于回放失败场景的页面路径一致的指标输出每个基准结束时输出一行BENCHMARKJSON。2.1 BENCHMARK / BENCHMARK_PAGE 两行诊断协议源码 benchmark.ts#L29-L46 输出的BENCHMARK行比 README 简写版更完整BENCHMARK {schemaVersion:2,runID:...,name:...,status:passed,expectedStatus:expected,retry:0, repeatEachIndex:0, context:{project:chromium,platform:darwin, ...场景 context}, metrics:{...}, error:undefined}每个被观察的页面在最终带状态的BENCHMARK记录之前先输出一条BENCHMARK_PAGEbenchmark.ts#L120-L138携带同一 runID、导航历史与可选的 trace 文件路径BENCHMARK_PAGE {schemaVersion:2,runID:...,name:...,context:{platform:...,trace:.../xxx.json, selectorTrace:false}, navigations:[https://...]}runID 由 playwright.config.ts#L5 生成ISO 时间戳 进程 PID 的OPENCODE_PERFORMANCE_RUN_ID用于把一次运行中所有页面级诊断与基准结果关联起来。2.2 隔离上下文withBenchmarkPage需要隔离浏览器上下文例如冷/热切换的每轮试验都要干净的环境时使用withBenchmarkPagebenchmark.ts#L100-L118它自行browser.newContext()、创建页面、安装同一套诊断生命周期并在结束时关闭 context。会话 tab 切换基准正是用它包裹每一轮 cold/hot 试验保证 5 轮结果互不污染results[mode].push( await withBenchmarkPage(browser, session-tab-switch-${mode}-${run}, (page) trial(page, mode), testInfo), )三、Chrome Trace页面全生命周期的标准轨迹采集设置OPENCODE_PERFORMANCE_TRACE_DIR后每个基准页面都会自动产出标准 Chrome DevTools trace无需在测试内写任何 trace 代码可直接加载进 Chrome DevTools 的 Performance 面板OPENCODE_PERFORMANCE_TRACE_DIR/tmp/opencode-performance-traces \ bunx playwright test --config e2e/performance/playwright.config.ts \ timeline/session-tab-switch-benchmark.spec.ts3.1 采集实现CDP Tracing ReturnAsStreamchrome-trace.ts 的startChromeTrace通过 CDP 会话采集轨迹要点chrome-trace.ts#L21-L67类别配置默认排除-*前缀的类别包含devtools.timeline、v8.execute、latencyInfo、disabled-by-default-devtools.timeline.stack等当OPENCODE_PERFORMANCE_SELECTOR_TRACE1时额外开启disabled-by-default-blink.debug与disabled-by-default-devtools.timeline.invalidationTracking——这是selector 统计INP 类分析的前置数据所需的增强采集传输模式Tracing.start使用ReturnAsStream停止后经Tracing.tracingComplete拿到流句柄再用IO.read分块落盘chrome-trace.ts#L84-L95完整性保证先写${file}.partial若 Chromium 报告dataLossOccurred则保留 partial 文件并抛错Chrome trace lost data成功才rename为正式文件——对应 Puppeteer 官方 tracing 的默认生命周期与失败语义文件命名${runID}-${sanitized-name}-${sha256(name)[0:8]}-${nonce}[-selectors].jsontrace 路径随后出现在BENCHMARK_PAGE行中供命令行工具消费bunx devtools-tracing stats trace-path-from-BENCHMARK_PAGEREADME 明确边界Chrome trace 是浏览器级、页面全生命周期的诊断数据而场景指标如首帧可见时间、稳定时间使用的是更窄的显式命名观察窗口。二者的分工写进了 AGENTS.md不要跨 harness、probe 和 trace 重复测量自定义探针只用于产品特有度量。INP 分析需要包含受支持的导航/交互 insight 的 traceselector 统计则需要以OPENCODE_PERFORMANCE_SELECTOR_TRACE1捕获。3.2 去帧率限制的 uncapped 配置playwright.uncapped.config.ts 在默认配置上追加启动参数--disable-frame-rate-limit、--disable-gpu-vsync用于显式的去上限诊断例如观察 RAF 间隔分布时排除合成器节流干扰。README 同时声明原生产品基准应使用默认 Playwright 配置。四、剖析开关、环境变量与指标语义4.1 剖析开关默认关闭CPU 与高负载视觉剖析默认禁用以保持基准负载的确定性环境变量作用TIMELINE_CPU_PROFILE1同时开启 CPU profile 与视觉剖析TIMELINE_VISUAL_PROFILE0在已开启 CPU profile 时仅保留 CPU 剖析OPENCODE_PERFORMANCE_TRACE_DIR开启全页面 Chrome trace 采集OPENCODE_PERFORMANCE_SELECTOR_TRACE1trace 中追加 selector/失效跟踪类别INP、selector 统计所需OPENCODE_PERFORMANCE_RUN_ID诊断行 runID默认由配置自动生成这与 AGENTS.md 的原则当详细剖析会改变负载行为时保持其 opt-in一致——视觉剖析的截图读取会扰动计时因此默认关闭。4.2 流式场景的负载参数流式时间线场景的默认值与可调项对照 session-timeline-benchmark.spec.ts#L102-L110 的解析代码环境变量默认值含义TIMELINE_DELTA_COUNT160流式增量事件数量覆盖时会随结果 context 上报TIMELINE_HISTORY_TURNS320会话历史轮数DOM 规模TIMELINE_EVENT_BATCH1事件投递批大小覆盖时同样进入 contextTIMELINE_CPU_THROTTLE3030x CPU 节流系数TIMELINE_COMPLETION_TIMEOUT_MS420000流式完成等待超时测试超时在其上再加 60sTIMELINE_MINIMAL—1时使用最小化负载布局SESSION_TAB_SWITCH_RUNS5tab 切换基准每种模式轮次4.3 指标语义的三条重要边界README 对流式基准的指标给出了明确的解释边界值得在引用数据时牢记30x CPU 节流是确定性压力画像不是模拟真实低端设备同样stability 套件中的 4x CPU 压力也如此声明这些指标是主线程回调诊断吞吐、RAF 回调间隔分布、帧预算等价值、长任务都度量到渲染器观察到的完成时间与最终几何稳定为止——不是合成器呈现或掉帧测量探针禁用的视觉/几何指标会以null呈现基准不断言机器相关的性能预算。断言只验证场景完成 指标采集完成。重绘状态做游程分组run-length grouping用于压缩但每条原始观察时间戳与原始 mutation 批次、布局偏移都无损保留——对应 AGENTS.md 的保留原始诊断数据或采用无损表示。五、与 timeline-stability 套件的分工e2e/performance下还有第二个独立配置目录 timeline-stability通过bun run test:stability运行见 packages/app/package.json#L30它对时间线布局连续性做可判定的合约测试锚点保持、行序、披露状态在虚拟化中的保持、键盘/滚轮所有权一致等并对失败场景保留video.webm、trace.zip、失败截图、采样 DOM/布局 trace JSON 等证据。两者分工清晰stability 套件负责布局连续性合约是否被违反的 pass/fail 判定performance 套件负责交互到底花了多久、主线程回调分布如何的诊断量化。前者的判明边界不检查每个合成器呈现像素、不覆盖特定刷新率/设备在其 README 中有专门声明。六、方法论依据与扩展边界套件的方法论直接对齐浏览器与框架生态的官方建议Electron 官方教程推荐用重复的 Chrome DevTools / Chrome Tracing 测量做性能回归Chrome DevTools 官方文档推荐用 Performance 录制刻画运行时工作Playwright 官方将 trace 定位为测试调试工具而非渲染进程剖析工具——因此本套件选择Playwright 管场景编排与完成检查、Chrome trace 管通用浏览器剖析、自定义探针只做产品特有测量的三层结构。对于未来的打包版Electron基准README 给出了明确路线若需要主进程与多进程归因应使用 Electron 官方contentTracingAPI而不是往这套渲染器 harness 里加自制的进程级插桩。当前套件剖析的对象始终是 Chromium 中的共享 app 渲染进程。参考路径汇总套件说明packages/app/e2e/performance/README.md共享 fixture 与诊断协议packages/app/e2e/performance/benchmark.tsChrome trace 采集实现packages/app/e2e/performance/chrome-trace.ts基准 Playwright 配置packages/app/e2e/performance/playwright.config.ts、uncapped 配置场景基准会话 tab 切换、流式时间线、首页 tab 导航、首次导航、review 面板扩展设计原则packages/app/e2e/performance/AGENTS.md布局连续性合约套件packages/app/e2e/performance/timeline-stability/README.md【免费下载链接】opencodeThe open source coding agent.项目地址: https://gitcode.com/GitHub_Trending/openc/opencode创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
