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

  • Z时代
  • 2024-01-10
  • 分类：综合

什么是敏捷测试？

敏捷测试是一种遵循敏捷软件开发规则和概念的测试方法。与瀑布技术不同，敏捷测试可以在项目开始时开始，并持续集成测试和开发。敏捷测试方法不是按时间顺序排列的（从某种意义上说，它仅在编码过程之后进行），而是一致的。

在本文中，我们将讨论 -

  • 敏捷测试计划

  • 敏捷测试策略

  • 敏捷测试象限

  • 敏捷软件开发面临的 QA 挑战

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

敏捷测试计划

在该迭代中执行的测试类型包含在敏捷测试计划中，例如测试数据需求、架构、测试环境和测试结果。与瀑布范式相比，敏捷方法包括为每个版本生成和修改的测试计划。敏捷测试策略通常包括以下项目 -

  • 测试范围

  • 正在测试的新功能

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

  • 性能和负载测试

  • 对基础设施的考虑

  • 风险缓解计划

  • 获取资源

  • 里程碑和可交付成果

敏捷测试策略

敏捷测试生命周期分为四个部分 -

迭代 0

您在第一步或迭代 0 执行初始设置杂务。它需要定位测试对象、部署测试工具、安排资源（例如可用性测试实验室）等。在迭代 0 中，计划完成以下步骤。

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

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

  • 描述一个或多个潜在的架构。

  • 认识危险

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

构建迭代

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

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

确认性测试和调查性测试是构建迭代的两种类型。由该小组进行的确认性测试侧重于确保系统满足迄今为止向该小组提出的消费者的目的。虽然调查测试发现了验证团队遗漏或忽视的问题。在调查测试中，测试人员以错误故事的形式识别可能的问题。完整性测试、负载/压力测试和安全测试是调查性测试的示例。

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

敏捷验收测试是传统功能和可接受性测试的混合体，因为开发团队和客户在此方面进行协作。开发人员测试将经典的单元测试与传统的服务集成测试相结合。在开发人员测试期间验证应用程序代码和数据库模式。

发布结束游戏或过渡阶段

“发布，结束游戏”的目的是将您的系统成功部署到运行中。此步骤包括最终用户培训、支持人员和操作人员等活动。它还包括产品发布营销、备份和恢复、系统和用户文档定稿。

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

生产

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

敏捷测试象限

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

  • 敏捷象限 I – 内部代码质量是该领域的主要关注点，它包括为帮助团队而构建的技术驱动的测试用例，其中涉及 -

    • 单元测试

    • 组件测试

  • 敏捷象限 II – 它包括为改进团队而开发的业务驱动的测试场景。该象限与先决条件有关。在此阶段进行的测试类型是 -

    • 尝试各种情况和程序。

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

    • 配对测试

  • 敏捷象限 III  – 该象限将信息反馈到第一和第二部分。测试用例可以作为自动化测试的基础。在这个象限中执行了许多迭代评估周期，这增加了对产品的信任。在该地区进行的测试类型是 -

    • 可用性测试

    • 探索性测试

    • 与客户配对测试

    • 协同测试

    • 用户验收测试

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

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

    • 身份识别和黑客攻击的安全测试

    • 基础设施测试

    • 数据迁移测试

    • 可扩展性测试

    • 负载测试

敏捷软件开发面临的 QA 挑战

  • 因为在敏捷中不太重视文档，所以失败的可能性增加了，给 QA 团队带来了额外的负担。

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

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

  • 测试执行周期非常短。

  • 设计测试计划的时间很少。

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

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

  • 在敏捷技术中，对需求的更改和修改是不可避免的，这使得 QA 成为最困难的任务。

敏捷过程中的自动化风险

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

  • 不可信的测试是自动化测试中令人担忧的主要来源。解决失败的测试和脆弱的测试问题应该是一个高度关注的焦点，以避免误报。

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

  • 不应将自动化测试用作探索性手动测试的替代品。需要多种测试方法和级别来实现产品的预期质量。

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

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

  • 在测试自动化期间，测试设置和中断故障过程经常被忽视。手动测试、测试设置和拆卸过程似乎很简单。

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

  • 敏捷自动化团队成员必须是有效的顾问：可访问、协作和足智多谋；否则，这个系统会迅速崩溃。

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

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

  • 自动化测试可能非常有效，以至于它用完要解决的关键问题，迫使它专注于不相关的问题。

结论

敏捷软件测试技术强调在软件开发生命周期开始时进行测试。一旦公开，就需要广泛的消费者互动和代码测试。代码应该足够可靠，以便在系统上进行测试。可以执行广泛的回归测试以确保所有问题都已修复和测试。敏捷模型测试成功的主要原因是团队之间的互动。

以上是 什么是敏捷测试？（流程、策略、测试计划、生命周期示例） 的全部内容， 来源链接： utcz.com/z/351663.html

回到顶部