31c - 需求到测试用例自动化

需求文档 (PRD/User Story/Jira Ticket)
         │
         ▼
   验收标准 (AC)  ←── 测试用例的"种子"
         │
    ┌────┼────┐
    ▼    ▼    ▼
  单元  集成  E2E
  测试  测试  测试

┌──────────────┐     ┌──────────────┐     ┌──────────────┐
│  需求来源      │     │  AI 解析      │     │  结构化 AC    │
│               │     │              │     │              │
│ • PRD 文档    │────→│ • NLP 解析   │────→│ • EARS 格式  │
│ • Jira Ticket │     │ • 条件提取   │     │ • Given/When │
│ • User Story  │     │ • 边界识别   │     │   /Then      │
│ • Slack 讨论  │     │ • 隐含推理   │     │ • 优先级标注  │
└──────────────┘     └──────────────┘     └──────┬───────┘
                                                  │
                                           ┌──────┴───────┐
                                           │  人工审查      │
                                           │  确认/补充/修正│
                                           └──────────────┘

你是一个资深 QA 架构师。请从以下需求文档中提取所有验收标准。

## 需求文档
[粘贴 PRD 或用户故事]

## 提取要求
1. 使用 EARS（Easy Approach to Requirements Syntax）格式：
   - Ubiquitous（始终成立）：THE 系统 SHALL [行为]
   - Event-Driven（事件触发）：WHEN [触发条件], THE 系统 SHALL [行为]
   - State-Driven（状态触发）：WHILE [状态], THE 系统 SHALL [行为]
   - Unwanted Behavior（异常处理）：IF [异常条件], THEN THE 系统 SHALL [处理]
   - Optional Feature（可选功能）：WHERE [配置条件], THE 系统 SHALL [行为]

2. 对每条验收标准标注：
   - 编号（如 AC-1.1）
   - 优先级（P0/P1/P2）
   - 测试类型建议（单元/集成/E2E/PBT）
   - 是否需要特殊测试环境

3. 额外识别：
   - 隐含的边界条件（文档中未明确但逻辑上存在的）
   - 潜在的竞态条件或并发场景
   - 安全相关的验收标准
   - 性能相关的验收标准

4. 输出格式：Markdown 表格 + 详细描述

分析以下 Jira Ticket，提取结构化的验收标准：

## Ticket 信息
- 标题：[Ticket 标题]
- 描述：[Ticket 描述]
- 评论/讨论：[相关评论]
- 关联 Ticket：[依赖或关联的 Ticket]

## 提取要求
1. 从描述和评论中提取所有显式和隐式的验收标准
2. 将每条标准转化为 Given/When/Then 格式
3. 标注每条标准对应的 Ticket 来源（描述/评论/关联）
4. 识别评论中讨论但未写入描述的隐含需求
5. 标注需要与产品经理确认的模糊点

输出格式：
| AC 编号 | Given | When | Then | 来源 | 优先级 | 待确认 |

EARS 模式          →  测试骨架

Ubiquitous:
  THE 系统 SHALL X  →  FORALL input: ValidInput, X(input) == true
                       （属性测试：对所有有效输入，X 始终成立）

Event-Driven:
  WHEN A, SHALL B   →  test: given(precondition), when(A), then(B)
                       （单元/集成测试：触发 A 后验证 B）

State-Driven:
  WHILE S, SHALL B  →  test: given(state == S), when(action), then(B)
                       （状态测试：在状态 S 下执行操作，验证 B）

Unwanted:
  IF E, THEN SHALL H → test: given(precondition), when(inject(E)), then(H)
                       （异常测试：注入异常 E，验证处理 H）

Optional:
  WHERE C, SHALL B  →  test: given(config(C) == true), when(action), then(B)
                       test: given(config(C) == false), when(action), then(NOT B)
                       （配置测试：开启/关闭配置 C，验证不同行为）

作为一个电商用户，我希望能够使用优惠券下单，
以便在购物时享受折扣优惠。

业务规则：
- 每个订单只能使用一张优惠券
- 优惠券有有效期
- 优惠券有最低消费门槛
- 部分商品不参与优惠

## AC-1: 优惠券应用
 
### AC-1.1 [Event-Driven] 正常应用
WHEN 用户在结算页面输入有效优惠券码,
THE 系统 SHALL 验证优惠券有效性并显示折扣金额
- 优先级：P0
- 测试类型：集成测试
 
### AC-1.2 [Unwanted] 过期优惠券
IF 用户输入的优惠券已过期,
THEN THE 系统 SHALL 显示"优惠券已过期"错误提示并不应用折扣
- 优先级：P0
- 测试类型：单元测试
 
### AC-1.3 [State-Driven] 最低消费未达标
WHILE 订单金额低于优惠券最低消费门槛,
THE 系统 SHALL 显示"未达到最低消费 ¥[金额]"提示
- 优先级：P0
- 测试类型：单元测试 + PBT
 
### AC-1.4 [Ubiquitous] 单券限制
THE 系统 SHALL 确保每个订单最多只能应用一张优惠券
- 优先级：P0
- 测试类型：PBT（属性测试）
 
### AC-1.5 [Optional] 商品排除
WHERE 购物车中包含不参与优惠的商品,
THE 系统 SHALL 仅对参与优惠的商品计算折扣
- 优先级：P1
- 测试类型：集成测试
 
### AC-1.6 [隐含] 并发使用
IF 同一优惠券被多个用户同时使用且剩余次数为 1,
THEN THE 系统 SHALL 仅允许一个用户成功使用，其他用户收到"优惠券已被使用"提示
- 优先级：P1
- 测试类型：并发测试
- 备注：原需求未明确，建议与产品确认

