第1章 可用性测试场景假设概述：测试目标、假设要素、验证逻辑
1.1 适用场景
本章内容适用于以下三类典型场景，团队可根据实际阶段对号入座：
- 产品概念验证期：尚未形成完整交互原型，仅有低保真线框或故事板，需快速判断核心场景假设是否成立。
- 关键流程改版前：已有线上版本，计划对注册、支付、搜索等主干流程进行重构，需预先验证新场景假设的有效性。
- 跨角色对齐会议：产品、设计、开发对用户行为预期存在分歧，需通过场景假设验证建立统一认知基准。
核心判断标准：当团队对“用户在什么情境下、因什么动机、采取什么操作”存在三个以上不确定点时，即应启动场景假设验证。
1.2 前置条件
执行本章内容前，必须完成以下四项基础准备，缺一不可：
| # | 检查项 | 验收依据 | 状态 |
|---|---|---|---|
| 1 | 明确测试发起方与核心问题 | 已记录至少1个待验证的业务或用户行为问题 | ☐ |
| 2 | 初步用户画像（Proto-Persona） | 包含用户身份、核心目标、典型痛点三要素 | ☐ |
| 3 | 关键场景列表 | 按优先级排序，至少3个候选场景 | ☐ |
| 4 | 测试资源确认 | 可用用户招募渠道、测试时长、记录设备已就位 | ☐ |
提示：前置条件中的检查清单建议由测试设计师与产品经理共同签字确认，避免因准备不足导致验证结论无效。
1.3 测试目标、假设要素与验证逻辑
本章核心围绕三个概念展开，下表从定义、构成维度和交付形态三个角度进行对比：
| 概念 | 定义 | 核心构成维度 | 典型交付形态 |
|---|---|---|---|
| 测试目标 | 本次可用性测试希望回答的关键问题 | 行为可观察、结果可测量、边界可定义 | 一句话假设陈述 |
| 假设要素 | 场景中影响用户行为的可变量 | 用户特征、任务情境、系统状态、环境因素 | 假设要素清单 |
| 验证逻辑 | 从假设到结论的推理链路与判断标准 | 预期行为→实际行为→差异分析→结论判定 | 验证逻辑框架图 |
三者的关系可用一条完整的验证链路概括：测试目标定义“验证什么”，假设要素界定“在什么条件下验证”，验证逻辑规定“如何判断验证通过”。
关键提示：验证逻辑不是单向流水线，每个环节都允许“回退修正”。例如数据评估后发现假设要素遗漏，应返回假设要素提取环节补充变量，而非强行通过。
1.4 输入输出物
| 类型 | 名称 | 格式/载体 | 责任人 |
|---|---|---|---|
| 输入物 | 测试目标陈述表 | 结构化文档（1页） | 产品经理 |
| 用户画像卡片 | A4单页 / Miro看板 | UX研究员 | |
| 候选场景清单 | 电子表格 / 任务管理卡片 | 测试设计师 | |
| 输出物 | 假设要素清单（含优先级） | 结构化文档（2~4页） | 测试设计师 |
| 验证逻辑框架图 | SVG / PNG / 白板截图 | 测试设计师 |
最佳实践：输入物建议在测试启动会前24小时完成归档，输出物应在测试结束后3个工作日内定稿，避免信息衰减。
1.5 责任边界
清晰的责任划分是场景假设验证不跑偏的保障，各角色边界如下：
- 产品经理：提供业务目标和待验证问题，对测试目标的业务价值负责。
- UX研究员：主导用户画像真实性校验，对假设要素的生态效度负责。
- 测试设计师：负责场景脚本编制和验证逻辑设计，对测试结论的可复现性负责。
- 开发工程师：提供系统状态配置和埋点支持，对测试环境的技术准确性负责。
- 决策者（如设计总监/产品总监）：根据验证结论做出继续/迭代/终止的决策，对资源投入负责。
常见边界冲突：测试设计师容易越界替产品经理定义“正确目标”，导致验证逻辑与业务脱节。建议在目标陈述阶段设置“双重签字”检查点。
1.6 记录材料
本章涉及的记录材料分为两类，所有材料应统一编号并归档至项目知识库：
| 材料编号 | 名称 | 记录内容 | 保存期限 |
|---|---|---|---|
| R01 | 测试目标确认单 | 目标原文、提出方、确认时间、版本号 | 项目结项后6个月 |
| R02 | 假设要素推导日志 | 每个要素的原始来源、推导过程、排除理由 | 项目结项后12个月 |
| R03 | 验证逻辑评审纪要 | 评审参会人、质疑点、修改决议 | 项目结项后12个月 |
| R04 | 场景脚本基线版 | 任务描述、预期行为、测量指标 | 项目结项后24个月 |
审计要求：若测试结论将影响产品上线决策，R01~R04 必须全部归档且不可篡改，建议使用带有时间戳的文档管理工具。
1.7 异常处理
场景假设验证过程中可能出现的异常及应对措施：
| 异常场景 | 触发条件 | 处理措施 | 输出调整 |
|---|---|---|---|
| 测试目标漂移 | 验证过程中业务方临时提出新目标 | 暂停当前验证，召开目标对齐会，重新确认优先级 | 更新 R01 测试目标确认单 |
| 假设要素与实际用户行为严重偏差 | 前3名测试用户的行为均不符合预期要素 | 中止测试，回退至假设要素提取环节进行修正 | 更新 R02 假设要素推导日志 |
| 测试环境技术故障 | 系统状态无法复现假设中的环境条件 | 记录故障详情，切换为备用环境或推迟测试 | 在 R04 脚本基线版中标注环境异常 |
| 验证结论无法收敛 | 数据评估后正反证据各占50% | 组织小型专家评审会，补充定性访谈后重新评估 | 更新 R03 验证逻辑评审纪要 |
特别提示：异常处理的核心原则是“先停再修，不强行通过”。任何绕过异常处理流程直接修改结论的行为，都将导致整个验证失效。
1.8 验收标准
本章内容交付物需通过以下验收检查清单方可视为完成：
| 验收项 | 验收标准 | 检查方式 | 通过 |
|---|---|---|---|
| 测试目标可测量 | 目标中包含至少1个可量化的行为指标（如点击率、完成时长） | 文本审查 | ☐ |
| 假设要素覆盖率 | 覆盖用户特征、任务情境、系统状态、环境因素4个维度 | 维度核对 | ☐ |
| 验证逻辑闭环 | 从目标到结论的推理链路无断裂，每个节点有判定标准 | 流程图走查 | ☐ |
| 记录材料完整性 | R01~R04 四项材料齐全，版本号一致 | 归档检查 | ☐ |
| 异常处理预案 | 至少覆盖4种异常场景并有明确处理路径 | 预案清单核对 | ☐ |
| 责任边界签字 | 产品经理、UX研究员、测试设计师三方签字确认 | 签字页审查 | ☐ |
验收时机：上述检查应在进入第2章“场景假设构建方法”之前完成，未通过项须在1个工作日内修正并重新验收。