第 1 章：明确测试目标与范围
适用场景
本章适用于以下场景：
- 项目启动初期，需要确定用户测试的总体方向。
- 产品需求文档（PRD）已初步完成，但测试团队尚未介入。
- 跨职能团队（产品、设计、开发）对测试对象和边界存在分歧。
- 资源有限，需要聚焦测试核心功能和高风险用户群体。
前置条件
- 产品需求文档（PRD）或功能规格说明书已评审通过或处于可讨论状态。
- 已获取初步的用户画像或目标用户调研数据（如没有，可通过访谈快速补全）。
- 测试团队已分配至少 1 名测试负责人，且有权参与产品讨论。
- 项目排期已确定测试窗口（如 Sprint 的最后 3 天）。
操作步骤
- 发起目标对齐会议：测试负责人召集产品、设计、开发代表，使用 PRD 逐条确认测试目的（例如：验证支付流程可用性、评估新用户注册转化率）。
- 明确测试目的：将会议结论转化为 1~3 条核心测试目标，每条目标需包含可量化指标（如“首次完成支付时长≤30秒”）。
- 定义核心用户群体：基于用户画像数据，筛选出覆盖主要行为路径的用户角色（如“新注册用户”“高净值付费用户”），并排除边缘角色。
- 划定功能边界：使用需求跟踪矩阵，标注本轮测试覆盖的功能模块（如“登录模块”“支付模块”），并明确不测试的功能及理由。
- 输出测试范围确认文档：将前四步结果整理为测试范围声明，由产品负责人签字确认。
输入 / 输出物
| 输入物 | 输出物 |
|---|---|
| 产品需求文档（PRD） | 测试范围声明（含测试目的、核心用户群、功能边界清单） |
| 用户画像 / 调研数据 | 测试目标优先级矩阵 |
| 项目时间窗口表 | 测试范围确认签字（邮件或文档签字） |
责任边界
| 角色 | 职责 |
|---|---|
| 测试负责人 | 主持会议、起草测试范围声明、推动签字确认 |
| 产品经理 | 提供 PRD、确认测试目的、签字批准范围 |
| 设计师 | 提供用户画像数据、确认用户群体定义合理性 |
| 开发代表 | 协助评估功能边界的技术可行性，提供不测试功能的依据 |
记录材料
- 测试范围声明（包含版本号、签署日期）
- 会议纪要（记录分歧点及最终决策理由）
- 测试目标优先级矩阵（可采用 MoSCoW 法标记 Must / Should / Could / Won‘t）
- 用户群体选择记录（列出选中的用户角色及排除理由）
异常处理
异常 1：产品需求未冻结
若 PRD 仍在频繁变更，测试负责人应推动产品方确认 最低稳定版本，并标注“测试范围随 PRD 更新而调整”，在输出物中标记为“待定”。不可在需求未确定时开展测试设计。
若 PRD 仍在频繁变更，测试负责人应推动产品方确认 最低稳定版本，并标注“测试范围随 PRD 更新而调整”，在输出物中标记为“待定”。不可在需求未确定时开展测试设计。
异常 2：核心用户群体无法定义
若用户画像数据缺失，建议快速进行 3~5 场用户访谈或发起内部研讨会，至少获取 2 个典型角色。不要使用“所有用户”作为群体定义。
若用户画像数据缺失，建议快速进行 3~5 场用户访谈或发起内部研讨会，至少获取 2 个典型角色。不要使用“所有用户”作为群体定义。
异常 3：功能边界争议
当产品方希望覆盖全部功能而测试资源不足时，请使用“风险排序法”：列出所有功能，按影响面和出现概率打分，仅覆盖总分前 30% 的高风险功能。争议无法调和时，上升至项目决策委员会。
当产品方希望覆盖全部功能而测试资源不足时，请使用“风险排序法”：列出所有功能，按影响面和出现概率打分，仅覆盖总分前 30% 的高风险功能。争议无法调和时，上升至项目决策委员会。
验收标准
- 测试范围声明已获得产品负责人签字确认。
- 核心用户群体明确，且至少覆盖产品目标的 80% 用户行为路径。
- 功能边界清单中明确标注了“测试范围”与“不测试范围”及其理由。
- 所有输入物（PRD、用户画像）均存储于项目共享文档库，可追溯。
本章要点总结
目标与范围是用户测试的“第一道防线”。缺少明确的范围，后续反馈收集可能偏离核心、浪费资源。务必在测试开始前与产品方达成书面共识。
目标与范围是用户测试的“第一道防线”。缺少明确的范围，后续反馈收集可能偏离核心、浪费资源。务必在测试开始前与产品方达成书面共识。