31a - AI辅助测试概览

Level 5 ─── 自主测试 ──────── AI 自主发现、生成、执行、优化测试
  ↑                           （2026+ 前沿探索）
Level 4 ─── 智能测试 ──────── AI 驱动测试策略、自愈 E2E、PBT 属性发现
  ↑                           （2025-2026 领先团队）
Level 3 ─── 辅助测试 ──────── AI 生成测试代码、人工审查和补充
  ↑                           （2024-2025 主流团队）
Level 2 ─── 补全测试 ──────── AI 补全测试代码片段、建议断言
  ↑                           （2023-2024 早期采用者）
Level 1 ─── 手动测试 ──────── 完全手动编写和维护测试
                              （传统方式）

# Copilot Chat 测试生成示例
/tests 为 UserService.cs 中的 CreateUser 方法生成单元测试，
使用 xUnit + Moq，覆盖正常路径、重复用户名、无效邮箱三种场景

# Claude Code 测试生成示例
claude "分析 src/services/payment.ts 的所有公开方法，
为每个方法生成单元测试和至少 2 个属性测试，
使用 Vitest + fast-check，遵循 CLAUDE.md 中的测试约定"

# Kiro Spec 驱动测试示例（design.md 中的 Correctness Properties）
Property 1: 用户创建幂等性
  FORALL validUserInput: UserInput
  createUser(createUser(validUserInput)) == createUser(validUserInput)
  Validates: Requirement 1.2
 
Property 2: 余额非负性
  FORALL account: Account, amount: PositiveNumber
  withdraw(account, amount).balance >= 0
  Validates: Requirement 3.1

传统测试金字塔（2009-2023）

          ╱  ╲
         ╱ E2E ╲          ← 少量：验证关键用户流程
        ╱────────╲
       ╱ 集成测试  ╲       ← 适量：验证组件间交互
      ╱──────────────╲
     ╱   单元测试      ╲    ← 大量：验证独立函数/类
    ╱────────────────────╲

    速度：快 ──────────→ 慢
    成本：低 ──────────→ 高
    数量：多 ──────────→ 少

AI 时代测试金字塔 2.0（2025-2026）

              ╱  ╲
             ╱ 探索 ╲         ← 新增：Agentic 探索性测试
            ╱────────╲
           ╱ 视觉 AI  ╲       ← 新增：视觉回归 + 无障碍
          ╱──────────────╲
         ╱   E2E（自愈）   ╲    ← 进化：AI 自愈式 E2E
        ╱────────────────────╲
       ╱    集成测试（AI 生成） ╲  ← 进化：AI 自动生成
      ╱──────────────────────────╲
     ╱   单元测试 + PBT（AI 生成）  ╲ ← 进化：AI 生成 + PBT 补充
    ╱──────────────────────────────────╲
   ╱        静态分析 + 类型检查          ╲ ← 基础：AI 增强的静态分析
  ╱──────────────────────────────────────────╲

  新增层级：
  🆕 Agentic 探索性测试：AI Agent 自主探索应用，发现未预期的行为
  🆕 视觉 AI 测试：像素级视觉对比 + 无障碍合规检查
  
  进化层级：
  🔄 E2E 测试：从脆弱的选择器脚本 → AI 自愈式测试
  🔄 集成测试：从手动编写 → AI 从 API 规范自动生成
  🔄 单元测试：从手动编写 → AI 生成 + PBT 属性测试补充
  🔄 静态分析：从规则匹配 → AI 语义理解

测试奖杯模型（AI 增强版）

         🏆
        ╱  ╲
       ╱ E2E ╲          ← AI 自愈 + 视觉 AI
      ╱────────╲
     ╱          ╲
    │  集成测试   │       ← AI 生成（最大价值区域）
    │            │
     ╲          ╱
      ╲────────╱
       ╲ 单元  ╱         ← AI 批量生成 + PBT
        ╲────╱
         ╲  ╱
          ╲╱
       静态分析           ← AI 增强

