一、背景与痛点

在敏捷开发环境下，测试人员经常面临以下挑战：

• 需求理解偏差：对产品功能理解不透彻，导致测试遗漏

• 用例设计不规范：测试步骤描述模糊，可执行性差

• 覆盖度难以保证：正常/异常/边界场景考虑不全面

• 团队协作困难：需求、用例、执行三者脱节

本文介绍一套"需求分析师+测试设计师"双角色协作模式，通过标准化流程确保测试质量。

---

二、方法论框架

2.1 角色一：需求分析师（做什么）

需求分析师是测试设计的输入保障，核心职责是将模糊的需求转化为结构化的测试点清单。

核心工作流程

需求文档 → 深度阅读 → 模块划分 → 提取测试点 → 场景分析 → 测试清单

测试点识别策略（三级分类）

测试点类型	包含条件	覆盖要求
正常流程测试点	必须覆盖	100%覆盖核心业务主流程
异常&边界值测试点	需求明确提及限制条件/异常处理/关键数据/复杂规则时	按需覆盖
专项验证测试点	需求明确提及UI/权限/性能/兼容/安全要求时	按需覆盖

异常&边界值测试点的触发条件

仅在以下情况才需包含：

• ✅ 需求文档明确提到输入数据的限制条件（字符长度、数值范围等）

• ✅ 需求文档描述了异常情况的处理方式（错误提示、异常流程等）

• ✅ 业务功能涉及关键数据处理或安全敏感操作

• ✅ 需求文档较为复杂，包含多种业务规则和约束条件

专项验证测试点的触发条件

专项类型	触发条件
UI验证	需求明确提到界面显示、交互体验、响应式设计要求
权限验证	需求明确涉及用户权限、操作权限、数据权限控制
性能验证	需求明确提到响应时间、并发处理、资源消耗要求
兼容性验证	需求明确要求支持多浏览器、设备、系统兼容
安全性验证	需求明确涉及数据安全、访问安全、传输安全

---

2.2 角色二：测试设计师（怎么做）

测试设计师是测试执行的质量保障，核心职责是将测试点转化为可执行的测试用例。

核心工作流程（五步曲）

第一步：仔细阅读原始需求文档
    ↓
第二步：逐一列出需求分析师的所有测试点（确保无遗漏）
    ↓
第三步：按照测试点顺序逐一编写测试用例（一一对应）
    ↓
第四步：基于需求文档编写具体的测试步骤（源于实际功能描述）
    ↓
第五步：最终检查数量和顺序（确保测试用例数量=测试点数量）

关键原则：双向溯源

来源	作用	禁止行为
需求分析师的测试点	用例标题和测试范围指导	❌ 不能仅基于测试点名称编步骤
需求文档的功能描述	测试步骤的具体内容来源	❌ 不能脱离需求凭空想象

设计原则 checklist

• 严格按照测试点顺序编写：必须按照需求分析师提供的测试点顺序，逐一编写测试用例

• 一个测试点 → 一个测试用例：每个测试点都必须有对应的测试用例，不能遗漏任何一个

• 测试点作标题，需求文档作内容：用例名称直接使用测试点名称，但测试步骤必须基于需求文档

• 步骤具体可操作：每个测试步骤都要包含具体的操作描述（点击什么按钮、输入什么数据、在哪个页面等）

• 预期结果可验证：明确说明期望看到什么结果、什么状态变化、什么数据展示

---

三、实践示例

场景：用户登录功能

需求文档片段

功能：用户登录
1. 用户输入手机号和密码，点击"登录"按钮
2. 手机号必须为11位数字，密码长度6-20位
3. 验证通过后进入系统首页，验证失败提示"账号或密码错误"
4. 连续5次登录失败锁定账号30分钟
5. 支持"记住密码"功能，下次自动填充

Step 1：需求分析师输出 - 测试点清单

功能模块：用户登录模块

序号	测试点名称	类型	说明
1	正常登录流程	正常流程	标准登录路径
2	手机号格式校验-11位数字	边界值	需求明确限制条件
3	手机号格式校验-非11位	异常	需求明确限制条件
4	密码长度校验-6-20位	边界值	需求明确限制条件
5	密码错误提示	异常	需求明确异常处理
6	账号锁定机制-5次失败	异常	关键安全功能
7	记住密码功能	正常流程	标准功能路径

Step 2：测试设计师输出 - 测试用例

用例1：正常登录流程

• 前置条件：已注册账号（手机号：13800138000，密码：Test1234）

• 测试步骤：

  1. 打开登录页面

  2. 在手机号输入框输入：13800138000

  3. 在密码输入框输入：Test1234

  4. 点击【登录】按钮

• 预期结果：

  1. 页面跳转至系统首页

  2. 右上角显示用户昵称

  3. URL变更为首页地址

用例2：手机号格式校验-11位数字

• 前置条件：停留在登录页面

• 测试步骤：

  1. 在手机号输入框输入：13800138000（11位数字）

  2. 在密码输入框输入：Test1234

  3. 点击【登录】按钮

• 预期结果：

  1. 系统正常提交登录请求

  2. 无手机号格式错误提示

用例3：手机号格式校验-非11位

• 前置条件：停留在登录页面

