什么是敏捷测试？流程与生命周期
Thomas Hamilton 什么是敏捷测试？
敏捷测试是一种遵循敏捷软件开发规则和原则的测试实践。与瀑布模型不同，敏捷测试可以在项目开始时进行，并实现开发和测试之间的持续集成。敏捷测试方法不是按顺序（即只在编码阶段之后执行），而是持续进行的。
敏捷测试原则
以下是敏捷测试的基本原则
- 在此敏捷测试模型中，可工作的软件是衡量进度的主要标准。
- 自组织团队可以取得最佳结果。
- 尽早并持续交付有价值的软件是我们的最高优先级。
- 软件开发人员必须在整个项目期间每天进行收集工作。
- 通过持续的技术改进和良好的设计来增强敏捷性。
- 敏捷测试通过提供持续反馈，确保最终产品符合业务预期。
- 在敏捷测试过程中，我们需要在实施过程中执行测试，这可以缩短开发时间。
- 敏捷中的测试过程应以一致的开发速度进行。
- 定期反思如何变得更有效。
- 最佳架构、需求和设计源于自组织团队。
- 每次团队开会时，都会审查和调整其行为，以提高效率。
- 与开发团队进行面对面交流是团队内部传达信息最有效的方法。
敏捷测试包括各种原则，有助于我们提高软件生产力。
敏捷测试生命周期
敏捷测试生命周期分为五个不同的阶段，如下图所示
以下是敏捷过程测试步骤
阶段1：影响评估：在此初始阶段，我们收集利益相关者和用户的输入。此阶段也称为反馈阶段，因为它有助于测试工程师设定下一个生命周期的目标。
阶段2：敏捷测试规划：这是敏捷测试生命周期的第二个阶段，所有利益相关者齐聚一堂，规划测试过程和交付成果的时间表。
阶段3：发布准备：在此阶段，我们审查已开发/实施的功能是否准备好上线。在此阶段，还决定哪些需要返回到之前的开发阶段。
阶段4：每日站会：此阶段包括每天早上的站会，以了解测试状态并设定全天目标。
阶段5：测试敏捷性审查：敏捷生命周期的最后阶段是敏捷性审查会议。它涉及与利益相关者的每周会议，以定期评估和衡量与目标的进展。
敏捷测试计划
敏捷测试计划包括在迭代中完成的测试类型，如测试数据要求、基础设施、测试环境和测试结果。与瀑布模型不同，在敏捷模型中，测试计划针对每个版本进行编写和更新。敏捷中典型的测试计划包括
- 测试范围
- 正在测试的新功能
- 基于功能复杂性的测试级别或类型
- 负载和性能测试
- 基础设施考虑
- 缓解或风险计划
- 资源
- 交付成果和里程碑
敏捷测试策略
敏捷测试生命周期跨越四个阶段
迭代 0
在第一阶段或迭代0期间，您执行初始设置任务。它包括识别测试人员、安装测试工具、调度资源（可用性测试实验室）等。迭代0旨在实现以下步骤
- 建立项目的商业案例
- 建立边界条件和项目范围
- 概述将驱动设计权衡的关键需求和用例
- 概述一个或多个候选架构
- 识别风险
- 成本估算并准备初步项目
构建迭代
敏捷测试方法的第二阶段是构建迭代，大部分测试在此阶段进行。此阶段被视为构建解决方案增量的一组迭代。为此，在每次迭代中，团队实施XP、Scrum、敏捷建模和敏捷数据等实践的混合。
在构建迭代中，敏捷团队遵循优先需求实践：每次迭代，他们都会从工作项堆栈中取出剩余的最基本需求并实施它们。
构建迭代分为两类：确认性测试和探索性测试。确认性测试侧重于验证系统是否满足利益相关者向团队描述的意图，并由团队执行。而探索性测试则检测确认性团队跳过或忽略的问题。在探索性测试中，测试人员以缺陷故事的形式确定潜在问题。探索性测试处理集成测试、负载/压力测试和安全测试等常见问题。
同样，对于确认性测试，有两个方面：开发人员测试和敏捷验收测试。两者都自动化以在整个生命周期中实现持续回归测试。确认性测试相当于对规范进行敏捷测试。
敏捷验收测试是传统功能测试和传统验收测试的组合，因为开发团队和利益相关者共同进行。而开发人员测试是传统单元测试和传统服务集成测试的混合。开发人员测试验证应用程序代码和数据库模式。
发布收尾或转换阶段
“发布收尾”的目标是成功将系统部署到生产环境。此阶段的活动包括最终用户、支持人员和运营人员的培训。此外，它还包括产品发布营销、备份和恢复、系统和用户文档的最终确定。
最终的敏捷方法测试阶段包括完整的系统测试和验收测试。为了顺利完成最终测试阶段，您应该在构建迭代期间更严格地测试产品。在收尾阶段，测试人员将致力于其缺陷故事。
生产
发布阶段后，产品将进入生产阶段。
敏捷测试象限
敏捷测试象限将整个过程分为四个象限，有助于理解敏捷测试是如何执行的。
敏捷象限 I
此象限主要关注内部代码质量，它由技术驱动并旨在支持团队的测试用例组成，包括
- 单元测试
- 组件测试
敏捷象限 II
它包含业务驱动并旨在支持团队的测试用例。此象限侧重于需求。在此阶段执行的测试类型是
- 测试可能场景和工作流的示例
- 测试用户体验，如原型
- 结对测试
敏捷象限 III
此象限向象限一和象限二提供反馈。测试用例可用作执行自动化测试的基础。在此象限中，进行多轮迭代审查，以建立对产品的信心。此象限中进行的测试类型是
- 可用性测试
- 探索性测试
- 与客户结对测试
- 协作测试
- 用户验收测试
敏捷象限 IV
此象限侧重于非功能性需求，如性能、安全性、稳定性等。借助此象限，应用程序旨在提供非功能性质量和预期价值。
- 非功能性测试，如压力和性能测试
- 关于身份验证和黑客攻击的安全测试
- 基础设施测试
- 数据迁移测试
- 可扩展性测试
- 负载测试
敏捷软件开发中的质量保证挑战
- 敏捷中出错的可能性更大，因为文档的优先级较低，最终给质量保证团队带来更大压力
- 新功能引入速度快，这减少了测试团队识别最新功能是否符合要求以及是否真正满足业务需求的时间
- 测试人员通常需要扮演半开发人员的角色
- 测试执行周期高度压缩
- 准备测试计划的时间很少
- 对于回归测试，他们的时间将非常有限
- 角色从质量的守门人转变为质量的合作伙伴
- 需求变更和更新是敏捷方法的固有特征，成为质量保证的最大挑战
敏捷流程中自动化的风险
- 自动化用户界面提供了高度的信心，但它们执行缓慢、维护脆弱且构建成本高昂。自动化可能不会显著提高测试生产力，除非测试人员知道如何测试
- 不可靠的测试是自动化测试中的主要问题。修复失败的测试并解决与脆弱测试相关的问题应是首要任务，以避免误报
- 如果自动化测试是手动启动而不是通过持续集成 (CI) 启动，则存在它们不定期运行的风险，因此可能导致测试失败
- 自动化测试不能替代探索性手动测试。为了获得预期的产品质量，需要混合使用各种测试类型和级别
- 许多商业自动化工具提供简单的功能，如自动化手动测试用例的捕获和回放。此类工具鼓励通过用户界面进行测试，并导致固有的脆弱且难以维护的测试。此外，将测试用例存储在版本控制系统之外会造成不必要的复杂性
- 为了节省时间，很多时候自动化测试计划规划不周或未经规划，导致测试失败
- 在测试自动化期间通常会遗漏测试设置和拆卸程序，而在执行手动测试时，测试设置和拆卸程序听起来很无缝
- 生产力指标（如每天创建或执行的测试用例数量）可能具有极大的误导性，并可能导致在运行无用测试上进行大量投资
- 敏捷自动化团队的成员必须是有效的顾问：易于接近、合作且足智多谋，否则该系统将很快失败
- 自动化可能会提出并提供需要过多持续维护的测试解决方案，相对于所提供价值而言
- 自动化测试可能缺乏构思和交付有效解决方案的专业知识
- 自动化测试可能非常成功，以至于它们解决了重要的所有问题，然后转向了不重要的问题。
结论
软件测试中的敏捷方法论涉及在软件开发生命周期中尽早进行测试。它要求客户高度参与，并在代码可用后立即进行测试。代码应足够稳定以进行系统测试。可以进行广泛的回归测试，以确保缺陷已修复并经过测试。最重要的是，团队之间的沟通是敏捷模型测试成功的关键！！！