┌──────────────┐     ┌──────────────┐     ┌──────────────┐
│  源代码文件    │────→│  AI 分析函数   │────→│  生成测试用例  │
│  (*.ts/*.py)  │     │  签名和实现    │     │  (正常/边界/   │
│               │     │              │     │   异常路径)    │
└──────────────┘     └──────────────┘     └──────┬───────┘
                                                  │
┌──────────────┐     ┌──────────────┐            │
│  人工审查      │←────│  运行测试      │←───────────┘
│  + 补充边界    │     │  + 修复失败    │
└──────────────┘     └──────────────┘

你是一个资深测试工程师。请为以下 [语言] 代码生成单元测试：

```[语言]
[粘贴源代码]

### 4.2 集成测试：AI 需要引导的领域

集成测试验证组件间的交互，AI 在这个层级需要更多的上下文引导。

#### AI 生成集成测试的挑战

| 挑战 | 原因 | 解决策略 |
|------|------|---------|
| **环境依赖** | 数据库、消息队列、外部 API | 在 prompt 中明确指定 mock 策略或 testcontainers 配置 |
| **状态管理** | 测试间的数据隔离 | 在 prompt 中要求每个测试独立设置/清理数据 |
| **异步行为** | 事件驱动、消息队列 | 在 prompt 中指定等待策略和超时处理 |
| **业务流程** | 多步骤业务逻辑 | 提供业务流程图或序列图作为上下文 |

#### 提示词模板：集成测试生成

[请求体示例]

[响应体示例]

### 4.3 E2E 测试：AI 自愈的前沿

E2E 测试是传统自动化测试中维护成本最高的层级。AI 的自愈能力正在改变这一局面。

#### AI 自愈 E2E 测试的工作原理

#### 主流 AI 自愈 E2E 工具对比

| 工具 | 自愈机制 | 支持的浏览器 | CI/CD 集成 | 价格 |
|------|---------|------------|-----------|------|
| **Mabl** | AI 智能定位器 + 视觉匹配 | Chrome、Firefox、Safari | Jenkins、GitHub Actions、GitLab CI | 联系销售 |
| **Testim** | 智能定位器 + 多属性匹配 | Chrome、Firefox、Edge | 所有主流 CI | 免费（基础）/ 企业定价 |
| **Katalon** | AI 自愈 + 智能等待 | 全浏览器 + 移动 | 所有主流 CI | 免费（基础）/ $208/月起 |
| **Playwright + AI** | 手动 + AI 辅助修复 | Chromium、Firefox、WebKit | 所有主流 CI | 免费（开源） |
| **testrigor** | 自然语言测试 + AI 执行 | 全浏览器 | 所有主流 CI | 联系销售 |

#### 提示词模板：E2E 测试生成

### 4.4 Property-Based Testing（PBT）：AI 时代的测试利器

PBT 是 AI 辅助测试中最具潜力的方向之一。传统 example-based 测试验证"这个输入产生这个输出"，PBT 验证"对于所有有效输入，这个属性都成立"。

#### 为什么 PBT 在 AI 时代特别重要？

1. **AI 生成的代码需要更强的验证**：AI 可能生成"看起来对但边界条件有 bug"的代码，PBT 能自动发现这些边界
2. **Spec 驱动天然适合 PBT**：需求文档中的验收标准可以直接转化为属性
3. **AI 擅长设计生成器**：AI 可以根据类型签名和业务规则设计智能的输入生成器
4. **收缩（Shrinking）提供最小反例**：当属性失败时，PBT 框架自动找到最小的失败输入，便于调试

#### PBT 框架推荐

| 框架 | 语言 | 核心特性 | 价格 | 适用场景 |
|------|------|---------|------|---------|
| **fast-check** | TypeScript/JavaScript | 丰富的内置 Arbitrary、智能收缩、异步支持 | 免费（开源） | 前端/Node.js 项目 |
| **Hypothesis** | Python | 数据库集成、有状态测试、Django 支持 | 免费（开源） | Python 项目 |
| **QuickCheck** | Haskell | PBT 鼻祖、类型驱动生成 | 免费（开源） | Haskell 项目 |
| **jqwik** | Java/Kotlin | JUnit 5 集成、丰富的组合子 | 免费（开源） | JVM 项目 |
| **proptest** | Rust | 宏驱动、与 Rust 类型系统深度集成 | 免费（开源） | Rust 项目 |
| **rapid** | Go | 简洁 API、与 go test 集成 | 免费（开源） | Go 项目 |
| **FsCheck** | C#/F# | .NET 生态集成、Arb 组合子 | 免费（开源） | .NET 项目 |

#### 提示词模板：PBT 属性发现

[粘贴源代码]

### 4.5 视觉 AI 测试

视觉 AI 测试使用计算机视觉技术对比 UI 截图，检测视觉回归。与传统像素级对比不同，AI 视觉测试能够理解"语义级"变化——区分"有意的设计变更"和"意外的视觉回归"。

#### 视觉测试工作流

#### 视觉 AI 测试工具详细对比

| 工具 | AI 能力 | 跨浏览器 | 跨设备 | CI 集成 | 价格 | 最佳场景 |
|------|--------|---------|--------|---------|------|---------|
| **Applitools Eyes** | Ultrafast Grid、AI 根因分析、布局匹配、内容匹配、严格匹配 | ✅ 50+ 浏览器 | ✅ 移动 + 桌面 | 所有主流 CI | 免费（100 检查点/月）/ 联系销售 | 企业级视觉回归，设计系统一致性 |
| **Percy (BrowserStack)** | 像素级对比、响应式快照、自动稳定化 | ✅ Chrome + Firefox | ✅ 多分辨率 | GitHub、GitLab、CircleCI | 免费（5000 快照/月）/ $399/月起 | 中小团队视觉回归 |
| **Chromatic** | Storybook 集成、组件级视觉测试、交互测试 | ✅ Chrome | ❌ | GitHub、GitLab | 免费（5000 快照/月）/ $149/月起 | Storybook 驱动的组件库 |
| **Lost Pixel** | 开源视觉回归、Storybook/Playwright 集成 | ✅ Chromium | ❌ | GitHub Actions | 免费（开源）/ $25/月（Cloud） | 预算有限的团队 |
| **BackstopJS** | 开源像素对比、Docker 支持 | ✅ Chromium | ❌ | 所有 CI | 免费（开源） | 简单的视觉回归需求 |

#### 提示词模板：视觉测试策略设计

### 4.6 变异测试：评估测试质量

变异测试通过在源代码中引入小的变异（如将 `>` 改为 `>=`），检查现有测试是否能检测到这些变异。如果测试套件无法"杀死"某个变异体，说明测试覆盖存在盲区。

#### AI 增强的变异测试

传统变异测试的问题是运行时间长（每个变异体都需要运行完整测试套件）。AI 增强的变异测试通过智能选择变异体和增量运行来解决这个问题。

| 工具 | 语言 | AI 增强 | 变异类型 | 增量支持 | 价格 |
|------|------|--------|---------|---------|------|
| **Stryker** | JavaScript/TypeScript/C# | 智能变异体选择、增量变异 | 算术、条件、字符串、数组 | ✅ | 免费（开源） |
| **mutmut** | Python | 基础变异 | 算术、条件、返回值 | ❌ | 免费（开源） |
| **pitest** | Java | 增量变异、历史分析 | 全面（15+ 变异器） | ✅ | 免费（开源） |
| **cargo-mutants** | Rust | Cargo 集成 | 返回值、条件 | ✅ | 免费（开源） |

#### 变异测试与 AI 测试生成的协同

变异测试是评估 AI 生成测试质量的最佳工具：

工作流示例：

```bash
# 1. AI 生成测试
claude "为 src/utils/calculator.ts 生成单元测试"

# 2. 运行变异测试评估质量
npx stryker run --mutate "src/utils/calculator.ts"

# 3. 分析存活的变异体
# Stryker 报告显示哪些代码变异没有被测试捕获

# 4. 让 AI 补充测试
claude "以下变异体存活了，请补充测试来杀死它们：
- 第 15 行：将 > 改为 >= 后测试仍然通过
- 第 23 行：将 + 改为 - 后测试仍然通过"

分析以下变异测试报告，为存活的变异体生成补充测试：

变异测试报告：
[粘贴 Stryker/pitest 报告中存活的变异体列表]

源代码：
```[语言]
[粘贴被测试的源代码]

[粘贴现有测试代码]

---

## 5. AI 测试生成的能力边界和局限性

### 5.1 AI 擅长的测试场景

| 场景 | AI 表现 | 原因 |
|------|--------|------|
| **纯函数单元测试** | ⭐⭐⭐⭐⭐ | 输入/输出明确，模式标准化 |
| **CRUD API 测试** | ⭐⭐⭐⭐ | 模式固定，边界清晰 |
| **数据转换/序列化测试** | ⭐⭐⭐⭐⭐ | 往返属性天然适合 PBT |
| **正则表达式/验证器测试** | ⭐⭐⭐⭐ | 边界值生成是 AI 强项 |
| **错误处理路径测试** | ⭐⭐⭐⭐ | AI 擅长枚举异常场景 |
| **快照测试生成** | ⭐⭐⭐⭐ | 机械性工作，AI 效率高 |
| **测试数据/Fixture 生成** | ⭐⭐⭐⭐⭐ | AI 可以生成大量多样化的测试数据 |

### 5.2 AI 不擅长的测试场景

| 场景 | AI 表现 | 原因 | 人工补充策略 |
|------|--------|------|------------|
| **业务规则验证** | ⭐⭐ | AI 不理解业务语义 | 在 prompt 中提供业务规则文档 |
| **并发/竞态条件测试** | ⭐⭐ | 时序问题难以通过代码分析发现 | 人工设计竞态场景，AI 生成测试骨架 |
| **安全测试** | ⭐⭐ | 攻击向量需要安全专业知识 | 使用专用安全测试工具 + AI 辅助 |
| **性能测试** | ⭐⭐ | 性能基线和阈值需要实际环境数据 | 人工定义性能指标，AI 生成负载脚本 |
| **跨系统集成测试** | ⭐⭐ | 系统间交互复杂，环境依赖多 | 人工设计测试场景，AI 生成测试代码 |
| **用户体验测试** | ⭐ | 主观判断，AI 无法评估"好不好用" | 人工测试 + 视觉 AI 辅助 |
| **无障碍合规测试** | ⭐⭐⭐ | 部分规则可自动化，但完整合规需要辅助技术测试 | axe-core 自动化 + 人工辅助技术测试 |

### 5.3 AI 测试生成的常见陷阱

#### 陷阱一：幻觉断言（Hallucinated Assertions）

AI 可能生成"看起来合理但实际上验证了错误行为"的断言：

```typescript
// ❌ AI 生成的幻觉断言示例
test('should calculate discount', () => {
  const result = calculateDiscount(100, 'VIP');
  expect(result).toBe(85); // AI 猜测 VIP 打 85 折，但实际业务是 8 折
});

// ✅ 正确做法：基于业务规则验证
test('should apply 20% discount for VIP customers', () => {
  const result = calculateDiscount(100, 'VIP');
  expect(result).toBe(80); // 明确的业务规则：VIP 8 折
});

// ❌ 过度 mock：测试只验证了 mock 返回值
test('should get user', async () => {
  jest.spyOn(db, 'findUser').mockResolvedValue({ id: 1, name: 'Alice' });
  const user = await userService.getUser(1);
  expect(user.name).toBe('Alice'); // 只验证了 mock，没有测试真实逻辑
});
 
// ✅ 使用真实数据库（testcontainers）或内存数据库
test('should get user from database', async () => {
  await db.insert({ id: 1, name: 'Alice', email: 'alice@example.com' });
  const user = await userService.getUser(1);
  expect(user.name).toBe('Alice');
  expect(user.email).toBe('alice@example.com');
});

// ❌ 测试实现细节
test('should call repository.save', async () => {
  const spy = jest.spyOn(repository, 'save');
  await service.createUser({ name: 'Alice' });
  expect(spy).toHaveBeenCalledWith({ name: 'Alice', createdAt: expect.any(Date) });
});
 
// ✅ 测试行为
test('should persist user and return with id', async () => {
  const user = await service.createUser({ name: 'Alice' });
  expect(user.id).toBeDefined();
  const found = await service.getUser(user.id);
  expect(found.name).toBe('Alice');
});

// ❌ 时间依赖的不稳定测试
test('should set expiry to 24 hours from now', () => {
  const token = createToken();
  const expected = new Date(Date.now() + 24 * 60 * 60 * 1000);
  expect(token.expiresAt).toEqual(expected); // 毫秒级差异导致间歇失败
});
 
// ✅ 使用时间范围或固定时钟
test('should set expiry to approximately 24 hours from now', () => {
  const before = Date.now();
  const token = createToken();
  const after = Date.now();
  const expectedMin = before + 24 * 60 * 60 * 1000;
  const expectedMax = after + 24 * 60 * 60 * 1000;
  expect(token.expiresAt.getTime()).toBeGreaterThanOrEqual(expectedMin);
  expect(token.expiresAt.getTime()).toBeLessThanOrEqual(expectedMax);
});

Spec 驱动测试的全链路

┌─────────────┐     ┌─────────────┐     ┌─────────────┐
│ Requirements │     │   Design    │     │    Tasks    │
│  需求文档     │────→│   设计文档    │────→│   任务列表   │
│              │     │             │     │            │
│ 验收标准 ────────→ 正确性属性 ────────→ 测试任务     │
│ (AC)         │     │ (Properties)│     │ (Test Tasks)│
└─────────────┘     └─────────────┘     └──────┬──────┘
                                                │
                    ┌───────────────────────────┘
                    │
              ┌─────┴─────┐
              │  AI Agent  │
              │  生成测试   │
              └─────┬─────┘
                    │
         ┌──────────┼──────────┐
         │          │          │
    ┌────┴────┐ ┌───┴───┐ ┌───┴────┐
    │ 单元测试 │ │  PBT  │ │ 集成测试│
    │ (Jest/  │ │(fast- │ │(super- │
    │ Vitest) │ │check) │ │ test)  │
    └─────────┘ └───────┘ └────────┘

# Requirements 示例
 
## Requirement 1: 用户注册
 
### Acceptance Criteria
1.1 WHEN 用户提交有效注册信息, THE 系统 SHALL 创建用户账户并返回用户 ID
1.2 WHEN 用户提交已存在的邮箱, THE 系统 SHALL 返回 409 冲突错误
1.3 WHEN 用户提交无效邮箱格式, THE 系统 SHALL 返回 400 验证错误
1.4 WHEN 用户密码少于 8 个字符, THE 系统 SHALL 返回 400 验证错误

# Design 示例 - Correctness Properties
 
Property 1: 注册幂等性
  FORALL validInput: RegistrationInput
  register(validInput) 成功后, register(validInput) 返回 409
  Validates: Requirement 1.1, 1.2
 
Property 2: 邮箱格式验证
  FORALL email: String
  NOT isValidEmail(email) => register({...validInput, email}) 返回 400
  Validates: Requirement 1.3
 
Property 3: 密码强度验证
  FORALL password: String WHERE password.length < 8
  register({...validInput, password}) 返回 400
  Validates: Requirement 1.4

# Tasks 示例
 
- [ ] 2.1 编写用户注册单元测试
  - 覆盖 AC 1.1-1.4 的 example-based 测试
  - _Requirements: 1.1, 1.2, 1.3, 1.4_
 
- [ ] 2.2 编写用户注册 PBT
  - 实现 Property 1（注册幂等性）
  - 实现 Property 2（邮箱格式验证）
  - 实现 Property 3（密码强度验证）
  - _Requirements: 1.1, 1.2, 1.3, 1.4_

.kiro/specs/user-registration/
├── requirements.md    # 需求文档（含验收标准）
├── design.md          # 设计文档（含正确性属性）
└── tasks.md           # 任务列表（含测试任务）

# EARS 验收标准示例
 
## Ubiquitous（始终成立）
- THE 系统 SHALL 在所有 API 响应中包含请求 ID
 
## Event-Driven（事件触发）
- WHEN 用户提交注册表单, THE 系统 SHALL 发送验证邮件
 
## State-Driven（状态触发）
- WHILE 用户处于试用期, THE 系统 SHALL 显示升级提示
 
## Unwanted Behavior（异常处理）
- IF 数据库连接失败, THEN THE 系统 SHALL 返回 503 并记录错误日志
 
## Optional Feature（可选功能）
- WHERE 用户启用了双因素认证, THE 系统 SHALL 在登录时要求验证码

# .kiro/hooks/auto-test.yaml
# 文件保存时自动运行相关测试
trigger: onFileSave
pattern: "src/**/*.ts"
action: askAgent
prompt: "运行与修改文件相关的测试，报告结果"

PBT 失败 → 获取反例 → 分诊决策
                         │
              ┌──────────┼──────────┐
              │          │          │
         测试有误    代码有 bug    规格有疑问
         修改测试    修复代码     询问用户

基于以下 Spec 文档生成测试代码：

## 需求（Requirements）
[粘贴相关的验收标准]

## 正确性属性（Correctness Properties）
[粘贴相关的属性定义]

## 测试任务
[粘贴当前要实现的测试任务描述]

要求：
1. 为每个验收标准生成至少一个 example-based 测试
2. 为每个正确性属性生成一个 property-based 测试
3. 每个测试用注释标注对应的需求编号：// Validates: Requirement X.Y
4. PBT 使用 [fast-check/Hypothesis/jqwik] 框架
5. 生成器要智能约束输入空间，避免无效输入
6. 测试文件放在 [测试目录] 下，命名为 [命名约定]

┌─────────────────────────────────────────────────────────────────────────┐
│                    AI 辅助测试全链路工作流                                 │
├─────────────────────────────────────────────────────────────────────────┤
│                                                                         │
│  阶段 1：需求分析        阶段 2：测试设计        阶段 3：测试生成          │
│  ┌──────────────┐      ┌──────────────┐      ┌──────────────┐         │
│  │ 需求文档       │      │ 测试策略       │      │ AI 生成测试   │         │
│  │ ↓             │      │ ↓             │      │ ↓             │         │
│  │ 提取验收标准   │─────→│ 确定测试类型   │─────→│ 单元测试      │         │
│  │ 识别测试属性   │      │ 设计 PBT 属性  │      │ PBT          │         │
│  │ 标注优先级     │      │ 规划覆盖策略   │      │ 集成测试      │         │
│  └──────────────┘      └──────────────┘      │ E2E 测试      │         │
│                                               └──────┬───────┘         │
│                                                       │                 │
│  阶段 6：持续优化        阶段 5：CI/CD 集成      阶段 4：人工审查         │
│  ┌──────────────┐      ┌──────────────┐      ┌──────────────┐         │
│  │ 覆盖率分析     │      │ PR 级测试运行  │      │ 审查断言正确性│         │
│  │ 变异测试评估   │←─────│ 自动回归测试   │←─────│ 补充边界用例  │         │
│  │ 测试策略调优   │      │ 失败自动修复   │      │ 验证业务语义  │         │
│  └──────────────┘      └──────────────┘      └──────────────┘         │
│                                                                         │
└─────────────────────────────────────────────────────────────────────────┘

# 以 TypeScript 项目为例
# 安装测试框架
npm install -D vitest @vitest/coverage-v8
 
# 安装 PBT 框架
npm install -D fast-check
 
# 安装 E2E 框架
npm install -D playwright @playwright/test
 
# 配置 vitest.config.ts

# 测试约定（CLAUDE.md / .cursorrules / .kiro/steering/testing.md）
 
## 测试框架
- 单元测试和集成测试：Vitest
- PBT：fast-check（通过 Vitest 运行）
- E2E：Playwright
 
## 文件命名
- 单元测试：`*.test.ts`（与源文件同目录）
- 集成测试：`*.integration.test.ts`（tests/integration/ 目录）
- E2E 测试：`*.e2e.ts`（tests/e2e/ 目录）
- PBT：`*.property.test.ts`（与源文件同目录）
 
## 测试风格
- 使用 describe/it 组织测试
- 测试名称格式：should [预期行为] when [条件]
- 遵循 AAA 模式（Arrange-Act-Assert）
- 每个测试独立，不依赖执行顺序
- 优先使用真实依赖，仅在必要时 mock 外部服务
 
## PBT 约定
- 每个属性测试标注对应的需求：// Validates: Requirement X.Y
- 生成器约束到有效输入空间
- 运行次数：开发时 100 次，CI 中 1000 次
 
## 覆盖率要求
- 核心业务逻辑：>90%
- 工具函数：>80%
- UI 组件：>60%（行为测试，非快照）

# 使用 Claude Code
claude "分析 src/services/ 目录下的所有服务文件，
为每个公开方法生成单元测试和属性测试，
遵循 CLAUDE.md 中的测试约定"
 
# 使用 Kiro（Spec 驱动）
# 在 Kiro 中创建 Spec，AI 自动生成测试任务并执行

审查清单：
□ 断言是否验证了正确的业务行为？
□ 是否覆盖了所有重要的边界条件？
□ PBT 属性是否准确反映了需求？
□ 生成器是否约束到了有效输入空间？
□ 是否存在过度 mock？
□ 测试是否独立且稳定？

# GitHub Actions 示例
name: Test Suite
on: [push, pull_request]
 
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '22'
      - run: npm ci
      - run: npx vitest run --coverage
      - run: npx playwright test
      - name: Upload coverage
        uses: codecov/codecov-action@v4

请对当前项目的测试套件进行健康审计：

1. 分析测试覆盖率报告，识别覆盖盲区
2. 检查是否存在以下问题：
   - 过度 mock 的测试（mock 数量 > 2 的测试）
   - 没有断言的测试（空测试或只有 console.log）
   - 重复的测试（测试相同行为的多个测试）
   - 过于脆弱的测试（依赖实现细节的测试）
3. 建议需要补充的测试类型和场景
4. 评估 PBT 属性的完整性
5. 生成审计报告，包含优先级排序的改进建议

## AI 生成测试审查清单
 
### 正确性
- [ ] 断言是否验证了正确的业务行为（而非实现细节）？
- [ ] 测试名称是否准确描述了被测试的行为？
- [ ] 边界值是否被覆盖（空值、零值、最大值、负值）？
- [ ] 异常路径是否被测试？
 
### PBT 特定
- [ ] 属性是否准确反映了需求文档中的验收标准？
- [ ] 生成器是否约束到了有效输入空间？
- [ ] 是否标注了对应的需求编号（Validates: Requirement X.Y）？
- [ ] 运行次数是否足够（开发 100 次，CI 1000 次）？
 
### 质量
- [ ] 是否存在过度 mock？
- [ ] 测试是否相互独立（无顺序依赖）？
- [ ] 是否存在时间依赖（硬编码时间、Date.now()）？
- [ ] 测试数据是否在 setup/teardown 中正确管理？
 
### 可维护性
- [ ] 测试是否遵循项目的命名和目录约定？
- [ ] 是否有适当的注释说明测试意图？
- [ ] 辅助函数是否被提取到共享的 test-utils 中？

# Requirements: 订单系统
 
## Requirement 1: 订单创建
1.1 WHEN 用户提交有效订单, THE 系统 SHALL 创建订单并返回订单 ID
1.2 WHEN 商品库存不足, THE 系统 SHALL 返回库存不足错误，不创建订单
1.3 WHEN 订单总金额超过用户信用额度, THE 系统 SHALL 拒绝订单
 
## Requirement 2: 价格计算
2.1 WHEN 计算订单价格, THE 系统 SHALL 正确应用商品单价 × 数量
2.2 WHEN 用户有优惠券, THE 系统 SHALL 在小计后应用折扣
2.3 WHEN 计算税费, THE 系统 SHALL 在折扣后金额上计算税费
2.4 WHEN 最终价格计算完成, THE 最终价格 SHALL 等于 (小计 - 折扣) × (1 + 税率)

# Design: Correctness Properties
 
Property 1: 价格计算一致性
  FORALL items: NonEmptyList<OrderItem>, discount: Percentage, taxRate: Percentage
  calculateTotal(items, discount, taxRate) ==
    sum(items.map(i => i.price * i.quantity)) * (1 - discount) * (1 + taxRate)
  Validates: Requirement 2.1, 2.2, 2.3, 2.4
 
Property 2: 价格非负性
  FORALL items: NonEmptyList<OrderItem>, discount: Percentage, taxRate: Percentage
  calculateTotal(items, discount, taxRate) >= 0
  Validates: Requirement 2.4
 
Property 3: 折扣单调性
  FORALL items: NonEmptyList<OrderItem>, d1: Percentage, d2: Percentage, taxRate: Percentage
  d1 <= d2 => calculateTotal(items, d1, taxRate) >= calculateTotal(items, d2, taxRate)
  Validates: Requirement 2.2
 
Property 4: 库存扣减原子性
  FORALL order: ValidOrder
  createOrder(order) 成功 => inventory.get(item) == originalInventory - order.quantity
  createOrder(order) 失败 => inventory.get(item) == originalInventory
  Validates: Requirement 1.1, 1.2

// order.property.test.ts - AI 生成的 PBT
import { describe, it, expect } from 'vitest';
import * as fc from 'fast-check';
import { calculateTotal } from './order-service';
 
// Validates: Requirement 2.1, 2.2, 2.3, 2.4
describe('Property: 价格计算一致性', () => {
  const orderItemArb = fc.record({
    productId: fc.uuid(),
    price: fc.float({ min: 0.01, max: 10000, noNaN: true }),
    quantity: fc.integer({ min: 1, max: 100 }),
  });
 
  const percentageArb = fc.float({ min: 0, max: 1, noNaN: true });
 
  it('should calculate total as (subtotal - discount) * (1 + taxRate)', () => {
    fc.assert(
      fc.property(
        fc.array(orderItemArb, { minLength: 1, maxLength: 20 }),
        percentageArb,
        percentageArb,
        (items, discount, taxRate) => {
          const result = calculateTotal(items, discount, taxRate);
          const subtotal = items.reduce((sum, i) => sum + i.price * i.quantity, 0);
          const expected = subtotal * (1 - discount) * (1 + taxRate);
          // 浮点数精度容差
          expect(Math.abs(result - expected)).toBeLessThan(0.01);
        }
      ),
      { numRuns: 1000 }
    );
  });
});
 
// Validates: Requirement 2.4
describe('Property: 价格非负性', () => {
  it('should never return negative total', () => {
    fc.assert(
      fc.property(
        fc.array(
          fc.record({
            productId: fc.uuid(),
            price: fc.float({ min: 0.01, max: 10000, noNaN: true }),
            quantity: fc.integer({ min: 1, max: 100 }),
          }),
          { minLength: 1, maxLength: 20 }
        ),
        fc.float({ min: 0, max: 1, noNaN: true }),
        fc.float({ min: 0, max: 0.5, noNaN: true }),
        (items, discount, taxRate) => {
          const result = calculateTotal(items, discount, taxRate);
          expect(result).toBeGreaterThanOrEqual(0);
        }
      ),
      { numRuns: 1000 }
    );
  });
});
 
// Validates: Requirement 2.2
describe('Property: 折扣单调性', () => {
  it('should decrease total as discount increases', () => {
    fc.assert(
      fc.property(
        fc.array(
          fc.record({
            productId: fc.uuid(),
            price: fc.float({ min: 0.01, max: 10000, noNaN: true }),
            quantity: fc.integer({ min: 1, max: 100 }),
          }),
          { minLength: 1, maxLength: 10 }
        ),
        fc.float({ min: 0, max: 0.5, noNaN: true }),
        fc.float({ min: 0.5, max: 1, noNaN: true }),
        fc.float({ min: 0, max: 0.3, noNaN: true }),
        (items, smallDiscount, largeDiscount, taxRate) => {
          const totalSmall = calculateTotal(items, smallDiscount, taxRate);
          const totalLarge = calculateTotal(items, largeDiscount, taxRate);
          expect(totalSmall).toBeGreaterThanOrEqual(totalLarge - 0.01);
        }
      ),
      { numRuns: 500 }
    );
  });
});

// order.test.ts - AI 生成的单元测试
import { describe, it, expect, beforeEach } from 'vitest';
import { OrderService } from './order-service';
import { InMemoryInventory } from '../test-utils/in-memory-inventory';
 
describe('OrderService', () => {
  let service: OrderService;
  let inventory: InMemoryInventory;
 
  beforeEach(() => {
    inventory = new InMemoryInventory();
    inventory.setStock('PROD-001', 10);
    inventory.setStock('PROD-002', 5);
    service = new OrderService(inventory);
  });
 
  // Validates: Requirement 1.1
  describe('createOrder - 正常路径', () => {
    it('should create order and return order ID for valid input', async () => {
      const order = await service.createOrder({
        userId: 'USER-001',
        items: [{ productId: 'PROD-001', quantity: 2, price: 29.99 }],
      });
      expect(order.id).toBeDefined();
      expect(order.status).toBe('created');
    });
 
    it('should deduct inventory after successful order', async () => {
      await service.createOrder({
        userId: 'USER-001',
        items: [{ productId: 'PROD-001', quantity: 3, price: 29.99 }],
      });
      expect(inventory.getStock('PROD-001')).toBe(7);
    });
  });
 
  // Validates: Requirement 1.2
  describe('createOrder - 库存不足', () => {
    it('should reject order when stock is insufficient', async () => {
      await expect(
        service.createOrder({
          userId: 'USER-001',
          items: [{ productId: 'PROD-002', quantity: 10, price: 49.99 }],
        })
      ).rejects.toThrow('Insufficient stock');
    });
 
    it('should not deduct inventory on failure', async () => {
      try {
        await service.createOrder({
          userId: 'USER-001',
          items: [{ productId: 'PROD-002', quantity: 10, price: 49.99 }],
        });
      } catch {
        // expected
      }
      expect(inventory.getStock('PROD-002')).toBe(5);
    });
  });
});