第1章 原型测试用例概述：定义、价值与适用范围
1.1 适用场景
原型测试用例适用于产品开发早期阶段，用于验证设计假设、交互流程与技术可行性。典型场景包括：
- 硬件原型：功能样板机、结构手板、电路验证板的功能与装配测试。
- 软件原型：MVP演示版、核心功能Demo、API骨架的接口与数据流测试。
- 交互原型：可点击线框图、高保真设计稿的用户操作路径与反馈测试。
关键判断：只要被测物尚未进入工程验证阶段（EVT/DVT）或正式编码完成阶段，都应使用原型测试用例而非正式测试用例。
1.2 前置条件
| 条件类别 | 具体说明 |
|---|---|
| 原型就绪 | 硬件样板已焊接/组装完成；软件分支已编译部署；交互原型已上传至可点击环境。 |
| 设计文档 | 至少具备产品需求文档、交互设计稿或功能规格说明（草案级即可）。 |
| 环境准备 | 测试工具、串口线、抓包代理、录屏软件等已安装并验证连通性。 |
| 角色确认 | 原型测试由产品经理+开发代表+测试代表共同执行，无需独立QA团队。 |
1.3 操作步骤
- 步骤一：拆解测试目标 — 从设计文档中提取本次原型需要验证的核心假设点（不超过5个）。
- 步骤二：编写用例草稿 — 每个假设点对应1~3条用例，只写前置条件、操作摘要、预期结果三栏。
- 步骤三：执行与记录 — 按照用例顺序逐条操作，用手机/截图/录屏记录实际结果。
- 步骤四：标记结论 — 每条用例标记为通过 / 部分通过 / 不通过，并附1~2句现象描述。
- 步骤五：汇总反馈 — 将不通过项整理为“设计改进清单”，提交给产品经理与设计师。
1.4 输入输出物
| 方向 | 内容 |
|---|---|
| 输入物 | 原型样机/可执行文件/可点击原型；产品需求文档（草案）；交互设计稿（线框图/高保真）。 |
| 输出物 | 原型测试用例草稿表；执行结果记录（截图/视频/现场笔记）；设计改进清单。 |
| 归档格式 | 共享表格或在线文档，每条用例保留“目标-操作-结果-结论-改进建议”五字段。 |
1.5 责任边界
- 产品经理：提供核心假设与验收标准；参与结果评审并决策是否修改设计。
- 开发代表：确保原型可运行；协助定位环境问题；记录技术限制。
- 测试代表：编写用例草稿、执行测试、汇总结果与改进清单。
- 设计师（可选）：参与交互原型测试，记录用户操作困惑点。
责任边界提醒：原型测试不承担“缺陷追踪”职责，不录入缺陷管理系统；所有发现均以改进清单形式反馈，不纳入缺陷率考核。
1.6 记录材料
| 材料类型 | 保存要求 |
|---|---|
| 原型测试用例表 | 以“项目名_原型测试_日期”命名，保留历史版本。 |
| 操作录屏/截图 | 按用例编号存放至共享文件夹，文件名含用例ID。 |
| 改进清单 | 与用例表分离，单独维护为“设计待办列表”，跟踪至下一轮原型或正式开发。 |
| 会议纪要 | 如召开结果评审会，保留结论与决策理由。 |
1.7 异常处理
| 异常情形 | 处理方式 |
|---|---|
| 原型无法启动/崩溃 | 暂停测试，由开发修复后重新开始；记录环境与复现步骤。 |
| 用例预期与实际偏差过大 | 标注“部分通过”并写明差异描述，不强制通过。 |
| 测试中途需求变更 | 停止当前用例，更新用例表后重新测试；已执行用例保留历史版本。 |
| 多人测试结论冲突 | 由产品经理做最终判定；必要时组织15分钟快速评审。 |
1.8 验收标准
- 所有核心假设点对应用例执行率 100%。
- 每条用例均有通过 / 部分通过 / 不通过结论及现象描述。
- 至少提交 1 份设计改进清单，包含优先级与建议方案。
- 记录材料完整归档：用例表 + 截图/录屏 + 改进清单。
注意：原型测试的验收标准不要求“全部通过”，而是“全部验证并记录”。关键价值在于暴露设计盲区，而非证明产品合格。
1.9 原型测试用例与正式测试用例的差异
| 对比维度 | 原型测试用例 | 正式测试用例 |
|---|---|---|
| 目标 | 验证设计假设与可行性 | 验证功能正确性与稳定性 |
| 详细度 | 三栏草稿（前置+操作+预期） | 完整字段（ID、步骤、数据、环境、预期、后置等） |
| 执行者 | 产品+开发+测试代表 | 独立测试团队 |
| 缺陷管理 | 不录入缺陷系统，以改进清单呈现 | 录入缺陷系统，追踪至修复关闭 |
| 通过标准 | 全部验证并记录即可 | 全部通过或缺陷已闭环 |
| 生命周期 | 随原型迭代更新，原型废弃后归档 | 随正式版本维护，长期复用 |
核心结论：原型测试用例是“设计验证工具”，正式测试用例是“质量检验工具”。两者在阶段、详细度、责任归属上存在本质区别，不能混用。