┌─────────────────────────────────────────────────────────────────────────┐
│                    需求→测试用例自动化管线                                │
├─────────────────────────────────────────────────────────────────────────┤
│                                                                         │
│  阶段 1           阶段 2           阶段 3           阶段 4              │
│  需求解析          AC 提取          测试设计          代码生成            │
│  ┌──────────┐    ┌──────────┐    ┌──────────┐    ┌──────────┐         │
│  │ PRD/Story │───→│ EARS 格式│───→│ 测试策略  │───→│ 测试代码  │         │
│  │ Jira/Spec │    │ AC 列表  │    │ 类型选择  │    │ 框架适配  │         │
│  │ 会议纪要  │    │ 优先级   │    │ 覆盖矩阵  │    │ 断言生成  │         │
│  └──────────┘    └──────────┘    └──────────┘    └────┬─────┘         │
│                                                        │               │
│                                                   阶段 5               │
│                                                   验证与追溯           │
│                                                   ┌──────────┐        │
│                                                   │ 运行测试  │        │
│                                                   │ RTM 更新  │        │
│                                                   │ 覆盖报告  │        │
│                                                   └──────────┘        │
│                                                                         │
└─────────────────────────────────────────────────────────────────────────┘

# 需求→测试映射规则（.kiro/steering/test-mapping.md）
 
## 映射约定
- 每条 P0 验收标准必须有至少 2 个测试用例（正常路径 + 异常路径）
- 每条 P1 验收标准必须有至少 1 个测试用例
- P2 验收标准根据风险评估决定是否需要测试
- Ubiquitous 类型的 AC 优先使用 PBT
- Event-Driven 类型的 AC 使用 example-based 测试
- 每个测试用例必须标注对应的 AC 编号
 
## 测试文件命名
- 单元测试：`*.test.ts`（与源文件同目录）
- 集成测试：`*.integration.test.ts`（tests/integration/）
- E2E 测试：`*.e2e.ts`（tests/e2e/）
- PBT：`*.property.test.ts`（与源文件同目录）
 
## 追溯标注格式
每个测试用例必须包含以下注释：
// Validates: AC-X.Y [AC 描述]
// Priority: P0/P1/P2

基于以下验收标准，生成测试设计文档：

## 验收标准
[粘贴 AC 列表]

## 源代码
[粘贴相关源代码或 API 定义]

请为每条 AC 生成：
1. 测试场景列表（正常/边界/异常）
2. 测试数据需求
3. 前置条件和后置条件
4. 预期结果
5. 推荐的测试类型和框架

基于以下测试设计文档，生成可执行的测试代码：

## 测试设计
[粘贴测试设计文档]

## 技术栈
- 测试框架：[Vitest/Jest/Pytest]
- PBT 框架：[fast-check/Hypothesis]
- 项目约定：[粘贴 Steering 规则]

要求：
1. 每个测试标注对应的 AC 编号
2. 使用 AAA 模式（Arrange-Act-Assert）
3. PBT 属性标注 Validates 注释
4. 生成器约束到有效输入空间

你是一个资深测试架构师。请完成从需求到测试代码的全链路转化。

## 输入：需求文档
[粘贴需求文档]

## 输出要求

### Part 1：验收标准提取
- 使用 EARS 格式
- 标注优先级和测试类型
- 识别隐含需求

### Part 2：测试设计
- 为每条 AC 设计测试场景
- 包含正常路径、边界值、异常路径
- 标注测试数据需求

### Part 3：测试代码
- 使用 [测试框架] 框架
- 每个测试标注 AC 编号：// Validates: AC-X.Y
- Ubiquitous AC 使用 PBT
- Event-Driven AC 使用 example-based 测试
- 遵循项目测试约定

### Part 4：追溯矩阵
- 生成 AC→测试用例的映射表
- 标注覆盖状态

RTM 的四向追溯

需求 ←──────→ 验收标准 ←──────→ 测试用例 ←──────→ 缺陷
 │                │                │                │
 │   前向追溯      │   前向追溯      │   前向追溯      │
 │   (需求→测试)   │   (AC→测试)    │   (测试→缺陷)   │
 │                │                │                │
 │   后向追溯      │   后向追溯      │   后向追溯      │
 │   (测试→需求)   │   (测试→AC)    │   (缺陷→测试)   │
 ▼                ▼                ▼                ▼

┌──────────────────────────────────────────────────────────────┐
│                    AI 驱动的 RTM 自动化                        │
├──────────────────────────────────────────────────────────────┤
│                                                              │
│  ① 初始生成                                                   │
│  ┌──────────┐    ┌──────────┐    ┌──────────┐              │
│  │ 需求文档  │───→│ AI 解析   │───→│ RTM 初稿  │              │
│  │ 测试代码  │    │ 匹配关联  │    │ 覆盖分析  │              │
│  └──────────┘    └──────────┘    └──────────┘              │
│                                                              │
│  ② 持续更新                                                   │
│  ┌──────────┐    ┌──────────┐    ┌──────────┐              │
│  │ 需求变更  │───→│ AI 检测   │───→│ RTM 更新  │              │
│  │ 代码变更  │    │ 影响分析  │    │ 差异报告  │              │
│  │ 测试结果  │    │ 覆盖计算  │    │ 告警通知  │              │
│  └──────────┘    └──────────┘    └──────────┘              │
│                                                              │
│  ③ 覆盖率报告                                                 │
│  ┌──────────┐    ┌──────────┐    ┌──────────┐              │
│  │ RTM 数据  │───→│ AI 分析   │───→│ 覆盖热力图│              │
│  │ 测试结果  │    │ 风险评估  │    │ 风险报告  │              │
│  └──────────┘    └──────────┘    └──────────┘              │
│                                                              │
└──────────────────────────────────────────────────────────────┘

## 追溯粒度决策
 
### 小型项目（<50 个需求）
- 粒度：需求 → 测试用例
- 工具：Markdown 表格 + AI 自动更新
- 维护频率：每个 Sprint
 
### 中型项目（50-200 个需求）
- 粒度：验收标准 → 测试用例
- 工具：Qase / Testomat.io
- 维护频率：每次需求变更
 
### 大型项目（200+ 个需求）
- 粒度：验收标准 → 测试步骤
- 工具：TestRail / Xray / SpiraTest
- 维护频率：持续自动化

基于以下需求文档和测试代码，生成需求可追溯性矩阵（RTM）。

## 需求文档
[粘贴需求文档或验收标准列表]

