18c - AI 驱动测试生成

你的主要语言是什么？
├── Java → Diffblue Cover（强化学习，无幻觉，企业级）
├── 多语言 + 企业合规需求 → Qodo Enterprise（SOC 2, 自托管）
├── 使用 Kiro IDE → Kiro Spec-Driven PBT（需求→属性→测试）
├── 使用 VS Code + Copilot → GitHub Copilot /tests 命令
├── 需要自主测试 Agent → TestSprite（云沙箱执行）
└── 通用对话式 → Cursor / Claude Code（灵活但需人工引导）

传统流程：
  写代码 → 写测试 → 发现 bug → 修代码
  问题：测试只验证"代码做了什么"，不验证"代码应该做什么"

Spec-Driven 流程：
  定义需求 → 提取正确性属性 → 生成 PBT → 写代码 → 运行测试
  优势：测试验证"代码是否符合规格说明"

### Requirement 3: 文件同步引擎
 
#### Acceptance Criteria
 
1. WHEN a file is modified locally, THE sync engine SHALL detect the change
   within 5 seconds and queue a sync operation
2. WHEN syncing a file, THE sync engine SHALL compute a content hash and
   only transfer if the hash differs from the remote version
3. WHEN a sync conflict occurs, THE sync engine SHALL preserve both versions
   and notify the user

## Correctness Properties
 
Property 1: 哈希确定性
- 对于任意文件内容 content，hash(content) 在多次计算中必须返回相同结果
- Validates: Requirement 3, Criteria 2
 
Property 2: 同步幂等性
- 对于任意文件集合 files，如果本地和远程完全相同，
  computeSyncPlan(files, files) 的操作列表必须为空
- Validates: Requirement 3, Criteria 2
 
Property 3: 冲突检测完整性
- 对于任意两个不同内容的文件修改（本地和远程同时修改同一文件），
  sync engine 必须标记为冲突
- Validates: Requirement 3, Criteria 3

- [ ] 5.1 实现 Property 1 的 Property-Based Test（哈希确定性）
- [ ] 5.2 实现 Property 2 的 Property-Based Test（同步幂等性）
- [ ] 5.3 实现 Property 3 的 Property-Based Test（冲突检测完整性）

1. 读取 design.md 中的正确性属性定义
2. 分析目标代码的函数签名和类型信息
3. 选择合适的 PBT 框架（fast-check / proptest / Hypothesis）
4. 生成智能生成器（Generator），约束输入空间
5. 编写属性测试代码，标注 "Validates: Requirements X.Y"
6. 运行测试
7. 如果发现反例（counter-example）：
   ├── 分析反例是否揭示代码 bug → 修复代码
   ├── 分析反例是否揭示测试 bug → 修复测试
   └── 分析反例是否揭示 spec 问题 → 提示用户确认
8. 更新 PBT 状态（passed / failed）

┌─────────────────┐     ┌──────────────────┐     ┌─────────────────┐
│  需求文档        │     │  AI 分析引擎      │     │  测试代码        │
│  (PRD/User Story │────▶│  (LLM + RAG)     │────▶│  (可执行测试)    │
│   /验收标准)     │     │                  │     │                 │
└─────────────────┘     └──────────────────┘     └─────────────────┘
        │                       │                        │
        ▼                       ▼                        ▼
   结构化输入              提取测试属性              生成测试代码
   - 用户故事              - 正常路径               - 单元测试
   - 验收标准              - 边缘场景               - 属性测试
   - API 规格              - 错误处理               - 集成测试
   - 业务规则              - 性能约束               - 断言验证

# requirements_to_tests.py - 需求到测试的自动化管线示例
import openai
 
def extract_test_cases(requirement: str, code_context: str) -> str:
    """从需求文档和代码上下文中提取测试用例"""
    prompt = f"""
分析以下需求和代码，生成结构化的测试用例：
 
## 需求
{requirement}
 
## 代码上下文
{code_context}
 
请输出：
1. 正常路径测试用例（至少 3 个）
2. 边缘场景测试用例（至少 2 个）
3. 错误处理测试用例（至少 2 个）
4. 如果适用，提取可测试的属性（用于 Property-Based Testing）
 
输出格式：JSON
"""
    response = openai.chat.completions.create(
        model="gpt-4o",
        messages=[{"role": "user", "content": prompt}],
        response_format={"type": "json_object"}
    )
    return response.choices[0].message.content

