# 测试策略示例场景

## 示例1：电商购物车多端同步

### 场景描述
用户同时在手机和电脑上操作购物车，验证数据同步和冲突解决机制。

### 测试用例

#### TC-CART-001：同用户多端添加商品

**前置条件**：
- 用户已登录手机和电脑端
- 购物车初始为空

**测试步骤**：
1. 手机端添加商品A（数量：1）
2. 电脑端添加商品A（数量：1）
3. 观察两端购物车显示

**预期结果**：
- 两端都显示商品A数量为2
- 数据同步延迟 < 1秒

**验证要点**：
- 并发写入冲突解决（乐观锁/版本号）
- WebSocket/长轮询实时更新机制
- 最终一致性保证

---

#### TC-CART-002：商品下架后的购物车处理

**前置条件**：
- 用户购物车中有商品B
- 商品B库存充足

**测试步骤**：
1. 管理员将商品B下架
2. 用户刷新购物车页面
3. 尝试结算包含商品B的订单

**预期结果**：
- 购物车显示商品B已下架
- 结算时提示移除已下架商品
- 历史订单中的商品B信息保持不变（价格快照）

**验证要点**：
- 依赖踏空场景处理
- 历史数据保护机制
- 用户提示的友好性

---

## 示例2：部门管理系统

### 场景描述
测试部门合并、人员调动时的数据一致性和权限继承。

### 测试用例

#### TC-DEPT-001：部门合并后的人员归属

**前置条件**：
- 存在部门A（10人）和部门B（8人）
- 部门A有独立的数据统计

**测试步骤**：
1. 将部门B合并到部门A
2. 查看部门A的人员列表
3. 查看部门A的统计数据
4. 查看原部门B成员的权限

**预期结果**：
- 部门A人员数量变为18人
- 统计数据包含原部门B的数据
- 原部门B成员继承部门A的权限
- 历史数据保留合并记录

**验证要点**：
- 数据迁移的完整性
- 权限继承的正确性
- 审计日志的记录

---

#### TC-DEPT-002：部门拆分后的数据归属

**前置条件**：
- 部门C有20人，3个子团队
- 部门C有共享的预算和资产

**测试步骤**：
1. 将部门C拆分为部门D、E、F
2. 查看各部门的人员分配
3. 查看预算和资产的分配
4. 验证历史数据的访问权限

**预期结果**：
- 人员按规则分配到新部门
- 预算和资产按比例分配
- 历史数据可追溯到原部门C
- 拆分操作可回滚

**验证要点**：
- 拆分规则的合理性
- 资源分配的准确性
- 历史数据的可追溯性

---

## 示例3：用户地址选择

### 场景描述
测试省市区三级联动的逆向操作和数据一致性。

### 测试用例

#### TC-ADDR-001：地址选择的逆向操作

**前置条件**：
- 地址选择组件已加载
- 省市区数据完整

**测试步骤**：
1. 选择"浙江省"
2. 选择"杭州市"
3. 选择"上城区"
4. 将省改为"江苏省"
5. 观察市和区的变化

**预期结果**：
- 市清空或显示江苏省的默认市
- 区清空
- 不能出现"江苏省-杭州市"的错误组合

**验证要点**：
- 级联依赖关系的正确处理
- 前置操作改变后的联动更新
- 数据合法性的校验

---

## 示例4：新旧数据兼容

### 场景描述
订单系统从V1升级到V2，测试新旧数据的兼容性。

### 测试用例

#### TC-MIGRATE-001：V2程序读取V1订单数据

**前置条件**：
- V1订单表：平铺字段（product_id, product_name, price）
- V2订单表：JSON对象（product: {id, name, price, sku}）
- 历史订单500万条

**测试步骤**：
1. V2程序查询V1订单
2. 显示订单详情
3. 修改V1订单状态
4. V1程序查询被V2修改的订单

**预期结果**：
- V2能正确解析V1的平铺字段
- 展示层统一使用V2的数据结构
- V1程序仍能正常访问被修改的订单
- 不丢失任何历史数据

**验证要点**：
- 数据访问层的适配逻辑
- 字段映射的准确性
- 双向兼容性
- 性能损耗在可接受范围（< 10%）

---

#### TC-MIGRATE-002：数据迁移方案验证

**前置条件**：
- 测试环境有V1数据备份
- 迁移脚本已准备好

**测试步骤**：
1. 执行数据迁移脚本
2. 验证迁移后的数据完整性
3. 对比迁移前后的订单总数、金额汇总
4. 抽样检查订单详情

**预期结果**：
- 数据迁移成功率 100%
- 金额汇总完全一致
- 订单详情字段映射正确
- 迁移过程有完整日志

