敏捷测试：方法论与生命周期

什么是敏捷测试？

敏捷测试 敏捷测试是一种遵循敏捷软件开发规则和原则的测试实践。与瀑布式开发方法不同，敏捷测试从项目启动之初就开始，并与开发过程同步持续进行。它并非顺序执行（仅在编码阶段之后进行），而是融入到每一次迭代中，以便在缺陷出现的第一时间就能获得反馈。

敏捷测试的原则

敏捷测试的基本原则是：

• 可用的软件是衡量进度的主要标准。
• 自组织团队往往能取得最佳成果。
• 尽早并持续交付有价值的软件是重中之重。
• 在整个项目过程中，开发人员和测试人员每天都会进行协作。
• 敏捷性是通过持续的技术改进和良好的设计来提高的。
• 持续的反馈确保最终产品符合业务预期。
• 在实施过程中进行测试，可以减少整体开发时间。
• 测试过程保持稳定、可持续的节奏。
• 团队会定期停下来反思和调整，以提高效率。
• 最佳的架构、需求和设计都源于自组织团队。
• 面对面的交流是团队内部最有效、最高效的沟通方式。

这些原则结合起来，可以提高软件生产力，缩短从构思到实际功能的实现路径。

敏捷测试生命周期

敏捷测试生命周期分为五个阶段，如下所示。

这些阶段包括：

• 第一阶段：影响评估。 收集利益相关者和用户的意见。这也被称为反馈阶段，因为它有助于测试工程师为下一个生命周期设定目标。
• 第二阶段：敏捷测试计划。 所有利益相关者齐聚一堂，共同制定测试计划、范围和交付成果。
• 第三阶段：发布准备。 Rev查看已实现的功能，并决定哪些功能可以上线，哪些功能需要返回开发阶段。
• 第四阶段：每日站会。 早晨的站立会议，团队会了解测试进度并制定当天的目标。
• 阶段 5：测试敏捷性 Rev看看。 每周与利益相关者召开会议，评估目标完成进度并调整策略。

敏捷测试计划

An 敏捷测试计划 描述了迭代中执行的测试类型、所需的数据和基础设施， 测试环境以及测试结果。与瀑布模型不同，敏捷测试计划会针对每个版本编写和更新。一个典型的计划包括：

• 测试范围。
• 正在测试新功能。
• 根据功能复杂度确定测试级别或类型。
• 负载和性能测试。
• 基础设施方面的考虑。
• 风险及缓解计划。
• 资源调配。
• 交付成果和里程碑。

敏捷测试策略

敏捷测试生命周期涵盖四个战略阶段。

迭代0

在第一阶段，您需要执行初始设置任务。这些任务包括确定测试人员、安装测试工具以及安排资源，例如可用性测试实验室。迭代 0 的目标是：

• 为该项目建立商业论证。
• 明确边界条件和项目范围。
• 概述将决定设计优劣的关键需求和用例。
• 列出一种或多种候选架构。
• 识别风险。
• 估算成本并编制初步项目计划。

构建迭代

敏捷测试的第二阶段是构建迭代阶段，大部分测试工作都在此阶段进行。该阶段包含一系列迭代，以增量方式构建解决方案。在每次迭代中，团队都会应用极限编程 (XP)、Scrum、敏捷建模和敏捷数据等多种实践方法。

团队遵循优先级需求实践：每次迭代，他们都会从待办事项列表中提取最重要的条目并进行实现。构建迭代分为两种互补的测试模式：

• 确认性检测 验证系统是否满足利益相关者的意图。这项工作由团队自行完成。
• 调查测试 调查性测试旨在发现验证性测试可能遗漏的问题。测试人员会将潜在问题作为缺陷报告提出。调查性测试涵盖集成测试、负载和压力测试以及安全测试。

确认性检测还有两个方面—— 开发人员测试 和 敏捷验收测试 ——而且两者都实现了自动化，从而可以在整个生命周期中持续进行回归测试。验证性测试相当于敏捷开发中的规范检验。

敏捷验收测试结合了传统的功能测试和验收测试，因为开发团队和利益相关者共同执行这些测试。开发人员测试则结合了传统的单元测试和服务集成测试，并验证应用程序代码和数据库模式。

发布、终局或过渡阶段

发布阶段的目标是成功将系统部署到生产环境。活动包括：培训最终用户、支持人员和运维团队；推广产品发布；进行备份和恢复演练；以及最终确定系统和用户文档。

