qa-ai-blindspot-compensation

AI在生成测试用例时存在六大系统性盲区：时序依赖、并发冲突、资源竞争、状态累积、数据一致性、第三方集成差异。评审完AI生成的用例之后，必须用此技能做盲区补盲——因为AI几乎一定会漏掉这些。如果你心里觉得"好像还差点什么但说不上来"，这就是答案。每个盲区维度至少补2-3个场景，总补盲数12-18个。 触发场景：还有什么没测到、AI漏了什么、补盲、全面覆盖、是不是不够、哪还没测、盲区分析、遗漏场景、时。 Use when the user asks about: compensating for known blind spots in AI-generated test cases — timing dependencies, concurrency conflicts, resource contention, state accumulation, data consistency, and third-party integration differences.

⚠️ 本技能单独使用效果有限，建议配合完整技能集（12 步工作流）使用。安装：npx skills add Kokxi/qa-test-skills

AI 盲区补偿

核心原则

AI有系统性的盲区，专家知道在哪些维度上主动补盲。

关键指标：每个盲区至少补充2-3个测试场景，六大盲区 × 每个2-3个场景 = 至少12-18个补盲用例。

AI 六大已知盲区

每个盲区的典型场景、检查清单、补盲问法详见 references/blindspot-details.md。

盲区	AI的典型盲点	补盲方向
时序依赖	不思考"操作顺序变更"的影响	打乱顺序、测试中间状态、验证依赖
并发冲突	不思考"多人同时操作"	多用户并发、多设备操作、锁机制
资源竞争	不思考"资源耗尽"	内存/连接/线程/磁盘不足
状态累积	不思考"长时间运行后漂移"	会话超时、累计操作、缓存过期
数据一致性	不思考"分布式数据问题"	跨服务同步、分布式事务、主从一致
第三方集成	不思考"Mock与真实差异"	第三方异常/超时/变更/降级

国内业务常见实例（补盲时优先对照）：

盲区	国内业务实例
时序依赖	秒杀活动中"先加购物车后下单"与"直接下单"顺序不同，库存扣减结果差异
并发冲突	双11多用户同时抢同一商品，超卖问题；多人同时编辑同一订单
资源竞争	支付网关连接池耗尽、日志磁盘写满、数据库连接数超限
状态累积	用户会话长期不退出导致 Token 过期/权限漂移；长连接内存泄漏
数据一致性	订单跨服务（订单服务+库存服务+支付服务）分布式事务；主从延迟读
第三方集成	微信支付/支付宝回调超时重试、短信服务商变更、地图/天气第三方异常降级

补盲检查清单

• 时序依赖：操作顺序变更是否影响结果？
• 并发冲突：多人同时操作是否测试？
• 资源竞争：资源耗尽场景是否覆盖？
• 状态累积：长时间运行是否测试？
• 数据一致性：分布式数据问题是否验证？
• 第三方集成：Mock与真实差异是否对比？

输出格式

markdown

## 补盲报告

### 盲区覆盖情况
| 盲区类型 | 原有用例 | 补盲用例 | 覆盖状态 |
|---------|---------|---------|---------|
| 时序依赖 | X条 | X条 | ✓/✗ |
| 并发冲突 | X条 | X条 | ✓/✗ |
| 资源竞争 | X条 | X条 | ✓/✗ |
| 状态累积 | X条 | X条 | ✓/✗ |
| 数据一致性 | X条 | X条 | ✓/✗ |
| 第三方集成 | X条 | X条 | ✓/✗ |

### 补盲用例清单
| 用例编号 | 盲区类型 | 测试标题 | 关联需求 |
|---------|---------|---------|---------|
| BS_XXX_001 | 时序依赖 | [标题] | REQ-XXXX |

加载时机

需要时才读，不要一上来全读：

什么时候读	读哪个
知道有六大盲区，但不清楚每类具体漏什么	references/blindspot-details.md（六类盲区的详细判据与示例）

---

补盲工作流

步骤1：识别盲区

text

对照六大盲区，检查当前测试场景：
- [ ] 时序依赖：有没有操作顺序影响结果的场景？
- [ ] 并发冲突：有没有多人同时操作的场景？
- [ ] 资源竞争：有没有资源可能耗尽的场景？
- [ ] 状态累积：有没有长时间运行的场景？
- [ ] 数据一致性：有没有分布式数据同步的场景？
- [ ] 第三方集成：有没有依赖外部服务的场景？

步骤2：生成补盲场景

text

对每个识别出的盲区，生成专项测试场景：

时序依赖补盲：
1. 打乱操作顺序，验证结果
2. 测试操作中间状态
3. 验证操作依赖关系

并发冲突补盲：
1. 多用户同时编辑同一数据
2. 同一用户多设备同时操作
3. 并发请求导致数据不一致

资源竞争补盲：
1. 模拟内存不足
2. 模拟连接池耗尽
3. 模拟线程池满

状态累积补盲：
1. 长时间运行测试
2. 会话超时测试
3. 累计操作测试

数据一致性补盲：
1. 跨服务数据同步测试
2. 分布式事务测试
3. 缓存一致性测试

第三方集成补盲：
1. Mock与真实行为对比
2. 第三方异常模拟
3. 第三方降级测试

步骤3：标注补盲场景

text

为每个补盲场景标注：
- 盲区类型：[时序/并发/资源/状态/数据/第三方]
- 风险等级：高/中/低
- 测试难度：高/中/低
- 建议测试深度：深测/常规/冒烟

逐项检查清单

测试完成后，逐项检查：

时序检查

• 操作顺序变更会怎样？
• 操作中间状态会丢失吗？
• 有操作依赖关系吗？

并发检查

• 多人同时操作会怎样？
• 多设备同时操作会怎样？
• 并发请求会冲突吗？

资源检查

• 内存会泄漏吗？
• 连接会耗尽吗？
• 线程会满吗？
• 磁盘会满吗？

状态检查

• 长时间运行会出问题吗？
• 会话超时会怎样？
• 累计操作会影响什么？

数据检查

• 跨服务数据同步正常吗？
• 分布式事务会失败吗？
• 缓存与数据库一致吗？

第三方检查

• Mock与真实行为一致吗？
• 第三方异常会怎样？
• 第三方降级会怎样？

输出示例

AI生成了一组登录功能测试用例 → 扫描六大盲区：

• 时序盲区：未测试"登录中切换页面"场景
• 并发盲区：未测试"多设备同时登录"场景 → 为每个盲区补充2-3个测试场景，标注风险等级

用户说"还有没有遗漏" → 启动六大盲区逐一排查，输出补盲报告 → 每个补盲用例带唯一ID（BS-XXXX）并关联原始用例

检查清单

补盲完成后检查：

• 是否覆盖了六大盲区？
• 补盲场景是否可执行？
• 补盲场景风险是否标注？
• 补盲场景优先级是否合理？