2. 原型测试用例的核心要素

原型测试用例设计不仅仅是记录“怎么测”，更需要明确测试的边界条件、执行环境和判定标准。只有将六项核心要素完整定义，才能确保用例具备可复现、可审核、可量化的特性。本章围绕每项要素的适用场景、操作要点与验收标准展开，并通过一张整体结构图呈现六要素之间的关系。

2.1 适用场景

当团队需要对原型进行正式验证（如关键流程走查、交互闭环跑测、异常状态反馈验证）时，必须使用包含完整六要素的用例。适用于以下几种典型场景：

• 里程碑评审前：产品经理提交高保真原型，测试团队基于核心要素编写验证用例，确保交付物无硬伤。
• 可用性测试准备：为外部用户测试设计标准化任务，确保每位被试的操作引导一致。
• 跨角色会签：开发、测试、产品三方共同执行同一套用例，减少因理解偏差导致的重复返工。
• 自动化回归基线：将原型用例中的操作步骤和预期结果作为后续前端自动化脚本的编写依据。

2.2 前置条件

1. 原型文件已定版：原型需经过内部至少一轮审查，确认所有页面跳转、动态面板、变量状态未处于草稿阶段。
2. 测试环境标识明确：原型部署或共享的链接、设备类型、操作系统版本已在测试计划中提前锁定。
3. 测试数据样例已配套：涉及列表、表单、搜索等模块时，需准备至少一组正确的占位数据（如账号、商品ID、关键词）。
4. 依赖服务状态已知：若原型依赖后端Mock API或第三方SDK，需确认接口响应正常且超时阈值已在用例中注明。

2.3 操作步骤

操作步骤的编写需遵循“操作对象 + 操作动作 + 输入数据”的最小粒度描述原则，建议按以下格式组织：

1. 定位触发点：描述用户首先进入的页面或组件（如“首页导航栏最右侧”）。
2. 明确交互手势：点击、长按、左滑、双指缩放等，避免使用“操作”“试试”等模糊动词。
3. 列举输入内容：如果步骤涉及文本输入、勾选选项或文件上传，需给出具体值（如“输入手机号：13800138000”）。
4. 等待状态：说明是否需要等待加载完成、动画结束或接口响应，以及最长等待时间（如“等待加载图标出现不超过3秒”）。
5. 结果确认触发：指明执行完前序动作后，观察哪个区域出现了何种变化（如“订单列表第一行显示‘已完成’状态标签”）。

2.4 核心要素结构与定义（表格）

2.5 责任边界

• 产品经理：提供输入条件中的有效数据范围与业务规则，确认前置依赖不包含未立项的功能。
• 测试工程师：负责编写操作步骤、预期结果与通过准则，并标注测试环境的版本要求。
• 前端开发：协助验证预期结果的可观察性（如某状态字段是否暴露给UI），并在前置依赖中说明Mock数据截止时间。
• 设计交互：确认操作步骤中的手势描述与交互规范一致，提供异常状态下的UI贴图（如空态、网络错误态）。

2.6 记录材料

用例编写完成后，需形成以下交付件：

• 《原型测试用例清单》（Excel或在线表格）：每条用例一行，六要素分列填写。
• 《核心要素检查对照表》：用于测试负责人审查每条用例是否漏填某要素。
• 《输入条件异常池》：集中记录边界/非法输入条件，供后续自动化测试复用。

2.7 异常处理

1. 输入条件不完整：若原型未定义某个输入的正确数据范围，用例暂缓执行，由产品经理补充规格后再进入测试。
2. 操作步骤不可执行：因原型组件缺失或动态面板失效导致步骤无法完成，记录Bug并退回原型修改。
3. 预期结果模糊：若预期结果包含“应该正常显示”“符合交互习惯”等主观描述，需修改为可截屏/可量化的指标。
4. 通过准则与预期结果冲突：例如预期结果写了三条，通过准则却只检查其中两条，需以业务需求为准并统一标准。
5. 测试环境不可达：若用例指定的设备/浏览器无法获取，标注“跳过”并在测试报告中注明环境限制，不可使用近似环境替代执行后再声称通过。

2.8 验收标准

1. 每一条用例的六要素字段均非空，且不可出现“待定”“详见XX文档”之类的跳转依赖。
2. 操作步骤中不包含任何预期性描述（如“确认提交成功”中“确认”属多余）。
3. 预期结果至少可以对应到一条原型中的视觉/状态变化或数据响应。
4. 通过准则必须是从预期结果直接推导出的布尔评价，不得附加其他隐含条件。
5. 前置依赖不得与操作步骤内容重复（如前置依赖已写“用户已登录”，步骤中不应再包含“输入账号密码并点击登录”）。
6. 所有用例经过至少一次交叉审查（测试工程师互审或产品经理走读），审核记录存档。

2.9 核心要素关系结构图（内联SVG）