Qa Critical Thinking

SKILL.md

---
name: qa-critical-thinking
version: 1.6.0
description: >-
  当需要挑战已有假设、挖掘隐含约束、发现"所有人都没想过"的测试场景时使用此技能。测试中最常犯的错误是接受了需求文档里的隐含假设——比如"用户一定会有网络"、"输入一定有内容"、"操作顺序一定正确"。用「如果不呢」的深度质疑方式反向思考，暴露那些被默认为"正常"的异常场景。每一个测试场景都应该走一遍"如果这个假设不成立呢"的质疑流程。

when_to_use: 用户说"还有什么"、"如果...会怎样"、"逆向思考"、"你怎么看"、"这样够吗"、"质疑"、"挑战需求"、"有没有漏"、需要怀疑和深度分析时
allowed-tools: Read Grep Glob
related_skills:
  upstream: []  # 基础层技能
  downstream:
    - qa-req-deconstruction      # 影响：需求挖掘深度
    - qa-scenario-tree           # 影响：场景覆盖全面性
    - qa-boundary-deep-dive      # 影响：边界分析深度
    - qa-requirement-review
input_format:
  required:
    - name: 需求描述
      type: string
      description: 功能需求的详细描述
    - name: 测试用例
      type: array
      description: 待审阅的测试用例列表
  optional:
    - name: 业务背景
      type: string
      description: 业务目标和用户角色
output_format:
  traceability:
    - 本技能质疑思维，不产出唯一ID；发现的假设挑战关联到需求ID或场景ID
  structure:
    - thinking_gaps: 思维盲区清单
    - assumption_challenges: 假设挑战列表
    - alternative_scenarios: 替代场景建议
    - risk_reevaluation: 风险重评估
categories: ['Development','Testing']
depth_requirement_quantification:
  reference_value: "根据需求复杂度调整质疑深度：简单×3/中等×5/复杂×7"
  minimum: "至少挑战3个隐含假设"
error_recovery_guidance:
  on_failure: "质疑流未能暴露假设时回退到需求解构补充上下文"
  retry_behavior: "补充业务背景后重新质疑"
---
> **⚠️ 安全警告**：本技能的示例可能涉及订单号、支付金额、截图、身份证、手机号等敏感数据。
> 实际使用时请勿粘贴真实生产数据、客户信息或财务凭证；测试前应脱敏/掩码处理。
> 本技能仅在 workspace/ 输出评估文件，不持久化、不外传、不跨会话复用。

# 测试批判性思维

## 核心原则

对每个"正常"都问"异常呢？"；对每个"确定"都问"假设呢？"
本技能适用于测试用例查漏补缺、需求深度分析和风险评估等需要逆向思考的场景。

## 质疑框架

### 5W1H 质疑法

```text
What（是什么）：
├─ 这个功能是什么？
├─ 这个规则是什么？
├─ 这个约束是什么？
└─ 如果不是这样会怎样？

Why（为什么）：
├─ 为什么要有这个功能？
├─ 为什么要有这个规则？
├─ 为什么是这样实现？
└─ 如果没有这个为什么会怎样？

Who（谁）：
├─ 谁在用这个功能？
├─ 谁负责这个模块？
├─ 谁会影响这个功能？
└─ 如果换一个人会怎样？

When（什么时候）：
├─ 什么时候用这个功能？
├─ 什么时候触发这个规则？
├─ 什么时候会出问题？
└─ 如果换个时间会怎样？

Where（在哪里）：
├─ 在哪里使用这个功能？
├─ 在哪里存储这些数据？
├─ 在哪里会出现问题？
└─ 如果换个地方会怎样？

How（怎么做）：
├─ 怎么实现这个功能？
├─ 怎么触发这个规则？
├─ 怎么处理异常情况？
└─ 如果换个方式会怎样？
```

### 逆向思维

```text
正常 → 异常
├─ 正常输入 → 异常输入（空值、超长、特殊字符）
├─ 正常流程 → 异常流程（中断、失败、超时）
├─ 正常数据 → 异常数据（空、脏、大量）
└─ 正常环境 → 异常环境（断网、高负载、硬件故障）

确定 → 假设
├─ 用户会正常操作 → 用户会误操作
├─ 网络会正常 → 网络会异常
├─ 数据会正确 → 数据会错误
└─ 服务会正常 → 服务会故障

存在 → 不存在
├─ 数据存在 → 数据不存在
├─ 服务可用 → 服务不可用
├─ 权限足够 → 权限不足
└─ 资源充足 → 资源不足
```

### 假设挖掘

```text
常见假设类型：
├─ 用户行为假设
│   ├─ 假设：用户会按预期操作
│   ├─ 反例：用户误操作、恶意操作
│   └─ 追问：用户不按预期操作会怎样？
│
├─ 环境假设
│   ├─ 假设：环境会正常
│   ├─ 反例：网络异常、服务故障
│   └─ 追问：环境异常会怎样？
│
├─ 数据假设
│   ├─ 假设：数据会正确
│   ├─ 反例：数据缺失、数据错误
│   └─ 追问：数据异常会怎样？
│
├─ 时序假设
│   ├─ 假设：操作会按顺序执行
│   ├─ 反例：乱序执行、并发执行
│   └─ 追问：时序异常会怎样？
│
└─ 依赖假设
    ├─ 假设：依赖服务会正常
    ├─ 反例：依赖服务故障
    └─ 追问：依赖异常会怎样？
```

