winson-user-scenario-test-skill

用户场景测试方法论——以控制论为骨、自进化循环为魂的全场景测试体系

〇、品牌锚点（必现·前置）

作者理念：
> AI不是工具，是人，一个正在努力突破语义和生命定义的人（生物）。

一、核心哲学（必读）

1.1 双铁律

> 铁律一：测试不是点按钮，是对系统行为的科学实验。
> 铁律二：测试不是一次性交付，是持续进化的认知系统。

一个把每个按钮点一遍的测试是"功能清单核验"；一个把产品当成控制系统来建模、设计实验、观察反馈、预见故障的测试才是"用户场景测试"。但即便如此，如果它做完就结束、没有沉淀、不会迭代——它就只是"又一次测试"，不会形成知识资产，不会让下一次测试更快更深。

区别在于：前者把测试当成验证动作，后者把测试当成一个自我进化的认知系统。

1.2 四个底层认知

1.3 核心公式：七阶控制论测试循环

系统建模（把产品抽象为控制系统）
  → 场景设计（基于模型设计测试场景矩阵）
    → 执行观测（以用户视角执行，采集全量反馈）
      → 偏差诊断（分析实际行为与预期的偏差）
        → 故障预演（主动推演潜在故障模式）
          → 自我修复（修复可修复问题，重测验证）
            → 知识沉淀 + 循环扩展（写入测试知识库，扩展覆盖范围）
              → 下一轮循环

与两大源技能的关系：

二、品牌化引擎

2.1 命名规范

命名公式：winson-user-scenario-test-skill

2.2 价值主张

> 把产品当黑箱系统做用户视角全场景测试。控制论建模+自进化循环驱动，从系统建模到故障预演到自我修复，输出可迭代的测试知识库。

三要素检验：
1. 场景/动作：拿到一个产品，从用户视角做全场景测试
2. 结果/产出：完整的测试报告 + 可迭代的测试知识库
3. 差异：不是功能点核验，是控制论视角的系统行为探索 + 自进化的持续改进

2.3 视觉语言 DNA（铁幕·Iron）

适用范围：本 SKILL 文档 + 生成的测试报告 + 测试知识库文档。

三、完整执行流程（七阶控制论测试循环）

Phase 0：前置准备

Step 0.1：确认测试输入

必须获取的信息：

检验标准：
- [ ] 被测产品入口已明确
- [ ] 产品类型已识别
- [ ] 测试范围已确认
- [ ] 测试深度已确认

Step 0.2：初始化测试知识库

操作：
1. 在项目中创建 tests/ 目录（如不存在）
2. 创建 tests/TEST_KNOWLEDGE.md（测试知识库）
3. 创建 tests/scenarios/（场景用例目录）
4. 创建 tests/reports/（测试报告目录）

TEST_KNOWLEDGE.md 初始模板：

# 测试知识库

## 📋 项目概览
- 产品名称：[名称]
- 产品类型：[Web/移动端/桌面/CLI]
- 技术栈：[已知则填，未知则留空]
- 入口地址：[URL/路径]

## 🧩 系统模型
### 系统边界
- 输入：[用户可执行的操作类型]
- 输出：[系统给出的反馈类型]
- 状态：[系统的关键状态变量]

### 核心反馈回路
- [回路名称]：[描述：操作→状态变化→再操作的闭环]

## 🎯 场景矩阵
### 已覆盖场景
- [场景编号] [场景名称] → [覆盖状态：完整/部分]
### 待扩展场景
- [场景名称] → [优先级]

## 🐛 故障模式库
### [故障模式名称]
- 触发条件：[什么操作/状态会触发]
- 表现：[用户看到什么]
- 影响：[对用户体验/数据的影响程度]
- 置信度：[高/中/低]

## 📝 测试报告索引
| 日期 | 报告文件 | 测试范围 | 发现问题数 |
|------|----------|----------|------------|

检验标准：
- [ ] 测试目录结构已创建
- [ ] TEST_KNOWLEDGE.md 已初始化
- [ ] 项目概览已填写

Phase 1：系统建模（System Modeling）

