Playwright 测试最佳实践用 Locator、Web-First 断言与 Trace 调试写出高可用端到端测试【免费下载链接】playwrightPlaywright is a framework for Web Testing and Automation. It allows testing Chromium, Firefox and WebKit with a single API.项目地址: https://gitcode.com/GitHub_Trending/pl/playwright本文基于 Playwright 仓库中的 best-practices-js.md 展开系统讲解 Playwright 的测试哲学用户可见行为、测试隔离、避免依赖第三方与核心最佳实践Locator 优先、Web-First 断言、调试工具链、CI 优化、并行与分片并结合仓库源码印证 Locator 生成的打分机制、断言重试等底层实现帮助你在真实项目中写出稳定、可维护、可调试的端到端测试。一、测试哲学先决定“测什么”再决定“怎么测”1. 只测用户可见的行为自动化测试的职责是验证应用代码对最终用户有效而不是验证实现细节。文档给出的原则是避免依赖用户通常看不到、也用不到的东西——函数名、某个值是不是数组、某个元素的 CSS 类名。终端用户看到的是渲染在页面上的东西测试就应该只与同样的渲染结果交互。这条原则在整篇文档中反复出现也是后文所有 Locator 建议的出发点选择器应基于 role、text、test id 等“用户面契约”而不是 DOM 结构。2. 让测试尽可能隔离每个测试都应与其他测试完全隔离独立运行并拥有自己的 local storage、session storage、数据、cookies 等。测试隔离能提升可复现性、简化调试、防止级联失败。为避免在每个测试中重复某些步骤如打开某个 URL、登录应用可以使用 before/after 钩子。在测试文件中添加 before 钩子让每个测试前先执行一段公共逻辑import { test } from playwright/test; test.beforeEach(async ({ page }) { // 每个测试前运行并登录页面。 await page.goto(https://github.com/login); await page.getByLabel(Username or email address).fill(username); await page.getByLabel(Password).fill(password); await page.getByRole(button, { name: Sign in }).click(); }); test(first, async ({ page }) { // page 已处于登录态。 }); test(second, async ({ page }) { // page 已处于登录态。 });这样既不破坏隔离性测试之间互不依赖又消除了重复。文档同时提醒如果测试足够简单允许存在少量重复——清晰易读比绝对 DRY 更重要。更进一步的方案是用 setup project 复用登录态只登录一次把已登录状态保存下来供所有测试使用直接跳过登录步骤。3. 不要测试第三方依赖只测你能控制的东西。不要试图测试指向外部站点或你无法控制的第三方服务器的链接这类测试不仅耗时、拖慢整体而且页面内容、cookie 弹窗、遮罩层等任何不受控因素都可能让测试失败。正确做法是用 Playwright 网络 APIpage.route拦截并保证所需的响应await page.route(**/api/fetch_data_third_party_dependency, route route.fulfill({ status: 200, body: testData, })); await page.goto(https://example.com);4. 涉及数据库时先控制数据如果测试涉及数据库请确保你能控制数据针对一个不会变化的 staging 环境测试。对视觉回归测试则要保证操作系统和浏览器版本一致。二、使用 Locator自动等待与可重试性的基础写端到端测试首先要定位页面上的元素。Playwright 内置的 Locator 自带自动等待auto-waiting与可重试性retry-ability自动等待意味着 Playwright 在执行动作前会做一系列可动作性actionability检查例如确保元素可见且可用之后才执行点击详见 actionability 文档。为了让测试更有韧性文档建议优先使用用户可见属性和显式契约。// page.getByRole(button, { name: submit });1. 用链式调用与过滤缩小范围Locator 可以链式组合以把搜索范围缩小到页面的某个特定部分const product page.getByRole(listitem).filter({ hasText: Product 2 });也可以按文本或另一个 locator 过滤await page .getByRole(listitem) .filter({ hasText: Product 2 }) .getByRole(button, { name: Add to cart }) .click();2. 优先用户可见属性少用 XPath / CSS 选择器DOM 结构很容易变化测试若依赖 DOM 结构就会频繁失败。文档的例子按 CSS 类名选择按钮一旦设计师改动类名测试就坏了// page.locator(button.buttonIcon.episode-actions-later);应使用对 DOM 变化有韧性的 locator// page.getByRole(button, { name: submit });3. 用工具自动生成 LocatorPlaywright 自带测试生成器codegen它会观察页面并为元素挑选最佳 locator优先 role、text 与 test id locator如果生成器发现 locator 匹配到多个元素会自动加以改进使其能唯一、稳定地指向目标元素。用codegen命令拾取 Locator运行codegen命令并附上要拾取 locator 的 URL# npm npx playwright codegen playwright.dev # yarn yarn playwright codegen playwright.dev # pnpm pnpm exec playwright codegen playwright.dev这会打开一个新的浏览器窗口和 Playwright Inspector。默认情况下codegen启动时就开始录制点击 Record 按钮停止录制后Pick Locator 按钮变为可点击。此后把鼠标悬停在浏览器窗口中的任意元素上可以看到光标下方高亮显示对应的 locator点击元素会把 locator 加入 Inspector——你可以直接复制粘贴到测试文件也可以在 Inspector 中继续编辑例如修改文本并在浏览器窗口中实时查看结果。源码佐证locator 是如何“挑选最佳”的。在注入浏览器的选择器生成器 selectorGenerator.ts 中每种定位方式都有一个打分常量分数越低越优先kTestIdScore 1配置的 testId 属性、kOtherTestIdScore 2其他data-test*属性、kRoleWithNameScore 100、kPlaceholderScore 120、kLabelScore 140、kAltTextScore 160、kTextScore 180、kTitleScore 200而 CSS 类名/id 的选择被压到kCSSIdScore 500以上kNthScore 10000、纯 CSS 兜底高达kCSSFallbackScore 10000000见 selectorGenerator.ts#L37-L68。这从源码层面印证了文档中“优先 role、text、test id”的表述生成器对 test id 和带名称的 role 给予最高优先对 CSS 结构类选择器施加巨大惩罚。此外当候选 selector 匹配到多个元素时生成器会尝试追加nth、或向父级回溯做嵌套过滤以生成唯一匹配selectorGenerator.ts#L146-L181。拾取到的内部 selector 字符串最终由 locatorGenerators.ts 中的asLocators()转换成各语言JavaScript/Python/Java/C#的 locator API 调用这也是 Inspector 中“编辑 locator 并实时预览”能力的底座。用 VS Code 扩展生成 Locator也可以直接用 VS Code 扩展来生成 locator 并录制测试它在编写、运行和调试测试时同样提供出色的开发体验。三、使用 Web-First 断言等待是断言的一部分断言用来验证预期结果与实际结果是否匹配。使用 Web-First 断言时Playwright 会一直等待到预期条件成立为止。例如测试提示消息点击一个使消息出现的按钮后检查该提示是否存在——如果提示需要 0.5 秒才出现toBeVisible()这类断言会自动等待并必要时重试。// await expect(page.getByText(welcome)).toBeVisible(); // expect(await page.getByText(welcome).isVisible()).toBe(true);不要用“手动断言”所谓手动断言指的是没有对expect本身做await的写法——await写在了expect内部而不是前面// expect(await page.getByText(welcome).isVisible()).toBe(true);使用isVisible()这类 API 时测试不会等待哪怕 1 秒它只检查 locator 当前是否存在然后立即返回。应改用toBeVisible()等 Web-First 断言// await expect(page.getByText(welcome)).toBeVisible();源码佐证。Playwright 测试库的断言实现位于 packages/playwright/src/matchers/ 目录toMatchText.ts、toHaveURL.ts、toMatchAriaSnapshot.ts等文件对应各自的 Web-First 断言统一的 expect 封装在 expect.ts 中从源码结构看这些断言均构建在“条件不满足则按超时窗口轮询重试”的语义上而非一次性取值比较这正是 Web-First 断言与手动断言的本质区别。四、配置调试能力1. 本地调试VS Code 实时调试本地调试推荐使用 VS Code 扩展实时调试测试在想要运行的测试行号旁右键即可在调试模式运行会打开浏览器窗口并暂停在断点处。你还可以在 VS Code 中点击或编辑测试里的 locator 进行实时调试——该 locator 会在浏览器窗口中高亮同时展示页面上其他匹配项帮助你确认匹配范围。2. 本地调试Playwright Inspector--debug也可以用 Playwright Inspector 调试测试加上--debug标志运行# npm npx playwright test --debug # yarn yarn playwright test --debug # pnpm pnpm exec playwright test --debug之后可以单步执行测试、查看可动作性日志、实时编辑 locator 并在浏览器窗口中看高亮——它会显示哪些 locator 匹配、匹配了多少个。只调试某个具体测试时附上测试文件名和行号再加--debug# npm npx playwright test example.spec.ts:9 --debug # yarn yarn playwright test example.spec.ts:9 --debug # pnpm pnpm exec playwright test example.spec.ts:9 --debug3. CI 调试用 Trace Viewer 取代视频与截图CI 失败时推荐使用 Playwright Trace Viewer而不是视频和截图。Trace Viewer 把测试的完整 trace 打包为一个本地 PWA便于分享你可以查看时间线、用 DevTools 检查每个动作的 DOM 快照、查看网络请求等。Trace 在 Playwright 配置文件中配置默认在 CI 上于失败测试的第一次重试时运行。文档不建议把它设为on对所有测试都录 trace——这对性能影响很大。但本地开发时可以用--trace标志录 trace# npm npx playwright test --trace on # yarn yarn playwright test --trace on # pnpm pnpm exec playwright test --trace on运行后每个测试都会记录 trace可以直接从 HTML 报告中打开。查看报告# npm npx playwright show-report # yarn yarn playwright show-report # pnpm pnpm exec playwright show-reporttrace 可以通过点击测试文件名旁的图标打开或进入每个测试的报告页滚动到 traces 区域打开。五、使用 Playwright 的配套工具链VS Code 扩展编写、运行、调试测试的完整开发体验测试生成器自动生成测试并为你拾取 locatorTrace Viewer以本地 PWA 形式呈现完整 trace可看时间线、每个动作的 DOM 快照、网络请求等UI Mode带“时间旅行”体验地探索、运行和调试测试附带 watch mode。所有测试文件都加载到测试侧边栏中可以展开每个文件和 describe 块分别运行、查看、监视和调试每个测试TypeScript开箱即用提供更好的 IDE 集成——IDE 会展示你能做的所有事情并在你犯错时高亮提示。不需要你有 TypeScript 经验代码也不必是 TypeScript只需以.ts扩展名创建测试即可。六、跨浏览器测试无论你在什么平台上开发Playwright 都能轻松跨所有浏览器测试你的站点确保应用对所有用户可用。在配置文件中通过projects设置项目名以及使用的浏览器或设备import { defineConfig, devices } from playwright/test; export default defineConfig({ projects: [ { name: chromium, use: { ...devices[Desktop Chrome] }, }, { name: firefox, use: { ...devices[Desktop Firefox] }, }, { name: webkit, use: { ...devices[Desktop Safari] }, }, ], });七、保持 Playwright 依赖更新保持 Playwright 版本最新你就能在最新浏览器版本上测试应用并在最新版浏览器公开发布前就捕获兼容性问题。# npm npm install -D playwright/testlatest # yarn yarn add --dev playwright/testlatest # pnpm pnpm install --save-dev playwright/testlatest查看发布说明了解最新版本及其变更内容。查看当前 Playwright 版本# npm npx playwright --version # yarn yarn playwright --version # pnpm pnpm exec playwright --version八、在 CI 上运行测试搭建 CI/CD 并频繁运行测试——跑得越勤越好。理想情况是每次提交和 pull request 都运行。Playwright 自带 GitHub Actions 工作流无需任何配置即可在 CI 上运行测试也可以配置到你选择的任意 CI 环境。CI 上运行测试建议使用 Linux因为它更便宜开发者本地可以使用任何环境但 CI 统一用 Linux。同时可以考虑配置 Sharding分片让 CI 更快。优化 CI 上的浏览器下载只安装你真正需要的浏览器在 CI 上尤其如此。例如只测 Chromium 时就只安装 Chromium# 而不是安装所有浏览器 npx playwright install --with-deps # 只安装 Chromium npx playwright install chromium --with-deps这能同时节省 CI 机器上的下载时间和磁盘空间。九、对测试进行 Lint文档推荐对测试使用 TypeScript ESLint尽早捕获错误。启用typescript-eslint/no-floating-promises这条 ESLint 规则确保对 Playwright API 的异步调用没有遗漏await在 CI 上还可以运行tsc --noEmit确保函数以正确的签名被调用。十、利用并行与分片Playwright 默认并行运行测试。同一文件内的测试按顺序、在同一 worker 进程中执行如果单个文件中有大量相互独立的测试可以让它们并行import { test } from playwright/test; test.describe.configure({ mode: parallel }); test(runs in parallel 1, async ({ page }) { /* ... */ }); test(runs in parallel 2, async ({ page }) { /* ... */ });Playwright 还可以分片整个测试套件在多台机器上执行# npm npx playwright test --shard1/3 # yarn yarn playwright test --shard1/3 # pnpm pnpm exec playwright test --shard1/3源码佐证。并行调度与 worker 生命周期由测试运行器的 worker 端实现如 workerMain.ts与 worker 进程入口管理测试元信息与 trace 记录在 testInfo.ts、testTracing.ts 中完成——上文 trace 与并行行为的配置最终都落到这些 worker 侧组件上。十一、生产力技巧Soft 断言测试失败时Playwright 会给出错误信息指明失败发生在测试的哪一部分你可以在 VS Code、终端、HTML 报告或 Trace Viewer 中查看。此外还可以使用 soft 断言它不会立即终止测试执行而是在测试结束时汇总并展示所有失败的断言列表。// 做一些检查失败时不会中止测试…… await expect.soft(page.getByTestId(status)).toHaveText(Success); // ……并继续测试以检查更多内容。 await page.getByRole(link, { name: next page }).click();总结把这份清单落到日常开发中就得到了稳定测试的完整闭环用测试隔离保证可复现性用page.route消灭第三方不稳定因素用 role/text/test id 优先的 Locator并借助 codegen 与 selector 生成器的打分机制定位元素用 Web-First 断言而非手动断言消除时间相关的抖动用--debug、VS Code 实时调试与 CI 上的 Trace Viewer 快速定位问题最后用 Linux CI、按需安装浏览器、分片与 soft 断言持续提高反馈速度与质量。以上实践均出自仓库文档 docs/src/best-practices-js.md可直接作为团队端到端测试规范的基线。【免费下载链接】playwrightPlaywright is a framework for Web Testing and Automation. It allows testing Chromium, Firefox and WebKit with a single API.项目地址: https://gitcode.com/GitHub_Trending/pl/playwright创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Playwright 测试最佳实践：用 Locator、Web-First 断言与 Trace 调试写出高可用端到端测试
Playwright 测试最佳实践用 Locator、Web-First 断言与 Trace 调试写出高可用端到端测试【免费下载链接】playwrightPlaywright is a framework for Web Testing and Automation. It allows testing Chromium, Firefox and WebKit with a single API.项目地址: https://gitcode.com/GitHub_Trending/pl/playwright本文基于 Playwright 仓库中的 best-practices-js.md 展开系统讲解 Playwright 的测试哲学用户可见行为、测试隔离、避免依赖第三方与核心最佳实践Locator 优先、Web-First 断言、调试工具链、CI 优化、并行与分片并结合仓库源码印证 Locator 生成的打分机制、断言重试等底层实现帮助你在真实项目中写出稳定、可维护、可调试的端到端测试。一、测试哲学先决定“测什么”再决定“怎么测”1. 只测用户可见的行为自动化测试的职责是验证应用代码对最终用户有效而不是验证实现细节。文档给出的原则是避免依赖用户通常看不到、也用不到的东西——函数名、某个值是不是数组、某个元素的 CSS 类名。终端用户看到的是渲染在页面上的东西测试就应该只与同样的渲染结果交互。这条原则在整篇文档中反复出现也是后文所有 Locator 建议的出发点选择器应基于 role、text、test id 等“用户面契约”而不是 DOM 结构。2. 让测试尽可能隔离每个测试都应与其他测试完全隔离独立运行并拥有自己的 local storage、session storage、数据、cookies 等。测试隔离能提升可复现性、简化调试、防止级联失败。为避免在每个测试中重复某些步骤如打开某个 URL、登录应用可以使用 before/after 钩子。在测试文件中添加 before 钩子让每个测试前先执行一段公共逻辑import { test } from playwright/test; test.beforeEach(async ({ page }) { // 每个测试前运行并登录页面。 await page.goto(https://github.com/login); await page.getByLabel(Username or email address).fill(username); await page.getByLabel(Password).fill(password); await page.getByRole(button, { name: Sign in }).click(); }); test(first, async ({ page }) { // page 已处于登录态。 }); test(second, async ({ page }) { // page 已处于登录态。 });这样既不破坏隔离性测试之间互不依赖又消除了重复。文档同时提醒如果测试足够简单允许存在少量重复——清晰易读比绝对 DRY 更重要。更进一步的方案是用 setup project 复用登录态只登录一次把已登录状态保存下来供所有测试使用直接跳过登录步骤。3. 不要测试第三方依赖只测你能控制的东西。不要试图测试指向外部站点或你无法控制的第三方服务器的链接这类测试不仅耗时、拖慢整体而且页面内容、cookie 弹窗、遮罩层等任何不受控因素都可能让测试失败。正确做法是用 Playwright 网络 APIpage.route拦截并保证所需的响应await page.route(**/api/fetch_data_third_party_dependency, route route.fulfill({ status: 200, body: testData, })); await page.goto(https://example.com);4. 涉及数据库时先控制数据如果测试涉及数据库请确保你能控制数据针对一个不会变化的 staging 环境测试。对视觉回归测试则要保证操作系统和浏览器版本一致。二、使用 Locator自动等待与可重试性的基础写端到端测试首先要定位页面上的元素。Playwright 内置的 Locator 自带自动等待auto-waiting与可重试性retry-ability自动等待意味着 Playwright 在执行动作前会做一系列可动作性actionability检查例如确保元素可见且可用之后才执行点击详见 actionability 文档。为了让测试更有韧性文档建议优先使用用户可见属性和显式契约。// page.getByRole(button, { name: submit });1. 用链式调用与过滤缩小范围Locator 可以链式组合以把搜索范围缩小到页面的某个特定部分const product page.getByRole(listitem).filter({ hasText: Product 2 });也可以按文本或另一个 locator 过滤await page .getByRole(listitem) .filter({ hasText: Product 2 }) .getByRole(button, { name: Add to cart }) .click();2. 优先用户可见属性少用 XPath / CSS 选择器DOM 结构很容易变化测试若依赖 DOM 结构就会频繁失败。文档的例子按 CSS 类名选择按钮一旦设计师改动类名测试就坏了// page.locator(button.buttonIcon.episode-actions-later);应使用对 DOM 变化有韧性的 locator// page.getByRole(button, { name: submit });3. 用工具自动生成 LocatorPlaywright 自带测试生成器codegen它会观察页面并为元素挑选最佳 locator优先 role、text 与 test id locator如果生成器发现 locator 匹配到多个元素会自动加以改进使其能唯一、稳定地指向目标元素。用codegen命令拾取 Locator运行codegen命令并附上要拾取 locator 的 URL# npm npx playwright codegen playwright.dev # yarn yarn playwright codegen playwright.dev # pnpm pnpm exec playwright codegen playwright.dev这会打开一个新的浏览器窗口和 Playwright Inspector。默认情况下codegen启动时就开始录制点击 Record 按钮停止录制后Pick Locator 按钮变为可点击。此后把鼠标悬停在浏览器窗口中的任意元素上可以看到光标下方高亮显示对应的 locator点击元素会把 locator 加入 Inspector——你可以直接复制粘贴到测试文件也可以在 Inspector 中继续编辑例如修改文本并在浏览器窗口中实时查看结果。源码佐证locator 是如何“挑选最佳”的。在注入浏览器的选择器生成器 selectorGenerator.ts 中每种定位方式都有一个打分常量分数越低越优先kTestIdScore 1配置的 testId 属性、kOtherTestIdScore 2其他data-test*属性、kRoleWithNameScore 100、kPlaceholderScore 120、kLabelScore 140、kAltTextScore 160、kTextScore 180、kTitleScore 200而 CSS 类名/id 的选择被压到kCSSIdScore 500以上kNthScore 10000、纯 CSS 兜底高达kCSSFallbackScore 10000000见 selectorGenerator.ts#L37-L68。这从源码层面印证了文档中“优先 role、text、test id”的表述生成器对 test id 和带名称的 role 给予最高优先对 CSS 结构类选择器施加巨大惩罚。此外当候选 selector 匹配到多个元素时生成器会尝试追加nth、或向父级回溯做嵌套过滤以生成唯一匹配selectorGenerator.ts#L146-L181。拾取到的内部 selector 字符串最终由 locatorGenerators.ts 中的asLocators()转换成各语言JavaScript/Python/Java/C#的 locator API 调用这也是 Inspector 中“编辑 locator 并实时预览”能力的底座。用 VS Code 扩展生成 Locator也可以直接用 VS Code 扩展来生成 locator 并录制测试它在编写、运行和调试测试时同样提供出色的开发体验。三、使用 Web-First 断言等待是断言的一部分断言用来验证预期结果与实际结果是否匹配。使用 Web-First 断言时Playwright 会一直等待到预期条件成立为止。例如测试提示消息点击一个使消息出现的按钮后检查该提示是否存在——如果提示需要 0.5 秒才出现toBeVisible()这类断言会自动等待并必要时重试。// await expect(page.getByText(welcome)).toBeVisible(); // expect(await page.getByText(welcome).isVisible()).toBe(true);不要用“手动断言”所谓手动断言指的是没有对expect本身做await的写法——await写在了expect内部而不是前面// expect(await page.getByText(welcome).isVisible()).toBe(true);使用isVisible()这类 API 时测试不会等待哪怕 1 秒它只检查 locator 当前是否存在然后立即返回。应改用toBeVisible()等 Web-First 断言// await expect(page.getByText(welcome)).toBeVisible();源码佐证。Playwright 测试库的断言实现位于 packages/playwright/src/matchers/ 目录toMatchText.ts、toHaveURL.ts、toMatchAriaSnapshot.ts等文件对应各自的 Web-First 断言统一的 expect 封装在 expect.ts 中从源码结构看这些断言均构建在“条件不满足则按超时窗口轮询重试”的语义上而非一次性取值比较这正是 Web-First 断言与手动断言的本质区别。四、配置调试能力1. 本地调试VS Code 实时调试本地调试推荐使用 VS Code 扩展实时调试测试在想要运行的测试行号旁右键即可在调试模式运行会打开浏览器窗口并暂停在断点处。你还可以在 VS Code 中点击或编辑测试里的 locator 进行实时调试——该 locator 会在浏览器窗口中高亮同时展示页面上其他匹配项帮助你确认匹配范围。2. 本地调试Playwright Inspector--debug也可以用 Playwright Inspector 调试测试加上--debug标志运行# npm npx playwright test --debug # yarn yarn playwright test --debug # pnpm pnpm exec playwright test --debug之后可以单步执行测试、查看可动作性日志、实时编辑 locator 并在浏览器窗口中看高亮——它会显示哪些 locator 匹配、匹配了多少个。只调试某个具体测试时附上测试文件名和行号再加--debug# npm npx playwright test example.spec.ts:9 --debug # yarn yarn playwright test example.spec.ts:9 --debug # pnpm pnpm exec playwright test example.spec.ts:9 --debug3. CI 调试用 Trace Viewer 取代视频与截图CI 失败时推荐使用 Playwright Trace Viewer而不是视频和截图。Trace Viewer 把测试的完整 trace 打包为一个本地 PWA便于分享你可以查看时间线、用 DevTools 检查每个动作的 DOM 快照、查看网络请求等。Trace 在 Playwright 配置文件中配置默认在 CI 上于失败测试的第一次重试时运行。文档不建议把它设为on对所有测试都录 trace——这对性能影响很大。但本地开发时可以用--trace标志录 trace# npm npx playwright test --trace on # yarn yarn playwright test --trace on # pnpm pnpm exec playwright test --trace on运行后每个测试都会记录 trace可以直接从 HTML 报告中打开。查看报告# npm npx playwright show-report # yarn yarn playwright show-report # pnpm pnpm exec playwright show-reporttrace 可以通过点击测试文件名旁的图标打开或进入每个测试的报告页滚动到 traces 区域打开。五、使用 Playwright 的配套工具链VS Code 扩展编写、运行、调试测试的完整开发体验测试生成器自动生成测试并为你拾取 locatorTrace Viewer以本地 PWA 形式呈现完整 trace可看时间线、每个动作的 DOM 快照、网络请求等UI Mode带“时间旅行”体验地探索、运行和调试测试附带 watch mode。所有测试文件都加载到测试侧边栏中可以展开每个文件和 describe 块分别运行、查看、监视和调试每个测试TypeScript开箱即用提供更好的 IDE 集成——IDE 会展示你能做的所有事情并在你犯错时高亮提示。不需要你有 TypeScript 经验代码也不必是 TypeScript只需以.ts扩展名创建测试即可。六、跨浏览器测试无论你在什么平台上开发Playwright 都能轻松跨所有浏览器测试你的站点确保应用对所有用户可用。在配置文件中通过projects设置项目名以及使用的浏览器或设备import { defineConfig, devices } from playwright/test; export default defineConfig({ projects: [ { name: chromium, use: { ...devices[Desktop Chrome] }, }, { name: firefox, use: { ...devices[Desktop Firefox] }, }, { name: webkit, use: { ...devices[Desktop Safari] }, }, ], });七、保持 Playwright 依赖更新保持 Playwright 版本最新你就能在最新浏览器版本上测试应用并在最新版浏览器公开发布前就捕获兼容性问题。# npm npm install -D playwright/testlatest # yarn yarn add --dev playwright/testlatest # pnpm pnpm install --save-dev playwright/testlatest查看发布说明了解最新版本及其变更内容。查看当前 Playwright 版本# npm npx playwright --version # yarn yarn playwright --version # pnpm pnpm exec playwright --version八、在 CI 上运行测试搭建 CI/CD 并频繁运行测试——跑得越勤越好。理想情况是每次提交和 pull request 都运行。Playwright 自带 GitHub Actions 工作流无需任何配置即可在 CI 上运行测试也可以配置到你选择的任意 CI 环境。CI 上运行测试建议使用 Linux因为它更便宜开发者本地可以使用任何环境但 CI 统一用 Linux。同时可以考虑配置 Sharding分片让 CI 更快。优化 CI 上的浏览器下载只安装你真正需要的浏览器在 CI 上尤其如此。例如只测 Chromium 时就只安装 Chromium# 而不是安装所有浏览器 npx playwright install --with-deps # 只安装 Chromium npx playwright install chromium --with-deps这能同时节省 CI 机器上的下载时间和磁盘空间。九、对测试进行 Lint文档推荐对测试使用 TypeScript ESLint尽早捕获错误。启用typescript-eslint/no-floating-promises这条 ESLint 规则确保对 Playwright API 的异步调用没有遗漏await在 CI 上还可以运行tsc --noEmit确保函数以正确的签名被调用。十、利用并行与分片Playwright 默认并行运行测试。同一文件内的测试按顺序、在同一 worker 进程中执行如果单个文件中有大量相互独立的测试可以让它们并行import { test } from playwright/test; test.describe.configure({ mode: parallel }); test(runs in parallel 1, async ({ page }) { /* ... */ }); test(runs in parallel 2, async ({ page }) { /* ... */ });Playwright 还可以分片整个测试套件在多台机器上执行# npm npx playwright test --shard1/3 # yarn yarn playwright test --shard1/3 # pnpm pnpm exec playwright test --shard1/3源码佐证。并行调度与 worker 生命周期由测试运行器的 worker 端实现如 workerMain.ts与 worker 进程入口管理测试元信息与 trace 记录在 testInfo.ts、testTracing.ts 中完成——上文 trace 与并行行为的配置最终都落到这些 worker 侧组件上。十一、生产力技巧Soft 断言测试失败时Playwright 会给出错误信息指明失败发生在测试的哪一部分你可以在 VS Code、终端、HTML 报告或 Trace Viewer 中查看。此外还可以使用 soft 断言它不会立即终止测试执行而是在测试结束时汇总并展示所有失败的断言列表。// 做一些检查失败时不会中止测试…… await expect.soft(page.getByTestId(status)).toHaveText(Success); // ……并继续测试以检查更多内容。 await page.getByRole(link, { name: next page }).click();总结把这份清单落到日常开发中就得到了稳定测试的完整闭环用测试隔离保证可复现性用page.route消灭第三方不稳定因素用 role/text/test id 优先的 Locator并借助 codegen 与 selector 生成器的打分机制定位元素用 Web-First 断言而非手动断言消除时间相关的抖动用--debug、VS Code 实时调试与 CI 上的 Trace Viewer 快速定位问题最后用 Linux CI、按需安装浏览器、分片与 soft 断言持续提高反馈速度与质量。以上实践均出自仓库文档 docs/src/best-practices-js.md可直接作为团队端到端测试规范的基线。【免费下载链接】playwrightPlaywright is a framework for Web Testing and Automation. It allows testing Chromium, Firefox and WebKit with a single API.项目地址: https://gitcode.com/GitHub_Trending/pl/playwright创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考