### "那又怎样" 追问法

```text
发现问题 → 那又怎样？
│
├─ 影响一个功能 → 那又怎样？还影响什么？
│   └─ 示例：登录失败 → 那又怎样？→ 无法访问任何功能
│
├─ 影响一个用户 → 那又怎样？还影响谁？
│   └─ 示例：VIP用户无法支付 → 那又怎样？→ 影响收入
│
├─ 影响一个数据 → 那又怎样？还影响什么数据？
│   └─ 示例：订单数据错误 → 那又怎样？→ 影响库存、财务
│
└─ 影响一个系统 → 那又怎样？还影响哪些系统？
    └─ 示例：支付系统故障 → 那又怎样？→ 影响所有交易
```

## 应用场景

**用户说"帮我测试登录功能"**
→ 应用5W1H质疑法：如果用户名不存在？如果密码错误？如果网络中断？
→ 应用逆向思维：正常登录→异常登录（空密码、超长密码、SQL注入）
→ 应用"那又怎样"追问：登录失败→那又怎样？→无法访问任何功能

**用户说"密码长度至少8位"**
→ 应用规则质疑：如果刚好8位？超过100位？全是空格？包含emoji？
→ 挖掘隐含假设：假设用户不会用特殊字符

**用户说"这个功能看起来很简单"**
→ 触发本技能进行深度质疑，挖掘"简单"背后的隐藏风险

## 思维练习

### 练习1：功能质疑
**功能**：用户登录

```text
正常思维：
- 用户输入用户名密码
- 系统验证
- 登录成功

批判性思维：
- 如果用户名不存在会怎样？
- 如果密码错误会怎样？
- 如果用户输入<script>会怎样？
- 如果用户同时在多设备登录会怎样？
- 如果用户登录后长时间不操作会怎样？
- 如果网络中断会怎样？
- 如果数据库挂了会怎样？
- 如果用户恶意暴力破解会怎样？
```

### 练习2：规则质疑
**规则**：密码长度至少8位

```text
正常思维：
- 验证密码长度是否≥8

批判性思维：
- 如果密码刚好8位会怎样？
- 如果密码超过100位会怎样？
- 如果密码全是空格会怎样？
- 如果密码包含emoji会怎样？
- 如果密码是常见密码（12345678）会怎样？
- 如果密码包含用户名会怎样？
- 如果密码包含生日会怎样？
- 如果密码长期不更换会怎样？
```

### 练习3：数据质疑
**数据**：用户输入手机号

```text
正常思维：
- 验证手机号格式

批判性思维：
- 如果手机号为空会怎样？
- 如果手机号不是11位会怎样？
- 如果手机号包含特殊字符会怎样？
- 如果手机号已注册其他账号会怎样？
- 如果手机号是虚拟号码会怎样？
- 如果手机号是国际号码会怎样？
- 如果手机号被标记为骚扰电话会怎样？
- 如果手机号运营商不支持会怎样？
```

## 常见陷阱

### 陷阱1：确认偏误
```text
现象：只找支持自己判断的证据，忽略反例
示例：认为"登录功能很简单"→只检查正常登录→遗漏异常场景
破解：强制列出5个"反例/异常情况"再开始测试
```

### 陷阱2：锚定效应
```text
现象：被第一个信息锚定，忽略其他可能性
示例：听到"用户量1万"→用例按1万设计→实际要考虑100万
破解：先不看任何限制条件，设计理想用例；再把条件加回来过滤
```

### 陷阱3：可得性启发
```text
现象：只测最近出过问题的地方
示例：上次上线是登录模块出Bug→这次死磕登录→忽略了新功能的核心风险
破解：按风险评估矩阵排序，不要凭印象分配测试精力
```

### 陷阱4：乐观偏差
```text
现象：默认事事顺利，低估异常概率
示例："用户一定会按要求操作"→遗漏误操作场景
破解：对每个正常路径追问"如果在这里出错了呢？"
```

### 陷阱5：框架效应
```text
现象：被问题表述方式限制了思考范围
示例："验证删除功能"→只测删除→忽略了恢复/回收站/级联删除
破解：跳出当前模块问"这个功能的上游是什么？下游是什么？"
```

### 陷阱6：沉没成本
```text
现象：已经做了大量用例就停止质疑
示例：写了50条查询用例→觉得"够多了"→遗漏了关键的并发查询场景
破解：用例数量和质量无关，强制问"还有没有极端场景没覆盖？"
```

## 自检清单

批判性思维应用后检查：
- [ ] 是否对每个"应该"都问了"如果不呢？"
- [ ] 是否对每个"正常"都问了"异常呢？"
- [ ] 是否对每个"确定"都问了"假设呢？"
- [ ] 是否挖掘了隐含假设？
- [ ] 是否应用了"那又怎样"追问？
- [ ] 是否覆盖了反向场景？


## 检查清单

- [ ] 隐含假设是否挑战？
- [ ] 证据是否充分？
- [ ] 逻辑是否自洽？
- [ ] 替代解释是否考虑？
- [ ] 结论是否可证伪？