功能测试计划模板：把风险映射到证据

## ❌ 反面示例：没有风险映射的测试计划
 
### 测试范围
- 支付流程
- 订单管理
- 退款功能
- 用户界面
 
### 测试类型
- 单元测试：覆盖核心逻辑
- 集成测试：覆盖 API
- E2E 测试：覆盖主要流程
- 回归测试：覆盖历史 bug

## ✅ 正面示例：风险驱动的测试计划
 
### 风险清单与证据映射
 
| 风险项 | RPN | 覆盖层级 | 具体证据 | 负责人 |
|--------|-----|---------|---------|--------|
| 支付回调签名验证失败 | 9×5×6=270 | 单元+集成 | `payment-callback.test.ts` + 契约测试 | 后端 A |
| 重复支付导致重复扣款 | 10×4×7=280 | 单元+E2E | `deduplication.test.ts` + 支付 E2E 场景 3 | 后端 B |
| 退款金额超过原订单 | 9×3×5=135 | 单元 | `refund-amount.test.ts` | 后端 A |
| 支付超时后状态不一致 | 8×6×8=384 | 集成+E2E | `timeout-reconcile.test.ts` + 超时 E2E 场景 | 后端 B |
| 支付页 loading 状态展示错误 | 3×7×3=63 | 浏览器验收 | 人工验收 checklist #2 | 前端 |
| 退款到账后邮件通知未发送 | 5×5×4=100 | 集成 | `notification.test.ts` | 后端 A |
 
### 不覆盖范围及原因
- 第三方支付网关内部逻辑（依赖 Stripe 自身的 SLA）
- 极端并发场景（首期流量预估不涉及，二期补压测）

// ✅ 正面：用类型定义驱动风险矩阵，确保每条风险都有覆盖
interface RiskItem {
  id: string
  description: string
  severity: number    // 1-10
  likelihood: number  // 1-10
  detectability: number // 1-10
  rpn: number
  testLayer: 'unit' | 'integration' | 'e2e' | 'browser' | 'manual'
  testFile: string    // 对应的测试文件或验收项
  owner: string
}
 
const paymentRisks: RiskItem[] = [
  {
    id: 'PAY-001',
    description: '支付回调签名验证失败',
    severity: 9,
    likelihood: 5,
    detectability: 6,
    rpn: 9 * 5 * 6, // 270
    testLayer: 'unit',
    testFile: 'tests/payment-callback.test.ts',
    owner: '后端 A',
  },
  {
    id: 'PAY-002',
    description: '重复支付导致重复扣款',
    severity: 10,
    likelihood: 4,
    detectability: 7,
    rpn: 10 * 4 * 7, // 280
    testLayer: 'e2e',
    testFile: 'tests/e2e/payment-dedup.spec.ts',
    owner: '后端 B',
  },
]
 
// 发布前校验：每条高风险项必须有对应测试
function validateCoverage(risks: RiskItem[], threshold = 150) {
  return risks
    .filter((r) => r.rpn >= threshold)
    .map((r) => ({
      id: r.id,
      covered: fileExists(r.testFile),
      rpn: r.rpn,
    }))
}

// ❌ 反面：风险项散落在文档里，没有结构化，发布前无法自动校验
// 以下信息只存在于 Confluence 页面的一个表格里
const risks = [
  { name: '支付回调问题', test: '应该测一下' },
  { name: '重复扣款', test: 'E2E 覆盖' },
  // 没有 RPN、没有文件路径、没有负责人
  // 发布前无法程序化检查覆盖情况
]

### 权限系统分层测试策略
 
