testing-strategies

测试策略

通过在单元测试、集成测试、端到端测试和契约测试等层级，策略性地选择并实施恰当的测试方法，构建全面、有效的测试套件。

目的

此技能提供策略框架，用于：

• 测试类型选择：判断何时使用单元测试、集成测试、端到端测试或契约测试
• 测试金字塔平衡：优化测试分布，以获得快速反馈和可靠覆盖
• 多语言实现：在 TypeScript、Python、Go 和 Rust 中应用一致的测试模式
• 测试数据管理：选择适当的策略（固定数据、工厂、基于属性的测试）
• CI/CD 集成：将测试集成到自动化流水线中，并采用最佳执行模式

测试是构建可靠软件的基础。随着微服务架构和持续交付在 2025 年成为标准，跨多个层级进行策略性测试比以往任何时候都更加重要。

何时使用此技能

在以下情况下调用此技能：

• 构建需要测试覆盖的新功能
• 为新项目设计测试策略
• 重构现有测试，以提升速度或可靠性
• 设置包含测试阶段的 CI/CD 流水线
• 在单元测试、集成测试和端到端测试方法之间进行选择
• 为微服务实现契约测试
• 使用固定数据、工厂或基于属性的测试管理测试数据

测试金字塔框架

核心概念

测试金字塔指导测试分布，以实现最佳速度和信心：

         /\
        /  \  E2E Tests (10%)
       /----\  - Slow but comprehensive
      /      \  - Full stack validation
     /--------\
    /          \  Integration Tests (20-30%)
   /            \  - Moderate speed
  /--------------\  - Component interactions
 /                \
/------------------\  Unit Tests (60-70%)
                      - Fast feedback
                      - Isolated units

核心原则：单元测试更多（快速、隔离），端到端测试更少（缓慢、全面）。集成测试填补两者之间的空隙。

现代调整（2025 年）

微服务调整：

• 在单元测试和集成测试之间增加契约测试层
• 将集成测试和契约测试提高至 30%（验证服务边界）
• 将端到端测试减少至仅覆盖关键用户流程

云原生模式：

• 在集成测试中使用容器（临时数据库、测试服务）
• 并行执行，以便 CI/CD 快速反馈
• 基于风险确定测试优先级（聚焦高影响区域）

有关测试金字塔的详细指导，请参见 references/testing-pyramid.md。

通用测试决策树

应使用哪种测试类型？

START: Need to test [feature]

Q1: Does this involve multiple systems/services?
  ├─ YES → Q2
  └─ NO  → Q3

Q2: Is this a critical user-facing workflow?
  ├─ YES → E2E Test (complete user journey)
  └─ NO  → Integration or Contract Test

Q3: Does this interact with external dependencies (DB, API, filesystem)?
  ├─ YES → Integration Test (real DB, mocked API)
  └─ NO  → Q4

Q4: Is this pure business logic or a pure function?
  ├─ YES → Unit Test (fast, isolated)
  └─ NO  → Component or Integration Test

测试类型选择示例

功能	测试类型	原因
calculateTotal(items)	单元测试	纯函数，无依赖项
POST /api/users 端点	集成测试	测试 API 与数据库的交互
用户注册流程（表单 → API → 重定向）	端到端测试	关键用户流程，涵盖完整技术栈
微服务 A → B 通信	契约测试	验证服务接口
formatCurrency(amount, locale)	单元测试 + 基于属性的测试	纯逻辑，存在许多边界情况
表单验证逻辑	单元测试	隔离的业务规则
上传文件至 S3	集成测试	与外部服务交互

有关全面的决策框架，请参见 references/decision-tree.md。

测试层级详解

单元测试（基础层 - 60-70%）

目的：验证小型、隔离的代码单元（函数、方法、组件）

特点：

• 快速（每项测试耗时数毫秒）
• 隔离（无外部依赖）
• 确定性（相同输入 = 相同输出）
• 广泛覆盖（测试数量多，每项测试范围小）

适用场景：

• 纯函数（输入 → 输出）
• 业务逻辑和算法
• 实用工具函数
• 组件渲染（不涉及集成）
• 验证逻辑

推荐工具：

• TypeScript/JavaScript：Vitest（首选，比 Jest 快 10 倍）、Jest（旧项目）
• Python：pytest（业界标准）
• Go：testing 包（标准库）+ testify（断言）
• Rust：cargo test（标准库）

有关详细模式，请参见 references/unit-testing-patterns.md。

集成测试（中间层 - 20-30%）

目的：验证组件、模块或服务之间的交互

特点：

• 速度适中（每项测试耗时数秒）
• 部分集成（使用真实数据库，模拟外部 API）
• 范围集中（测试组件边界）
• 验证 API 和数据库

适用场景：