## 测试代码目录结构
[粘贴测试文件列表或目录树]

## 测试代码中的追溯标注
[粘贴包含 "Validates: AC-X.Y" 注释的测试代码片段]

请生成：
1. 完整的 RTM 表格（需求→AC→测试用例→状态）
2. 覆盖率分析：
   - 已覆盖的 AC 数量和百分比
   - 未覆盖的 AC 列表（高亮 P0 未覆盖项）
   - 过度测试的 AC（测试用例数 > 5 的）
3. 风险评估：
   - 高风险未覆盖需求
   - 建议补充的测试类型
4. 输出格式：Markdown 表格

以下需求发生了变更，请分析对现有测试的影响：

## 变更前
[粘贴原始需求/AC]

## 变更后
[粘贴修改后的需求/AC]

## 现有 RTM
[粘贴当前 RTM]

请分析：
1. 哪些现有测试需要修改？
2. 哪些测试需要删除？
3. 需要新增哪些测试？
4. 变更对覆盖率的影响
5. 更新后的 RTM

传统流程：
  需求 → 设计 → 编码 → [补测试] → 发布
                         ↑
                    测试是事后补充，覆盖率低

Spec 驱动流程：
  需求(AC) → 设计(属性) → 任务(含测试任务) → 编码+测试 → 发布
    ↓            ↓              ↓
  测试种子    测试属性       测试代码
                    ↑
              测试从第一步就开始规划，覆盖率高

┌─────────────────────────────────────────────────────────────┐
│                 Kiro Spec 驱动测试三阶段                      │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  阶段 1：Requirements（需求文档）                             │
│  ┌─────────────────────────────────────────────────────┐   │
│  │ requirements.md                                      │   │
│  │                                                      │   │
│  │ ## Requirement 1: 用户注册                            │   │
│  │ ### Acceptance Criteria                               │   │
│  │ 1.1 WHEN 用户提交有效信息, SHALL 创建账户              │   │
│  │ 1.2 WHEN 邮箱已存在, SHALL 返回 409                   │   │
│  │ 1.3 WHEN 密码少于 8 字符, SHALL 返回 400              │   │
│  │                                                      │   │
│  │ → 验收标准 = 测试用例的种子                            │   │
│  └─────────────────────────────────────────────────────┘   │
│                          │                                  │
│                          ▼                                  │
│  阶段 2：Design（设计文档）                                  │
│  ┌─────────────────────────────────────────────────────┐   │
│  │ design.md                                            │   │
│  │                                                      │   │
│  │ ## Correctness Properties                             │   │
│  │ Property 1: 注册幂等性                                │   │
│  │   FORALL input: ValidRegistration                     │   │
│  │   register(input) 成功后, register(input) 返回 409    │   │
│  │   Validates: Requirement 1.1, 1.2                     │   │
│  │                                                      │   │
│  │ → 正确性属性 = PBT 测试的规格                          │   │
│  └─────────────────────────────────────────────────────┘   │
│                          │                                  │
│                          ▼                                  │
│  阶段 3：Tasks（任务列表）                                   │
│  ┌─────────────────────────────────────────────────────┐   │
│  │ tasks.md                                             │   │
│  │                                                      │   │
│  │ - [ ] 2.1 编写用户注册单元测试                         │   │
│  │   - 覆盖 AC 1.1-1.3                                  │   │
│  │   - _Requirements: 1.1, 1.2, 1.3_                    │   │
│  │ - [ ] 2.2 编写用户注册 PBT                            │   │
│  │   - 实现 Property 1（注册幂等性）                      │   │
│  │   - _Requirements: 1.1, 1.2_                          │   │
│  │                                                      │   │
│  │ → 测试任务 = 可执行的测试开发计划                       │   │
│  └─────────────────────────────────────────────────────┘   │
│                                                             │
└─────────────────────────────────────────────────────────────┘

// AI 从 requirements.md 的 AC 1.1 自动生成
// Validates: AC-1.1 WHEN 用户提交有效信息, SHALL 创建账户
describe('用户注册 - AC-1.1', () => {
  it('should create user account with valid registration info', async () => {
    // Arrange
    const validInput = {
      email: 'alice@example.com',
      password: 'securePass123',
      name: 'Alice',
    };
 
    // Act
    const result = await registerUser(validInput);
 
    // Assert
    expect(result.id).toBeDefined();
    expect(result.email).toBe('alice@example.com');
    expect(result.name).toBe('Alice');
  });
});

import { fc } from 'fast-check';
 
// AI 从 design.md 的 Property 1 自动生成
// Validates: Property 1 - 注册幂等性
// Validates: Requirements 1.1, 1.2
describe('Property: 注册幂等性', () => {
  it('should return 409 when registering with same email twice', () => {
    fc.assert(
      fc.asyncProperty(
        fc.record({
          email: fc.emailAddress(),
          password: fc.string({ minLength: 8, maxLength: 64 }),
          name: fc.string({ minLength: 1, maxLength: 100 }),
        }),
        async (input) => {
          // 第一次注册应该成功
          const first = await registerUser(input);
          expect(first.id).toBeDefined();
 
          // 第二次注册应该返回 409
          await expect(registerUser(input)).rejects.toThrow(/already exists/);
        }
      ),
      { numRuns: 100 }
    );
  });
});

# tasks.md 中的测试任务追踪
 
- [x] 2.1 编写用户注册单元测试 ✅
  - 覆盖 AC 1.1-1.3
  - _Requirements: 1.1, 1.2, 1.3_
 
- [x] 2.2 编写用户注册 PBT ✅ (passed)
  - 实现 Property 1（注册幂等性）
  - _Requirements: 1.1, 1.2_

基于以下 Kiro Spec 文档生成完整的测试套件：

## requirements.md（验收标准）
[粘贴相关的验收标准]

## design.md（正确性属性）
[粘贴相关的正确性属性]

## tasks.md（测试任务）
[粘贴当前要实现的测试任务]

## 源代码
[粘贴被测试的源代码]