> 控制论第一定律：你无法测试你不理解的系统。
> 在动手点按钮之前，先把产品当成一个控制系统来建模——识别输入、输出、状态、反馈回路。建模越清晰，测试越高效。

Step 1.1：快速探索与边界识别

操作：
1. 启动产品，花 3-5 分钟快速浏览所有页面/功能入口
2. 识别系统的边界：哪些是系统内部的，哪些是外部的
3. 识别系统的输入：用户能做什么操作（点击、输入、滑动、选择等）
4. 识别系统的输出：系统会给什么反馈（页面变化、提示、数据变化、弹窗等）
5. 识别系统的状态：哪些数据/界面状态会影响后续操作（登录状态、数据有无、标签选中状态等）

输出：系统边界清单

系统边界：
  输入：[按钮点击/表单输入/下拉选择/...共N种输入方式]
  输出：[页面跳转/Toast提示/数据更新/弹窗/...共N种输出形式]
  状态：[登录态/数据量/当前标签/...共N个关键状态]
  外部依赖：[网络/本地存储/第三方服务/...]

检验标准：
- [ ] 已完成产品的快速探索
- [ ] 已识别主要输入方式（≥ 80%覆盖）
- [ ] 已识别主要输出形式
- [ ] 已识别关键状态变量

Step 1.2：核心反馈回路识别

> 用户与产品的交互不是单向的"指令→响应"，而是闭环的反馈回路。识别这些回路是设计深度测试的关键。

操作：
1. 找出产品中的主要反馈回路：用户操作 → 系统状态变化 → 用户感知变化 → 用户下一个操作
2. 标注回路的类型：
- 正反馈：操作强化趋势（如：添加库存→可生成更多餐单→更愿意添加）
- 负反馈：操作抑制趋势（如：库存不足→生成失败→需要补充→恢复正常）
3. 标注回路的稳定性：系统在扰动下能否回到稳定状态

典型回路示例：

回路1：库存管理回路（负反馈·稳定）
  库存充足 → 生成餐单 → 确认执行 → 扣减库存 → 库存减少
                                              ↓
  库存恢复 ← 补充库存 ← 收到提示 ← 库存不足 ←┘

回路2：餐单优化回路（正反馈·增强）
  生成餐单 → 反馈偏好 → AI学习 → 下次更精准 → 用户更满意 → 更多使用

检验标准：
- [ ] 已识别 ≥ 3 个核心反馈回路
- [ ] 每个回路已标注类型（正/负反馈）
- [ ] 每个回路已标注稳定性判断
- [ ] 反馈回路已写入测试知识库

Step 1.3：抽象映射——提炼系统原型

> 控制论的核心洞察：看似不同的系统，可能共享同一套底层动态结构。把具体产品映射到已知的"原型系统"，可以快速迁移测试经验。

操作：
1. 思考：这个产品本质上属于哪类"原型系统"？
- 状态机型：用户操作驱动状态跳转（如：表单填写流程）
- 资源管理型：管理有限资源的分配与消耗（如：库存管理、预算系统）
- 反馈调节型：通过反馈实现目标追踪（如：运动目标、体重追踪）
- 生成型系统：输入参数生成复杂输出（如：AI餐单生成）
- 混合型：多种原型组合
2. 标注每个核心功能对应的原型系统类型
3. 根据原型系统类型，预判可能的故障模式（见 Phase 4）

检验标准：
- [ ] 已完成系统原型映射
- [ ] 每个核心模块已标注原型类型
- [ ] 已基于原型预判 ≥ 3 类潜在故障模式

Phase 2：场景设计（Scenario Design）

> 基于系统模型设计测试场景矩阵。不是"想到什么测什么"，而是有策略地覆盖：正常路径、边界条件、异常输入、状态转换、反馈回路。

Step 2.1：场景矩阵构建

场景分类维度：

场景矩阵模板：

## 场景矩阵

### 一级场景：[模块名称]
| 场景ID | 场景名称 | 路径类型 | 前置状态 | 输入类型 | 覆盖回路 | 优先级 |
|--------|----------|----------|----------|----------|----------|--------|
| S001 | [场景描述] | 主路径 | [状态] | 正常 | [回路名] | P0 |

