说实话Chrome 扩展做端到端自动化测试最折磨人的不是写用例而是让浏览器在测试环境里老老实实把扩展装上、跑起来、还能被脚本控制。普通网页测试打开 URL 就能开始扩展不一样它没有统一的入口可能是地址栏旁边的小图标、右键菜单、页面里注入的工具条甚至一个独立的弹窗页面。你没法像访问普通网站那样访问一个扩展这套特殊性让很多团队一上来就卡住。这篇文章我会从实际踩坑经验出发讲清楚一套真正能落地的 Chrome 扩展端到端测试方案为什么选 TestCafe 而不是 Selenium 或 Playwright怎么让扩展在测试浏览器里稳定加载content script 和测试代码之间怎么通信以及完整的测试用例怎么写、怎么接进 CI。适合正在为扩展写自动化测试发愁的开发者也适合想了解扩展测试基础设施怎么搭的同学。整篇文章会围绕一个选中文本翻译的极简扩展示例展开从零开始搭一套可以直接抄走的方案。1. 整体方案选型为什么 TestCafe 是扩展测试的最佳选择1.1 主流自动化框架对 Chrome 扩展的支持现状先看一组我实际对比过的结果直接用表格说明问题。这里的原生支持指的是框架是否在官方文档里明确支持 Chrome 扩展加载而不是靠改浏览器启动参数绕过去。框架能否加载扩展加载方式能否操作 popup/options 页对 content script 的感知力维护成本Selenium可以自定义 profile 加载 unpacked extension一般需切换窗口句柄弱无法直接感知注入状态中高Puppeteer可以args 指定扩展路径能访问但只有一个页面上下文弱需要手动桥接中Playwright不可以官方不支持 Chrome 扩展需要绕道 persistent context限制多体验很差弱高TestCafe可以官方提供加载扩展的配置项能且是同一套测试代码强靠注入脚本天然兼容低这个表里需要多解释两句的是 Playwright。Playwright 官方明确指出不支持 Chrome 扩展社区里常用的绕行方案是用launchPersistentContext配合自定义 userDataDir 来加载扩展。它确实能跑但会有很多隐性坑扩展的 service worker 生命周期不稳定、popup 窗口关闭后上下文丢失等等。国内团队如果坚持用 Playwright 测扩展通常会耗大量精力在适配层上而这部分投入在 TestCafe 里是免费的。Selenium 虽然能加载扩展但它的问题在于脚本跑在页面外面无法深入扩展注入的 content script 上下文。你可以在页面上断言扩展加了一个按钮但你很难在测试里直接和这个按钮背后的扩展逻辑对话。而 TestCafe 的架构是脚本注入型这使它天然能感知扩展在页面里做的各种事情这一点放到第 3 节详细展开。1.2 TestCafe 的架构优势恰好命中扩展测试的痛点TestCafe 不需要 WebDriver它通过向浏览器注入一段客户端脚本testcafe hammerhead来控制页面。对普通网页而言这只是个实现细节但对扩展测试来说这个机制是决定性的优势。扩展的 content script 本质上也是在页面里运行的脚本它和 TestCafe 注入的脚本共享同一个 DOM 环境。这意味着你在测试里可以等待 content script 注入完成、可以用Selector直接选中 content script 创建的 DOM 元素、可以通过window.postMessage和 content script 通信。整个过程不需要切换上下文不需要管窗口句柄代码写起来就像在测一个普通网页。打个比方Selenium 像是一个站在门外通过猫眼观察房间里情况的人而 TestCafe 是直接进到房间里的人。测普通网页时这个差别不明显但测扩展这种同时存在于页面内和页面外的东西时能站进房间里就意味着少走一大堆弯路。1.3 备选方案什么时候还得用 Playwright 绕行虽然 TestCafe 是我的主力方案但有一个场景我建议你考虑 Playwright当你的扩展主要逻辑在 background service worker 里且你需要非常细粒度地控制浏览器网络层时Playwright 的page.on(request)事件比 TestCafe 的 RequestHooks 更强大。当然这个优势要用一堆代价来换。我在一个后台数据上报比较重的扩展项目里试过 Playwright 绕行方案需要自己处理扩展 ID 的稳定性、service worker 的唤醒时机、popup 与页面之间的消息桥接。最后自动化用例的编写速度大概是 TestCafe 的三分之一。所以我的结论是默认选 TestCafe只有当你确实需要深度网络断言时再考虑 Playwright而且要给自己留足适配时间。2. 测试基础设施搭一个能装扩展的浏览器环境2.1 初始化项目结构和依赖先说清楚这里要做的事一个端到端测试项目它需要同时包含被测扩展的源码或者至少是构建产物和测试代码。你当然可以把测试仓库和扩展仓库分开但我建议至少在测试项目里保留一份扩展的构建产物副本这样 CI 时的构建依赖更清晰。初始化项目mkdir chrome-extension-e2e cd chrome-extension-e2e npm init -y npm install --save-dev testcafelatest然后建一个简单的目录结构chrome-extension-e2e/ ├── extension/ # 被测扩展源码或构建产物 │ ├── manifest.json │ ├── background.js │ ├── content.js │ └── popup.html ├── tests/ # 测试用例 │ ├── helpers/ │ │ ├── extension-id.js │ │ └── wait-for-extension.js │ └── e2e/ │ ├── content-script.test.js │ ├── popup.test.js │ └── api-request.test.js ├── .testcaferc.json # TestCafe 配置文件 └── package.json2.2 TestCafe 配置固定 userDataDir 是稳定性的基础很多人第一次用 TestCafe 加载扩展时会遇到扩展装了但下次跑就失效、或者扩展 ID 随机变化导致测试代码里写死的 ID 失效的问题。根本原因是没有固定浏览器的 user data 目录。TestCafe 配置文件里这样写{ browsers: [ { path: /Applications/Google Chrome.app/Contents/MacOS/Google Chrome, cmd: --user-data-dir./.testcafe-chrome-profile --disable-background-networking } ], selectorTimeout: 10000, assertionTimeout: 10000, pageLoadTimeout: 30000, disablePageCaching: true, screenshots: { path: ./screenshots, takeOnFails: true } }关键点在cmd里的--user-data-dir。这个参数最好指向你项目目录下的一个固定路径而不是系统临时目录。为什么因为 Chrome 扩展加载后扩展 ID 的生成取决于扩展目录的路径和 manifest 里的key字段。如果你每次启动都用系统随机分配的临时用户目录那么扩展的安装状态可能在某些情况下不稳定而且你如果想在真实场景里做一些需要用户授权的测试比如权限弹窗固定 userDataDir 可以让你手动授权一次后续自动跑。2.3 用 fixture.before 装载扩展TestCafe 官方提供了testcafe的浏览器启动配置来加载扩展但更灵活的方式是在 fixture 的before钩子里定义。核心代码如下import { fixture } from testcafe; import path from path; const extensionPath path.resolve(__dirname, ../../extension); fixture(扩展端到端测试) .before(async (ctx) { ctx.extensionId await getExtensionId(); }); async function getExtensionId() { // 通过读取 Chrome 扩展安装后的 id 目录来获取扩展 ID const fs require(fs); const profileDir path.resolve(__dirname, ../../.testcafe-chrome-profile); const extDir path.join(profileDir, Default/Extensions); const extensionFolders fs.readdirSync(extDir); if (extensionFolders.length 0) { throw new Error(扩展没有加载成功请检查浏览器配置); } return extensionFolders[0]; }这里有个细节在非 headless 模式下TestCafe 启动时会自动带上对--load-extension的支持但为了避免每次运行都要手动点一遍启用扩展我更常用的是直接用 Chrome 的--load-extension参数{ browsers: [ { path: /path/to/chrome, cmd: --user-data-dir./.testcafe-chrome-profile --load-extension./extension } ] }这样每次启动浏览器时扩展会自动加载不需要人工确认。稳定性比什么方案都高。至于getExtensionId里读目录的方式是因为 Chrome 在加载 unpacked extension 后会在 profile 的Default/Extensions目录下生成一个以扩展 ID 命名的文件夹。虽然这个目录只有在扩展真正被启用后才会写入但通过这个方式拿到 ID 是最可靠的比自己在 manifest 里猜要准确。2.4 一个小提醒manifest v3 下的加载差异如果你还在用 manifest v2上面的配置在 Chrome 88 之前没问题。但 Chrome 88 之后默认禁用了 v2而且 TestCafe 在加载 v3 扩展时一般也能正常工作。真正要注意的是v3 扩展用 service worker 代替了 background page如果你的扩展在 service worker 里注册了一些权限请求Chrome 在自动化场景下可能会弹出权限确认框。虽然 TestCafe 的 headless 模式会自动处理部分权限但我还是建议在本地调试时先用有头模式跑一遍确认权限弹窗不会卡住流程。3. 核心机制测试代码如何与扩展的 content script 通信3.1 先搞清楚扩展的三个运行环境写扩展测试前脑子里必须有一张地图扩展的代码分散在三个完全不同的环境里它们之间用消息传递通信。popup/options 页面纯粹的 HTML 页面运行在扩展自己的独立标签页里。测试时可以直接用t.navigateTo访问chrome-extension://id/popup.html就像访问普通网页一样。content script注入到目标页面中的脚本和页面共享 DOM但拥有独立的 JS 环境。它是扩展与页面之间的桥梁。background service workerv3 扩展的后台逻辑不直接接触页面通过消息和 content script 通信。这三个环境的测试策略完全不同。popup 页面最简单当普通网页测。content script 是端到端测试的核心战场因为用户所有可见的交互都发生在页面里。background service worker 最难直接测因为 TestCafe 没有提供访问它的 API通常要通过触发 content script 的行为来间接验证。3.2 用 window.postMessage 打通测试与 content script测试代码跑在 TestCafe 注入的脚本环境里content script 跑在它自己的隔离环境里。两者虽然共享 DOM但不能直接调用对方的函数。最稳妥的通信方式是window.postMessage。举个例子假设扩展会给页面里的按钮加一个翻译功能。content script 大概长这样// content.js function addTranslateButton() { const btn document.createElement(button); btn.id translate-btn; btn.textContent 翻译; btn.addEventListener(click, () { window.postMessage({ type: TRANSLATE_CLICKED, text: window.getSelection().toString() }, *); }); document.body.appendChild(btn); } window.addEventListener(message, (event) { if (event.data event.data.type GET_TRANSLATED_TEXT) { // 模拟翻译结果 window.postMessage({ type: TRANSLATED_TEXT, result: event.data.text _translated }, *); } }); addTranslateButton();测试代码这边通过一个专门帮助函数来等待扩展注入完成并获取翻译结果// helpers/wait-for-extension.js import { ClientFunction } from testcafe; export const waitForTranslateButton ClientFunction(() { return new Promise((resolve) { const check () { const btn document.getElementById(translate-btn); if (btn) { resolve(true); } else { setTimeout(check, 100); } }; check(); }); }); export const triggerTranslate ClientFunction((text) { return new Promise((resolve) { window.addEventListener(message, function listener(event) { if (event.data event.data.type TRANSLATED_TEXT) { window.removeEventListener(message, listener); resolve(event.data.result); } }); window.postMessage({ type: GET_TRANSLATED_TEXT, text }, *); }); });这里用ClientFunction把测试代码塞进页面环境然后靠postMessage发消息。注意消息类型要做命名空间隔离避免和页面自身的消息冲突。我这里用的是TRANSLATE_CLICKED、GET_TRANSLATED_TEXT这类前缀真实项目里建议带扩展名比如MY_EXTENSION_GET_TRANSLATED_TEXT。3.3 关键点为什么不能直接在测试里调用 chrome.* API很多人第一次写扩展测试时会尝试在测试代码里写chrome.runtime.sendMessage然后发现控制台报chrome is not defined。这很正常因为测试代码运行在 TestCafe 注入的脚本环境里它并不是 content script自然没有 chrome API 权限。这也是为什么必须通过 postMessage 这种纯粹 DOM 层面的通信来间接调起扩展逻辑。换个角度理解content script 才是扩展派到页面的外交官测试代码是页面里的访客两者只能通过邮局window寄信。虽然绕了一层但正是这种隔离保证了测试的稳定性和真实性——用户也看不到 chrome API用户只能通过 DOM 交互触达扩展。3.4 测 popup 和 options 页面其实是最简单的部分popup 和 options 页面本质上就是普通 HTML 页面它们拥有 chrome API 权限加载在chrome-extension://id/popup.html路径下。测试代码可以直接导航过去test(popup 页面能显示当前扩展状态, async (t) { const extensionBaseUrl chrome-extension://${extensionId}; await t.navigateTo(${extensionBaseUrl}/popup.html); await t.expect(Selector(h1).innerText).eql(翻译扩展); });前提是拿到extensionId。固定扩展 ID 的方法是在 manifest.json 里设置key字段这个 key 是一个 Base64 编码的公钥Chrome 会用它对扩展路径做 hash 生成固定 ID。没有key字段时每次加载扩展 ID 都会变。你可以通过 chrome://extensions 页面查看 ID但自动化场景下最好直接固定。生成key的步骤不复杂先用 openssl 生成一组 RSA 私钥再从私钥导出公钥把公钥做 Base64 编码放进 manifest。具体命令是openssl genrsa -out private_key.pem 2048 openssl rsa -in private_key.pem -pubout -outform DER | openssl base64 -A输出的字符串就是key的值。放进去之后扩展 ID 在所有环境里都一致测试代码里可以直接用常量不用去读目录。4. 实战演练给一个选中文本翻译扩展写完整的端到端测试4.1 被测扩展的极简实现为了让测试代码可以对照着看先给一个最小可运行的扩展实现。这个扩展的功能是在页面上加一个翻译选中文字的按钮点击后向远程翻译 API 发请求把结果写回页面。manifest.json{ manifest_version: 3, name: Text Translator, version: 1.0.0, permissions: [activeTab], background: { service_worker: background.js }, content_scripts: [ { matches: [all_urls], js: [content.js], run_at: document_idle } ], action: { default_popup: popup.html } }content.js// content.js const btn document.createElement(button); btn.id translate-btn; btn.style.position fixed; btn.style.top 10px; btn.style.right 10px; btn.textContent 翻译; btn.addEventListener(click, () { const selection window.getSelection().toString(); if (selection) { window.postMessage({ type: TRANSLATE_TEXT, text: selection }, *); } }); document.body.appendChild(btn); window.addEventListener(message, async (event) { if (event.data event.data.type DO_TRANSLATE) { const response await fetch(https://api.example.com/translate, { method: POST, body: JSON.stringify({ q: event.data.text }) }); const data await response.json(); window.postMessage({ type: TRANSLATE_RESULT, result: data.translatedText }, *); } });background.js// background.js chrome.runtime.onMessage.addListener((message, sender, sendResponse) { if (message.type TRANSLATE_ACTION) { // 实际项目的后台处理逻辑 fetch(https://api.example.com/translate, { method: POST, body: JSON.stringify({ q: message.text }) }) .then(res res.json()) .then(data sendResponse({ translatedText: data.translatedText })); return true; // 保持通道打开 } });注意这个示例里 content.js 直接用了fetch调翻译 API实际上更合理的架构是让 background 去做远程请求content script 只负责 UI 和消息转发。这里简化是为了让测试代码更直观真实项目中建议用 background 中转。4.2 第一个用例验证 content script 是否正确注入这个用例是整个测试套件的冒烟测试它的作用是确认扩展能在目标页面里正常工作。先访问一个页面然后等待按钮出现点击后检查是否出现翻译结果。// tests/e2e/content-script.test.js import { Selector, ClientFunction } from testcafe; import { waitForTranslateButton, triggerTranslate } from ../helpers/wait-for-extension; const extensionId your-fixed-extension-id; fixture(content script 注入测试) .page(https://example.com/) .before(async (t) { await waitForTranslateButton(); }); test(页面加载后扩展按钮自动出现, async (t) { await t.expect(Selector(#translate-btn).exists).ok(扩展按钮应该出现在页面上); }); test(点击翻译按钮后返回翻译结果, async (t) { await t.click(#translate-btn); const result await triggerTranslate(Hello World); await t.expect(result).contains(translated); });这里的triggerTranslate是在页面里先手动注入一个 message event模拟扩展受到请求后返回结果。但在真实项目中你不会希望每次测试都真的请求外部翻译 API所以在端到端测试里通常还要配合 RequestHooks 做请求替换这就是下一个用例。4.3 第二个用例用 RequestHooks 断言扩展发出的请求TestCafe 的RequestMock可以用来拦截并模拟网络请求。这个能力在扩展测试里尤其好用你可以验证扩展是否朝正确的 API 发送了正确的请求体也可以伪造响应让测试不依赖外部服务。// tests/e2e/api-request.test.js import { RequestMock, RequestLogger } from testcafe; const logger RequestLogger(https://api.example.com/translate, { logRequestBody: true, logResponseBody: true }); const mock RequestMock() .onRequestTo(https://api.example.com/translate) .respond({ translatedText: 你好世界 }, 200, { access-control-allow-origin: * }); fixture(翻译 API 请求测试) .page(https://example.com/) .requestHooks(mock, logger); test(扩展会向翻译 API 发送选中文本, async (t) { await t.click(#translate-btn); await t.wait(1000); // 等待请求发出 const request logger.requests[0]; await t.expect(request).ok(应该捕获到一次翻译请求); await t.expect(JSON.parse(request.request.body).q).eql(Hello World); });这里有几个值得深入解释的点。第一RequestMock的respond方法里必须带上access-control-allow-origin头因为 content script 发出的请求受页面的 CORS 策略约束。如果不加这个头扩展的 fetch 会在浏览器层面被拦截测试用例会报网络错误。第二logger.requests[0]的时机问题。点击按钮后content script 需要先发 message 给 backgroundbackground 再发请求。这个链路有延迟所以await t.wait(1000)是给请求一个缓冲时间。更优雅的写法是使用 TestCafe 的条件等待但为了代码简洁用固定 wait 在大多数情况下也够用。等到测试跑稳定了再根据实际耗时去调这个数值。第三mock 响应里的translatedText是真实接口的字段名扩展拿到这个字段后会把结果显示在页面里。所以第二个测试用例可以用页面里的文本断言来验证扩展是否正确处理了响应而不只是断言请求发对了。4.4 第三个用例验证 popup 页面交互popup 页面的测试更接近常规前端测试区别只是 URL 变成了chrome-extension://协议。// tests/e2e/popup.test.js import { Selector } from testcafe; fixture(popup 页面交互测试) .page(chrome-extension://${extensionId}/popup.html); test(用户点击翻译按钮后能看到状态更新, async (t) { await t.typeText(#source-text, Hello World); await t.click(#do-translate); await t.expect(Selector(#status).innerText).contains(翻译完成); });这里有个很实际的坑正常用户打开 popup 是通过点击浏览器工具栏图标那是一个独立于页面上下文的小窗口。但在测试里我们直接导航到chrome-extension://id/popup.html它打开的是一个完整标签页。这两种方式在功能上没有差别但在视觉和行为上有细微差异——比如 popup 的宽高限制在标签页里不生效有些依赖window.close的逻辑也可能表现不同。所以 popup 测试要时刻记住它验证的是扩展页面内部的逻辑而不是浏览器弹窗交互本身。4.5 在 CI 环境里跑起来本地跑通之后接 CI 是另一个坎。最核心的坑是无头模式下 Chrome 加载扩展的支持。Chrome 的老版本 headless 模式不支持扩展但 Chrome 112 之后新增了--headlessnew模式支持加载扩展。TestCafe 里你可以这么指定浏览器npx testcafe chrome:headless --user-data-dir./.testcafe-chrome-profile --load-extension./extension tests/e2e/如果是 Jenkins 环境建议把 npm 脚本固化到 package.json 里{ scripts: { test:e2e: testcafe \chrome:headless\ tests/e2e/ --user-data-dir./.testcafe-chrome-profile --load-extension./extension } }Jenkins 构建步骤里直接跑npm run test:e2e就行。需要注意几个 CI 环境特有的问题CI 服务器通常没有图形界面Chrome 需要额外参数避免启动失败--no-sandbox在某些 Docker 容器里必须加CI 网络环境可能无法访问 example.com所以测试页面最好用本地文件或可控的测试环境。5. 常见问题与排查技巧实录5.1 扩展没有加载成功页面找不到注入元素这是最频繁的问题症状是运行测试时Selector(#translate-btn)一直超时。排查步骤我按下面的顺序做第一先在有头模式下跑一次在测试执行过程中手动打开chrome://extensions看扩展是否出现在列表里有没有报错信息。如果扩展本身就有错误Chrome 会在扩展卡片上直接标红这是最快的定位方式。第二检查 manifest.json 的matches字段。如果你的测试页面是https://example.com但matches写的是all_urls那没问题如果你写的是http://localhost:3000/*那测试页面必须走这个地址。很多线上扩展只匹配特定域名测试环境很容易踩到。第三确认run_at时机。document_idle会在 DOM 加载完成后注入但如果测试页面本身加载很慢或者扩展的 content script 里有异步初始化逻辑可能需要等到 DOMContentLoaded 之后再等一段时间。此时可以在 fixture 的 before 钩子里加一个t.wait(2000)给扩展留出初始化时间。如果以上都正常还有一个隐蔽的原因测试环境里同时存在多个扩展content script 被其它扩展的代码干扰了。遇到这种情况临时禁用其它扩展单独跑一次能快速定位是不是冲突。5.2 Service Worker 被休眠后台任务不执行manifest v3 的 service worker 有生命周期管理空闲一段时间后会被浏览器回收。这在自动化测试里表现为首次访问页面时扩展正常第二次跑同一个用例时background 里的状态丢了或者消息发过去没有响应。解决方法是在每次用例跑之前主动唤醒 service worker。一个简单办法是通过扩展的 popup 页面触发消息因为打开 popup 会唤醒 service worker。在测试里可以在 before 钩子加一行fixture.before(async (t) { await t.navigateTo(chrome-extension://${extensionId}/popup.html); await t.wait(500); await t.navigateTo(https://example.com/); });另一种思路是把测试设计成不依赖后台持久状态。假设你的扩展有翻译历史功能这个历史存在 chrome.storage 或 IndexedDB 里每个测试用例之间应该尽量隔离。TestCafe 的disablePageCaching配置能避免页面缓存带来的状态残留但 storag 的清理还需要自己在 before 钩子里处理。5.3 扩展 ID 不稳定导致 popup 路径写死失败这个问题在文章前面提过但在实际项目里遇到的频率非常高。很多人测试时手动复制了 chrome://extensions 页面的 ID写死在测试代码里第二天跑就发现 ID 变了。原因很简单没有在 manifest 里设置key字段。Chrome 在加载 unpacked extension 时如果 manifest 没有 key会根据扩展目录的绝对路径生成 ID。你一旦改了项目目录名、移动了项目位置、换了 CI 机器ID 就会变。解法就是文章前面写过的生成一组固定密钥把公钥的 Base64 放进 manifest 的key字段。这样无论扩展加载到哪台机器ID 都一样。注意这个 key 是公开信息不需要保密放进代码仓库没问题。5.4 无头模式能加载扩展但 action 弹窗测试失败Chrome 的--headlessnew虽然支持加载扩展但点击浏览器工具栏图标打开 popup 这个操作在无头模式下没法做因为根本看不到工具栏。这也是为什么我建议 popup 测试用navigateTo直接访问chrome-extension://id/popup.html而不是模拟点击图标。如果你的产品需求里必须验证用户点击工具栏图标后 popup 显示的正确性那在 CI 里就没办法完全覆盖。通常的做法是在本地开发时跑一次有头模式测试CI 里只跑 popup 页面的逻辑测试。这个取舍要提前和产品团队对齐否则测试方案会被认为覆盖不全而反复折腾。5.5 测试偶发失败重跑才通过端到端测试的稳定性问题在扩展场景里更突出。我的经验是区分两类偶发失败。一类是真实的产品缺陷比如扩展在页面加载极快时丢失事件监听另一类是测试环境层面的抖动比如请求超时、service worker 冻结。区分方法很简单看失败用例的报错位置。如果断言时选中的 DOM 元素不存在大概率是环境问题可以尝试加重试策略。TestCafe 的 fixture 支持meta配置我通常用t.retry做一层兜底fixture.meta(retry, 3); test(翻译流程完整走通, async (t) { t.retry(3); // ... });但注意重试是最后手段不能把所有稳定性问题都交给重试。如果同一个用例连续重试 3 次都失败说明它有确定性缺陷需要回来修而不是继续重跑。6. 经验总结扩展自动化测试的落地顺序最后说一下我在多个扩展项目里实际总结出的落地顺序这个顺序能帮你避开一上来就写全量用例然后被各种环境问题淹没的困境。第一步先写最小冒烟用例。内容就一句话打开测试页面断言扩展注入的元素存在。这个用例能跑通说明整个测试基础设施是通的。这一步卡住时不要急着写更多用例先解决环境问题。第二步把 API 请求 mock 掉写核心业务链路的用例。比如翻译扩展选中文本、点击翻译、断言结果出现。这一步要能看到一个完整的业务闭环。第三步再补 popup 和 options 页面的用例以及一些边界场景比如没有选中文本时点击按钮、翻译接口超时等。这些用例对基础设施的依赖已经很少了写得再慢也不会有环境问题折磨你。第四步把测试接进 CI设置定时任务或提交时触发同时关注用例的执行时长和失败率持续优化等待时间和重试策略。按照这个顺序大多数项目能在两三天内搭出一套能用的扩展端到端测试体系。相比一开始就规划二十个完美用例再动手这种粗颗粒度起步、快速见效的方式反而更容易在团队里推广和维护。