• API 端点（请求 → 响应）
• 数据库操作（CRUD、查询）
• 服务间通信
• 事件处理程序和消息处理
• 文件 I/O 操作

推荐工具：

• TypeScript/JavaScript：Vitest + MSW（API 模拟）、Supertest（HTTP 测试）
• Python：pytest + pytest-httpserver、pytest-postgresql
• Go：testing + httptest、testcontainers
• Rust：cargo test + mockito、testcontainers

有关详细模式，请参阅 references/integration-testing-patterns.md。

端到端测试（顶层 - 10%）

目的：验证贯穿整个应用程序堆栈的完整用户工作流

特点：

• 速度较慢（每个测试套件耗时数分钟）
• 完全集成（真实浏览器、服务和数据库）
• 范围广泛（从头到尾的用户旅程）
• 容易出现不稳定（需要谨慎设计）

适用场景：

• 关键用户旅程（登录、结账、支付）
• 跨浏览器兼容性验证
• 集成测试未覆盖的真实场景
• 防止核心功能回归

最佳实践：

• 将 E2E 测试限制在高价值场景（而非每个边缘情况）
• 使用稳定的选择器（data-testid，而非 CSS 类）
• 针对网络不稳定实现重试逻辑
• 并行运行测试以提高速度

推荐工具：

• 所有语言：Playwright（支持跨浏览器、速度快，由 Microsoft 支持）

有关详细模式，请参阅 references/e2e-testing-patterns.md。

契约测试（微服务）

目的：无需完整集成即可验证服务接口和 API 契约

适用场景：

• 微服务架构
• 服务间通信
• API 契约验证
• 减少 E2E 测试开销

推荐工具：Pact（pact.io）——支持 TypeScript、Python、Go、Rust

有关详细模式，请参阅 references/contract-testing.md。

测试数据管理策略

何时采用不同方法

Fixtures（静态数据）：

• 优点：确定性强，易于调试
• 缺点：可能过时，无法测试多样性
• 适用场景：测试已知场景、回归测试

Factories（生成数据）：

• 优点：灵活，可生成多样化数据
• 缺点：确定性较低，较难调试
• 适用场景：需要多样化测试数据、测试边缘情况

基于属性的测试（随机数据）：

• 优点：发现未预料到的边缘情况
• 缺点：可能较慢，较难重现故障
• 适用场景：复杂算法、解析器、验证器

推荐组合：

• 单元测试：Fixtures（已知输入）+ 基于属性的测试（边缘情况）
• 集成测试：Factories（灵活的数据）+ 数据库播种
• E2E 测试：Fixtures（可复现场景）

基于属性的测试工具：

• TypeScript/JavaScript：fast-check
• Python：hypothesis（同类最佳）
• Go：gopter
• Rust：proptest（主要工具）

有关详细策略，请参阅 references/test-data-strategies.md。

模拟决策矩阵

何时使用模拟依赖，何时使用真实依赖

依赖项	单元测试	集成测试	E2E 测试
数据库	模拟（内存中）	真实（测试数据库、Docker）	真实（预发布数据库）
外部 API	模拟（MSW、nock）	模拟（MSW、VCR）	真实（或预发布环境）
文件系统	模拟（内存文件系统）	真实（临时目录）	真实
时间/日期	模拟（freezeTime）	模拟（如需确定性）	真实（通常）
环境变量	模拟（setEnv）	模拟（测试配置）	真实（测试环境）
内部服务	模拟（存根）	真实（或容器）	真实

指导原则：

1. 单元测试：模拟所有外部依赖
2. 集成测试：使用真实数据库（临时），模拟外部 API
3. E2E 测试：所有依赖都使用真实环境（或预发布环境中的等效项）
4. 契约测试：不模拟任何内容（测试真实接口）

有关详细的模拟模式，请参阅 references/mocking-strategies.md。

各语言快速入门

TypeScript/JavaScript

使用 Vitest 进行单元测试：

import { describe, test, expect } from 'vitest'

test('calculates total with tax', () => {
  const items = [{ price: 10, quantity: 2 }]
  expect(calculateTotal(items, 0.1)).toBe(22)
})

使用 MSW 进行集成测试：

import { setupServer } from 'msw/node'
import { http, HttpResponse } from 'msw'

const server = setupServer(
  http.get('/api/user/:id', ({ params }) => {
    return HttpResponse.json({ id: params.id, name: 'Test User' })
  })
)

使用 Playwright 进行 E2E 测试：

import { test, expect } from '@playwright/test'

test('user can checkout', async ({ page }) => {
  await page.goto('https://example.com')
  await page.getByRole('button', { name: 'Add to Cart' }).click()
  await expect(page.getByText('1 item in cart')).toBeVisible()
})

完整的可运行示例请参阅 examples/typescript/。