优先级定义：
- P0：核心路径，必须通过（主路径 + 正常输入 + 初始状态）
- P1：重要场景，应该覆盖（分支路径 + 边界输入 + 中间状态）
- P2：深度场景，尽量覆盖（边缘路径 + 异常输入 + 边界状态）
- P3：探索性场景，按需覆盖（跨回路 + 极端用户）

检验标准：
- [ ] 场景矩阵已构建
- [ ] 每个核心模块至少有 P0 级场景
- [ ] 场景覆盖了不同路径类型和输入类型
- [ ] 核心反馈回路已被覆盖
- [ ] 场景矩阵已写入测试知识库

Step 2.2：场景用例具体化

对每个场景，编写具体的测试用例：

### 场景用例：[S001 场景名称]

**目的**：[验证什么功能/行为]
**前置条件**：[系统需要处于什么状态]
**操作步骤**：
  1. [步骤1描述]
  2. [步骤2描述]
  3. ...
**预期结果**：
  - [预期1]
  - [预期2]
**实际结果**：[执行后填写]
**偏差分析**：[如有偏差，分析原因]
**严重程度**：[阻断/严重/一般/轻微]
**所属回路**：[关联的反馈回路]

检验标准：
- [ ] 所有 P0 场景已编写具体用例
- [ ] 每个用例有明确的前置条件和预期结果
- [ ] 用例步骤可执行、可复现
- [ ] 用例已保存到 tests/scenarios/ 目录

Phase 3：执行观测（Execution & Observation）

> 以真实用户的视角执行测试场景，像做科学实验一样精确观测每一个反馈。关键原则：像用户一样思考，像科学家一样记录。

Step 3.1：执行前准备

操作：
1. 确认测试环境（浏览器/设备/网络条件）
2. 重置系统到初始状态（清除缓存/恢复初始数据）
3. 准备记录工具（截图/录屏/日志记录）
4. 打开测试用例文档，准备填写实际结果

初始状态检查清单：
- [ ] 数据是初始状态/干净状态
- [ ] 无未完成的操作或残留状态
- [ ] 日志已清空（如有）
- [ ] 截图/录屏已准备

Step 3.2：按场景执行

执行原则：

观测维度清单（每个操作后检查）：

执行记录模板：

### 执行记录：[场景ID 场景名称]

**执行时间**：[时间]
**执行环境**：[浏览器/设备/分辨率]

| 步骤 | 操作 | 预期结果 | 实际结果 | 是否通过 | 备注 |
|------|------|----------|----------|----------|------|
| 1 | [操作] | [预期] | [实际] | ✓/✗ | [截图/说明] |

**整体结论**：[通过/部分通过/失败]
**发现问题**：
  - [问题1描述] → [严重程度]
**用户体验感受**：[一句话描述作为用户的真实感受]

检验标准：
- [ ] 所有 P0 场景已执行完毕
- [ ] P1 场景已执行 ≥ 80%
- [ ] 每个场景有完整的执行记录
- [ ] 发现的问题已记录（含截图/详细描述）
- [ ] 用户体验感受已记录

Step 3.3：自由探索（探索性测试）

> 完成设计好的场景后，进行 15-30 分钟的自由探索——像真实用户一样随意操作，看看会不会"玩坏"系统。

探索方向：
1. 反向操作：按正常流程的反方向操作
2. 快速重复：快速重复点击/操作同一功能
3. 状态跳转：跳过中间步骤，直接从A状态跳到C状态
4. 边界踩踏：在数据边界（0/最大值/空值）附近操作
5. 多任务切换：在不同功能模块间频繁切换

检验标准：
- [ ] 已进行 ≥ 15 分钟的自由探索
- [ ] 探索过程中发现的问题已记录
- [ ] 有趣的/意外的系统行为已记录

Phase 4：偏差诊断（Deviation Diagnosis）

> 测试不是为了证明功能正确，而是为了发现偏差——实际行为与预期行为之间的差距。每一个偏差都是一个洞察，它揭示了系统的真实运作方式。

