敏捷测试 - 四象限

敏捷测试 - 象限框架

与传统软件开发类似，敏捷测试 (Agile testing) 包含各种测试级别 (test level)，以确保全面的质量 (comprehensive quality)。这些通常包括：

• 单元测试 (Unit Testing)：验证独立的组件 (component) 或模块 (module)。主要由开发人员主导。
• 集成测试 (Integration Testing)：测试集成组件或服务之间的接口和交互。
• 系统测试 (System Testing)：测试完整、集成的系统，以验证它是否满足规定的需求（功能性 - functional 和非功能性 - non-functional）。
• 用户验收测试 (User Acceptance Testing, UAT)：验证系统是否满足最终用户或客户的需求和期望。

理解敏捷环境下的测试级别

单元测试 (Unit Testing)

• 由开发人员在编码的同时进行，通常使用 TDD。
• 专注于小型、独立的代码片段（方法 - method、类 - class）。
• 自动化测试 (automated test) 确保高代码覆盖率 (code coverage) 并提供快速反馈 (rapid feedback)。
• 对于构建稳定基础和支持安全重构 (safe refactoring) 至关重要。

集成测试 (Integration Testing)

• 在组件集成时执行，通常在 CI/CD 流水线内持续进行。
• 测试模块、服务（例如 API 调用）之间或与外部系统的交互。
• 在微服务架构 (microservices architecture) 中可以包括契约测试 (contract testing)，以确保服务兼容性 (service compatibility)。
• 主要依赖自动化，以快速反馈集成问题。

系统测试 (System Testing)

• 在完全集成的系统上执行，模拟端到端用户场景 (end-to-end user scenario)。
• 验证功能性需求（用户故事 - user story、特性 - feature）和非功能性需求（性能 - performance、安全性 - security、可用性 - usability）。
• 通常结合自动化测试和手动（探索性 - exploratory）测试。
• 通常在类生产环境 (production-like environment) 中执行。

用户验收测试 (UAT)

• 通常在每个迭代（Sprint 评审）结束时和/或主要发布 (major release) 之前进行。
• 由产品负责人、干系人或实际最终用户执行。
• 专注于业务验证 (business validation)，并确保产品交付预期价值。
• 来自 UAT 的反馈对于后续迭代至关重要。

测试分类：目的与受众

为了有效规划和优先安排测试，根据其主要目的和目标受众将测试分类很有帮助。我们可以考虑两个维度：

• 指导开发 (Guiding Development) vs. 评审产品 (Critiquing the Product)：有些测试用于帮助指导开发过程（例如，TDD、BDD），而其他测试则旨在评估成品并发现缺陷。
• 业务导向 (Business-Facing) vs. 技术导向 (Technology-Facing)：有些测试以业务术语描述，非技术干系人也能理解，而其他测试则使用技术语言，专注于底层技术。

业务导向测试 (Business-Facing Tests)

这些测试使用业务领域语言构建。它们回答系统是否按业务预期运行以及是否为用户交付价值的问题。例如，源自用户故事或 BDD 场景的验收测试。

技术导向测试 (Technology-Facing Tests)

这些测试使用技术语言构建，专注于系统的内部工作原理、架构和非功能性方面。程序员和技术测试人员主要使用这些测试来验证代码正确性、组件交互、性能和安全性。例如，单元测试、API 契约测试和性能测试。

敏捷测试象限 (Agile Testing Quadrants)

Brian Marick 引入了敏捷测试象限 (Agile Testing Quadrants) 作为模型，帮助团队思考所需的不同类型测试，并确保全面的测试覆盖率 (test coverage)。它结合了前面提到的两个维度：（业务导向 vs. 技术导向）和（指导开发 vs. 评审产品）。

象限提供了一个测试分类法 (taxonomy)，帮助团队规划平衡的测试策略 (testing strategy)。它们通常编号为 Q1、Q2、Q3 和 Q4：

敏捷测试象限的文本表示：

左上 (Q1)：指导开发的技术导向测试 (Technology-Facing tests that Guide Development)

• 焦点：内部质量、代码正确性、组件行为。
• 测试：单元测试 (Unit test)、组件测试 (component test)（例如，单独测试单个类、模块或微服务）。
• 主要目标：支持开发人员正确构建代码。
• 自动化：几乎总是自动化的，构成了测试自动化金字塔 (test automation pyramid) 的基础。
• 工具/技术：xUnit 框架（JUnit、NUnit、PyTest）、模拟/桩 (mocking/stubbing) 框架。

右上 (Q2)：指导开发的业务导向测试 (Business-Facing tests that Guide Development)

• 焦点：外部质量、特性行为、用户需求。
• 测试：功能测试 (Functional test)、示例、故事测试 (story test)、原型 (prototype)、模拟 (simulation)、API 级别的业务流程测试 (API-level business workflow test)。
• 主要目标：通过验证业务规则和用户场景，确保团队构建正确的产品。
• 自动化：通常是自动化的。BDD 和 ATDD 实践在此处大放异彩。
• 工具/技术：BDD 框架（Cucumber、SpecFlow）、UI 自动化工具（Selenium、Cypress、Playwright，用于 E2E 场景）、用于业务流程的 API 测试工具。

右下 (Q3)：评审产品的业务导向测试 (Business-Facing tests that Critique the Product)

• 焦点：用户体验 (User experience)、适用性 (suitability)、真实世界用法。
• 测试：探索性测试 (Exploratory testing)、可用性测试 (Usability testing)、用户验收测试 (UAT)、Alpha/Beta 测试、基于场景的测试 (scenario-based testing)。
• 主要目标：从最终用户角度评估产品，并就其是否符合目的提供反馈。
• 自动化：主要依赖手动，因为它们通常需要人工观察、直觉和领域专业知识 (domain expertise)。
• 工具/技术：检查表 (checklist)、用户画像 (persona)、基于会话的测试管理 (session-based test management)、用户反馈工具。

左下 (Q4)：评审产品的技术导向测试 (Technology-Facing tests that Critique the Product)

• 焦点：非功能性特性，如性能 (performance)、安全性 (security)、可靠性 (reliability)、可伸缩性 (scalability)、可维护性 (maintainability)。
• 测试：性能测试 (Performance test)、负载测试 (Load test)、压力测试 (Stress test)、安全漏洞扫描 (Security vulnerability scan)、基础设施测试 (Infrastructure test)、恢复测试 (Recovery test)、混沌工程实验 (Chaos engineering experiment)。
• 主要目标：验证系统的操作方面和技术健壮性 (technical robustness)。
• 自动化：通常使用专用工具自动化。
• 工具/技术：性能测试工具（JMeter、K6、Gatling）、安全扫描工具（OWASP ZAP、Veracode）、监控工具 (monitoring tool)、基础设施自动化工具 (infrastructure automation tool)。

敏捷测试象限 (Agile Testing Quadrants) 帮助团队确保采用全面的测试方法 (holistic testing approach)，涵盖质量的所有必要方面。它不是一个严格的规定，而是一个指南，用于激发关于“何时进行何种测试 (what testing to do when)”的讨论和规划，以支持团队的目标。