3. 测试目标与假设定义
适用场景
本章流程适用于以下三类启动情形:
- 新场景建模启动:产品团队首次对某业务域构建场景模型,需要将模糊的业务诉求转化为可验证的测试目标。
- 迭代前假设对齐:已有场景模型,但在新一轮迭代前需确认哪些可用性假设已被验证、哪些仍为待测风险。
- 跨角色口径拉通:业务方、设计、开发和测试对“成功标准”理解不一致,需要通过结构化假设定义统一验收语言。
前置条件
| 编号 | 条件项 | 验收说明 |
|---|---|---|
| PC-1 | 已产出场景模型 v0.1 草稿 | 至少包含场景主线、分支路径和关键触点 |
| PC-2 | 业务目标清单已收集 | 来自产品经理或业务方的原始需求列表(非技术语言) |
| PC-3 | 可用性测试计划已立项 | 明确测试轮次、预算、设备与用户招募渠道 |
| PC-4 | 核心干系人已确认 | 业务负责人、测试负责人、场景模型负责人必须参与假设评审 |
操作步骤
本章流程共四个阶段,每个阶段均需在团队工作坊中完成,建议时长 2–3 小时。
步骤 1:业务目标拆解(Business Goal Decomposition)
将原始业务需求逐层拆解为可观测、可量化的子目标,消除模糊术语。
- 输入:产品经理提供的业务目标清单(如“提升下单转化率”“降低用户操作错误”)。
- 操作:使用 「目标树」 方法,从顶层目标向下分解至操作层。每个子目标必须包含 指标名称 和 目标值区间。
- 示例:
顶层:提升新客首单转化率(当前32% → 目标45%) ├─ 子目标A:缩短商品查找时长(当前58s → 目标≤30s) ├─ 子目标B:减少加购路径步数(当前5步 → 目标≤3步) └─ 子目标C:降低规格选择困惑度(当前改选率22% → 目标≤10%)
步骤 2:可用性假设编写(Usability Hypothesis Writing)
每个子目标对应一条或多条可用性假设,格式为:「如果[用户]在[场景]下使用[方案],那么[可观测结果]将会[达成指标]」。
- 模板:
HYP-{编号}: 如果 [用户角色] 在 [场景节点] 使用 [交互方案], 那么 [可用性指标] 将会 [目标值],因为 [理论依据]。 - 示例:
HYP-003: 如果「首次下单用户」在「商品详情页」使用「智能规格推荐弹窗」, 那么「规格选择时长」将会 ≤10s,因为「聚合选项减少了认知负荷」。
步骤 3:假设优先级排序(Hypothesis Prioritization)
使用 「影响-信心-风险」三维矩阵 对假设排序,筛选本轮测试应当覆盖的高价值假设。
| 维度 | 评分标准(1–5 分) | 权重 |
|---|---|---|
| 影响(Impact) | 该假设对核心业务目标的影响程度 | 40% |
| 信心(Confidence) | 团队有多大把握假设会成立 | 30% |
| 风险(Risk) | 假设不成立可能导致的损失或额外成本 | 30% |
综合得分 = I×0.4 + C×0.3 + R×0.3。每轮测试选取前 3–5 条高优先级假设。
步骤 4:验收标准设定(Acceptance Criteria Definition)
为每条优先假设编写可量化的验收标准,用于判定测试通过/失败。
- 结构:「给定[前置条件],当[操作事件]时,系统应在[时间/状态]内达到[指标阈值]」。
- 示例:
AC-HYP-003: 给定「首次下单用户」进入商品详情页, 当「点击智能规格推荐弹窗」时,规格选择操作应在 10s 内完成, 且弹窗关闭后用户不再返回修改规格。
💡 讲师提示:验收标准必须与步骤 1 的子目标指标形成双向追溯。建议在每条 AC 后标注「关联子目标编号」,如
→ SG-A。
输入输出物
| 类型 | 名称 | 格式/载体 | 负责人 |
|---|---|---|---|
| 输入 | 业务目标清单 | 文档 / 看板 | 产品经理 |
| 输入 | 场景模型 v0.1 草稿 | 图表 / 模型文件 | 场景建模师 |
| 输出 | 目标树分解图 | SVG / 白板截图 | 可用性测试负责人 |
| 输出 | 可用性假设清单(含优先级评分) | 表格 / 电子表格 | 可用性测试负责人 |
| 输出 | 验收标准对照表 | 电子表格 / 测试管理工具 | 测试工程师 |
责任边界
- 产品经理:提供原始业务目标,解释“为什么做”而非“怎么做”;参与假设优先级评审会议。
- 可用性测试负责人:引导工作坊流程,撰写假设草案,维护假设清单版本,驱动优先级评分。
- 场景建模师:提供场景模型上下文,确保假设中的场景节点与模型一致。
- 测试工程师:将验收标准转化为测试用例脚本,在后续测试轮次中执行。
记录材料
本章工作需留存以下记录,归档至项目知识库:
- 工作坊签到表 — 记录参与者、角色、时间。
- 目标树分解照片/截图 — 含评注和修改痕迹。
- 可用性假设清单(v1.0) — 含优先级得分、排序结果。
- 验收标准评审纪要 — 记录争议点、弃置假设的原因。
- 假设-子目标追溯矩阵 — 确保每条假设关联至少一个子目标。
异常处理
| 异常场景 | 处理方式 |
|---|---|
| 业务目标描述过于抽象,无法拆解 | 暂停拆解,由产品经理补充「用户故事地图」,直至每个目标至少包含一个可观测行为。 |
| 假设编写时团队争议过大 | 使用「静默投票 + 分组辩论」法,每人先独立写假设,再合并同类项,最后投票保留前 5 条。 |
| 优先级评分结果高度趋同 | 引入「成本估算」作为第四维度(权重 20%),将实现难度纳入排序因子。 |
| 验收标准与子目标指标脱钩 | 强制检查:每条验收标准必须在目标树上有可追溯的子目标编号,否则退回重写。 |
验收标准
本章交付物通过以下检查项视为合格:
- ✅ 目标树包含至少 3 层分解,每个叶子节点有指标名称 + 目标值区间。
- ✅ 可用性假设清单不少于 8 条,且每条格式严格符合模板。
- ✅ 优先级排序得分已公示,且前 5 条假设已标注本轮测试覆盖。
- ✅ 验收标准对照表覆盖所有优先假设,且每条标准均可独立验证。
- ✅ 所有记录材料已归档至项目知识库,权限开放给核心干系人。
📌 关键检查点:在进入第4章(测试工具与环境配置)之前,必须完成验收标准对照表的评审签名。缺少签名不得进入下一环节。