敏捷测试的最后阶段包括完整的系统测试和验收测试。为了确保顺利完成，产品必须在开发迭代过程中进行严格的测试。在最后阶段，测试人员将专注于解决在早期阶段提出的缺陷。

生产部门

发布阶段结束后，产品将进入生产环境，接受实时运行情况的监控，并将任何问题反馈到下一个计划周期中。

敏捷测试象限

敏捷测试象限将整个过程分为四个领域，帮助团队了解敏捷测试是如何执行的。

敏捷象限 I

第一象限侧重于内部代码质量，通过技术驱动的测试来支持团队：

• 单元测试。
• 组件测试。

敏捷象限 II

第二象限包含以业务为导向的测试，旨在支持团队并专注于需求。该象限的典型工作包括：

• 测试各种可能场景和工作流程的示例。
• 测试用户体验成果，例如原型。
• 配对测试。

敏捷象限 III

第三象限为第一象限和第二象限提供反馈。这里的测试用例通常是自动化测试的基础，多次迭代评审能够增强人们对产品的信心。典型工作包括：

• 可用性测试。
• 探索性测试。
• 与客户进行结对测试。
• 协作测试。
• 用户验收测试。

敏捷象限 IV

第四象限侧重于性能、安全性和稳定性等非功能性需求。该象限确保应用程序能够达到预期的非功能性要求。典型工作包括：

• 非功能性测试，例如压力测试和性能测试。
• 安全测试涵盖身份验证和入侵尝试。
• 基础设施测试。
• 数据迁移测试。
• 可扩展性测试。
• 负载测试。

敏捷软件开发中的质量保证挑战

敏捷交付带来了实实在在的好处，但也给质量保证团队带来了新的挑战：

• 文档编制的优先级较低，因此出错的风险增加，压力转移到了质量保证团队。
• 新功能推出速度很快，导致测试人员没有足够的时间来验证最新功能是否符合需求和业务意图。
• 测试人员通常扮演着半开发人员的角色。
• 测试执行周期被高度压缩。
• 准备测试计划的时间有限。
• 回归测试预算变得紧张。
• 测试人员从质量的把关人转变为质量的合作伙伴。
• 敏捷开发中需求频繁变更的固有特性，是质量保证面临的最大挑战之一。

敏捷流程中自动化的风险

自动化在敏捷开发中至关重要，但它也存在风险，团队必须积极管理这些风险：

• 自动化UI测试虽然置信度高，但速度慢、稳定性差且维护成本高。只有当测试人员掌握了如何设计高质量测试时，才能真正提高效率。
• 不可靠的检测结果是一个主要问题。修复脆弱的检测方法和解决假阳性问题必须始终是重中之重。
• 手动运行的自动化测试（而不是通过持续集成运行）可能会悄无声息地偏离目标，并产生过时的结果。
• 自动化测试并不能取代探索性的手动测试。要达到预期的质量，需要结合多种测试类型和级别。
• 捕获和回放工具鼓励使用用户界面驱动的脚本，这类脚本脆弱且难以维护。存储在版本控制之外的测试会增加不必要的复杂性。
• 为了“节省时间”而进行的规划不周的自动化，往往会彻底失败。
• 自动化测试时很容易忽略测试设置和拆卸程序，而手动测试则可以自然地处理这些程序。
• 诸如“每日测试用例数”之类的生产力指标可能会误导团队运行无用的测试。
• 自动化团队必须是高效的顾问——平易近人、乐于合作、足智多谋——否则实践将会失败。
• 需要大量持续维护的解决方案可能得不偿失。
• 自动化测试可能缺乏提供有效解决方案所需的专业知识。
• 成功的自动化可能会遇到无重要问题需要解决的情况，并逐渐转向价值较低的工作。

有效敏捷测试的最佳实践

以下做法可确保敏捷测试快速、可靠且对团队有价值：

• Shift 剩下： 在需求阶段就开始测试，而不是在迭代结束时才开始测试。
• 与开发人员合作： 共同审查验收标准，以便从设计上消除缺陷，而不是从代码中引入缺陷。
• 图层自动化： 构建一个健康的单元测试、服务测试和 UI 测试金字塔。
• 保持测试独立性： 将每项测试单独进行，以便将失败结果指向单一根本原因。
• Track 个不稳定的测试： 及时隔离并修复不稳定的测试，以防止套件信任度下降。
• 利用人工智能辅助分析： 让工具标记受影响的测试、对失败的测试进行分组，并在每次合并后建议稳定的定位器。

常见问题