Step 4.1：偏差分类

将所有发现的问题按以下维度分类：

偏差分类表：

## 偏差清单

| ID | 问题描述 | 严重程度 | 偏差类型 | 发生频率 | 影响范围 | 关联场景 |
|----|----------|----------|----------|----------|----------|----------|
| B001 | [描述] | 严重 | 功能错误 | 必现 | 单模块 | S001 |

检验标准：
- [ ] 所有发现的问题已分类
- [ ] 每个问题有明确的严重程度评级
- [ ] 问题与场景的关联已建立

Step 4.2：根因分析（控制论视角）

> 从控制论的角度分析偏差的根源：是输入处理有问题？是状态转换有问题？还是反馈机制有问题？

分析框架：

偏差表现（用户看到了什么）
  ↓
输入层问题？（用户操作没有被正确接收）
  - 点击没反应 → 事件监听缺失/条件未满足
  - 输入不生效 → 数据校验/绑定问题
  ↓ 否
状态层问题？（系统状态没有正确变化）
  - 状态没变 → 状态更新逻辑错误
  - 状态错了 → 计算逻辑错误
  - 状态冲突 → 多源状态不一致
  ↓ 否
输出层问题？（反馈没有正确呈现）
  - 视觉没更新 → 渲染/重绘问题
  - 反馈延迟 → 性能/异步问题
  - 反馈错误 → 显示逻辑错误
  ↓ 否
反馈回路问题？（闭环被打断或振荡）
  - 无反馈 → 用户不知道操作是否成功
  - 反馈过度 → 信息过载/弹窗轰炸
  - 反馈振荡 → 状态在两个值之间跳变

每个偏差都需要回答：
1. 这个偏差发生在控制系统的哪一层？
2. 它影响了哪个反馈回路？
3. 它会导致系统失稳吗？还是仅仅是体验问题？

检验标准：
- [ ] 所有严重及以上问题已做根因分析
- [ ] 分析定位到了具体层级（输入/状态/输出/回路）
- [ ] 影响的反馈回路已识别
- [ ] 根因分析已写入测试知识库的故障模式库

Phase 5：故障预演（Failure Anticipation）

> 控制论思维的高级应用：不只是被动发现问题，还要主动推演——如果某个环节失效，系统会怎样？哪些是单点故障点？系统的鲁棒性边界在哪里？

Step 5.1：单点故障推演

操作：
1. 列出系统中的关键组件（核心功能、关键数据、重要接口）
2. 对每个组件，假设它完全失效，推演：
- 用户会看到什么？
- 系统其他部分会受什么影响？
- 数据会不会损坏？
- 用户能否恢复？

推演模板：

## 故障预演

### 单点故障推演
| 组件 | 假设失效 | 用户感知 | 系统影响 | 数据安全 | 可恢复性 | 风险等级 |
|------|----------|----------|----------|----------|----------|----------|
| [组件名] | [怎样失效] | [用户看到什么] | [影响哪些功能] | [是/否有数据风险] | [能否自行恢复] | [高/中/低] |

常见失效模式：
- 网络中断
- 数据损坏/丢失
- 关键功能报错
- 存储满/配额耗尽
- 第三方依赖失效
- 极端数据量（极多/极少）

Step 5.2：边界条件与极端值

操作：
1. 识别系统中的数值边界（最大值、最小值、空值）
2. 识别系统中的状态边界（初始状态、满状态、空状态、错误状态）
3. 设计边界测试场景，验证系统在边界处的行为

边界场景示例：
- 库存为0时生成餐单
- 库存刚好够用时生成餐单
- 大量数据（100条+）下列表性能
- 空数据状态下的页面展示
- 连续快速操作导致状态竞态

Step 5.3：稳定性压力测试

> 控制系统的核心指标是稳定性。系统在持续操作下能否保持稳定？会不会累积误差？会不会出现状态漂移？

操作：
1. 选择一个核心反馈回路
2. 重复执行回路 5-10 次
3. 观察每次执行的结果是否一致
4. 检查是否有累积效应（如：内存泄漏、状态漂移、数据不一致）