你是一位资深测试工程师。基于以下代码，生成全面的单元测试。

## 待测代码
文件路径：[文件路径]

## 项目上下文
- 测试框架：[Jest/Vitest/Pytest/Go testing/JUnit]
- 语言版本：[语言和版本]
- 已有测试风格参考：[粘贴一个已有测试示例，如果有的话]

## 生成要求
1. 单元测试：覆盖正常路径、边缘场景、错误处理
2. 每个测试用例使用描述性命名（说明测试什么行为）
3. 不要使用 mock，尽量测试真实逻辑
4. 遵循 AAA 模式（Arrange-Act-Assert）
5. 包含以下场景：
   - 空输入 / null / undefined
   - 边界值（最大值、最小值、零）
   - 异常输入（错误类型、超长字符串）
   - 并发场景（如果适用）

你是一位精通 Property-Based Testing 的测试专家。基于以下代码和需求，
生成 PBT 测试。

## 待测代码

## 需求/验收标准
[粘贴相关需求]

## PBT 框架
使用 [fast-check (TypeScript) / proptest (Rust) / Hypothesis (Python) /
QuickCheck (Haskell)] 框架

## 生成要求
1. 从需求中提取至少 3 个可测试的属性（Property）
2. 每个属性包含：
   - 属性名称和描述
   - 对应的需求编号（格式：Validates: Requirements X.Y）
   - 智能生成器（Generator）设计——约束到有意义的输入空间
   - 属性断言
3. 不要使用 mock，测试真实逻辑
4. 生成器要考虑：
   - 输入范围的合理约束
   - 特殊值的权重（空字符串、零、极大值）
   - 组合输入的关联约束
5. 测试命名格式：property_[属性描述]

你是一位 QA 架构师。将以下需求文档转化为结构化的测试用例集。

## 需求文档
[粘贴 PRD / 用户故事 / 验收标准]

## 输出要求

### 第一部分：测试用例矩阵
以表格形式输出：
| 编号 | 测试场景 | 前置条件 | 操作步骤 | 预期结果 | 优先级 | 测试类型 |

测试类型包括：单元测试、集成测试、E2E 测试、属性测试

### 第二部分：可执行测试代码
- 框架：[指定框架]
- 对每个高优先级测试用例生成可执行代码
- 包含测试数据准备和清理

### 第三部分：覆盖率分析
- 列出需求中每个验收标准的测试覆盖情况
- 标注未覆盖或难以自动化的场景
- 建议补充的手动测试场景

### 第四部分：属性提取
- 从需求中提取适合 PBT 的属性
- 说明为什么这些属性适合用 PBT 验证

你是一位后端测试专家。为以下 API 端点生成集成测试。

## API 规格
端点：[HTTP 方法] [路径]
请求体：
```json
[请求体 schema]

[响应体 schema]

### 3.5 测试审查与补全模板

[粘贴源代码]

[粘贴现有测试]

---

## 4. 各工具实操指南

### 4.1 Qodo 实操

#### IDE 插件使用

#### CI/CD 集成

```yaml
# .github/workflows/qodo-tests.yml
name: Qodo Test Generation
on:
  pull_request:
    types: [opened, synchronize]

jobs:
  generate-tests:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Qodo Test Coverage Analysis
        uses: qodo-ai/qodo-cover-action@v1
        with:
          api-key: ${{ secrets.QODO_API_KEY }}
          coverage-threshold: 80
          test-command: "npm test"

在 VS Code 中：
1. 打开待测文件
2. 选中要测试的函数/类
3. 打开 Copilot Chat（Ctrl+Shift+I）
4. 输入：/tests
5. Copilot 分析选中代码，生成测试
6. 可追加上下文：/tests #file:utils.ts 使用 Vitest

在 Copilot Agent Mode 中：
1. 输入自然语言需求：
   "为 src/services/auth.ts 中的 AuthService 类生成完整的测试套件，
    使用 Vitest，覆盖登录、注册、token 刷新、权限验证场景"
2. Agent 自动：
   - 分析 AuthService 的所有方法
   - 识别依赖和接口
   - 生成测试文件
   - 运行测试并修复失败

1. 安装 Diffblue Cover IntelliJ 插件
2. 打开 Java 项目
3. 右键点击类/方法 → "Write Tests with Diffblue Cover"
4. Diffblue 使用强化学习（非 LLM）分析字节码
5. 自动生成 JUnit/TestNG 测试，包含：
   - 方法行为验证
   - 边界条件测试
   - 异常路径测试
