敏捷测试教程（软件测试人员专用）¶
教程简介
本教程面向软件测试工程师，讲解敏捷开发模式下测试人员的工作方式、协作流程和实践方法。
前置要求¶
| 项目 | 要求 | 获取方式 |
|---|---|---|
| 软件测试理论基础 | 了解测试流程、测试级别、用例设计 | 软件测试理论基础教程 |
新手导读¶
敏捷测试重点不是背 Scrum 名词，而是理解测试人员如何在快节奏迭代中提前参与需求、持续反馈风险。
第一遍建议抓住这些问题：
- 什么是迭代、用户故事、验收标准。
- 测试人员什么时候介入需求评审。
- 如何把验收标准转成测试点。
- 为什么敏捷团队需要持续测试和自动化回归。
学完后，你应该能看懂一个用户故事，并写出对应的验收测试点。
一、敏捷基础¶
1.1 敏捷是什么¶
敏捷是一种 迭代式、增量式 的软件开发方法，核心理念：
- 个体与互动 高于流程与工具
- 可工作的软件 高于详尽的文档
- 客户协作 高于合同谈判
- 响应变化 高于遵循计划
1.2 敏捷 vs 瀑布¶
| 维度 | 瀑布 | 敏捷 |
|---|---|---|
| 周期 | 长（数月） | 短（1-4 周迭代） |
| 需求 | 前期固定 | 每个迭代可调整 |
| 测试阶段 | 编码后才开始 | 全程参与 |
| 反馈 | 上线后才得到 | 每个迭代末评审 |
| 风险 | 后期暴露 | 持续暴露 |
| 文档 | 重文档 | 够用即可 |
1.3 敏捷宣言十二原则（节选）¶
- 尽早持续交付可工作的软件
- 欢迎需求变更
- 业务人员与开发人员每天协作
- 面对面沟通最有效
- 可工作的软件是进度的首要度量
- 保持可持续的开发节奏
- 技术卓越与良好设计
二、Scrum 框架¶
Scrum 是最流行的敏捷框架。
2.1 核心角色¶
| 角色 | 职责 |
|---|---|
| Product Owner（PO） | 管理需求优先级，代表业务方 |
| Scrum Master（SM） | 保障流程执行，移除障碍 |
| 开发团队 | 开发 + 测试 + 设计（跨职能自组织） |
2.2 Scrum 事件¶
| 事件 | 频率 | 时长 | 目的 |
|---|---|---|---|
| Sprint | 持续 | 1-4 周 | 一个迭代周期 |
| Sprint Planning | 每个 Sprint 开始 | 最多 8 小时（1 月 Sprint），按比例缩放 | 确定本迭代做什么 |
| Daily Standup | 每天 | 15 分钟 | 同步进展、暴露问题 |
| Sprint Review | 每个 Sprint 结束 | 1-2 小时 | 展示成果、收集反馈 |
| Sprint Retrospective | 每个 Sprint 结束 | 1 小时 | 回顾改进 |
2.3 核心工件¶
| 工件 | 说明 |
|---|---|
| Product Backlog | 所有需求的优先级列表（PO 维护） |
| Sprint Backlog | 本迭代要完成的需求 |
| Increment | 本迭代交付的可工作软件 |
2.4 Sprint 流程¶
Sprint Planning → 每日开发 → Sprint Review → Retrospective
↓ ↓ ↓ ↓
确定范围 Daily Standup 展示成果 回顾改进
拆分任务 编码+测试 收集反馈 优化流程
三、测试人员在敏捷中的角色¶
3.1 角色转变¶
| 传统测试 | 敏捷测试 |
|---|---|
| 独立测试团队 | 嵌入开发团队 |
| 需求文档驱动 | 用户故事驱动 |
| 编码后才测试 | 全程参与 |
| 手工执行为主 | 自动化为主 |
| 质量守门员 | 质量教练 |
| 发现缺陷 | 预防缺陷 |
3.2 测试人员的职责¶
Sprint Planning 阶段： - 参与需求评审 - 拆分测试任务 - 评估测试工作量 - 识别风险点
开发阶段： - 编写自动化测试用例 - 与开发并行测试 - 探索性测试 - 接口测试先于 UI 测试
Sprint Review 阶段： - 展示测试结果 - 反馈质量问题 - 参与验收
Retrospective 阶段： - 回顾测试过程 - 提出改进建议
3.3 测试左移与右移¶
左移（Shift Left）：尽早介入
需求 → 设计 → 编码 → 测试 → 发布
↑ 测试从这里开始参与
右移（Shift Right）：上线后持续关注
发布 → 生产监控 → 用户反馈 → 持续改进
↑ 测试也参与
左移实践： - 参加需求评审，提前发现歧义 - 提前写测试用例，帮助开发理解预期 - 接口测试在 UI 开发前完成
右移实践： - 监控线上错误日志 - 分析用户反馈 - 参与生产环境验证
四、用户故事与验收标准¶
4.1 什么是用户故事¶
用户故事是需求的最小单元，格式：
4.2 验收标准（Acceptance Criteria）¶
每个用户故事必须有验收标准，定义"完成"的条件。
格式示例：
用户故事：作为用户，我想要重置密码，以便找回账号
验收标准：
1. 输入注册邮箱，系统发送重置链接
2. 链接 24 小时内有效
3. 点击链接后可设置新密码
4. 新密码需满足：8-20 位，含大小写和数字
5. 密码重置后，旧密码立即失效
6. 重置成功后跳转到登录页，提示"密码已重置"
4.3 Given-When-Then 格式¶
验收标准也可用 BDD 风格：
4.4 测试人员参与用户故事¶
Sprint Planning 时： - 检查验收标准是否完整 - 补充异常场景 - 评估可测试性 - 拆分测试任务
示例任务拆分：
用户故事：登录功能
├── 测试任务 1：编写接口自动化用例（2h）
├── 测试任务 2：编写 UI 自动化用例（1h）
├── 测试任务 3：探索性测试异常场景（1h）
└── 测试任务 4：跨浏览器验证（0.5h）
五、敏捷测试策略¶
5.1 测试金字塔（敏捷版）¶
╱╲
╱UI ╲ 少量（5%）
╱──────╲ 端到端验证
╱ 接口 ╲ 中量（20-25%）
╱──────────╲ 业务逻辑验证
╱ 单元测试 ╲ 大量（70%+）
╱──────────────╲ 快速反馈
敏捷强调： 自动化测试占比高，手工测试聚焦探索性测试。
5.2 四象限测试¶
支持团队 评价产品
┌─────────────────┬─────────────────┐
手工为主 │ Q2: 功能测试 │ Q3: 探索性测试 │ 手工为主
│ 接口测试 │ 用户体验测试 │
│ （测试主导） │ Alpha/Beta 测试 │
├─────────────────┼─────────────────┤
自动化 │ Q1: 单元测试 │ Q4: 性能测试 │ 自动化
│ 组件测试 │ 安全测试 │
│ （开发负责） │ 可靠性测试 │
└─────────────────┴─────────────────┘
- Q1：开发负责，测试协助
- Q2：测试核心工作（接口自动化、功能自动化）
- Q3：手工探索性测试、用户体验
- Q4：专项测试（性能、安全）
5.3 每个迭代的测试活动¶
| Sprint 阶段 | 测试活动 |
|---|---|
| Planning | 需求评审、用例设计、任务拆分 |
| 开发前期 | 接口自动化（与开发并行） |
| 开发中期 | UI 自动化、集成测试 |
| 开发后期 | 探索性测试、回归测试 |
| Review | 验收测试、展示结果 |
| Retrospective | 回顾测试过程、改进 |
5.4 冒烟测试与回归测试¶
冒烟测试（Smoke Test）： - 每个构建自动执行 - 覆盖核心流程（登录、下单、支付） - 失败则阻塞后续测试
回归测试（Regression Test）： - 每个 Sprint 结束执行 - 覆盖所有自动化用例 - 确保新功能不影响老功能
六、持续测试¶
6.1 持续集成中的测试¶
每个阶段都有测试，失败则阻塞后续。
6.2 测试门禁（Quality Gate）¶
# 示例：Jenkins 流水线门禁
quality_gates:
- name: 单元测试通过率
threshold: 95%
current: 98% # ✅
- name: 接口测试通过率
threshold: 90%
current: 92% # ✅
- name: 代码覆盖率
threshold: 70%
current: 65% # ❌ 阻塞发布
- name: 严重缺陷数
threshold: 0
current: 1 # ❌ 阻塞发布
6.3 测试报告与反馈¶
每日： - 自动化测试结果通知（钉钉/企业微信） - 失败用例当天修复
每 Sprint： - 测试覆盖率报告 - 缺陷统计 - 遗留风险
七、敏捷测试实践¶
7.1 实践一：结对测试¶
测试人员与开发人员结对工作：
- 开发写代码时，测试写用例
- 开发提交前，测试先验证
- 减少后期返工
7.2 实践二：三 Amigos 会议¶
需求讨论时，三方一起：
产出：明确的用户故事 + 验收标准。
7.3 实践三：探索性测试¶
每个 Sprint 预留时间做探索性测试：
7.4 实践四：Definition of Done（DoD）¶
团队共同定义"完成"的标准：
一个用户故事"完成"的条件：
- [ ] 代码完成并通过 Code Review
- [ ] 单元测试通过
- [ ] 接口自动化用例通过
- [ ] UI 自动化用例通过（如有 UI 变更）
- [ ] 无 P0/P1 缺陷
- [ ] 验收标准全部满足
- [ ] 文档更新（如有必要）
7.5 实践五：缺陷分析与预防¶
每个 Sprint 分析缺陷：
缺陷分布：
├── 需求理解偏差（30%）→ 加强需求评审
├── 边界场景遗漏（25%）→ 补充边界用例
├── 集成问题（20%）→ 加强接口测试
├── 回归缺陷（15%）→ 扩大自动化覆盖
└── 其他（10%）→ 具体分析
八、常见问题与应对¶
8.1 迭代太快，测试来不及¶
应对： - 接口测试先于 UI 测试 - 自动化覆盖核心流程 - 探索性测试聚焦高风险区域 - 与 PO 协商调整范围
8.2 需求频繁变更¶
应对： - 用例设计模块化，易于调整 - 自动化用例参数化 - 接受变更，拥抱敏捷精神 - 变更影响分析及时同步
8.3 开发不写单元测试¶
应对： - 在 DoD 中明确要求 - Code Review 检查覆盖率 - 测试人员协助开发写单元测试 - 用 SonarQube 等工具监控
8.4 自动化维护成本高¶
应对： - Page Object 模式 - 数据驱动减少重复 - 定期清理无效用例 - 开发配合加 data-testid
8.5 测试环境不稳定¶
应对： - Docker 容器化环境 - Mock 外部依赖 - 环境健康检查脚本 - 与运维协作保障环境
附录：敏捷术语表¶
| 术语 | 含义 |
|---|---|
| Sprint | 一个迭代周期（1-4 周） |
| User Story | 用户故事（需求单元） |
| Acceptance Criteria | 验收标准 |
| Product Backlog | 需求池 |
| Sprint Backlog | 本迭代任务 |
| DoD | 完成的定义 |
| Scrum Master | 流程守护者 |
| Product Owner | 产品负责人 |
| Daily Standup | 每日站会 |
| Retrospective | 回顾会 |
| Burndown Chart | 燃尽图（进度可视化） |
| Velocity | 团队速率（每 Sprint 完成的故事点） |
核心理念
敏捷测试不是"测试更快"，而是"测试更早、更持续、更协作"。测试人员从质量守门员转变为质量教练，帮助团队在每个环节把控质量。
推荐下一步¶
根据你的学习进度，选择下一步：
- 如果你想检验理论基础：做 软件测试理论基础测验，检验学习效果
- 如果你想进入工具阶段：学习 数据库 SQL 教程，掌握数据校验
- 如果你想学 Python：学习 Python 基础教程，为自动化做准备
通关检查¶
完成本阶段后，使用 第1阶段-测试入门通关 检查是否可以进入下一阶段。