要求：
1. 为每条 AC 生成至少一个 example-based 测试
2. 为每个 Correctness Property 生成一个 PBT
3. 每个测试标注：
   - // Validates: AC-X.Y [描述]
   - // Validates: Property N [描述]
   - // Validates: Requirements X.Y
4. PBT 使用 [fast-check/Hypothesis] 框架
5. 生成器智能约束输入空间
6. 测试文件命名遵循项目约定
7. 生成追溯矩阵摘要

BDD 工作流中的 AI 角色

┌──────────────┐     ┌──────────────┐     ┌──────────────┐
│  需求/用户故事 │     │  AI 转化      │     │  Gherkin      │
│              │     │              │     │  Feature 文件  │
│ "用户可以用   │────→│ 解析意图      │────→│ Feature: 优惠券│
│  优惠券下单"  │     │ 枚举场景      │     │  Scenario: ... │
│              │     │ 生成步骤      │     │  Given ...     │
│              │     │ 识别边界      │     │  When ...      │
└──────────────┘     └──────────────┘     │  Then ...      │
                                          └──────┬───────┘
                                                  │
                                          ┌──────┴───────┐
                                          │  Step 定义    │
                                          │  (自动化代码)  │
                                          └──────────────┘

# Gherkin 核心语法
 
Feature: 功能名称
  功能描述（可选）
 
  Background: 前置条件（所有场景共享）
    Given 共享的前置条件
 
  Scenario: 场景名称
    Given 前置条件（准备状态）
    And 额外的前置条件
    When 触发动作
    And 额外的动作
    Then 预期结果
    And 额外的预期结果
    But 不应该发生的事情
 
  Scenario Outline: 参数化场景
    Given 前置条件 "<参数1>"
    When 触发动作 "<参数2>"
    Then 预期结果 "<参数3>"
 
    Examples:
      | 参数1 | 参数2 | 参数3 |
      | 值1   | 值2   | 值3   |
      | 值4   | 值5   | 值6   |
 
  @tag1 @tag2
  Scenario: 带标签的场景
    ...

# AI 生成的 Feature 文件示例
# 来源：用户故事 "用户可以使用优惠券下单"
 
Feature: 优惠券应用
  作为一个电商用户
  我希望能够在结算时使用优惠券
  以便享受折扣优惠
 
  Background:
    Given 用户已登录
    And 购物车中有商品
 
  @happy-path @P0
  Scenario: 成功应用有效优惠券
    Given 用户有一张有效的优惠券 "SAVE20"
    And 优惠券折扣为 20%
    And 购物车总金额为 200 元
    And 购物车金额满足最低消费 100 元
    When 用户在结算页面输入优惠券码 "SAVE20"
    Then 系统应显示折扣金额 40 元
    And 应付金额应为 160 元
 
  @error-handling @P0
  Scenario: 使用过期优惠券
    Given 用户有一张已过期的优惠券 "EXPIRED10"
    When 用户在结算页面输入优惠券码 "EXPIRED10"
    Then 系统应显示错误提示 "优惠券已过期"
    And 订单金额不应变化
 
  @boundary @P0
  Scenario Outline: 最低消费门槛验证
    Given 用户有一张最低消费 <门槛> 元的优惠券
    And 购物车总金额为 <金额> 元
    When 用户尝试应用优惠券
    Then 系统应 <结果>
 
    Examples:
      | 门槛 | 金额 | 结果                              |
      | 100  | 99   | 显示 "未达到最低消费 ¥100"         |
      | 100  | 100  | 成功应用优惠券                     |
      | 100  | 101  | 成功应用优惠券                     |
      | 200  | 150  | 显示 "未达到最低消费 ¥200"         |
 
  @business-rule @P0
  Scenario: 单券限制
    Given 用户已应用优惠券 "SAVE20"
    When 用户尝试再应用优惠券 "SAVE10"
    Then 系统应显示提示 "每个订单只能使用一张优惠券"
    And 原优惠券 "SAVE20" 应保持生效
 
  @edge-case @P1
  Scenario: 部分商品不参与优惠
    Given 购物车中有参与优惠的商品总价 150 元
    And 购物车中有不参与优惠的商品总价 50 元
    And 用户有一张 10% 折扣优惠券
    When 用户应用优惠券
    Then 折扣应仅基于参与优惠的商品计算
    And 折扣金额应为 15 元
    And 应付金额应为 185 元

// AI 生成的 Step 定义（Playwright BDD 示例）
import { Given, When, Then } from '@cucumber/cucumber';
import { expect } from '@playwright/test';
 
// Validates: AC-1.1
Given('用户有一张有效的优惠券 {string}', async function (couponCode: string) {
  this.coupon = await createTestCoupon({
    code: couponCode,
    status: 'active',
    expiresAt: new Date(Date.now() + 86400000), // 明天过期
  });
});
 
Given('优惠券折扣为 {int}%', async function (discount: number) {
  this.coupon.discountPercent = discount;
  await updateCoupon(this.coupon);
});
 
Given('购物车总金额为 {int} 元', async function (amount: number) {
  await setCartTotal(this.userId, amount);
});
 
// Validates: AC-1.1
When('用户在结算页面输入优惠券码 {string}', async function (code: string) {
  await this.page.goto('/checkout');
  await this.page.fill('[data-testid="coupon-input"]', code);
  await this.page.click('[data-testid="apply-coupon"]');
});
 
// Validates: AC-1.1
Then('系统应显示折扣金额 {int} 元', async function (discount: number) {
  const discountText = await this.page.textContent('[data-testid="discount-amount"]');
  expect(discountText).toContain(`¥${discount}`);
});
 
Then('应付金额应为 {int} 元', async function (total: number) {
  const totalText = await this.page.textContent('[data-testid="total-amount"]');
  expect(totalText).toContain(`¥${total}`);
});
 
// Validates: AC-1.2
Then('系统应显示错误提示 {string}', async function (message: string) {
  const error = await this.page.textContent('[data-testid="coupon-error"]');
  expect(error).toContain(message);
});