| 验证目标 | 测试层级 | 数量 | 说明 |
|---------|---------|------|------|
| 权限判断纯函数 | 单元测试 | ~80 | `hasPermission(role, action, resource)` 的各种组合 |
| 角色 CRUD API | 集成测试 | ~25 | 创建/编辑/删除角色的 API 契约和数据库一致性 |
| 权限分配后的 API 响应 | 集成测试 | ~30 | 分配权限后接口返回的数据是否正确 |
| 预设角色的关键路径 | E2E 测试 | ~10 | 管理员创建角色 → 分配权限 → 成员登录 → 验证可见菜单 |
| 自定义角色的关键路径 | E2E 测试 | ~5 | 自定义角色的完整创建到使用流程 |
| 菜单权限的视觉呈现 | 浏览器验收 | ~3 | 权限变更后的菜单显隐、禁用态 |

// ✅ 正面：纯函数单测，覆盖各种边界条件
import { hasPermission } from '@/core/permissions'
 
describe('hasPermission', () => {
  it('超级管理员拥有所有权限', () => {
    expect(hasPermission('admin', 'delete', 'user')).toBe(true)
    expect(hasPermission('admin', 'create', 'role')).toBe(true)
  })
 
  it('自定义角色只能访问已分配的权限', () => {
    const role = {
      name: 'editor',
      permissions: [
        { action: 'read', resource: 'article' },
        { action: 'write', resource: 'article' },
      ],
    }
    expect(hasPermission(role, 'read', 'article')).toBe(true)
    expect(hasPermission(role, 'delete', 'article')).toBe(false)
    expect(hasPermission(role, 'read', 'user')).toBe(false)
  })
 
  it('未分配任何权限的角色不能访问任何资源', () => {
    const emptyRole = { name: 'guest', permissions: [] }
    expect(hasPermission(emptyRole, 'read', 'article')).toBe(false)
  })
 
  it('权限判断区分 action 粒度', () => {
    const role = {
      name: 'viewer',
      permissions: [{ action: 'read', resource: 'report' }],
    }
    expect(hasPermission(role, 'read', 'report')).toBe(true)
    expect(hasPermission(role, 'export', 'report')).toBe(false)
  })
})

// ❌ 反面：把权限判断逻辑放在组件里测试，依赖完整渲染
// 测试慢、脆弱、出错时不知道是权限逻辑问题还是渲染问题
import { render, screen } from '@testing-library/react'
import { AdminPanel } from '@/components/AdminPanel'
 
test('admin can see delete button', async () => {
  render(<AdminPanel userRole="admin" />)
  // 依赖整个组件树渲染
  // 如果组件结构变了，测试就要改
  // 实际上权限判断逻辑和渲染无关
  const btn = await screen.findByText('删除')
  expect(btn).toBeVisible()
})

### 注册流程边界条件映射
 
| 边界条件 | 来源 | 测试层级 | 测试文件 | 状态 |
|---------|------|---------|---------|------|
| 手机号前后有空格 | 需求 1.3 节 | 单元测试 | `phone-validation.test.ts` | ✅ |
| 验证码过期后旧码不可用 | 需求 2.1 节 | 集成测试 | `sms-code-expire.test.ts` | ✅ |
| 密码不能包含手机号 | 需求 3.2 节 | 单元测试 | `password-strength.test.ts` | ✅ |
| 邀请码过期提示 | 需求 4.1 节 | E2E | `register-invite.spec.ts` | ✅ |
| 同一手机号 60 秒内重复发送 | 需求 2.3 节 | 集成测试 | `sms-rate-limit.test.ts` | ✅ |

// ✅ 正面：针对每个边界条件写独立测试，名称即文档
describe('手机号验证', () => {
  it('拒绝前后带空格的手机号', () => {
    expect(validatePhone(' 13800138000')).toBe(false)
    expect(validatePhone('13800138000 ')).toBe(false)
  })
 
  it('拒绝非 11 位号码', () => {
    expect(validatePhone('1380013800')).toBe(false)
    expect(validatePhone('138001380001')).toBe(false)
  })
 
  it('拒绝非大陆号段', () => {
    expect(validatePhone('12345678901')).toBe(false)
  })
 
  it('接受合法手机号', () => {
    expect(validatePhone('13800138000')).toBe(true)
    expect(validatePhone('15912345678')).toBe(true)
  })
})
 
