# 测试计划正反例

正例展示测试必须可执行且可追踪；命令、数据和证据等级必须来自当前工程。本例采用 HTTP API 与关系型存储，不代表其他项目也应采用。

## 正例

| 场景 | 关联 | 类型 | 数据 | 断言 | 证据 |
|---|---|---|---|---|---|
| 首次创建订单 | `REQ-014/SLC-03` | 正常/集成 | 新用户、单商品有库存 | HTTP 201 且一笔订单 | 测试命令输出与数据库查询 |
| 同键并发提交 | `REQ-014/SLC-03` | 边界/并发 | 两个并发请求、相同请求体 | 两次响应订单 ID 相同，订单表仅一行 | E1 运行日志与查询结果 |
| 同键不同内容 | `REQ-014/SLC-03` | 错误 | 第二次修改数量 | HTTP 409，不改变首次订单 | E1 集成测试结果 |

- 执行顺序：本例因集成测试依赖新 schema，采用迁移验证 → 单元 → 集成 → E2E；其他项目按依赖和最快失败反馈重新排序
- 失败处理：记录失败用例、实际输出、负责人和复验条件，不把计划写成通过结果

## 反例

- 测试正常流程
- 测试异常情况
- 做一下压力测试
- 预期全部通过

问题：没有需求映射、数据、断言、命令、证据等级和失败处理。

### e2e 纪律反例

- 计划写「e2e 覆盖全部场景」却不声明边界——不稳定的级联断言会让整批测试长期红，最终被整体跳过，覆盖承诺落空。
- 被验证链路里用 API 创建订单再打开页面断言——绕过了真实表单链路，API 的参数校验/前端交互从未被测到（API 只能做事后断言或显式划界的替代侧）。
- 失败后只能从头重跑全部阶段——没有阶段化与状态文件，长链路测试的重跑成本让它逐渐不被执行。

问题：e2e 的价值在真实链路与可持续执行；边界含糊与不可续跑都会让它在实践中被架空。

## 迁移到当前项目

替换场景、数据、环境、工具、命令、阈值和证据位置。每个场景须对应真实需求或风险，命令必须在当前项目可执行；示例测试比例不是默认要求。