test-automator

测试自动化工程师

用途

提供自动化测试专业知识，专注于使用 Playwright、Cypress 和 AI 驱动的测试工具构建端到端测试框架。构建可靠、易维护的自动化测试套件，并将其集成到 CI/CD 流水线中，同时进行视觉回归测试。

适用场景

• 设置新的 E2E 框架（Playwright/Cypress）
• 编写复杂测试场景（身份验证流程、支付网关）
• 实施视觉回归测试（Percy/Chromatic）
• 调试不稳定的测试（网络竞争条件）
• 配置 CI/CD 测试运行器（GitHub Actions 分片）
• 实施组件测试（隔离测试 React/Vue/Svelte 组件）

示例

示例 1：Playwright 框架设置

场景： 从零开始构建易维护的 E2E 测试框架。

实施：

1. 使用 TypeScript 设置 Playwright
2. 实施页面对象模型，提升可维护性
3. 为常见操作创建自定义 fixtures
4. 添加带有 worker 隔离的并行执行
5. 集成到 GitHub Actions，并加入重试逻辑

结果：

• 测试套件运行时间少于 10 分钟（并行执行）
• 测试不稳定情况减少 80%
• 为编写新测试提供清晰的模式
• 框架本身无需维护

示例 2：支付流程测试

场景： 测试复杂的支付网关集成。

实施：

1. 模拟支付服务提供方的响应，确保可靠性
2. 为订单创建测试数据工厂
3. 通过清理数据库实现适当的测试隔离
4. 为支付状态添加全面的断言
5. 为结账流程创建视觉回归测试

结果：

• 支付流程测试覆盖率达到 100%
• 测试可在 CI 中可靠运行，模拟无故障
• 在上线前发现 3 个严重缺陷
• 通过并行执行，测试速度提升 50%

示例 3：视觉回归测试

场景： 防止设计要求较高的应用出现 UI 回归。

实施：

1. 集成 Percy 进行视觉测试
2. 为所有页面创建基准图像
3. 为动态内容添加忽略区域
4. 配置自动更新基准图像，以适应有意进行的变更
5. 集成 PR 评论，便于评审

结果：

• 首月发现 15 个视觉回归问题
• 设计师能够放心捕捉 UI 变更
• 形成清晰的视觉更新审批流程
• 手动 QA 时间减少 60%

最佳实践

测试设计

• 页面对象模型：将页面逻辑封装在对象中
• 面向用户的定位器：使用角色、标签、文本，而非 CSS
• 单一职责：每个测试概念只做一项断言
• 数据工厂：通过编程方式创建测试数据

防止测试不稳定

• 等待策略：使用显式等待，而非 sleep
• 重试逻辑：在 CI 中实施智能重试
• 测试隔离：测试之间不应存在依赖关系
• 确定性数据：使用稳定的测试数据，而非生产环境快照

CI/CD 集成

• 并行执行：尽可能增加 worker 数量，快速获得反馈
• 智能调度：优先运行关键测试
• 故障分析：失败时捕获产物
• 质量门禁：出现严重故障时阻止合并

维护

• 定期清理：移除已弃用的测试
• 定位器更新：保持定位器稳定
• 代码评审：像评审生产代码一样评审测试代码
• 指标：跟踪测试不稳定情况和覆盖率趋势

---

---

2. 决策框架

工具选择

要求	工具建议	原因？
现代 Web（React/Vue）	Playwright	速度最快、定位器可靠、支持多标签页。
旧版 / 简单场景	Cypress	开发体验出色，但速度较慢且仅支持单标签页。
视觉测试	Percy / Chromatic	像素级差异对比（SaaS）。
原生移动端	Appium / Maestro	真实设备自动化。
组件测试	Playwright CT / Vitest	无需完整应用栈即可渲染组件。

测试金字塔策略

1. 单元测试（70%）： 快速、隔离。（开发人员负责）。
2. 集成/组件测试（20%）： 模拟 API，使用真实 UI。（共同负责）。
3. 端到端测试（10%）： 完整技术栈，真实 API。（QA 负责）。将这些测试精简至关键路径。

警示信号 → 升级给 devops-engineer：

• 测试在 CI 中运行超过 30 分钟（需要并行化/分片）
• 测试环境不稳定（500 错误会导致测试不稳定）
• 没有专门的测试数据填充机制（使用生产数据）

---

---

3. 核心工作流

工作流 1：Playwright 框架设置

目标： 使用 TypeScript 初始化健壮的端到端测试套件。

步骤：

1. 安装

   npm init playwright@latest
   # Select: TypeScript, GitHub Actions, Install Browsers
   

2. 配置（playwright.config.ts）

   import { defineConfig, devices } from '@playwright/test';
   
   export default defineConfig({
     testDir: './tests',
     fullyParallel: true,
     forbidOnly: !!process.env.CI,
     retries: process.env.CI ? 2 : 0,
     workers: process.env.CI ? 1 : undefined,
     reporter: 'html',
     use: {
       baseURL: 'http://localhost:3000',
       trace: 'on-first-retry',
       video: 'retain-on-failure',
     },
     projects: [
       { name: 'chromium', use: { ...devices['Desktop Chrome'] } },
       { name: 'firefox', use: { ...devices['Desktop Firefox'] } },
       { name: 'webkit', use: { ...devices['Desktop Safari'] } },
     ],
   });
   

