Testing Strategy

测试策略

Systematic test planning and coverage improvement workflow.

系统化的测试规划与覆盖率提升工作流。

When to Use

适用场景

Trigger	Description
Post-COMPLEX Feature	After implementing major features
Coverage Drop	When coverage falls below thresholds
Test Debt Sprint	Dedicated testing improvement effort
New Project	Establishing testing foundation
Pre-Release	Ensuring quality before deployment

触发场景	描述
复杂功能开发完成后	实现主要功能之后
覆盖率下降	当覆盖率低于阈值时
测试债务专项迭代	专门针对测试改进的工作周期
新项目启动	搭建测试基础架构阶段
发布前	部署前确保产品质量

Coverage Targets

覆盖率目标

Category	Target	Warning	Critical
Business Logic	>80%	70-80%	<70%
Overall	>60%	50-60%	<50%
Critical Paths	>90%	80-90%	<80%

类别	目标值	警告阈值	危险阈值
业务逻辑	>80%	70-80%	<70%
整体代码	>60%	50-60%	<50%
关键路径	>90%	80-90%	<80%

Prerequisites

前置条件

Before starting:

Test framework configured
Coverage tool available
CI/CD running tests
Access to current coverage report
Understanding of business-critical features

开始前需确认：

已配置测试框架
覆盖率工具可用
CI/CD已集成测试运行
可获取当前覆盖率报告
了解业务核心功能

Strategy Process

策略执行流程

Phase 1: Coverage Analysis
    ↓
Phase 2: Critical Path Identification
    ↓
Phase 3: Test Pyramid Planning
    ↓
Phase 4: Test Prioritization
    ↓
Phase 5: Edge Case Planning
    ↓
Phase 6: Flaky Test Remediation
    ↓
Phase 7: Implementation Roadmap

阶段1: 覆盖率分析
    ↓
阶段2: 关键路径识别
    ↓
阶段3: 测试金字塔规划
    ↓
阶段4: 测试优先级排序
    ↓
阶段5: 边缘场景规划
    ↓
阶段6: 不稳定测试修复
    ↓
阶段7: 实施路线图制定

Phase 1: Coverage Analysis

阶段1：覆盖率分析

1.1 Generate Coverage Report

1.1 生成覆盖率报告

Node.js (Jest/Vitest):

bash

npm test -- --coverage

Node.js (Jest/Vitest):

bash

npm test -- --coverage

or

npx vitest run --coverage


**Python (pytest)**:
```bash
pytest --cov=src --cov-report=html

Go:

bash

go test -cover ./...
go test -coverprofile=coverage.out ./...
go tool cover -html=coverage.out

Rust:

bash

cargo tarpaulin --out Html

npx vitest run --coverage


**Python (pytest)**:
```bash
pytest --cov=src --cov-report=html

Go:

bash

go test -cover ./...
go test -coverprofile=coverage.out ./...
go tool cover -html=coverage.out

Rust:

bash

cargo tarpaulin --out Html

1.2 Analyze Coverage Gaps

1.2 分析覆盖率缺口

Review coverage report for:

Area	Target	Current	Gap
`src/auth/`	90%	45%	-45%
`src/api/`	80%	62%	-18%
`src/utils/`	60%	78%	+18%
Overall	60%	55%	-5%

审查覆盖率报告，关注以下维度：

区域	目标值	当前值	缺口
`src/auth/`	90%	45%	-45%
`src/api/`	80%	62%	-18%
`src/utils/`	60%	78%	+18%
整体	60%	55%	-5%

1.3 Identify Uncovered Files

1.3 识别未覆盖文件

List files with lowest coverage:

Lowest Coverage Files:
1. src/auth/oauth.ts - 12% (critical!)
2. src/api/payments.ts - 28% (critical!)
3. src/services/email.ts - 35%
4. src/utils/validation.ts - 42%
5. src/api/users.ts - 48%

列出覆盖率最低的文件：

最低覆盖率文件:
1. src/auth/oauth.ts - 12% (核心风险!)
2. src/api/payments.ts - 28% (核心风险!)
3. src/services/email.ts - 35%
4. src/utils/validation.ts - 42%
5. src/api/users.ts - 48%

