testing-strategy

测试策略

概述

分析项目背景并推荐全面的测试策略。此技能会选择合适的框架、定义测试金字塔、设定覆盖率阈值，并生成测试配置文件。目标是建立一套可重复、可衡量且团队能够持续维护的测试基础。

开始时宣布：“我正在使用 testing-strategy 技能来定义测试方案。”

---

阶段 1：分析项目

目标： 在提出任何建议之前，了解当前技术栈、现有测试和 CI 设置。

操作

1. 确认技术栈（语言、框架、运行时）
2. 调查现有测试（目前已有哪类测试？）
3. 查看 CI/CD 流水线（测试如何运行？）
4. 衡量当前覆盖率
5. 梳理外部依赖（服务、数据库、API）

探查命令

# Identify test files
find . -name "*.test.*" -o -name "*.spec.*" | head -30

# Check for test config
ls vitest.config.* jest.config.* pytest.ini pyproject.toml .mocharc.* 2>/dev/null

# Check current coverage
cat coverage/coverage-summary.json 2>/dev/null || echo "No coverage report found"

# Check CI config
cat .github/workflows/*.yml 2>/dev/null | head -50

停止 — 未满足以下条件前，请勿进入阶段 2：

• 已确认技术栈
• 已梳理现有测试基础设施
• 已了解 CI 流水线状态
• 已列出外部依赖

---

阶段 2：推荐测试金字塔

目标： 选择框架并定义金字塔比例。

框架选择表

技术栈	单元测试	集成测试	端到端测试
Node.js/TS	Vitest	Vitest + Supertest	Playwright
React/Next.js	Vitest + Testing Library	Vitest + MSW	Playwright/Cypress
Python	pytest	pytest + httpx	Playwright
Go	testing + testify	testing + testcontainers	Playwright
Rust	cargo test	cargo test + testcontainers	-
PHP/Laravel	Pest/PHPUnit	Pest + HTTP tests	Playwright/Dusk

测试金字塔比例

        /\
       /  \     E2E Tests (10%)
      /    \    Critical user journeys only
     /------\
    /        \   Integration Tests (30%)
   /          \  API endpoints, DB queries, service interactions
  /------------\
 /              \ Unit Tests (60%)
/                \ Pure functions, business logic, utilities

各层级的测试内容

层级	测试内容	不要测试的内容
单元测试（60%）	纯函数、业务逻辑、数据转换、验证、状态管理	框架内部实现、第三方库
集成测试（30%）	API 端点、数据库查询、服务间调用、身份验证流程	单独隔离的函数
端到端测试（10%）	关键用户旅程（注册、购买）、跨浏览器、无障碍访问	边缘情况（在单元测试层级处理）

停止 — 未满足以下条件前，请勿进入阶段 3：

• 框架选择与技术栈匹配
• 已定义金字塔比例
• 已记录各层级的测试范围

---

阶段 3：定义覆盖率阈值

目标： 设定切实可行且可强制执行的覆盖率目标。

覆盖率阈值表

类别	最低值	目标值	备注
整体	70%	85%	代码行覆盖率
关键路径	90%	95%	身份验证、支付、数据访问
新代码（PR）	80%	90%	在 CI 中强制执行
工具函数	95%	100%	纯函数易于测试

阈值选择决策表

项目成熟度	整体最低值	新代码最低值	理由
从零构建	80%	90%	从高标准起步并保持
活跃开发（覆盖率良好）	70%	85%	保持并提升
遗留项目（覆盖率低）	50%	80%	逐步提高基线
原型/MVP	60%	70%	覆盖关键路径，接受未覆盖部分

停止 — 未满足以下条件前，请勿进入阶段 4：

• 覆盖率阈值符合项目成熟度，切实可行
• 已定义关键路径覆盖率目标
• 已决定 CI 强制执行策略

---

阶段 4：生成配置

目标： 生成可用的测试配置文件并集成到 CI 中。

操作

1. 生成测试运行器配置（vitest.config.ts、jest.config.js、pytest.ini）
2. 配置带阈值的覆盖率
3. 在 CI 工作流中添加测试命令
4. 设置测试环境（.env.test、测试数据库）

示例：Vitest 配置

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    globals: true,
    environment: 'jsdom',
    coverage: {
      provider: 'v8',
      reporter: ['text', 'json', 'html'],
      thresholds: {
        lines: 80,
        functions: 80,
        branches: 80,
        statements: 80,
      },
    },
    include: ['src/**/*.test.{ts,tsx}'],
  },
});

停止——在进入阶段 5 之前，请勿继续：

• 配置文件语法有效
• 覆盖率阈值与阶段 3 的决策一致
• 已定义 CI 集成命令

---

阶段 5：创建测试模板

目标： 提供示例测试文件，展示项目规范。

操作

1. 创建一个采用 Arrange-Act-Assert 模式的单元测试示例
2. 创建一个包含 setup/teardown 的集成测试
3. 为外部依赖创建 mock/stub 模式
4. 创建测试数据工厂/fixtures
5. 创建一个快照测试示例（适用时）

停止——在宣称完成前的验证关卡：

• 框架选择与技术栈一致
• 覆盖率阈值切合实际
• 测试配置文件有效
• 示例测试确实可以运行
• 已配置 CI 集成

---

反模式 / 常见错误

反模式	错误原因	正确做法
测试实现细节	每次重构都会导致测试失败，带来虚假的信心	测试行为和结果
过度使用 mock	测试没有覆盖真实行为，mock 会掩盖真实故障	只在边界处使用 mock
E2E 测试使用脆弱的 CSS 选择器	样式变更就会导致测试失败	使用 data-testid 或可访问性角色
测试相互依赖	会因执行顺序导致失败，在 CI 中不稳定	每个测试都必须能够独立运行
慢速测试阻塞 CI	开发者会跳过运行测试	并行运行测试、使用测试数据库、mock 外部 API
过度使用快照	未阅读就批准快照，基线也会过时	仅用于稳定输出
未在 CI 中强制执行覆盖率	覆盖率会随着时间推移而下降	在 CI 流水线中强制执行阈值
所有地方采用相同的覆盖率目标	工具函数和关键路径的要求不同	按类别设置阈值

---

决策表：Mock 策略

依赖类型	Mock 策略	示例
外部 API	MSW / nock / responses	第三方支付 API
数据库	测试数据库或内存数据库	PostgreSQL 测试容器
文件系统	虚拟文件系统或临时目录	文件上传处理
时间/日期	Fake timers	过期逻辑
环境变量	在测试设置中覆盖	功能标志
随机值/UUID	设定种子或 stub	ID 生成

---

集成点

技能	关系
test-driven-development	策略定义框架；TDD 定义循环
acceptance-testing	策略包含验收测试基础设施
code-review	评审会检查测试是否遵循既定策略
senior-frontend	前端测试使用策略选定的框架
senior-backend	后端测试使用策略选定的框架
performance-optimization	负载测试属于整体测试策略的一部分
webapp-testing	Playwright E2E 测试遵循策略金字塔

---

核心原则

• 测试行为，而非实现——关注它做什么，而非如何实现
• 快速反馈——单元测试应在几秒内运行完毕
• 确定性——不应有不稳定的测试或依赖时间的逻辑
• 易读——测试是文档；应确保清晰易懂
• 易维护——测试应助力重构，而非阻碍重构

---

技能类型

灵活——根据项目背景调整框架选择和覆盖率阈值。强烈建议采用五阶段流程和测试金字塔结构，但可根据项目规模进行调整。