// cucumber.json 配置
{
  "default": {
    "paths": ["features/**/*.feature"],
    "require": ["step-definitions/**/*.ts"],
    "format": [
      "progress-bar",
      "json:reports/cucumber-report.json",
      "html:reports/cucumber-report.html"
    ],
    "publishQuiet": true
  }
}

你是一个 BDD 专家。请将以下需求转化为 Gherkin Feature 文件。

## 需求/用户故事
[粘贴需求文档]

## 生成要求
1. Feature 文件结构：
   - Feature 描述使用"作为...我希望...以便..."格式
   - 使用 Background 提取共享前置条件
   - 使用 Scenario Outline + Examples 参数化相似场景

2. 场景覆盖：
   - Happy Path（正常路径）：至少 2 个
   - Error Handling（错误处理）：至少 2 个
   - Boundary（边界值）：至少 1 个 Scenario Outline
   - Edge Case（边缘情况）：至少 1 个

3. 标签规范：
   - @happy-path / @error-handling / @boundary / @edge-case
   - @P0 / @P1 / @P2（优先级）
   - @smoke（冒烟测试场景）
   - @regression（回归测试场景）

4. 步骤编写规范：
   - Given：描述前置状态，使用过去时或现在时
   - When：描述触发动作，使用现在时
   - Then：描述预期结果，使用"应"/"应该"
   - 避免在步骤中包含实现细节（如 CSS 选择器）
   - 步骤要可复用（参数化）

5. 每个 Scenario 标注对应的 AC 编号

基于以下 Gherkin Feature 文件，生成 Step 定义代码。

## Feature 文件
[粘贴 .feature 文件内容]

