什么是敏捷测试？（流程、策略、测试计划、生命周期示例）

什么是敏捷测试？

敏捷测试是一种遵循敏捷软件开发规则和概念的测试方法。与瀑布模型不同，敏捷测试可以在项目早期开始，持续集成测试和开发。敏捷测试方法不是按时间顺序进行的（即仅在编码过程之后进行），而是持续进行的。

在本文中，我们将讨论：

  • 敏捷测试计划

  • 敏捷测试策略

  • 敏捷测试象限

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

  • 敏捷流程中自动化的风险

敏捷测试计划

敏捷测试计划中包含在该迭代中执行的测试类型，例如测试数据需求、架构、测试环境和测试结果。与瀑布模型相反，敏捷方法包括为每个版本创建和修改的测试计划。敏捷测试策略通常包括以下内容：

  • 测试范围

  • 正在测试的新功能

  • 测试级别或类型取决于特性的复杂性

  • 性能和负载测试

  • 基础设施考虑

  • 风险缓解计划

  • 获取资源

  • 里程碑和交付成果


敏捷测试策略

敏捷测试生命周期分为四个阶段：

迭代 0

在第一步或迭代 0 中，您进行初始设置任务。这包括查找测试对象、部署测试工具、安排资源（例如可用性测试实验室）等等。在迭代 0 中，计划完成以下步骤。

  • 为项目创建商业案例 b) 定义项目的初始条件和目标

  • 描述将影响设计权衡的必要标准和用例。

  • 描述一种或多种可能的架构。

  • 识别风险

  • 成本估算和试点项目的开发

构建迭代

构建迭代是敏捷测试方法的第二阶段，在这个阶段进行大部分测试。此阶段被视为一系列迭代以构建解决方案增量。为此，团队在每次迭代中使用来自 XP、Scrum、敏捷建模和敏捷数据等方法的组合。

敏捷团队在构建迭代期间实施优先级需求方法——在每次迭代中，他们从工作项堆栈中选择最重要的剩余项目并执行它们。

构建迭代有两种类型：确认测试和调查测试。由团队进行的确认测试侧重于确保系统满足迄今为止向团队展示的客户目标。而调查测试则发现了确认团队错过或忽略的问题。在调查测试中，测试人员以错误的故事形式识别潜在问题。完整性测试、负载/压力测试和安全测试是调查测试的示例。

同样，确认测试也有两种类型：开发人员测试和敏捷验收测试。两者都是自动的，允许在整个生命周期中进行持续测试。确认测试是规范测试的敏捷对应物。

敏捷验收测试是传统功能测试和可接受性测试的混合体，因为开发团队和客户共同参与其中。开发人员测试将经典单元测试与传统的服务集成测试相结合。开发人员测试验证应用程序代码和数据库模式。

发布收尾或过渡阶段

“发布，收尾”的目的是成功地将您的系统投入运行。此步骤包括诸如最终用户培训、支持人员和运营人员等活动。它还包括产品发布营销、备份和恢复、系统和用户文档最终确定。

敏捷方法测试的最后阶段包括全面的系统测试和验收测试。为了在没有障碍的情况下完成最终测试阶段，您必须在构建迭代时更彻底地评估产品。测试人员将在最后阶段专注于故障报告。

生产

发布阶段之后，产品将进入生产阶段。

敏捷测试象限

敏捷测试象限将整个过程划分为四个象限，有助于理解敏捷测试是如何进行的。

  • **敏捷象限 I** – 此区域主要关注内部代码质量，它包含旨在帮助团队的技术驱动型测试用例，包括：

    • 单元测试

    • 组件测试

  • **敏捷象限 II** – 它包括旨在改进团队的业务驱动型测试场景。此象限关注需求。在此阶段执行的测试类型为：

    • 实验不同的情况和程序。

    • 用户体验测试，例如原型测试

    • 结对测试

  • **敏捷象限 III** – 此象限将信息反馈给第一和第二部分。测试用例可以用作自动化测试的基础。在此象限中执行许多迭代评估周期，从而增强对产品的信任。在此区域执行的测试类型为：

    • 可用性测试

    • 探索性测试

    • 与客户的结对测试

    • 协作测试

    • 用户验收测试

  • **敏捷象限 IV** – 此象限关注非功能性标准，例如效率、安全性和可靠性等。该应用程序旨在借助此象限提供非功能性属性和预期价值。

    • 非功能测试，例如压力和性能评估。

    • 安全测试，用于识别和黑客攻击

    • 基础设施测试

    • 数据迁移测试

    • 可扩展性测试

    • 负载测试

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

  • 由于敏捷方法较少重视文档，因此失败的可能性增加，给质量保证团队带来了额外负担。

  • 升级快速发布，减少了测试团队确定当前功能是否符合要求并真正满足业务需求的时间。

  • 测试人员经常被迫承担半开发人员的工作。

  • 测试执行时间非常短。

  • 设计测试计划的时间非常少。

  • 他们将尽可能少地使用时间进行回归测试。

  • 将他们的工作从质量守门人转变为质量伙伴。

  • 在敏捷方法中，需求的变化和修改是不可避免的，这使得质量保证成为最困难的任务。

敏捷流程中自动化的风险

  • 尽管自动化UI提供了高度的保证，但它实施缓慢，管理不稳定，并且开发成本高昂。除非测试人员了解如何进行测试，否则自动化可能不会显著提高测试效率。

  • 不可靠的测试是自动化测试的主要担忧来源。为了避免误报，应该高度关注解决失败的测试和脆弱的测试问题。

  • 如果自动化测试是手动开始的而不是通过 CI（持续集成）开始的，那么它们实际上永远不会定期执行，从而导致测试失败。

  • 自动化测试不应替代探索性手动测试。需要多种测试方法和级别才能达到预期的产品质量。

  • 一些市售的自动化解决方案包括基本功能，例如手动测试用例的自动捕获和回放。这种技术促进了通过UI进行测试，导致测试固有脆弱且难以管理。此外，将测试用例保留在版本控制系统之外会增加额外的复杂性。

  • 为了节省时间，自动化测试策略经常设计不良或准备不足，导致测试失败。

  • 在测试自动化过程中，经常忽略测试设置和拆解过程。手动测试、测试设置和拆解过程似乎很简单。

  • 每天开发或执行的测试用例数量等生产力指标可能极具欺骗性，导致在执行无效测试方面产生巨大支出。

  • 敏捷自动化团队成员必须是高效的顾问：易于沟通、协作和足智多谋；否则，这个系统将迅速崩溃。

  • 自动化可以提供并提供需要过度持续维护的测试解决方案，而与提供的价值相比。

  • 设计和实施良好解决方案所需的技能在自动化测试中可能缺乏。

  • 自动化测试可能非常有效，以至于它用完了需要解决的关键问题，迫使其关注无关紧要的问题。

结论

敏捷软件测试方法强调在软件开发生命周期开始时进行测试。它需要广泛的客户互动和对代码的测试，一旦代码公开可用。代码应该足够可靠，可以在系统上进行测试。可以进行广泛的回归测试，以确保所有问题都已修复并经过测试。敏捷模型测试成功的根本原因是团队之间的互动。

更新于：2021年6月9日

1K+ 次浏览

开启您的职业生涯

完成课程获得认证

开始
广告