Python

使用 pytest 进行单元测试：

def test_calculate_total_with_tax():
    items = [{"price": 10, "quantity": 2}]
    assert calculate_total(items, tax_rate=0.1) == 22

使用 hypothesis 进行基于属性的测试：

from hypothesis import given, strategies as st

@given(st.lists(st.integers()))
def test_reverse_reverse_is_identity(lst):
    assert reverse(reverse(lst)) == lst

完整的可运行示例请参阅 examples/python/。

Go 和 Rust

有关这些语言的完整可运行示例，请参阅 examples/go/ 和 examples/rust/。

覆盖率和质量指标

有意义的覆盖率目标

建议目标：

• 关键业务逻辑：覆盖率 90% 以上
• API 端点：覆盖率 80% 以上
• 实用工具函数：覆盖率 70% 以上
• UI 组件：覆盖率 60% 以上（关注逻辑，而非标记）
• 整个项目：覆盖率 70-80%

反模式：追求 100% 覆盖率会导致测试琐碎代码，并产生虚假的信心。

覆盖率工具：

• TypeScript/JavaScript：Vitest coverage（c8/istanbul）
• Python：pytest-cov
• Go：go test -cover
• Rust：cargo-tarpaulin

变异测试（验证测试质量）

变异测试通过引入错误来验证测试能否捕获这些错误。

工具：

• TypeScript/JavaScript：Stryker Mutator
• Python：mutmut
• Go：go-mutesting
• Rust：cargo-mutants

有关详细的覆盖率策略，请参阅 references/coverage-strategies.md。

CI/CD 集成模式

快速反馈循环策略

阶段 1：提交前（< 30 秒）

• Lint 和格式检查
• 单元测试（仅关键路径）

阶段 2：提交时（< 2 分钟）

• 所有单元测试
• 静态分析

阶段 3：拉取请求（< 5 分钟）

• 集成测试
• 覆盖率报告

阶段 4：合并前（< 10 分钟）

• E2E 测试（关键路径）
• 跨浏览器测试

并行执行

加快测试运行：

• Vitest：vitest --threads
• Playwright：playwright test --workers=4
• pytest：pytest -n auto（需要 pytest-xdist）
• Go：go test -parallel 4

应避免的常见反模式

冰淇淋锥（倒金字塔）

问题：E2E 测试太多，单元测试太少
结果：测试套件运行缓慢、测试不稳定、反馈周期长
解决方案：调整测试结构，增加单元测试、减少 E2E 测试

测试实现细节

问题：测试与内部结构耦合，而非关注行为
解决方案：测试行为（输入 → 输出），而非实现方式

集成测试中过度模拟

问题：模拟所有内容会违背集成测试的目的
解决方案：使用真实数据库（临时），仅模拟外部 API

不稳定的 E2E 测试

问题：测试因时序问题而间歇性失败
解决方案：

• 使用自动等待功能（Playwright 内置自动等待）
• 避免硬编码等待（sleep(1000)）
• 使用稳定的选择器（data-testid）
• 为网络请求实现重试逻辑

与其他技能集成

表单测试：表单专用的验证和提交测试模式，请参阅 building-forms 技能。

API 测试：REST/GraphQL 端点测试和契约验证，请参阅 api-patterns 技能。

CI/CD 流水线：测试自动化、并行执行和覆盖率报告，请参阅 building-ci-pipelines 技能。

数据可视化测试：图表配置的快照测试和视觉回归测试，请参阅 visualizing-data 技能。

参考文档

如需深入了解特定主题：

• references/testing-pyramid.md - 详细的测试金字塔框架和平衡策略
• references/decision-tree.md - 测试类型选择的综合决策框架
• references/unit-testing-patterns.md - 跨语言的单元测试模式
• references/integration-testing-patterns.md - 使用数据库、API 和容器进行集成测试
• references/e2e-testing-patterns.md - E2E 测试最佳实践和 Playwright 模式
• references/contract-testing.md - 使用 Pact 进行消费者驱动的契约测试
• references/test-data-strategies.md - Fixtures、工厂和基于属性的测试
• references/mocking-strategies.md - 何时以及如何模拟依赖项
• references/coverage-strategies.md - 有意义的覆盖率指标和变异测试

可运行示例

examples/ 目录中提供了完整、可运行的代码示例：

• examples/typescript/ - Vitest 单元/集成测试、Playwright E2E、MSW 模拟、fast-check 基于属性的测试
• examples/python/ - pytest 单元/集成测试、fixtures、Playwright E2E、hypothesis 基于属性的测试
• examples/go/ - 标准库测试、testify 断言、httptest 集成测试
• examples/rust/ - cargo test 单元测试、proptest 基于属性的测试、集成模式

所有示例均包含依赖项、使用说明和错误处理。