第1章 原型测试的价值与目标
1.1 原型测试在开发流程中的定位
原型测试处于需求分析和详细设计之间，是衔接抽象概念与具体实现的关键验证环节。它通过构建低保真或高保真可交互模型，在投入大规模开发前检验核心逻辑与用户体验。
1.2 核心价值矩阵
| 价值维度 | 描述 | 量化目标 |
|---|---|---|
| 降低风险 | 在代码编写前暴露技术不可行或逻辑矛盾点 | 减少后期返工成本 60%~80% |
| 早期验证 | 用最小成本验证核心假设与关键路径 | 每个迭代可在 1~3 天内完成验证 |
| 利益干系人对齐 | 提供可感知的实物，消除文字描述的歧义 | 干系人理解度偏差 < 15% |
| 缩短反馈周期 | 让用户/产品经理提前介入，避免后期需求变更 | 反馈闭环时间 ≤ 5 个工作日 |
经验要点： 原型测试是“低成本试错”的最佳载体。一个原型发现 1 个关键逻辑错误，可避免后续 20 人/天的无效开发。
1.3 适用场景
- 需求文档歧义较大，需要视觉/交互验证
- 涉及多系统交互或复杂状态流转
- 用户界面或流程对用户体验要求高
- 团队采用敏捷/精益开发模式
1.4 前置条件
- 已完成用户故事或需求列表的优先级排序
- 存在可执行的用户流程图或线框图
- 测试环境/原型工具（如 Figma、Axure、墨刀）已就绪
- 已定义明确的功能边界：测试范围不覆盖全量功能
1.5 操作步骤
- 拆解验证单元： 将需求分解为 5~10 个可独立验证的场景
- 设计测试用例： 基于用户旅程编写关键路径与异常路径
- 执行交互测试： 按用例操作原型，记录行为与预期偏差
- 组织评审： 邀请产品、开发、设计三方对齐结论
1.6 输入输出物
| 输入物 | 输出物 |
|---|---|
| 原始需求文档 / 用户故事 | 测试通过的交互原型（标注版本号） |
| 低保真/高保真原型文件 | 原型测试用例清单（含通过/失败标记） |
| 用户流程图 | 问题清单与改进建议 |
1.7 责任边界
下图为原型测试阶段的角色责任矩阵，明确谁参与、谁审批、谁执行。
1.8 记录材料
测试执行完成后，需产出以下记录：
- 原型测试用例执行报告：包含用例通过/失败状态、缺陷描述、截图证据
- 问题跟踪表：格式为“问题编号-严重级别-责任方-修复状态”
- 用户反馈摘要：记录利益干系人的关键意见和票数
记录模板示例（问题分类列）：
P1-严重逻辑错误：流程无法进入下一环节（必须修复）
P2-交互体验不足：按钮位置不符合习惯（建议优化）
P3-文案歧义：提示信息用户理解错误（修正文案）1.9 异常处理
| 异常情况 | 处理措施 |
|---|---|
| 原型与需求文档严重不一致 | 暂停测试，召集产品和设计进行三方对齐 |
| 测试环境出现技术故障 | 记录故障，切换至截图/录播方式进行人工走查 |
| 利益干系人未达成一致 | 开放投票或决策会议，明确最终裁决者 |
| 测试用例未覆盖关键路径 | 补充用例，延长测试周期不超过 1 天 |
1.10 验收标准
满足以下条件时，本阶段原型测试通过：
- 所有 P1 级问题已解决或已明确解决方案
- 关键路径用例通过率 ≥ 90%
- 未解决的 P2/P3 问题已记录并得到干系人确认
- 输出物（测试报告、问题清单、优化建议）完整归档
常见误区： 原型测试没有通过 / 不通过两分法。即使发现大量问题，只要记录完整、方案明确，即视为有效测试。不要因为追求“完美原型”而延迟进入开发阶段。