**验证要点**：
- 迁移脚本的健壮性
- 数据校验的严格性
- 回滚方案的可行性
- 迁移耗时评估

---

## 示例5：订单状态流转（状态迁移测试）

### 场景描述
测试订单系统状态流转的合法性和非法跳转拦截。

### 测试用例

#### TC-STATE-001：订单状态合法流转

**前置条件**：
- 订单初始状态为“待支付”
- 订单金额为100元

**测试步骤**：
1. 用户支付订单
2. 系统更新订单状态
3. 仓库发货
4. 用户确认收货

**预期结果**：
- 状态流转：待支付 → 已支付 → 已发货 → 已完成
- 每个状态变更都有时间戳和操作人记录

**验证要点**：
- 状态机是否按预定路径流转
- 状态变更是否有审计日志

---

#### TC-STATE-002：非法状态跳转拦截

**前置条件**：
- 订单状态为“已取消”

**测试步骤**：
1. 直接调用 API 将订单状态改为“已发货”
2. 观察系统响应

**预期结果**：
- 系统拒绝请求，返回错误码和提示信息
- 订单状态保持“已取消”不变
- 记录异常操作日志

**验证要点**：
- 非法状态跳转是否被拦截
- 是否有越权操作的防护机制

---

#### TC-STATE-003：状态回退后的数据一致性

**前置条件**：
- 订单状态为“已发货”
- 库存已扣减

**测试步骤**：
1. 用户申请退货
2. 客服审核通过
3. 订单状态回退为“已退款”

**预期结果**：
- 订单状态正确回退
- 库存恢复或进入退货仓
- 退款金额正确计算
- 相关优惠券/积分同步回退

**验证要点**：
- 状态回退后的联动更新
- 数据一致性是否保证

---

## 示例6：优惠券叠加规则（因果判定测试）

### 场景描述
测试多条件组合下的优惠券叠加规则覆盖完整性。

### 业务规则

| 条件 | 说明 |
|------|------|
| A | 订单满100元 |
| B | 新用户 |
| C | 非特价商品 |
| D | 使用优惠券 |

**规则**：
- A且B且C → 可用20元券
- A且非B且C → 可用10元券
- 非A → 不可用券
- 非C → 不可用券（特价商品不参与）
- D与其他优惠不叠加

### 测试用例

#### TC-CAUSE-001：判定表覆盖测试

**前置条件**：
- 用户账户有10元和20元优惠券
- 购物车有商品若干

**测试步骤（8种组合）**：

| 用例 | 满100元 | 新用户 | 非特价 | 预期结果 |
|------|---------|--------|--------|----------|
| 1 | ✅ | ✅ | ✅ | 可用20元券 |
| 2 | ✅ | ✅ | ❌ | 不可用（特价） |
| 3 | ✅ | ❌ | ✅ | 可用10元券 |
| 4 | ✅ | ❌ | ❌ | 不可用（特价） |
| 5 | ❌ | ✅ | ✅ | 不可用（不满100） |
| 6 | ❌ | ✅ | ❌ | 不可用（不满100） |
| 7 | ❌ | ❌ | ✅ | 不可用（不满100） |
| 8 | ❌ | ❌ |  | 不可用（不满100） |

**验证要点**：
- 所有条件组合是否覆盖完整
- 规则优先级是否正确（特价>新用户>满减）

---

#### TC-CAUSE-002：规则冲突处理

**前置条件**：
- 用户有新用户20元券
- 购物车有特价商品

**测试步骤**：
1. 用户同时使用新用户券和特价商品
2. 观察系统计算逻辑

**预期结果**：
- 系统优先应用特价商品规则（不可用券）
- 提示用户“特价商品不可使用优惠券”

**验证要点**：
- 规则冲突时的优先级处理
- 用户提示是否友好

---

## 使用建议

### 如何编写测试用例

1. **明确测试目标**：基于测试策略的四大方法论选择测试场景
2. **覆盖完整路径**：正向、逆向、边界、异常都要覆盖
3. **设计验证要点**：不仅验证功能，还要验证性能、一致性、用户体验
4. **准备测试数据**：提前规划需要的测试数据和环境

### 测试执行优先级

- **P0**：核心功能的逆向操作和依赖踏空测试
- **P1**：多端并发和数据一致性测试
- **P2**：新旧兼容和迁移测试
- **P3**：边界条件和异常场景测试

### 缺陷预防

在执行测试前，可以在编码阶段就加入以下防御机制：
- 乐观锁/版本号控制并发
- 数据快照保护历史信息
- 依赖关系校验和降级策略
- 版本检查和兼容转换层