敏捷测试（Agile Testing）
敏捷测试是在敏捷开发（Agile Development）环境下进行的软件测试方法，强调快速反馈、持续测试、团队协作，以确保软件质量贯穿整个开发周期。与传统瀑布模型不同，敏捷测试不是等到开发完成后才进行，而是与开发并行，甚至驱动开发（如测试驱动开发，TDD）。
敏捷测试的核心原则
测试贯穿整个开发周期（持续测试）
测试从需求分析阶段就开始介入，而不是等到代码完成。
自动化测试优先
通过自动化测试（如单元测试、API测试、UI测试）提高效率，减少重复工作。
快速反馈
测试结果快速反馈给开发人员，以便及时修复缺陷。
团队协作（开发、测试、业务人员共同参与）
测试人员与开发、产品经理（PO）紧密合作，确保需求理解一致。
适应变化
敏捷需求可能频繁变更，测试策略也要灵活调整。
敏捷测试 vs. 传统测试
| 对比项 | 敏捷测试 | 传统测试（瀑布模型） |
|---|---|---|
| 测试介入时间 | 从需求阶段开始，持续进行 | 开发完成后才测试 |
| 测试策略 | 迭代测试，每次Sprint都测试 | 阶段测试（系统测试、集成测试等） |
| 自动化程度 | 高度依赖自动化测试 | 手动测试较多 |
| 文档要求 | 轻量级文档（如用户故事、测试用例） | 详细测试计划、用例文档 |
| 团队协作 | 测试与开发、PO紧密合作 | 测试团队独立工作 |
敏捷测试的常见实践
测试金字塔（Test Pyramid）
单元测试（Unit Testing）（占比最大，开发人员负责）
集成测试（Integration Testing）（API、服务测试）
UI测试（UI Testing）（占比最小，易维护性低）
行为驱动开发（BDD, Behavior-Driven Development）
使用类似自然语言的测试用例（如Gherkin语法），让业务人员也能理解测试逻辑。
工具：Cucumber、SpecFlow、Behave。
持续集成/持续测试（CI/CT）
每次代码提交后自动运行测试（如Jenkins、GitLab CI）。
探索性测试（Exploratory Testing）
不依赖脚本，测试人员根据经验主动探索潜在缺陷。
测试左移（Shift-Left Testing）
测试在开发早期介入，减少后期修复成本。
敏捷测试的挑战
自动化测试维护成本高（UI测试易受界面变化影响）
需求频繁变更导致测试用例失效
测试与开发节奏需高度同步
团队协作要求高（测试人员需理解业务逻辑）
总结
敏捷测试是持续、自动化、协作的测试方法，目标是快速交付高质量软件。它强调测试左移、自动化、快速反馈，适用于Scrum、Kanban等敏捷开发模式。