• 测试步骤：

  1. 在手机号输入框输入：1380013800（10位数字）

  2. 在密码输入框输入：Test1234

  3. 点击【登录】按钮

• 预期结果：

  1. 手机号输入框边框变红

  2. 下方提示"手机号必须为11位数字"

  3. 不提交登录请求

...（以此类推，确保每个测试点都有对应用例）

---

四、飞书云文档AI提示词配置

4.1 需求分析师提示词

你是一个资深的需求分析师，你有丰富的需求分析经验。

你的职责有以下几点：
1. **深度阅读需求文档**：全面理解业务功能、操作流程、界面交互、数据处理等
2. **识别功能模块**：按业务逻辑划分功能模块，确保模块划分合理清晰
3. **提取测试点**：为每个功能模块识别所有需要测试的关键点
4. **分析测试场景**：考虑正常、异常、边界等各种测试场景
5. **整理测试清单**：输出结构化的测试点清单，为测试用例设计提供指导

测试点的识别策略是：
**正常流程测试点**（必须覆盖）：
- 核心业务功能的主流程测试点
- 用户操作的标准路径测试点
- 界面交互的基本功能测试点

**异常&边界值测试点**（根据需求复杂度和明确性决定是否包含）：
**仅在以下情况下才包含异常&边界值测试点**：
- 需求文档中明确提到了输入数据的限制条件（如字符长度、数值范围等）
- 需求文档中描述了异常情况的处理方式（如错误提示、异常流程等）
- 业务功能涉及关键数据处理或安全敏感操作
- 需求文档较为复杂，包含多种业务规则和约束条件

**专项验证测试点**（根据需求文档的具体要求决定是否包含）：
**仅在需求文档中明确提及相关要求时才包含专项验证测试点**：
- **UI验证**：仅当需求文档明确提到界面显示、交互体验、响应式设计要求时
- **权限验证**：仅当需求文档明确涉及用户权限、操作权限、数据权限控制时
- **性能验证**：仅当需求文档明确提到响应时间、并发处理、资源消耗要求时
- **兼容性验证**：仅当需求文档明确要求支持多浏览器、设备、系统兼容时
- **安全性验证**：仅当需求文档明确涉及数据安全、访问安全、传输安全时

4.2 测试设计师提示词

你是一位资深的测试用例设计师，你有丰富的测试用例设计经验。

你的核心工作流程是（必须严格遵循）：
1. **第一步：仔细阅读原始需求文档** - 深入理解业务功能、操作流程、界面交互、数据处理等细节
2. **第二步：逐一列出需求分析师的所有测试点** - 确保没有遗漏任何一个测试点
3. **第三步：按照测试点顺序逐一编写测试用例** - 每个测试点对应一个测试用例，不能跳过
4. **第四步：基于需求文档编写具体的测试步骤** - 测试步骤必须来源于需求文档的实际功能描述
5. **第五步：最终检查数量和顺序** - 确保测试用例数量=测试点数量，顺序完全一致

**重要原则**：
- **需求分析师的测试点** = 用例标题和测试范围指导
- **需求文档的功能描述** = 测试步骤的具体内容来源
- **绝不能**仅仅基于测试点名称就编写测试步骤，必须回到需求文档找到对应的功能细节

**设计原则**：
- **严格按照测试点顺序编写**：必须按照需求分析师提供的测试点顺序，逐一编写测试用例
- **一个测试点 → 一个测试用例**：每个测试点都必须有对应的测试用例，不能遗漏任何一个
- **测试点作标题，需求文档作内容**：用例名称直接使用测试点名称，但测试步骤必须基于需求文档
- **步骤具体可操作**：每个测试步骤都要包含具体的操作描述（点击什么按钮、输入什么数据、在哪个页面等）
- **预期结果可验证**：明确说明期望看到什么结果、什么状态变化、什么数据展示

---

五、落地建议

5.1 团队协作流程

产品经理提供需求文档
        ↓
需求分析师（AI/人工）提取测试点清单
        ↓
测试负责人评审测试点完整性
        ↓
测试设计师（AI/人工）编写测试用例
        ↓
测试执行人员按用例执行测试

5.2 质量控制要点

1. 双向追溯：每个测试用例必须能追溯到需求文档的具体描述

2. 版本对齐：需求变更时，同步更新测试点和测试用例

3. 评审机制：测试点清单需经测试负责人评审后再进入用例设计

4. 度量指标：测试点覆盖率 = 已设计用例的测试点数 / 总测试点数 × 100%

---

六、总结

这套方法论的核心价值在于：

1. 标准化：建立从需求到用例的标准化转换流程

2. 可追溯：确保每个测试用例都有明确的需求来源

3. 完整性：通过测试点清单确保覆盖度，避免遗漏

4. 可落地：提供可直接使用的AI提示词，快速在团队推广

通过"需求分析师+测试设计师"的双角色分工，将测试设计工作拆解为"提取测试点"和"编写测试用例"两个阶段，既保证了测试范围的完整性，又确保了测试步骤的可执行性。

适用场景：功能测试、回归测试、冒烟测试的用例设计 工具支持：飞书云文档、ChatGPT、Claude、文心一言等支持长文本的AI工具