describe('密码强度校验', () => {
  it('密码不能包含手机号', () => {
    const result = validatePassword('abc13800138000xyz', '13800138000')
    expect(result.valid).toBe(false)
    expect(result.reason).toContain('手机号')
  })
 
  it('密码长度至少 8 位', () => {
    expect(validatePassword('short', '13800138000').valid).toBe(false)
    expect(validatePassword('longEnough1!', '13800138000').valid).toBe(true)
  })
})

// ❌ 反面：一个巨型测试函数覆盖所有场景，出错时定位困难
test('注册流程验证', () => {
  // 手机号、验证码、密码、邀请码全搅在一起
  expect(register({ phone: '13800138000', password: 'test1234' })).toBeTruthy()
  expect(register({ phone: ' 13800138000' })).toBeFalsy()
  expect(register({ phone: '13800138000', inviteCode: 'EXPIRED' })).toBeFalsy()
  // 哪个条件失败？为什么失败？不知道
  // 新增边界条件时只能往这个 test 里堆
})

// ✅ 正面：风险评分结构化，可以程序化校验
type RiskLevel = 'critical' | 'high' | 'medium' | 'low'
 
function classifyRisk(rpn: number): RiskLevel {
  if (rpn >= 300) return 'critical'
  if (rpn >= 200) return 'high'
  if (rpn >= 100) return 'medium'
  return 'low'
}
 
function requiredLayers(level: RiskLevel): string[] {
  switch (level) {
    case 'critical':
      return ['unit', 'integration', 'e2e', 'monitoring']
    case 'high':
      return ['unit', 'integration']
    case 'medium':
      return ['unit']
    case 'low':
      return ['manual']
  }
}
 
// 使用示例
const risk = classifyRisk(270) // 'high'
const layers = requiredLayers(risk) // ['unit', 'integration']

// ❌ 反面：风险等级靠口头约定，没有量化标准
// 「这个风险比较高，多测一下」
// 多高算高？多测是测多少？每个人理解不同
function testRisk(riskName: string) {
  if (riskName.includes('支付')) return '测仔细点'
  if (riskName.includes('显示')) return '随便看看'
  // 没有量化，无法自动化校验
}

// ✅ 正面：发布前自动校验所有高风险项都有对应测试
import { existsSync } from 'node:fs'
import { join } from 'node:path'
 
interface RiskEntry {
  id: string
  rpn: number
  testFile: string
  testPassed: boolean
}
 
function preReleaseCheck(risks: RiskEntry[], rootDir: string) {
  const highRisks = risks.filter((r) => r.rpn >= 200)
  const results = highRisks.map((r) => {
    const filePath = join(rootDir, r.testFile)
    return {
      id: r.id,
      rpn: r.rpn,
      fileExists: existsSync(filePath),
      testPassed: r.testPassed,
    }
  })
 
  const uncovered = results.filter((r) => !r.fileExists)
  const failed = results.filter((r) => r.fileExists && !r.testPassed)
 
  if (uncovered.length > 0) {
    console.error(`❌ 未覆盖的高风险项: ${uncovered.map((r) => r.id).join(', ')}`)
  }
  if (failed.length > 0) {
    console.error(`❌ 测试未通过的高风险项: ${failed.map((r) => r.id).join(', ')}`)
  }
 
  const canRelease = uncovered.length === 0 && failed.length === 0
  console.log(canRelease ? '✅ 高风险项全部覆盖且通过' : '🚫 发布阻塞')
  return canRelease
}

// ❌ 反面：发布前靠人工确认，容易遗漏
// 在 Slack 里问一句「测试都过了吗」然后有人说「过了」就上线
// 没有程序化校验，没有审计记录
async function manualReleaseCheck() {
  // 打开 Confluence 页面
  // 逐条对比测试计划和测试结果
  // 手动标记哪些通过哪些没通过
  // 祈祷没有漏看
  console.log('人工检查完毕，应该可以发布')
}