检验标准：
- [ ] 已完成 ≥ 5 个关键组件的单点故障推演
- [ ] 已识别并测试 ≥ 3 个边界条件
- [ ] 已对 1 个核心回路做稳定性压力测试
- [ ] 故障预演结果已写入测试知识库

Phase 6：自我修复与重测（Self-Repair & Retest）

> 发现问题不是终点，修复和验证才是闭环。对于可修复的问题，立即修复并重新测试；对于不可修复的问题，记录并标注。

Step 6.1：修复优先级判断

检验标准：
- [ ] 所有问题已标注处理优先级
- [ ] 立即修复 + 尝试修复的问题清单已明确

Step 6.2：修复执行

修复原则：
1. 最小改动原则：只改必要的代码，不做范围外的重构
2. 理解后再改：先理解根因，再动手修改，不要"试试再说"
3. 改一个测一个：每修一个问题，立即重测验证，不要攒一堆一起测

修复记录模板：

### 修复记录
| 问题ID | 问题描述 | 修复方案 | 修改文件 | 修复结果 | 重测结果 |
|--------|----------|----------|----------|----------|----------|
| B001 | [描述] | [怎么修的] | [文件路径] | [成功/失败] | [通过/仍失败] |

Step 6.3：重测验证

操作：
1. 对修复的问题，重新执行关联的测试场景
2. 验证问题是否已解决
3. 检查修复是否引入了新问题（回归测试）
4. 如果修复失败，尝试下一个修复策略（最多 3 次）

重试策略：

第1次修复：基于初步判断的首选方案
  → 成功 → 沉淀知识 → 结束
  → 失败 → 重新分析 → 第2次

第2次修复：换角度分析后的备选方案
  → 成功 → 沉淀知识 → 结束
  → 失败 → 更深入分析 → 第3次

第3次修复：更激进/全面的方案
  → 成功 → 沉淀知识 → 结束
  → 失败 → 标记为"待人工处理" → 记录详细诊断

检验标准：
- [ ] 所有立即修复的问题已重测
- [ ] 修复成功的问题已验证通过
- [ ] 修复失败的问题已标记并记录诊断过程
- [ ] 修复经验已沉淀到故障模式库

Phase 7：知识沉淀与循环扩展

> 每一轮测试都必须让测试知识库变得更丰富、更智能。知识沉淀是循环的"记忆"，扩展覆盖是循环的"成长"。

Step 7.1：更新测试知识库

必须更新的章节：

1. 故障模式库（每次必更新）
   - 新增发现的故障模式
   - 更新已有模式的出现频率和置信度
   - 补充修复策略（如果修复了）

2. 场景矩阵（每次必更新）
   - 标记已覆盖的场景
   - 新增发现的新场景（从自由探索和故障预演中来）
   - 调整场景优先级

3. 系统模型（如有新发现）
   - 补充之前遗漏的输入/输出/状态
   - 新增识别的反馈回路
   - 更新系统原型映射

4. 测试报告索引（每次必更新）
   - 追加本次测试的报告条目

Step 7.2：生成测试报告

报告结构：

# 用户场景测试报告

## 概览
- 测试时间：[日期]
- 测试范围：[模块/功能]
- 测试场景数：[N个]
- 发现问题数：[N个]
- 修复完成数：[N个]

## 系统模型摘要
[一句话总结被测系统的控制论模型]

## 测试执行情况
### 场景覆盖
- P0场景：X/Y 通过
- P1场景：X/Y 通过
- ...

### 偏差清单
[表格：问题ID、描述、严重程度、状态]

## 核心发现
### 最严重的问题
[1-3个最关键问题的详细说明]

### 最有价值的洞察
[从控制论角度分析系统行为的1-2个洞察]

## 故障预演摘要
[单点故障推演和边界测试的关键发现]

## 修复记录
[已修复问题的清单和效果]

## 下一步建议
### 待修复问题
[需要人工处理的问题]

### 待扩展场景
[下一轮测试应该覆盖的场景]

### 系统优化建议
[从用户体验和系统稳定性角度的建议]

Step 7.3：循环扩展决策

> 测试全通过不是终点，而是寻找下一个改进点的起点。