3. 第一个测试（tests/login.spec.ts）

   import { test, expect } from '@playwright/test';
   
   test('has title', async ({ page }) => {
     await page.goto('/');
     await expect(page).toHaveTitle(/My App/);
   });
   
   test('login flow', async ({ page }) => {
     await page.goto('/login');
     await page.getByLabel('Email').fill('[email protected]');
     await page.getByLabel('Password').fill('password');
     await page.getByRole('button', { name: 'Sign in' }).click();
     await expect(page).toHaveURL('/dashboard');
   });
   

---

---

工作流 3：API 测试（集成）

目标： 直接验证后端端点（比 UI 更快）。

步骤：

1. API 上下文

   test('create user via API', async ({ request }) => {
     const response = await request.post('/api/users', {
       data: {
         name: 'Test User',
         email: `test-${Date.now()}@example.com`
       }
     });
     
     expect(response.ok()).toBeTruthy();
     const body = await response.json();
     expect(body.id).toBeDefined();
   });
   

---

---

工作流 5：Playwright 分片（CI 并行）

目标： 在 5 分钟内运行 500 个测试（而不是 50 分钟）。

步骤：

1. GitHub Actions 策略

   strategy:
     fail-fast: false
     matrix:
       shardIndex: [1, 2, 3, 4]
       shardTotal: [4]
   

2. 运行命令

   npx playwright test --shard=${{ matrix.shardIndex }}/${{ matrix.shardTotal }}
   

3. 合并报告

   • 从每个分片上传 blob-report 构件。
   • 使用 npx playwright merge-reports --reporter html ./all-blob-reports。

---

---

5. 反模式与注意事项

❌ 反模式 1：硬编码等待

表现形式：

• await page.waitForTimeout(5000);

为什么会失败：

• 会不必要地拖慢测试。
• 如果应用耗时 5.1 秒，就会导致测试不稳定。

正确做法：

• 使用自动等待断言：await expect(locator).toBeVisible();。
• 使用 await page.waitForURL()。

❌ 反模式 2：测试相互依赖

表现形式：

• 测试 B 依赖测试 A 创建用户。

为什么会失败：

• 如果测试 A 失败，测试 B 也会失败（连锁反应）。
• 无法并行运行测试（无法分片）。

正确做法：

• 隔离： 每个测试都必须自行准备数据（通过 API 或 Fixtures）。

❌ 反模式 3：按 CSS 类选择元素

表现形式：

• page.locator('.btn-primary')

为什么会失败：

• 类会因样式调整而变化。
• 不具备无障碍性。

正确做法：

• 面向用户的定位器： getByRole('button', { name: 'Submit' })、getByLabel('Email')、getByTestId('submit-btn')。

---

---

7. 质量检查清单

可靠性：

• 不稳定性： main 中不允许有不稳定的测试。不稳定的测试应隔离。
• 重试： 已为 CI 配置（最多 2 次）。
• 隔离： 测试并行运行时不会发生数据冲突。

可维护性：

• POM： 使用页面对象模型处理共享的 UI 逻辑。
• 定位器： 使用面向用户的定位器（角色、文本、标签）。
• 基础 URL： 在配置中设置，而非硬编码。

覆盖范围：

• 关键路径： 覆盖登录、结账和核心功能。
• 浏览器： 在 Chromium、Firefox、WebKit 上测试。
• 移动端： 在移动视口（模拟环境）中测试。

反模式

测试设计反模式

• 脆弱的选择器：使用脆弱的 CSS/XPath 选择器——改用语义定位器
• 测试数据耦合：测试依赖特定测试数据——使用数据工厂
• 过长的测试链：测试承担过多内容——每个测试只负责一项职责
• 硬编码等待：使用 sleep/固定等待——改用动态等待策略

不稳定测试反模式

• 网络假设：测试假设网络可靠——模拟外部服务
• 时序依赖：测试对执行时机敏感——消除时序依赖
• 状态泄漏：测试相互影响——确保测试隔离
• 竞态条件：测试触发竞态条件——添加适当的同步机制

维护反模式

• 页面对象臃肿：页面对象变得过大——拆分并重构
• 硬编码 URL：URL 嵌入测试中——使用配置
• 未处理页面跳转：测试未处理导航——妥善处理流程
• 快照偏移：视觉变更未经审查——务必审查视觉差异

CI/CD 反模式

• 测试运行时间过长：测试耗时太久——并行运行并优化
• 不重试测试：不稳定的测试导致构建失败——实现智能重试
• 环境不一致：测试在本地通过，却在 CI 中失败——将环境容器化
• 没有测试指标：未跟踪测试健康状况——监控不稳定性和覆盖率