感谢大家一年对我的支持，如果方便请帮忙投个票，衷心感谢！
投票链接：https://www.csdn.net/blogstar2025/detail/002
在大量团队中，产品原型评审对测试来说，往往只是一个“被动参与”的过程：
- 产品在讲交互逻辑
- 设计在讲视觉规范
- 开发在估算工作量
- 测试在……看页面是否齐全
等需求文档定稿、接口文档出来、研发开始编码，测试才真正介入测试设计。但问题是：真正低成本、最高价值的测试介入窗口，其实正是在“产品原型阶段”。
原型阶段隐藏着大量未来必然暴雷的风险点：
- 规则未定义
- 状态未穷尽
- 异常未被显式设计
- 业务假设未经验证
优秀的测试工程师，并不是“等代码出来找 Bug”，而是在原型阶段就提前看见 Bug 的形态。
这篇文章要回答的不是“怎么评审原型”，而是一个更本质的问题：
如何从一张看似“只是 UI 草图”的产品原型中，系统性地挖掘出隐藏的测试场景？
一、先统一一个前提：原型不是“界面”，而是“业务假设的可视化结果”
很多测试在看原型时，只关注三个点：
- 有没有漏页面
- 按钮能不能点
- 跳转对不对
这是把原型当成 UI在看。
但在产品视角中，原型的本质是产品经理对业务规则、用户行为、系统能力的“假设集合”，以界面的形式表达出来。
换句话说：
- 每一个按钮背后，都隐含一个业务动作
- 每一次页面跳转，都隐含一个状态变化
- 每一个输入框，都隐含一组数据约束
- 每一个默认值，都隐含一个产品决策
测试的价值，不在于验证“画没画出来”，而在于质疑：这些假设成立吗？
二、从原型中挖场景的第一层能力：识别“显性流程”之外的暗线
1. 不要只顺着“主流程”走
产品原型天然会强调 Happy Path：
打开页面 → 填表 → 提交 → 成功提示
但真实系统中，主流程永远不是风险最大的地方。
测试在看原型时，必须主动做一件事：对每一个主流程节点，反问一句：如果这里“不顺利”，会发生什么？
例如：
- 表单没填完，能不能点提交？
- 网络慢 / 中断时，按钮是否可重复点击？
- 成功提示出现前，用户刷新页面会怎样？
- 成功提示出现后，用户返回上一页会怎样？
这些问题，原型通常不会画出来，但系统一定要面对。
2. 用“反向视角”看原型
一个非常有效的技巧是假设自己是来“破坏系统”的，而不是“使用系统”的。
从这个视角看原型，会自然产生一批测试场景：
- 连续点击
- 快速返回
- 多窗口并发操作
- 中途退出再进入
- 跨页面状态错位
这些行为，99% 的产品原型不会明确设计，但 100% 的真实用户都会做。
三、第二层能力：把“界面元素”翻译成“系统状态机”
真正成熟的测试，看原型时脑子里浮现的不是页面，而是状态图。
1. 页面 ≠ 状态
一个常见误区是“一个页面就是一个状态。”
事实上：
- 同一个页面，可能有未初始化 / 已加载 / 加载失败 / 局部成功等多种状态
- 同一个按钮，在不同状态下，语义完全不同
例如一个“提交”按钮：
- 可点击但数据未校验
- 校验中（loading）
- 校验失败（高亮错误字段）
- 提交中（防重复）
- 提交成功（按钮失效或隐藏）
原型往往只画了“看起来一样的一个按钮”，但系统状态至少有 5 种。
2. 测试要主动补全“状态空间”
优秀测试在原型阶段，会做这样一件事：
- 把页面拆成状态 × 行为的组合
- 思考每一次状态迁移是否有异常路径
这一步，往往能提前发现：
- 缺失的 loading 状态
- 没有定义的失败回退
- 状态切换时数据是否一致
- 状态异常时 UI 是否可恢复
四、第三层能力：从“输入框”中看见数据风险
1. 原型里的输入框，往往是“风险密集区”
在原型中，一个输入框通常只标注：
- 文案
- 占位符
- 是否必填
但在测试视角中，每一个输入框至少包含以下隐含维度：
- 数据类型
- 长度边界
- 取值范围
- 特殊字符
- 国际化 / 本地化
- 前后端校验一致性
原型如果只写了“请输入金额”，测试应该立即追问：
- 最小值是多少？
- 最大值是多少？
- 支持几位小数？
- 是否支持负数？
- 输入法切换是否影响？
- 前端校验失败，后端是否兜底？
原型越“干净”，测试越要“肮脏地去想”。
2. 把“用户输入”视为“不可信数据”
这是测试与产品最大的认知差异之一：
- 产品默认用户是“正常人”
- 测试默认用户是“不可预测的变量”
因此，看原型时，测试要强制自己站在：
- 恶意用户
- 非目标用户
- 操作失误用户
- 极端环境用户
这些视角下，原型中所有“看起来合理”的输入点，都会暴露风险。
五、第四层能力：从“没画的地方”挖掘系统级场景
一个非常重要但常被忽视的事实是产品原型一定是不完整的。
而测试的价值，恰恰在于发现这些“不完整”。
1. 原型里没画的，通常包括什么？
经验来看，以下内容最容易被遗漏：
- 异常提示的具体文案
- 系统错误时的用户引导
- 后台任务失败的可感知性
- 数据回滚与补偿机制
- 跨系统依赖失败时的行为
测试在原型阶段提出这些问题，本质上是在帮团队：
- 降低后期返工成本
- 提前暴露系统设计缺陷
- 避免“上线后才补异常方案”
2. 测试不是“挑刺”，而是在补系统设计
高水平的测试提问，通常是这样的：
- “如果这里失败了，用户下一步能做什么？”
- “这个状态下，系统是否允许重试？”
- “异常发生后，数据是一致的吗？”
- “用户是否有感知？是否会误操作？”
这些问题，不是为了否定原型，而是让产品更完整。
六、第五层能力：从单点原型，扩展到“端到端业务场景”
很多测试只盯着“当前模块”的原型，这是不够的。
1. 原型之间，存在隐形的“业务链路”
例如：
- 下单页面 → 支付页面 → 订单详情 → 售后入口
- 配置页面 → 生效时间 → 历史数据 → 权限控制
测试在看单个原型时，必须主动思考：
- 上游数据异常会不会影响当前页面？
- 当前操作是否会影响下游流程？
- 多个模块对同一数据是否有一致理解？
2. 场景不是“页面级”，而是“业务级”
真正有价值的测试场景，往往是：
- 跨页面
- 跨模块
- 跨系统
- 跨时间
而这些，几乎从来不会在单张原型中完整体现。
测试需要做的，是把零散的原型，在脑中拼成一条完整的业务链路，并在链路中寻找断点。
七、能力跃迁的关键：从“执行者”到“系统思考者”
当测试能在原型阶段做到以下几点时，角色已经发生了质变：
- 不再只问“怎么测”，而是问“是否合理”
- 不再等需求定稿，而是参与需求塑形
- 不再只关注 Bug，而是关注系统稳定性
- 不再是“质量把关人”，而是“风险前置者”
这也是为什么在成熟团队中优秀测试，往往在原型阶段就已经“测完了一半”。
总结：从原型中挖掘测试场景的核心思维模型
下面用一张 Mermaid 图，来总结从产品原型到测试场景的完整思考路径：
原型不是测试的起点，而是测试思考能力的放大器。
你能从原型中看见多少风险，取决于你对系统、业务和用户的理解深度。
