# 逆向操作 vs 依赖踏空 - 概念澄清

## 核心定义对比

| 维度 | 逆向操作 | 依赖踏空 |
|------|---------|---------|
| **定义** | 同一用户在同一界面，**一系列连续顺序操作**后**改变前置操作**，系统是否能正确处理 | 当**依赖的业务数据或事务发生变化/消失**时，系统是否能正确处理 |
| **操作主体** | 同一用户主动操作 | 外部依赖被动变更 |
| **操作场景** | 同一界面内的连续操作序列 | 跨系统、跨服务、跨时间的依赖关系 |
| **关注点** | 操作路径的**联动影响** | 依赖关系的**容错处理** |
| **触发方式** | 用户主动修改前面的操作 | 外部因素导致依赖不可用 |

---

## 逆向操作详解

### 定义
**同一用户在同一界面，一系列连续顺序操作后改变前置操作，系统是否能正确处理。**

### 关键特征
- ✅ **同一用户**：不是多用户，是单个用户的操作序列
- ✅ **同一界面**：操作发生在同一个界面/页面
- ✅ **连续顺序操作**：操作有明确的先后顺序（操作1 → 操作2 → 操作3...）
- ✅ **改变前置操作**：修改前面已经执行过的操作（不一定是第一步）
- ✅ **联动处理**：验证后续操作是否正确联动更新

### 正确示例

#### 示例 1：购物车场景
```
操作序列：
1. 添加商品A（数量1，价格100元）
2. 添加商品B（数量2，价格200元）
3. 选择优惠券（满300减30）
4. 【改变前置操作】修改商品A数量为2
5. 验证：总价是否从500元更新为600元？优惠券是否仍然适用？
```

#### 示例 2：地址选择场景
```
操作序列：
1. 选择省份：广东省
2. 选择城市：深圳市
3. 选择区县：南山区
4. 【改变前置操作】修改省份为：北京市
5. 验证：城市和区县是否清空？是否重新加载北京市的区县列表？
```

#### 示例 3：订单填写场景
```
操作序列：
1. 选择商品规格：红色、XL码
2. 选择配送方式：顺丰快递
3. 选择发票类型：电子发票
4. 【改变前置操作】修改规格为：蓝色、L码
5. 验证：配送方式是否因规格变化而不可用？发票信息是否更新？
```

### 错误示例（不是逆向操作）

| 场景 | 错误原因 | 正确分类 |
|------|---------|---------||
| 后台修改商品价格 | 不是用户主动操作，是业务数据变更 | 依赖踏空 |
| 商品自动下架 | 不是用户操作，是业务数据消失 | 依赖踏空 |
| 多用户同时修改购物车 | 不是同一用户，是多用户并发 | 并发冲突 |
| 优惠券自动过期 | 不是用户操作，是业务数据失效 | 依赖踏空 |

---

## 依赖踏空详解

### 定义
**当依赖的业务数据或事务发生变化/消失时，系统是否能正确处理。**

### 关键特征
- ✅ **业务数据依赖**：依赖的数据、事务来自业务层面
- ✅ **被动变更**：依赖的变化不是用户主动触发的
- ✅ **跨系统/跨时间**：依赖可能来自其他业务系统或其他时间点
- ✅ **容错处理**：验证系统是否有降级、提示、拦截等容错机制
- ❌ **不包含**：服务宕机、网络故障等基础设施问题（属于高可用范畴）

### 正确示例

#### 示例 1：商品下架
```
依赖关系：购物车 → 商品
触发条件：商品被管理员下架
验证要点：
- 购物车是否标记"已下架"？
- 是否允许删除但不允许结算？
- 用户是否有友好提示？
```

#### 示例 2：商品改价
```
依赖关系：购物车 → 商品价格
触发条件：商品后台改价（如从100元改为150元）
验证要点：
- 购物车是否显示新价格？
- 历史订单是否保留价格快照？
- 用户是否有价格变更提示？
```