6. 生成的测试是确定性的——相同输入总是产生相同测试

CLI 批量生成：
$ dcover create --class com.example.MyService
$ dcover create --project  # 整个项目

在 Claude Code 中：

$ claude "读取 src/sync_engine.rs 的代码，为所有公开方法生成
  proptest 属性测试。要求：
  1. 每个属性对应一个业务规则
  2. 生成器约束到合理的输入范围
  3. 不使用 mock
  4. 将测试写入 tests/sync_engine_props.rs"

Claude Code 会：
1. 读取源文件，分析函数签名和类型
2. 推断业务规则和不变量
3. 设计智能生成器
4. 生成属性测试代码
5. 运行 cargo test 验证
6. 如果失败，自动修复

              ┌───────────┐
              │   E2E     │  ← Agentic Testing（Bug0/TestSprite）
              │  (5-10个)  │     AI 自主探索关键用户流程
             ┌┴───────────┴┐
             │  集成测试    │  ← AI 生成 + 人工审查
             │  (适量)      │     Qodo/Copilot 生成 API 测试
            ┌┴─────────────┴┐
            │  单元测试      │  ← AI 大量生成 + PBT 补充
            │  (大量)        │     Qodo/Diffblue/Copilot 自动生成
           ┌┴───────────────┴┐
           │  属性测试 (PBT)  │  ← Spec-Driven 自动生成
           │  (核心逻辑)      │     Kiro / 手动 Prompt
          ┌┴─────────────────┴┐
          │  静态分析          │  ← AI 驱动 lint + 安全扫描
          │  (自动)            │     CI 流水线自动运行
          └───────────────────┘

1. 订单总价 = Σ(商品单价 × 数量) × (1 - 折扣率) × (1 + 税率)
2. 库存扣减后，库存数量 = 原库存 - 订单数量，且库存不能为负
3. 订单状态只能按 created → paid → shipped → delivered 流转
4. 取消订单必须恢复库存

Property 1: 价格计算正确性
- 对于任意正数的单价、数量、折扣率(0-1)、税率(0-0.5)，
  计算结果必须等于数学公式的精确值（允许浮点误差 0.01）
 
Property 2: 库存守恒
- 对于任意订单操作序列（创建、取消），
  最终库存 + 所有未取消订单的商品数量 = 初始库存
 
Property 3: 状态机合法性
- 对于任意状态转换序列，不存在非法转换
  （如 created → delivered 跳过中间状态）

import fc from 'fast-check';
import { calculateOrderTotal, OrderItem } from '../src/order';
 
describe('Order Properties', () => {
  // Property 1: 价格计算正确性
  // Validates: Requirements 1
  test('order total matches mathematical formula', () => {
    fc.assert(
      fc.property(
        fc.array(
          fc.record({
            price: fc.double({ min: 0.01, max: 10000, noNaN: true }),
            quantity: fc.integer({ min: 1, max: 100 })
          }),
          { minLength: 1, maxLength: 20 }
        ),
        fc.double({ min: 0, max: 1, noNaN: true }),    // 折扣率
        fc.double({ min: 0, max: 0.5, noNaN: true }),   // 税率
        (items, discount, taxRate) => {
          const result = calculateOrderTotal(items, discount, taxRate);
          const expected = items.reduce(
            (sum, item) => sum + item.price * item.quantity, 0
          ) * (1 - discount) * (1 + taxRate);
          expect(Math.abs(result - expected)).toBeLessThan(0.01);
        }
      )
    );
  });
});

describe('calculateOrderTotal - Edge Cases', () => {
  test('空订单返回 0', () => {
    expect(calculateOrderTotal([], 0, 0.1)).toBe(0);
  });
 
  test('100% 折扣返回 0', () => {
    const items = [{ price: 99.99, quantity: 5 }];
    expect(calculateOrderTotal(items, 1.0, 0.1)).toBe(0);
  });
 
  test('单个商品无折扣无税', () => {
    const items = [{ price: 10, quantity: 1 }];
    expect(calculateOrderTotal(items, 0, 0)).toBe(10);
  });
 
  test('大量商品不溢出', () => {
    const items = [{ price: 9999.99, quantity: 100 }];
    const result = calculateOrderTotal(items, 0, 0);
    expect(result).toBeFinite();
    expect(result).toBeGreaterThan(0);
  });
});