敏捷测试 - 技术

敏捷测试 - 现代技术

尽管传统模型的基础测试技术仍然有价值，但敏捷测试将其融入到其迭代和协作框架中。此外，敏捷方法论催生了针对快速、质量驱动型开发的特定技术和术语。

敏捷中的测试基础

在敏捷项目中，主要的测试基础 (Test Basis) 通常源于产品待办事项列表 (Product Backlog) 中的用户故事 (User Story)，这些用户故事取代了大量传统的软件需求文档。这些用户故事概括了功能性需求 (Functional Requirements)，而且至关重要的是，非功能性需求 (NFRs) 和验收标准 (Acceptance Criteria) 也嵌入其中或与之关联。高效的敏捷团队通常利用协作会议（例如，“三友” (Three Amigos) - 产品负责人、开发人员、测试人员）来完善用户故事并确保达成共识。

为了确保全面和高质量的测试，以下各项也是测试基础的重要组成部分：

• 从之前的迭代或类似项目中获得的见解和经验教训。
• 现有系统架构、设计文档、代码以及已建立的质量属性。
• 当前项目和过去项目的缺陷历史和模式。
• 直接的客户反馈和用户研究。
• 用户文档、API 规范和设计原型 (Mockups)。
• 用户画像 (Personas) 和用户旅程图 (User Journey Maps)。

完成的定义 (Definition of Done, DoD)

完成的定义 (Definition of Done, DoD) 是敏捷团队内部关于产品增量（例如用户故事）必须满足哪些标准才能被视为完成的关键共识。虽然 DoD 可以演进，但团队必须持续应用它。它作为所有工作的质量门。

DoD 本质上是一个检查清单，确保用户故事所有必要的活动——包括功能实现、非功能方面、测试和文档——都已完成。只有当所有 DoD 项都满足时，用户故事才被标记为“完成”。这有助于防止技术债务 (Technical Debt) 并确保可交付的增量 (Shippable increments)。

一个用户故事的全面 DoD 可能包括：

• 清晰、可测试的验收标准已定义并满足。
• 代码已通过同行评审 (Peer-reviewed)。
• 单元测试已编写并通过（达到约定的代码覆盖率）。
• 集成测试已编写并通过。
• 相关的端到端测试 (End-to-end Tests) 已更新/创建并通过。
• 性能和安全问题已解决。
• 用户文档（如果适用）已更新。
• 已获得产品负责人接受。
• 已成功部署到预生产/测试环境 (Staging/Testing Environment)。
• 没有关键或高严重性未解决的缺陷。

除了用户故事的 DoD，还应为以下各项建立 DoD：

• 每个冲刺/迭代 (Iteration)。
• 每个功能或史诗 (Epic)。
• 一个发布（可发布的定义 Definition of Releasable）。

必要的测试信息

敏捷环境中的测试人员需要持续访问以下信息：

• 当前迭代优先处理的特定用户故事或功能。
• 每个故事的明确定义的验收标准。
• 系统架构、API 契约 (Contracts) 和接口规范。
• 目标部署环境的详细信息。
• 测试工具和框架的可用性与配置。
• 约定的测试覆盖目标（例如，与风险、需求关联）。
• 当前的完成的定义 (DoD)。
• 访问 CI/CD 管道 (Pipelines) 和构建制品 (Build Artifacts)。

鉴于敏捷中的测试是一个持续协作的努力，而非一个顺序阶段，测试人员负责：

• 在整个迭代过程中主动获取和澄清测试信息。
• 识别可能阻碍有效测试的信息空白，并与团队合作解决这些问题。
• 协作决定迭代内不同测试级别的适当范围和深度。
• 确保在最佳时间执行相关的测试，提供快速反馈。

现代功能性与非功能性测试设计

敏捷项目利用已建立的测试设计技术，但强调早期测试和持续反馈。测试用例或至少测试场景，理想情况下应在开发之前或并行定义（例如，通过 ATDD/BDD）。

对于功能测试设计，测试人员和开发人员经常使用黑盒测试 (Black-box Testing) 技术，例如：

• 等价类划分 (Equivalence Partitioning)
• 边界值分析 (Boundary Value Analysis)
• 判定表 (Decision Tables)
• 状态迁移测试 (State Transition Testing)
• 用例测试 (Use Case Testing) / 用户故事测试

对于非功能测试设计（例如，性能、安全性、可用性），这些需求通常是用户故事的一部分或定义为单独的 NFR。测试策略包括：

• 早期性能测试（例如，组件级别、API 负载测试）。
• 集成到 CI/CD 管道 (Pipeline) 中的安全测试（例如，SAST, DAST 工具）。
• 与代表性用户进行的可用性测试或启发式评估 (Heuristic Evaluations)。
• 对照 WCAG 等标准进行的无障碍性测试 (Accessibility Testing)。

考虑利用 API 测试工具（例如 Postman、REST Assured、Karate DSL）和契约测试 (Contract Testing)（例如 Pact），尤其是在微服务 (Microservice) 架构中。

探索性测试

在快节奏的敏捷环境中，为每个场景进行正式的测试用例设计可能会耗时过多。探索性测试 (Exploratory Testing, ET) 是一个强大的补充，定义为同时进行学习、测试设计和测试执行的过程。

在探索性测试中，测试人员动态地设计和执行测试，利用从应用程序行为中获得的见解来指导后续测试。这对于发现脚本化测试可能遗漏的缺陷以及适应频繁变更非常有效。Session-Based Test Management (SBTM) 等结构化方法可以为探索性测试带来重点和可衡量性。

基于风险的测试

基于风险的测试 (Risk-based Testing, RBT) 在敏捷中至关重要，它能确保将测试工作优先投入到最重要的领域。它涉及识别潜在的产品质量风险（功能、性能、安全性等）并评估其可能性和影响。

风险分析有助于在时间受限的迭代中优先安排测试活动：

• 高影响、高概率的风险需要全面和早期的测试。
• 较低风险可能接受强度较低或后期的测试。

测试技术根据风险级别和特征选择。目标是高效地减轻最重大的风险，确保最关键的功能稳定可靠。

自动化验收测试 (ATDD/BDD)

自动化验收测试是敏捷质量的基石。验收测试驱动开发 (Acceptance Test-Driven Development, ATDD) 和行为驱动开发 (Behavior-Driven Development, BDD) 等实践有助于弥合业务干系人、开发人员和测试人员之间的沟通鸿沟。它们侧重于定义可执行的规范。

BDD 框架（例如 Cucumber、SpecFlow、Behave）使用人类可读的语言，如 Gherkin（Given-When-Then 格式）来定义验收标准。这些规范随后可以被自动化。

一个 Gherkin 场景示例：

Feature: User Login

  Scenario: Successful login with valid credentials
    Given the user is on the login page
    When the user enters valid username and password
    And clicks the login button
    Then the user should be redirected to the dashboard

这些自动化测试作为活文档 (Living Documentation)，并提供关于系统是否符合约定行为的快速反馈。它们通常作为 CI/CD 管道的一部分运行。Selenium、Cypress 或 Playwright 等工具常用于 UI 级别的验收测试，而 API 测试工具可以在服务层自动化验收测试。