## 技术栈
- BDD 框架：[Cucumber/SpecFlow/Behave]
- 测试框架：[Playwright/Cypress/Selenium]
- 语言：[TypeScript/Python/C#]

## 生成要求
1. 每个 Step 定义标注对应的 AC 编号
2. 使用 Page Object 模式（如涉及 UI）
3. 参数化步骤使用正确的类型转换
4. 包含 setup/teardown 逻辑
5. 使用 data-testid 属性定位元素（避免脆弱选择器）
6. 异步步骤使用 async/await
7. 包含合理的等待策略（避免硬编码 sleep）

代码覆盖率 vs 需求覆盖率

代码覆盖率（Code Coverage）：
  ┌────────────────────────────────┐
  │ 源代码                          │
  │ ████████████░░░░░░░░           │  80% 行覆盖
  │ ████████░░░░░░░░░░░            │  60% 分支覆盖
  └────────────────────────────────┘
  回答：多少代码被执行了？
  局限：100% 代码覆盖 ≠ 所有需求都被验证了

需求覆盖率（Requirements Coverage）：
  ┌────────────────────────────────┐
  │ 需求/验收标准                    │
  │ AC-1.1 ✅  AC-1.2 ✅  AC-1.3 ❌│  67% 需求覆盖
  │ AC-2.1 ✅  AC-2.2 ⚠️  AC-2.3 ✅│  83% 需求覆盖
  └────────────────────────────────┘
  回答：多少需求被验证了？
  价值：直接反映业务风险

需求覆盖率 = 已覆盖的 AC 数量 / 总 AC 数量 × 100%

其中"已覆盖"的定义：
- 至少有 1 个测试用例验证该 AC
- 该测试用例当前状态为"通过"
- 测试用例标注了对应的 AC 编号（可追溯）

加权需求覆盖率（考虑优先级）：
  = (P0 已覆盖 × 3 + P1 已覆盖 × 2 + P2 已覆盖 × 1)
    / (P0 总数 × 3 + P1 总数 × 2 + P2 总数 × 1) × 100%

┌─────────────────────────────────────────────────────────────┐
│                    需求覆盖率仪表板                            │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  总体覆盖率                                                  │
│  ████████████████████░░░░░  82%  (41/50 AC)                │
│                                                             │
│  按优先级                                                    │
│  P0: ████████████████████████  96%  (24/25 AC)  ← 关注！    │
│  P1: ████████████████░░░░░░░  72%  (13/18 AC)              │
│  P2: ██████████░░░░░░░░░░░░  57%  (4/7 AC)                │
│                                                             │
│  按模块                                                      │
│  用户管理:  ████████████████████████  100%                   │
│  订单系统:  ████████████████████░░░░  85%                    │
│  支付模块:  ████████████████░░░░░░░░  70%   ← 风险！        │
│  优惠券:    ████████████░░░░░░░░░░░░  55%   ← 高风险！      │
│                                                             │
│  未覆盖的 P0 需求（需立即处理）                                │
│  ⚠️ AC-3.5: 支付超时处理                                    │
│                                                             │
│  代码覆盖率 vs 需求覆盖率                                     │
│  代码覆盖率:  ████████████████████████  88%                  │
│  需求覆盖率:  ████████████████████░░░░  82%                  │
│  差距分析: 6% 的代码被测试但未关联到需求                        │
│                                                             │
└─────────────────────────────────────────────────────────────┘

// 在每个测试中标注对应的 AC
describe('优惠券应用', () => {
  // Validates: AC-1.1 成功应用有效优惠券
  it('should apply valid coupon and calculate discount', () => { ... });
 
  // Validates: AC-1.2 过期优惠券
  it('should reject expired coupon', () => { ... });
 
  // Validates: AC-1.4 单券限制
  // Validates: Property 1 - 单券不变量
  it('should enforce single coupon per order', () => { ... });
});

// scripts/requirements-coverage.ts
// 从测试文件中提取 "Validates: AC-X.Y" 注释，生成覆盖率报告
 
import * as fs from 'fs';
import * as path from 'path';
import { glob } from 'glob';
 
interface CoverageEntry {
  acId: string;
  testFile: string;
  testName: string;
  status: 'passed' | 'failed' | 'skipped';
}
 
async function extractCoverage(): Promise<CoverageEntry[]> {
  const testFiles = await glob('**/*.test.ts', { ignore: 'node_modules/**' });
  const entries: CoverageEntry[] = [];
 
  for (const file of testFiles) {
    const content = fs.readFileSync(file, 'utf-8');
    const lines = content.split('\n');
 
    for (let i = 0; i < lines.length; i++) {
      const match = lines[i].match(/\/\/\s*Validates:\s*(AC-[\d.]+)/);
      if (match) {
        // 查找下一个 it/test 块
        for (let j = i + 1; j < lines.length; j++) {
          const testMatch = lines[j].match(/(?:it|test)\s*\(\s*['"`](.+?)['"`]/);
          if (testMatch) {
            entries.push({
              acId: match[1],
              testFile: file,
              testName: testMatch[1],
              status: 'passed', // 从测试结果 JSON 中获取实际状态
            });
            break;
          }
        }
      }
    }
  }
 
  return entries;
}
 
async function generateReport() {
  const coverage = await extractCoverage();
 
  // 从 requirements.md 提取所有 AC
  const allACs = extractACsFromRequirements('requirements.md');
 
  // 生成覆盖率报告
  const covered = new Set(coverage.map(e => e.acId));
  const uncovered = allACs.filter(ac => !covered.has(ac.id));
 
  console.log(`\n📊 需求覆盖率报告`);
  console.log(`总 AC 数: ${allACs.length}`);
  console.log(`已覆盖: ${covered.size}`);
  console.log(`未覆盖: ${uncovered.length}`);
  console.log(`覆盖率: ${((covered.size / allACs.length) * 100).toFixed(1)}%`);
 
  if (uncovered.length > 0) {
    console.log(`\n⚠️ 未覆盖的验收标准:`);
    uncovered.forEach(ac => {
      console.log(`  - ${ac.id}: ${ac.description} [${ac.priority}]`);
    });
  }
}
 
generateReport();

# .github/workflows/requirements-coverage.yml
name: Requirements Coverage Check
 
on: [pull_request]
 
jobs:
  coverage:
    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 --reporter=json --outputFile=test-results.json
      - run: npx tsx scripts/requirements-coverage.ts
      - name: Check P0 Coverage
        run: |
          # 确保所有 P0 需求都被覆盖
          UNCOVERED_P0=$(npx tsx scripts/check-p0-coverage.ts)
          if [ -n "$UNCOVERED_P0" ]; then
            echo "❌ 以下 P0 需求未被测试覆盖："
            echo "$UNCOVERED_P0"
            exit 1
          fi

分析以下项目的需求覆盖率：

## 验收标准列表
[粘贴所有 AC，含编号和优先级]

## 测试文件列表
[粘贴测试文件名和包含的 "Validates: AC-X.Y" 注释]

## 测试运行结果
[粘贴测试运行结果摘要]

请生成：
1. 需求覆盖率报告（总体 + 按优先级 + 按模块）
2. 未覆盖的 AC 列表（按优先级排序）
3. 过度测试的 AC（测试用例 > 5 个的）
4. 风险评估（未覆盖的 P0 需求）
5. 建议补充的测试（优先级排序）
6. 代码覆盖率 vs 需求覆盖率的差距分析

┌─────────────────────────────────────────────────────────────────────┐
│                CI/CD 中的需求→测试自动化管线                          │
├─────────────────────────────────────────────────────────────────────┤
│                                                                     │
│  触发器                                                              │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐          │
│  │ PR 提交   │  │ 需求变更  │  │ 定时触发  │  │ 手动触发  │          │
│  └────┬─────┘  └────┬─────┘  └────┬─────┘  └────┬─────┘          │
│       │              │              │              │                │
│       └──────────────┴──────────────┴──────────────┘                │
│                              │                                      │
│                              ▼                                      │
│  阶段 1：需求同步                                                    │
│  ┌──────────────────────────────────────────────────────────┐      │
│  │ • 从 Jira/Spec 拉取最新需求和 AC                          │      │
│  │ • 检测需求变更（新增/修改/删除）                            │      │
│  │ • 生成需求变更报告                                         │      │
│  └──────────────────────────────────────────────────────────┘      │
│                              │                                      │
│                              ▼                                      │
│  阶段 2：测试生成/更新                                               │
│  ┌──────────────────────────────────────────────────────────┐      │
│  │ • AI 分析需求变更影响                                      │      │
│  │ • 自动生成新测试 / 更新现有测试                             │      │
│  │ • 生成测试变更 PR（人工审查）                               │      │
│  └──────────────────────────────────────────────────────────┘      │
│                              │                                      │
│                              ▼                                      │
│  阶段 3：测试执行                                                    │
│  ┌──────────────────────────────────────────────────────────┐      │
│  │ • 运行单元测试 + PBT                                      │      │
│  │ • 运行集成测试                                             │      │
│  │ • 运行 E2E 测试（BDD Gherkin）                            │      │
│  │ • 收集测试结果                                             │      │
│  └──────────────────────────────────────────────────────────┘      │
│                              │                                      │
│                              ▼                                      │
│  阶段 4：覆盖率分析                                                  │
│  ┌──────────────────────────────────────────────────────────┐      │
│  │ • 计算代码覆盖率                                          │      │
│  │ • 计算需求覆盖率                                          │      │
│  │ • 更新 RTM                                               │      │
│  │ • 生成覆盖率报告                                          │      │
│  └──────────────────────────────────────────────────────────┘      │
│                              │                                      │
│                              ▼                                      │
│  阶段 5：质量门                                                      │
│  ┌──────────────────────────────────────────────────────────┐      │
│  │ • P0 需求覆盖率 ≥ 95%？                                   │      │
│  │ • 代码覆盖率 ≥ 80%？                                      │      │
│  │ • 所有 P0 测试通过？                                      │      │
│  │ • 无新增未覆盖的 P0 需求？                                 │      │
│  │ → 通过：允许合并                                          │      │
│  │ → 失败：阻止合并 + 通知团队                                │      │
│  └──────────────────────────────────────────────────────────┘      │
│                                                                     │
└─────────────────────────────────────────────────────────────────────┘

# .github/workflows/requirements-to-test.yml
name: Requirements-to-Test Pipeline
 
on:
  pull_request:
    paths:
      - 'requirements/**'
      - 'src/**'
      - 'tests/**'
      - '.kiro/specs/**'
  schedule:
    - cron: '0 6 * * 1'  # 每周一早上 6 点运行完整检查
 
jobs:
  # 阶段 1：需求变更检测
  detect-changes:
    runs-on: ubuntu-latest
    outputs:
      requirements-changed: ${{ steps.changes.outputs.requirements }}
      code-changed: ${{ steps.changes.outputs.code }}
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - uses: dorny/paths-filter@v3
        id: changes
        with:
          filters: |
            requirements:
              - 'requirements/**'
              - '.kiro/specs/**/requirements.md'
            code:
              - 'src/**'
 
  # 阶段 2：测试执行
  test:
    runs-on: ubuntu-latest
    needs: detect-changes
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '22'
          cache: 'npm'
      - run: npm ci
 
      # 运行单元测试 + PBT
      - name: Run Unit Tests & PBT
        run: npx vitest run --coverage --reporter=json --outputFile=test-results.json
 
      # 运行 BDD 测试
      - name: Run BDD Tests
        run: npx cucumber-js --format json:reports/bdd-results.json
 
      # 上传测试结果
      - uses: actions/upload-artifact@v4
        with:
          name: test-results
          path: |
            test-results.json
            reports/
            coverage/
 
  # 阶段 3：需求覆盖率分析
  requirements-coverage:
    runs-on: ubuntu-latest
    needs: test
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '22'
          cache: 'npm'
      - run: npm ci
 
      - uses: actions/download-artifact@v4
        with:
          name: test-results
 
      # 生成需求覆盖率报告
      - name: Generate Requirements Coverage
        run: npx tsx scripts/requirements-coverage.ts > coverage-report.md
 
      # 质量门检查
      - name: Quality Gate - P0 Coverage
        run: |
          P0_COVERAGE=$(npx tsx scripts/p0-coverage-check.ts)
          echo "P0 需求覆盖率: $P0_COVERAGE%"
          if [ $(echo "$P0_COVERAGE < 95" | bc) -eq 1 ]; then
            echo "❌ P0 需求覆盖率低于 95%"
            exit 1
          fi
 
      # PR 评论
      - name: Comment PR with Coverage
        if: github.event_name == 'pull_request'
        uses: actions/github-script@v7
        with:
          script: |
            const fs = require('fs');
            const report = fs.readFileSync('coverage-report.md', 'utf8');
            github.rest.issues.createComment({
              issue_number: context.issue.number,
              owner: context.repo.owner,
              repo: context.repo.repo,
              body: `## 📊 需求覆盖率报告\n\n${report}`
            });
 
  # 阶段 4：RTM 更新（仅在需求变更时）
  update-rtm:
    runs-on: ubuntu-latest
    needs: [detect-changes, requirements-coverage]
    if: needs.detect-changes.outputs.requirements-changed == 'true'
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '22'
      - run: npm ci
 
      - name: Update RTM
        run: npx tsx scripts/update-rtm.ts
 
      - name: Commit RTM Update
        run: |
          git config user.name "github-actions[bot]"
          git config user.email "github-actions[bot]@users.noreply.github.com"
          git add docs/rtm.md
          git diff --staged --quiet || git commit -m "chore: update RTM [automated]"
          git push

# .kiro/hooks/requirements-sync.yaml
# 需求文件变更时自动检查测试覆盖
trigger: onFileEdited
pattern: ".kiro/specs/**/requirements.md"
action: askAgent
prompt: |
  需求文件已更新。请执行以下操作：
  1. 分析需求变更（新增/修改/删除的 AC）
  2. 检查现有测试是否覆盖了变更的 AC
  3. 如果有未覆盖的新 AC，生成测试骨架
  4. 更新 RTM 文档
  5. 报告覆盖率变化

# .kiro/hooks/test-traceability.yaml
# 测试文件变更时检查追溯标注
trigger: onFileEdited
pattern: "**/*.test.ts"
action: askAgent
prompt: |
  测试文件已更新。请检查：
  1. 所有新增的测试是否包含 "Validates: AC-X.Y" 注释
  2. 追溯标注是否指向有效的 AC 编号
  3. 是否有 AC 的测试被意外删除
  如果发现问题，请提醒开发者补充追溯标注。

// scripts/quality-gate.ts
// 需求→测试管线的质量门检查
 
interface QualityGateConfig {
  p0CoverageThreshold: number;    // P0 需求覆盖率阈值
  overallCoverageThreshold: number; // 总体需求覆盖率阈值
  codeCoverageThreshold: number;   // 代码覆盖率阈值
  maxUncoveredP0: number;          // 允许的最大未覆盖 P0 数量
  requireTraceability: boolean;    // 是否要求所有测试有追溯标注
}
 
const defaultConfig: QualityGateConfig = {
  p0CoverageThreshold: 95,
  overallCoverageThreshold: 80,
  codeCoverageThreshold: 80,
  maxUncoveredP0: 0,
  requireTraceability: true,
};
 
async function checkQualityGate(config: QualityGateConfig = defaultConfig) {
  const results = {
    passed: true,
    checks: [] as { name: string; passed: boolean; message: string }[],
  };
 
  // 检查 1：P0 需求覆盖率
  const p0Coverage = await calculateP0Coverage();
  results.checks.push({
    name: 'P0 需求覆盖率',
    passed: p0Coverage >= config.p0CoverageThreshold,
    message: `${p0Coverage}% (阈值: ${config.p0CoverageThreshold}%)`,
  });
 
  // 检查 2：总体需求覆盖率
  const overallCoverage = await calculateOverallCoverage();
  results.checks.push({
    name: '总体需求覆盖率',
    passed: overallCoverage >= config.overallCoverageThreshold,
    message: `${overallCoverage}% (阈值: ${config.overallCoverageThreshold}%)`,
  });
 
  // 检查 3：代码覆盖率
  const codeCoverage = await getCodeCoverage();
  results.checks.push({
    name: '代码覆盖率',
    passed: codeCoverage >= config.codeCoverageThreshold,
    message: `${codeCoverage}% (阈值: ${config.codeCoverageThreshold}%)`,
  });
 
  // 检查 4：追溯标注完整性
  if (config.requireTraceability) {
    const untracedTests = await findUntracedTests();
    results.checks.push({
      name: '追溯标注完整性',
      passed: untracedTests.length === 0,
      message: untracedTests.length === 0
        ? '所有测试都有追溯标注'
        : `${untracedTests.length} 个测试缺少追溯标注`,
    });
  }
 
  results.passed = results.checks.every(c => c.passed);
  return results;
}

为以下项目生成需求→测试自动化的 CI/CD 管线配置：

## 项目信息
- CI/CD 平台：[GitHub Actions/GitLab CI/Jenkins]
- 测试框架：[Vitest/Jest/Pytest]
- BDD 框架：[Cucumber/Behave]（如使用）
- 需求管理：[Kiro Specs/Jira/Markdown]
- 部署平台：[Vercel/AWS/GCP]

## 管线要求
1. PR 触发：运行测试 + 需求覆盖率检查
2. 需求变更触发：影响分析 + 测试更新建议
3. 定时触发：完整覆盖率报告
4. 质量门：
   - P0 需求覆盖率 ≥ [阈值]%
   - 代码覆盖率 ≥ [阈值]%
   - 所有测试有追溯标注
5. 报告：PR 评论 + 仪表板更新

请生成：
1. 完整的 CI/CD 配置文件
2. 需求覆盖率计算脚本
3. 质量门检查脚本
4. RTM 自动更新脚本

## Requirement 1: 订单创建
 
### Acceptance Criteria
1.1 WHEN 用户提交包含有效商品和地址的订单,
    THE 系统 SHALL 创建订单并返回订单号
1.2 WHEN 订单中的商品库存不足,
    THE 系统 SHALL 返回库存不足错误并标明具体商品
1.3 THE 系统 SHALL 确保订单总金额等于所有商品单价×数量之和
1.4 IF 支付网关超时,
    THEN THE 系统 SHALL 将订单标记为"待支付"并在 30 分钟后自动取消
1.5 WHEN 用户应用优惠券,
    THE 系统 SHALL 验证优惠券有效性并计算折扣

## Correctness Properties
 
Property 1: 订单金额一致性
  FORALL items: NonEmptyList<OrderItem>
  calculateTotal(items) == sum(items.map(i => i.price * i.quantity))
  Validates: Requirement 1.3
 
Property 2: 库存扣减原子性
  FORALL order: ValidOrder
  createOrder(order) 成功 => 所有商品库存减少对应数量
  createOrder(order) 失败 => 所有商品库存不变
  Validates: Requirement 1.1, 1.2
 
Property 3: 优惠券单次使用
  FORALL coupon: ValidCoupon, order1: Order, order2: Order
  applyCoupon(order1, coupon) 成功后,
  applyCoupon(order2, coupon) 返回"优惠券已使用"
  Validates: Requirement 1.5

- [ ] 3.1 编写订单创建单元测试
  - 覆盖 AC 1.1-1.5 的 example-based 测试
  - _Requirements: 1.1, 1.2, 1.3, 1.4, 1.5_
 
- [ ] 3.2 编写订单创建 PBT
  - 实现 Property 1（订单金额一致性）
  - 实现 Property 2（库存扣减原子性）
  - 实现 Property 3（优惠券单次使用）
  - _Requirements: 1.1, 1.2, 1.3, 1.5_
 
- [ ] 3.3 编写订单创建 BDD 测试
  - 生成 Gherkin Feature 文件
  - 实现 Step 定义
  - _Requirements: 1.1, 1.2, 1.4, 1.5_

// tests/order/create-order.test.ts
import { describe, it, expect, beforeEach } from 'vitest';
import { createOrder, OrderInput } from '../../src/services/order';
 
describe('订单创建', () => {
  // Validates: AC-1.1 有效订单创建
  it('should create order with valid items and address', async () => {
    const input: OrderInput = {
      items: [
        { productId: 'P001', quantity: 2, price: 99.9 },
        { productId: 'P002', quantity: 1, price: 199.0 },
      ],
      address: { city: '北京', street: '朝阳区xxx路', zip: '100000' },
    };
 
    const order = await createOrder(input);
 
    expect(order.id).toBeDefined();
    expect(order.status).toBe('created');
    expect(order.total).toBe(398.8); // 99.9*2 + 199.0
  });
 
  // Validates: AC-1.2 库存不足
  it('should return stock error when inventory insufficient', async () => {
    const input: OrderInput = {
      items: [{ productId: 'P003', quantity: 999, price: 10 }],
      address: { city: '上海', street: 'xxx路', zip: '200000' },
    };
 
    await expect(createOrder(input)).rejects.toThrow(/库存不足/);
  });
 
  // Validates: AC-1.4 支付超时
  it('should mark order as pending and auto-cancel after 30min', async () => {
    // ... 测试支付超时逻辑
  });
});

// tests/order/create-order.property.test.ts
import { describe, it, expect } from 'vitest';
import { fc } from 'fast-check';
import { calculateTotal, OrderItem } from '../../src/services/order';
 
// Validates: Property 1 - 订单金额一致性
// Validates: Requirements 1.3
describe('Property: 订单金额一致性', () => {
  const orderItemArb = fc.record({
    productId: fc.string({ minLength: 1, maxLength: 20 }),
    quantity: fc.integer({ min: 1, max: 100 }),
    price: fc.double({ min: 0.01, max: 99999.99, noNaN: true }),
  });
 
  it('total should equal sum of item prices × quantities', () => {
    fc.assert(
      fc.property(
        fc.array(orderItemArb, { minLength: 1, maxLength: 20 }),
        (items: OrderItem[]) => {
          const total = calculateTotal(items);
          const expected = items.reduce(
            (sum, item) => sum + item.price * item.quantity,
            0
          );
          // 使用近似比较处理浮点精度
          expect(Math.abs(total - expected)).toBeLessThan(0.01);
        }
      ),
      { numRuns: 200 }
    );
  });
});