Phase 2: Critical Path Identification

阶段2：关键路径识别

2.1 Define Critical Paths

2.1 定义关键路径

Critical paths are user journeys that MUST work:

Path	Description	Files	Priority
Authentication	Login, logout, session	auth/*	P0
Checkout	Cart → Payment → Confirm	payments/, cart/	P0
Registration	Signup → Verify → Profile	users/, email/	P1
Search	Query → Results → Filter	search/, api/	P1

关键路径是指必须正常运行的用户流程：

路径	描述	涉及文件	优先级
身份验证	登录、登出、会话管理	auth/*	P0
结账流程	购物车 → 支付 → 确认	payments/, cart/	P0
用户注册	注册 → 验证 → 个人资料	users/, email/	P1
搜索功能	查询 → 结果 → 筛选	search/, api/	P1

2.2 Map Critical Files

2.2 映射核心文件

For each critical path, list involved files:

Authentication Path:

src/auth/login.ts        - 45% coverage
src/auth/session.ts      - 52% coverage
src/auth/middleware.ts   - 88% coverage
src/models/user.ts       - 72% coverage

针对每条关键路径，列出涉及的文件：

身份验证路径:

src/auth/login.ts        - 覆盖率45%
src/auth/session.ts      - 覆盖率52%
src/auth/middleware.ts   - 覆盖率88%
src/models/user.ts       - 覆盖率72%

2.3 Calculate Critical Path Coverage

2.3 计算关键路径覆盖率

Authentication Path:
- Total lines: 450
- Covered lines: 267
- Coverage: 59% (target: 90%)
- Gap: 183 lines to cover

身份验证路径:
- 总行数: 450
- 已覆盖行数: 267
- 覆盖率: 59% (目标: 90%)
- 缺口: 需覆盖183行

Phase 3: Test Pyramid Planning

阶段3：测试金字塔规划

3.1 Ideal Test Pyramid

3.1 理想测试金字塔

         /\
        /  \
       / E2E \         10% - Slow, expensive, covers user flows
      /______\
     /        \
    /Integration\      20% - Medium speed, covers integrations
   /______________\
  /                \
 /    Unit Tests    \  70% - Fast, cheap, covers logic
/____________________\

         /\
        /  \
       / E2E \         10% - 速度慢、成本高，覆盖用户完整流程
      /______\
     /        \
    /集成测试\      20% - 速度中等，覆盖模块间集成
   /______________\
  /                \
 /    单元测试    \  70% - 速度快、成本低，覆盖核心逻辑
/____________________\

3.2 Current Distribution

3.2 当前测试分布

Analyze current test distribution:

Current State:
- Unit tests: 45 (60%)
- Integration: 25 (33%)
- E2E: 5 (7%)

Ideal State:
- Unit tests: 70 (70%)
- Integration: 20 (20%)
- E2E: 10 (10%)

Gap:
- Need +25 unit tests
- Need -5 integration tests (or OK)
- Need +5 E2E tests

分析当前测试类型占比：

当前状态:
- 单元测试: 45个 (60%)
- 集成测试:25个 (33%)
- E2E测试:5个 (7%)

理想状态:
- 单元测试:70个 (70%)
- 集成测试:20个 (20%)
- E2E测试:10个 (10%)

缺口:
- 需新增25个单元测试
- 需减少5个集成测试（或保持现状）
- 需新增5个E2E测试

3.3 Test Type Guidelines

3.3 测试类型指南

Unit Tests (70%):

Pure functions
Business logic
Utility functions
Model methods
State transitions

Integration Tests (20%):

API endpoints
Database operations
Service interactions
Authentication flows
External service mocks

E2E Tests (10%):

Critical user journeys
Happy path scenarios
Cross-system flows
Smoke tests

单元测试 (70%):

纯函数
业务逻辑
工具函数
模型方法
状态转换

集成测试 (20%):

API接口
数据库操作
服务间交互
身份验证流程
外部服务模拟

E2E测试 (10%):

核心用户旅程
正常流程场景
跨系统流程
冒烟测试

Phase 4: Test Prioritization

阶段4：测试优先级排序

4.1 Priority Matrix

4.1 优先级矩阵

Priority	Criteria	Example
P0	Critical path, no tests	Payment processing
P1	Critical path, low coverage	Authentication
P2	High risk, medium coverage	Data validation
P3	Medium risk, any coverage	Utility functions
P4	Low risk, nice to have	Formatting helpers

优先级	判定标准	示例
P0	关键路径，无测试覆盖	支付处理流程
P1	关键路径，覆盖率低	身份验证流程
P2	高风险，覆盖率中等	数据验证逻辑
P3	中等风险，有一定覆盖率	工具函数
P4	低风险，锦上添花	格式化辅助函数

4.2 Effort Estimation

4.2 工作量估算

Test Type	Effort	Coverage Impact
Unit (simple)	15 min	High
Unit (complex)	1 hour	High
Integration	2 hours	Medium
E2E	4 hours	Low (but valuable)

测试类型	工作量	覆盖率影响
简单单元测试	15分钟	高
复杂单元测试	1小时	高
集成测试	2小时	中
E2E测试	4小时	低（但价值高）

4.3 Prioritized Test Backlog

4.3 优先级测试待办清单

markdown

undefined

markdown

undefined

Test Backlog

测试待办清单

P0 - Immediate (This Sprint)

P0 - 紧急（当前迭代）

Unit: payment.processPayment()
Unit: auth.validateToken()
Integration: POST /api/payments
E2E: Complete checkout flow

单元测试: payment.processPayment()
单元测试: auth.validateToken()
集成测试: POST /api/payments
E2E测试: 完整结账流程

P1 - High (Next Sprint)

P1 - 高优先级（下一个迭代）

Unit: auth.refreshToken()
Unit: user.validateEmail()
Integration: GET /api/users/:id
E2E: Registration flow

单元测试: auth.refreshToken()
单元测试: user.validateEmail()
集成测试: GET /api/users/:id
E2E测试: 用户注册流程

P2 - Medium (Backlog)

P2 - 中等优先级（待办库）

Unit: validation helpers
Unit: formatting utilities
Integration: Search API

单元测试: 验证辅助函数
单元测试: 格式化工具
集成测试: 搜索API

P3 - Low (Nice to Have)

P3 - 低优先级（可选）

Unit: logging utilities
Unit: config loaders

---

单元测试: 日志工具
单元测试: 配置加载器

---

Phase 5: Edge Case Planning

阶段5：边缘场景规划

5.1 Required Edge Cases

5.1 必测边缘场景

Every function should test:

Category	Cases	Example
Null/Undefined	null, undefined input	`validateUser(null)`
Empty	"", [], {}	`searchUsers("")`
Boundary	0, -1, MAX_INT	`setQuantity(0)`
Invalid Type	Wrong type input	`calculatePrice("abc")`
Concurrent	Race conditions	Parallel updates

每个函数都应覆盖以下场景：

类别	场景	示例
空值/未定义	null、undefined输入	`validateUser(null)`
空内容	""、[]、{}	`searchUsers("")`
边界值	0、-1、最大整数	`setQuantity(0)`
无效类型	类型错误的输入	`calculatePrice("abc")`
并发场景	竞态条件	并行更新

5.2 Edge Case Checklist

5.2 边缘场景检查清单

Phase 6: Flaky Test Remediation

阶段6：不稳定测试修复

6.1 Identify Flaky Tests

6.1 识别不稳定测试

Signs of flaky tests:

Intermittent failures in CI
Tests that pass locally but fail in CI
Tests that depend on execution order
Tests with timing-dependent assertions

不稳定测试的特征：

CI中间歇性失败
本地通过但CI失败
依赖执行顺序的测试
包含时间相关断言的测试

6.2 Common Causes & Fixes

6.2 常见原因与修复方案

Cause	Symptom	Fix
Timing	Random timeouts	Use proper async/await
Order dependency	Fails when run alone	Reset state in beforeEach
Shared state	Random failures	Isolate test data
External services	Network failures	Mock external calls
Date/time	Fails at midnight	Mock dates

原因	症状	修复方案
计时问题	随机超时	使用正确的async/await
顺序依赖	单独运行时失败	在beforeEach中重置状态
共享状态	随机失败	隔离测试数据
外部服务依赖	网络失败	模拟外部调用
日期/时间依赖	午夜后失败	模拟日期

Phase 7: Implementation Roadmap

阶段7：实施路线图

7.1 Sprint Planning Template

7.1 迭代规划模板

markdown

undefined

markdown

undefined

Sprint 1: Critical Path (2 weeks)

迭代1：关键路径覆盖（2周）

Goals

目标

Achieve 90% coverage on authentication
Achieve 90% coverage on payments
Add 5 E2E tests for critical paths

身份验证模块覆盖率达到90%
支付模块覆盖率达到90%
新增5个核心路径的E2E测试

Tasks

任务

Unit tests for auth module (20 tests)
Unit tests for payment module (15 tests)
Integration tests for auth API (5 tests)
E2E test: Complete checkout (1 test)
E2E test: Login flow (1 test)

身份验证模块单元测试（20个）
支付模块单元测试（15个）
身份验证API集成测试（5个）
E2E测试: 完整结账流程（1个）
E2E测试: 登录流程（1个）

Expected Outcome

预期成果

Overall coverage: 55% → 65%
Critical path coverage: 59% → 90%

undefined

整体覆盖率: 55% → 65%
关键路径覆盖率: 59% → 90%

undefined

7.2 Test Writing Guidelines

7.2 测试编写规范

Test Structure:

typescript

describe('Module or Function', () => {
  // Setup
  beforeEach(() => {
    // Reset state
  });

  describe('method or scenario', () => {
    it('should [expected behavior] when [condition]', () => {
      // Arrange
      const input = createTestInput();

      // Act
      const result = functionUnderTest(input);

      // Assert
      expect(result).toEqual(expectedOutput);
    });
  });
});

Naming Convention:

should [expected behavior] when [condition]

Examples:
- should return user when valid ID provided
- should throw error when user not found
- should update timestamp when saving

测试结构:

typescript

describe('模块或函数', () => {
  // 前置设置
  beforeEach(() => {
    // 重置状态
  });

  describe('方法或场景', () => {
    it('当[条件]时，应[预期行为]', () => {
      // 准备测试数据
      const input = createTestInput();

      // 执行测试函数
      const result = functionUnderTest(input);

      // 断言结果
      expect(result).toEqual(expectedOutput);
    });
  });
});

命名规范:

当[条件]时，应[预期行为]

示例:
- 当提供有效ID时，应返回用户信息
- 当用户不存在时，应抛出错误
- 当保存时，应更新时间戳

7.3 Coverage Tracking

7.3 覆盖率跟踪

Track coverage weekly:

Week	Overall	Business	Critical	Tests Added
1	55%	62%	59%	+15
2	62%	75%	78%	+22
3	68%	82%	88%	+18
4	72%	85%	92%	+12

每周跟踪覆盖率变化：

周数	整体覆盖率	业务逻辑覆盖率	关键路径覆盖率	新增测试数
1	55%	62%	59%	+15
2	62%	75%	78%	+22
3	68%	82%	88%	+18
4	72%	85%	92%	+12

Quick Reference

快速参考

Coverage Commands

覆盖率命令

bash

undefined

bash

undefined

Node.js

npm test -- --coverage --coverageReporters=text-summary

Python

pytest --cov=src --cov-report=term-missing

Go

go test -cover ./... | grep -E "coverage:"

Rust

cargo tarpaulin --out Stdout

undefined

cargo tarpaulin --out Stdout

undefined

Test Templates

测试模板

Unit Test:

typescript

describe('functionName', () => {
  it('should [behavior] when [condition]', () => {
    const result = functionName(input);
    expect(result).toEqual(expected);
  });
});

Integration Test:

typescript

describe('POST /api/resource', () => {
  it('should create resource when valid data', async () => {
    const response = await request(app)
      .post('/api/resource')
      .send(validData);
    expect(response.status).toBe(201);
  });
});

单元测试:

typescript

describe('functionName', () => {
  it('当[条件]时，应[行为]', () => {
    const result = functionName(input);
    expect(result).toEqual(expected);
  });
});

集成测试:

typescript

describe('POST /api/resource', () => {
  it('当提供有效数据时，应创建资源', async () => {
    const response = await request(app)
      .post('/api/resource')
      .send(validData);
    expect(response.status).toBe(201);
  });
});

Checklist

检查清单

Analysis

分析阶段

Coverage report generated
Gaps identified
Critical paths mapped
Current pyramid analyzed

已生成覆盖率报告
已识别覆盖率缺口
已映射关键路径
已分析当前测试金字塔分布

Planning

规划阶段

Tests prioritized
Edge cases documented
Flaky tests identified
Sprint plan created

已完成测试优先级排序
已记录边缘场景
已识别不稳定测试
已制定迭代计划

Implementation

实施阶段

P0 tests written
P1 tests written
Edge cases covered
Flaky tests fixed

P0测试已完成
P1测试已完成
边缘场景已覆盖
不稳定测试已修复

Validation

验证阶段

Coverage targets met
All tests passing
No flaky tests
CI/CD updated

已达成覆盖率目标
所有测试通过
无不稳定测试
CI/CD已更新

Extended Resources

扩展资源

For detailed examples, patterns, and in-depth guidance, see:

```
references/process.md
```
- Comprehensive testing patterns and examples

如需详细示例、模式和深度指导，请查看：

```
references/process.md
```
- 全面的测试模式与示例

testing-strategy

Original

Translation

Testing Strategy

测试策略

When to Use

适用场景

Coverage Targets

覆盖率目标

Prerequisites

前置条件

Strategy Process

策略执行流程

Phase 1: Coverage Analysis

阶段1：覆盖率分析

1.1 Generate Coverage Report

1.1 生成覆盖率报告

or

or

1.2 Analyze Coverage Gaps

1.2 分析覆盖率缺口

1.3 Identify Uncovered Files

1.3 识别未覆盖文件

Phase 2: Critical Path Identification

阶段2：关键路径识别

2.1 Define Critical Paths

2.1 定义关键路径

2.2 Map Critical Files

2.2 映射核心文件

2.3 Calculate Critical Path Coverage

2.3 计算关键路径覆盖率

Phase 3: Test Pyramid Planning

阶段3：测试金字塔规划

3.1 Ideal Test Pyramid

3.1 理想测试金字塔

3.2 Current Distribution

3.2 当前测试分布

3.3 Test Type Guidelines

3.3 测试类型指南

Phase 4: Test Prioritization

阶段4：测试优先级排序

4.1 Priority Matrix

4.1 优先级矩阵

4.2 Effort Estimation

4.2 工作量估算

4.3 Prioritized Test Backlog

4.3 优先级测试待办清单

Test Backlog

测试待办清单

P0 - Immediate (This Sprint)

P0 - 紧急（当前迭代）

P1 - High (Next Sprint)

P1 - 高优先级（下一个迭代）

P2 - Medium (Backlog)

P2 - 中等优先级（待办库）

P3 - Low (Nice to Have)

P3 - 低优先级（可选）

Phase 5: Edge Case Planning

阶段5：边缘场景规划

5.1 Required Edge Cases

5.1 必测边缘场景

5.2 Edge Case Checklist

5.2 边缘场景检查清单

Phase 6: Flaky Test Remediation

阶段6：不稳定测试修复

6.1 Identify Flaky Tests

6.1 识别不稳定测试

6.2 Common Causes & Fixes

6.2 常见原因与修复方案

Phase 7: Implementation Roadmap

阶段7：实施路线图

7.1 Sprint Planning Template

7.1 迭代规划模板

Sprint 1: Critical Path (2 weeks)

迭代1：关键路径覆盖（2周）

Goals

目标

Tasks

任务

Expected Outcome