敏捷测试 - 工作产物

敏捷测试 - 关键工作产物

在敏捷项目中，测试工作产物通常是轻量级、动态的，并由团队协作创建。它们侧重于提供价值和促进沟通，而不是大量静态文档。

测试策略 / 轻量级测试计划

敏捷团队不会采用厚重的传统测试计划，而是经常制定精益的测试策略 (Test Strategy) 或轻量级、持续更新的测试计划 (Living Test Plan)。这份文档通常在发布计划 (Release Planning) 期间创建，并在每个 Sprint 计划期间进行细化。它作为团队测试方法的指南。

敏捷测试策略的典型内容可能包括：

测试范围 (Testing Scope)：将要测试和不测试的内容、关键功能和风险区域。
测试级别与类型 (Testing Levels & Types)：单元、集成、系统、UAT、性能、安全测试等方法的说明。
测试环境 (Test Environments)：测试环境的描述和管理。
测试数据管理策略 (Test Data Management Strategy)：如何创建、管理和维护测试数据。
自动化策略 (Automation Strategy)：自动化什么、工具、框架以及与 CI/CD 的集成。
角色与职责 (Roles and Responsibilities)：负责各项测试活动的人员（强调全团队所有权）。
工具 (Tools)：选定的测试管理、自动化、性能等工具。
度量与报告 (Metrics & Reporting)：要跟踪的关键质量度量以及如何报告它们。

所有团队成员，特别是测试人员，都会为测试策略做出贡献，确保其与项目目标和背景一致。

用户故事和验收标准

虽然用户故事 (User Stories) 主要用于描述需求，但测试人员在用户故事的细化过程中起着至关重要的作用。测试人员协作（通常在与产品负责人和开发人员的“三友”会议 Three Amigos sessions 中）确保用户故事清晰、可测试（遵循 INVEST 标准），并且具有定义明确、无歧义的验收标准 (Acceptance Criteria)。

验收标准通常构成验收测试（手动或自动化）的基础，并且是 ATDD/BDD 实践的关键输入。

测试用例（手动和自动化）

敏捷测试采用不同级别的手动和自动化测试混合方法：

自动化单元测试 (Automated Unit Tests)：由开发人员编写，通常使用 TDD，用于验证小的代码单元。
自动化集成/API 测试 (Automated Integration/API Tests)：验证组件或服务之间的交互。
自动化 UI/端到端测试 (Automated UI/End-to-End Tests)：通过 UI 验证用户工作流程。这些测试功能强大，但也可能更脆弱、更慢，因此要明智地使用（位于测试金字塔的顶端）。
手动测试用例/检查列表 (Manual Test Cases/Checklists)：用于探索性测试、可用性测试以及难以或不值得自动化的场景。它们通常是轻量级的，基于经验。
BDD 场景 (BDD Scenarios)：使用 Gherkin（Given-When-Then 格式）编写并自动化，作为活文档和验收测试。

在 TDD 中，单元测试是在代码之前编写的。在 ATDD/BDD 中，验收测试/场景是在开发 之前或同时 定义的。持续集成 (Continuous Integration) 和持续测试 (Continuous Testing) 是核心，自动化测试作为 CI/CD 流水线的一部分频繁运行。

何时以及自动化什么是一个战略性决策，需要平衡投入、价值、可维护性和反馈速度。自动化显著减少了重复性测试工作，使测试人员能够腾出时间进行探索性测试和测试策略细化等更高价值的活动。

如果用户故事的测试无法在一个 Sprint 内完成（违反了完成定义 Definition of Done），团队会在每日站会 (Daily Stand-ups) 中讨论并决定如何处理（例如，拆分用户故事、将其移至未来的 Sprint）。

测试结果和缺陷报告

测试结果对于反馈至关重要。自动化测试执行报告通常由 CI/CD 工具和测试自动化框架生成。测试人员分析这些结果，调查失败原因，并记录缺陷 (Defects)。

敏捷中的缺陷报告通常在问题跟踪系统（例如 JIRA）中进行管理。报告应该清晰、简洁，并提供足够的信息以便开发人员重现和修复问题。缺陷会被优先排序，并通常在当前或下一个 Sprint 中处理。

在迭代或发布结束时，可能会共享一个简短的测试摘要 (Test Summary)，重点说明：

测试范围（测试了什么，涵盖了哪些关键功能）。
测试执行摘要（通过/失败率，执行的测试数量）。
发现的主要缺陷及其状态。
回归测试 (Regression Testing) 状态。
任何未解决的风险或问题。
关键测试度量和趋势。

测试度量报告和看板

敏捷团队跟踪各种度量来监控质量和过程效率。这些度量通常在看板 (Dashboards) 上进行可视化展示，以提高透明度：

测试覆盖率 (Test Coverage)（需求、代码、API 端点）。
测试自动化覆盖率 (Test Automation Coverage)（自动化测试占总测试的百分比）。
缺陷密度 (Defect Density)（每用户故事点/功能发现的缺陷数量）。
缺陷逃逸率 (Defect Escape Rate)（在生产环境中发现的缺陷）。
缺陷平均检测时间 (MTTD) / 缺陷平均解决时间 (MTTR)。
构建成功率 (Build Success Rate)（CI 构建的稳定性）。
测试执行通过/失败率 (Test Execution Pass/Fail Rate)。

这些度量有助于识别趋势、改进领域，并为决策提供数据驱动的洞察。

Sprint 评审和回顾会议的贡献

测试人员积极参与 Sprint 评审 (Sprint Review)，演示已测试的功能并讨论质量方面的问题。在 Sprint 回顾会议 (Retrospective) 中，测试人员提供有价值的输入，内容包括：

在测试和质量保障方面做得好的地方。
遇到的挑战（例如，测试环境问题、不明确的需求、自动化测试不稳定 Automation Flakiness）。
对测试度量和缺陷趋势的分析。
改进测试流程、工具或协作的建议。
吸取的经验教训和识别出的最佳实践。
用于在未来 Sprint 中提升质量的行动项 (Action Items)。

在 Sprint 评审或 UAT 期间收集的客户反馈 (Customer Feedback) 也是一个关键工作产物，它为未来的开发和测试工作提供信息/指导。