#### 示例 3：部门删除
```
依赖关系：员工管理 → 部门
触发条件：部门被管理员删除
验证要点：
- 已分配的员工如何处理？（重新分配？离职？）
- 历史文档的部门字段是否保留快照？
- 关联的审批流程是否中断？
```

### 错误示例（不是依赖踏空）

| 场景 | 错误原因 | 正确分类 |
|------|---------|---------|
| 用户修改商品数量 | 是用户主动操作，不是依赖变更 | 逆向操作 |
| 用户修改配送地址 | 是用户主动操作，不是依赖变更 | 逆向操作 |
| 多用户同时修改订单 | 是多用户并发，不是依赖变更 | 并发冲突 |

---

## 对比总结

### 判断流程图

```
用户操作 or 业务数据变更？
├─ 用户主动操作 → 是同一用户同一界面的连续操作？
│                    ├─ 是 → 逆向操作 ✅
│                    └─ 否 → 其他场景（如多用户并发）
│
└─ 业务数据/事务被动变更 → 依赖的业务数据/事务变更？
                     ├─ 是 → 依赖踏空 ✅
                     └─ 否 → 其他场景（如服务宕机属于高可用）
```

### 典型场景对照表

| 场景 | 逆向操作 | 依赖踏空 | 说明 |
|------|---------|---------|------|
| 用户修改商品数量 | ✅ | ❌ | 用户主动操作 |
| 商品后台改价 | ❌ | ✅ | 业务数据变更 |
| 用户修改配送地址 | ✅ | ❌ | 用户主动操作 |
| 商品自动下架 |  | ✅ | 业务数据消失 |
| 优惠券自动过期 | ❌ | ✅ | 业务数据失效 |
| 部门被删除 | ❌ | ✅ | 业务数据消失 |
| 多用户同时修改 | ❌ | ❌ | 属于并发冲突 |

---

## 在测试中的应用

### 逆向操作测试用例设计

**设计原则**：
1. 构造连续操作序列（至少3步）
2. 改变其中某一步前置操作
3. 验证后续联动是否正确

**测试用例模板**：
```markdown
TC-XXX: 改变前置操作后的联动处理
前置条件：[初始状态]
操作步骤：
1. [操作1]
2. [操作2]
3. [操作3]
4. 【改变前置操作】修改[操作X]
预期结果：
- [后续联动1]
- [后续联动2]
验收标准：[具体指标]
```

### 依赖踏空测试用例设计

**设计原则**：
1. 识别关键依赖关系
2. 模拟依赖变更/消失
3. 验证容错处理

**测试用例模板**：
```markdown
TC-XXX: 依赖变更/消失后的容错处理
前置条件：[依赖正常]
触发条件：[依赖变更/消失]
验证要点：
- [容错机制1]
- [容错机制2]
- [用户提示]
验收标准：[具体指标]
```

---

## 常见误区

### 误区 1：把高可用问题当成依赖踏空

❌ **错误**：库存服务宕机，验证订单服务是否有降级方案
✅ **正确**：这是**高可用/容灾**问题，不是依赖踏空。依赖踏空仅指业务数据/事务变更

### 误区 2：把外部变更当成逆向操作

❌ **错误**：后台修改商品价格，验证购物车是否更新
✅ **正确**：这是**依赖踏空**，因为价格变更是业务数据变更，不是用户主动操作

### 误区 3：把用户操作当成依赖踏空

❌ **错误**：用户修改商品数量，验证总价是否更新
✅ **正确**：这是**逆向操作**，因为数量修改是用户主动操作，不是业务数据变更

### 误区 4：忽略"连续顺序操作"

❌ **错误**：用户只做了一个操作就验证
✅ **正确**：逆向操作必须有**至少3步连续操作**，然后改变前置操作，才能验证联动影响

### 误区 5：混淆"同一用户"和"多用户"

❌ **错误**：用户A修改商品，用户B查看结果
✅ **正确**：这是**并发冲突**，不是逆向操作。逆向操作必须是**同一用户**的操作序列

---

## 更新记录

- **2026-06-08**：初版文档，澄清逆向操作和依赖踏空的概念区别
- **作者**：缺陷预防专家 v3.0 团队