第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 内完成，
  且弹窗关闭后用户不再返回修改规格。

输入输出物

类型	名称	格式/载体	负责人
输入	业务目标清单	文档 / 看板	产品经理
输入	场景模型 v0.1 草稿	图表 / 模型文件	场景建模师
输出	目标树分解图	SVG / 白板截图	可用性测试负责人
输出	可用性假设清单（含优先级评分）	表格 / 电子表格	可用性测试负责人
输出	验收标准对照表	电子表格 / 测试管理工具	测试工程师

责任边界

• 产品经理：提供原始业务目标，解释“为什么做”而非“怎么做”；参与假设优先级评审会议。
• 可用性测试负责人：引导工作坊流程，撰写假设草案，维护假设清单版本，驱动优先级评分。
• 场景建模师：提供场景模型上下文，确保假设中的场景节点与模型一致。
• 测试工程师：将验收标准转化为测试用例脚本，在后续测试轮次中执行。

记录材料

本章工作需留存以下记录，归档至项目知识库：

1. 工作坊签到表 — 记录参与者、角色、时间。
2. 目标树分解照片/截图 — 含评注和修改痕迹。
3. 可用性假设清单（v1.0） — 含优先级得分、排序结果。
4. 验收标准评审纪要 — 记录争议点、弃置假设的原因。
5. 假设-子目标追溯矩阵 — 确保每条假设关联至少一个子目标。

异常处理

异常场景	处理方式
业务目标描述过于抽象，无法拆解	暂停拆解，由产品经理补充「用户故事地图」，直至每个目标至少包含一个可观测行为。
假设编写时团队争议过大	使用「静默投票 + 分组辩论」法，每人先独立写假设，再合并同类项，最后投票保留前 5 条。
优先级评分结果高度趋同	引入「成本估算」作为第四维度（权重 20%），将实现难度纳入排序因子。
验收标准与子目标指标脱钩	强制检查：每条验收标准必须在目标树上有可追溯的子目标编号，否则退回重写。

验收标准

本章交付物通过以下检查项视为合格：

• ✅ 目标树包含至少 3 层分解，每个叶子节点有指标名称 + 目标值区间。
• ✅ 可用性假设清单不少于 8 条，且每条格式严格符合模板。
• ✅ 优先级排序得分已公示，且前 5 条假设已标注本轮测试覆盖。
• ✅ 验收标准对照表覆盖所有优先假设，且每条标准均可独立验证。
• ✅ 所有记录材料已归档至项目知识库，权限开放给核心干系人。