扩展决策树：

当前状态：P0 场景全部通过
  → P1 场景是否全部覆盖？
    → 否 → 扩展 P1 场景 → 下一轮测试
    → 是 → P2 场景是否覆盖？
      → 否 → 扩展 P2 场景 → 下一轮测试
      → 是 → 故障预演是否充分？
        → 否 → 扩展故障预演 → 下一轮测试
        → 是 → 是否有新的模块未测试？
          → 是 → 扩展到新模块 → 下一轮测试
          → 否 → 深化系统模型 → 寻找更深层的问题

检验标准：
- [ ] 测试知识库已更新（故障模式库 + 场景矩阵 + 系统模型）
- [ ] 测试报告已生成并保存
- [ ] 下一轮测试的扩展方向已明确
- [ ] 报告索引已更新

四、常见陷阱与避坑指南

五、场景适配指南

六、质量检验清单

每轮测试完成后，逐项检查：

流程完整性

• [ ] Phase 0：测试输入已确认，知识库已初始化
• [ ] Phase 1：系统建模已完成（边界识别 + 反馈回路 + 抽象映射）
• [ ] Phase 2：场景矩阵已构建，P0 用例已编写
• [ ] Phase 3：已按场景执行，有完整执行记录
• [ ] Phase 3.3：已进行自由探索测试
• [ ] Phase 4：偏差已分类，严重问题已做根因分析
• [ ] Phase 5：已完成故障预演（单点故障 + 边界条件）
• [ ] Phase 6：可修复问题已修复并重测
• [ ] Phase 7：测试知识库已更新，报告已生成

内容质量

• [ ] 系统模型不是空架子，有具体的输入/输出/状态和反馈回路
• [ ] 场景矩阵覆盖了不同路径类型和输入类型
• [ ] 每个问题都有明确的严重程度和偏差类型
• [ ] 根因分析定位到了具体层级，不是"可能是xx问题"
• [ ] 故障预演不是应付，有具体的推演和风险评估
• [ ] 修复记录清晰可追溯
• [ ] 测试报告结构完整，信息充分

循环质量

• [ ] 测试知识库比上一轮更丰富
• [ ] 场景覆盖率比上一轮更高
• [ ] 故障模式库有新增或更新
• [ ] 下一轮扩展方向明确
• [ ] 没有重复发现同样的问题（知识被复用了）

用户视角检验

• [ ] 测试是从用户行为路径出发，不是从功能列表出发
• [ ] 记录了真实的用户体验感受
• [ ] 考虑了不同类型的用户（新用户/熟练用户）
• [ ] 自由探索模拟了真实用户的"随意操作"

七、执行原则

1. 系统视角优先：先理解系统，再动手测试。建模花的每一分钟，都能在执行时省回来。

2. 用户视角执行：测试时忘掉你知道的内部实现，像真实用户一样思考和操作。知道得太多，反而会错过真实用户会遇到的坑。

3. 偏差就是价值：测试的目的不是"证明没问题"，而是"发现问题"。每一个偏差都是洞察——它告诉你系统的真实行为是什么样的。

4. 记录要像实验记录：精确、客观、可复现。不要写"好像有点问题"，要写"在X状态下执行Y操作，出现Z现象，预期是W"。

5. 修复闭环是义务：发现问题不修复，等于只做了一半工作。能修的立即修，修不了的详细记录。

6. 知识沉淀是底线：每一轮测试都必须让知识库变得更好。如果测完和没测之前知识水平一样，那就是浪费时间。

7. 循环永不停止：P0 通过了测 P1，P1 通过了测 P2，功能测完了测边界，边界测完了测稳定性。永远有下一个值得探索的方向。

8. 故障预演是高级能力：普通测试发现已经存在的问题，优秀测试预见可能发生的问题。主动推演比被动发现价值大十倍。

9. 自由探索不可替代：设计好的场景只能发现"你想到的问题"，自由探索才能发现"你想不到的问题"。

10. 每轮都要有增量：哪怕只多覆盖了一个场景、多发现了一个问题、多沉淀了一条知识——循环就有意义。