⚡

测试最佳实践 testing-best-practices

这是一个关于软件测试的专家技能，提供跨单元测试、集成测试和端到端测试的分层策略、执行指导和持续集成规划。它帮助开发者和测试工程师设计测试用例、规划测试矩阵、编写可维护的测试代码，并确保测试的可靠性、高效性和可重复性。关键词：软件测试，单元测试，集成测试，端到端测试，测试策略，测试矩阵，CI/CD，自动化测试，测试最佳实践。

测试 0 次安装 0 次浏览 更新于 2/23/2026

name: 测试最佳实践 description: 跨单元测试、集成测试和端到端测试的测试分层、执行和持续集成指导。在为一个模块设计测试、编写测试用例或规划测试策略时使用。

何时激活

在以下情况时使用：

  • 处理规范文件（*.spec.md, SPEC.md, spec/*.md）时
  • 为模块设计测试用例或测试策略时
  • 编写或评审单元测试、集成测试或端到端测试时
  • 在 /specout 完成后
  • 规划持续集成测试通道时

修改策略

  • 默认：分析代码并生成测试策略、矩阵和实施计划。
  • 除非用户明确要求维护规范，否则不要编辑规范文件。
  • 当此技能与系统/项目规则冲突时，遵循系统/项目规则。

测试分层策略

单元测试

目的：在隔离环境中验证单个函数和不变量。

  • 数据驱动：参数化表格，涵盖正常路径、边界值、错误和边缘情况。
  • 基于属性：模糊测试在所有输入下都必须成立的不变量（例如，幂等性、排序稳定性、往返序列化）。
  • 从模块的公共API表面推导用例：输入类型/约束、输出形状、错误模式、不变量。
  • 按函数覆盖类别：正常路径、边界值、错误情况、边缘情况、不变量。

集成 / 契约测试

目的：验证组件之间以及与外部服务的交互。

  • API信封：请求/响应形状、状态码、内容类型、分页。
  • 错误契约：错误码、错误形状、速率限制、重试。
  • 认证和范围：令牌验证、基于角色的访问、租户隔离。
  • 最终一致性：在有界时间内验证收敛性；轮询而非休眠。
  • 尽可能在测试间复用认证状态；避免冗余的登录流程。

端到端测试

目的：通过完整技术栈验证真实用户工作流。

  • 不使用模拟；调用真实的服务、数据库和API。
  • 仅限正常路径工作流；将边缘情况留给下层测试。
  • 快速：每个测试应在合理的超时时间内完成。
  • 状态容忍：绝不假设干净状态；容忍并使用现有状态。
  • 幂等性：可安全重复运行，无需在运行间清理。
  • 流程导向：验证端到端的真实数据路径，而非孤立的断言。

硬性规则

  • 绝不发明签名、源代码位置或行号。 仅引用从代码库中读取的内容。
  • 不捏造测试夹具。 从仓库中的实际模式、类型或种子数据推导测试数据。
  • 不在产品代码中添加仅用于测试的hack。 没有 if (process.env.TEST) 分支，没有测试专用导出，没有测试后门。
  • 端到端测试绝不能依赖干净状态。 测试必须容忍预先存在的数据、先前的测试运行和共享环境。
  • 绝不为了通过测试而削弱断言。 修复根本问题。
  • 绝不硬编码与测试断言匹配的值。 实现通用逻辑。

执行指导

飞行前检查（端到端测试前）

  1. 验证目标环境可达（健康端点、ping）。
  2. 确认所需服务正在运行（数据库、API、认证提供者）。
  3. 验证测试用户/凭证存在且功能正常。
  4. 检查可能导致错误失败的残留状态；记录它，但不要因此失败。

确定性夹具

  • 使用带种子的随机性生成数据（带种子的faker、确定性UUID）。
  • 夹具应自包含；避免跨测试的夹具依赖。
  • 优先使用工厂函数而非共享的可变夹具对象。

异步处理

  • 使用有界超时和退避进行轮询；绝不使用固定的 sleep/waitForTimeout。
  • 为每个操作设置明确的超时；超时后快速失败并给出描述性消息。
  • 限制重试次数（例如，最多3次重试，采用指数退避）。
  • 使用框架原生的等待机制（Playwright expect、异步断言）而非手动循环。

处理不稳定测试

  • 每次测试运行仅进行一次基础设施重试；如果失败两次，则不是不稳定测试。
  • 重试失败时，收集诊断信息：截图、网络日志、服务健康状态、时间戳。
  • 在尝试修复前，对失败进行分类（不稳定 / 过时 / 缺陷）。
  • 绝不添加任意延迟或重试循环作为不稳定测试的“修复”。

API表面发现

生成测试用例前：

  • 阅读模块源代码以枚举导出/公共函数。
  • 根据用户请求和检查的代码上下文确认范围；如果模糊，陈述假设并保守进行。
  • 对于每个函数：输入类型/约束、输出形状、错误模式、不变量。
  • 探测函数间的状态依赖和顺序约束。
  • 根据上下文决定粒度：单元级别（单个函数）与集成级别（组合）。

输出格式

保持输出可操作且简洁。使用markdown，而非严格的JSON模式。

测试策略

简要总结测试内容及层级：

## 测试策略

- **单元测试**：[函数/模块]，针对[不变量]的数据驱动 + 基于属性测试
- **集成测试**：[API契约]，认证范围，错误信封
- **端到端测试**：[工作流]，针对真实服务的正常路径流程

测试矩阵

按函数或流程的表格化用例列表：

## 测试矩阵

### `functionName`

| ID | 类别 | 名称 | 输入 | 预期 |
|----|----------|------|-------|----------|
| HP-01 | 正常路径 | 基本大写 | "hello" | "HELLO" |
| BV-01 | 边界值 | 空字符串 | "" | "" |
| ERR-01 | 错误 | null输入 | null | INVALID_ARGUMENT |
| EDGE-01 | 边缘 | Unicode组合 | "cafe\u0301" | "CAFE\u0301" |

用例ID方案：{CATEGORY}-{NN} (HP, BV, ERR, EDGE)。仅追加；绝不重新编号。

实施计划

编写和运行测试的有序步骤：

## 实施计划

1. 为[夹具]添加使用种子数据的工厂
2. 为[函数]编写参数化单元测试（X个用例）
3. 为[API端点]编写认证 + 错误契约的集成测试
4. 为[工作流]编写带飞行前检查的端到端流程测试
5. 运行测试套件：`[命令]`

持续集成指导

快速PR冒烟通道

  • 每次PR运行单元测试 + 代码检查 + 类型检查。
  • 覆盖关键契约的集成测试子集。
  • 目标：5分钟内完成。

夜间完整通道

  • 完整的单元 + 集成 + 端到端测试套件。
  • 包含更高迭代次数的基于属性测试。
  • 幂等性验证：运行关键设置路径两次，断言第二次运行无副作用。
  • 不稳定测试检测：标记初始失败但重试通过的测试。

工作流

  1. 规范或代码定义模块行为（类型、约束、API表面）。
  2. 代理（使用此技能）生成测试策略、矩阵和实施计划。
  3. 测试编写代理将计划转换为目标语言惯用语的可运行代码。
  4. 开发人员实现以通过测试。
  5. 如果实现揭示缺失用例，首先提出；仅在明确请求时追加到规范。