敏捷测试自动化框架

在过去的几年里，自从敏捷方法论出现，其创始人呼吁并愿意摒弃传统瀑布模型中繁琐乏味的现实后，其影响也在自动化测试方面显现出来。

瀑布模型中的自动化与敏捷中的自动化

在传统的软件测试生命周期过程中，自动化测试通常在应用程序稳定、持续且需求涉及相当长的时间，并且在大多数情况下需要一组非常熟练的自动化专家资源以及相当多的设置成本时才可行。自动化测试的基本目的是长期降低成本并确保不会因现有测试用例引入新的缺陷。

自动化测试从技术本质上来说并非探索性的，因为自动化测试的主要作用是节省时间和降低成本。自动化测试的目的不是发现新的和创新的缺陷。自动化测试主要旨在确认已有的缺陷。

如何在敏捷方法论中实现自动化

现在，根据敏捷方法论的定义，它旨在摒弃繁琐的文档，以便可以实施新的创新想法，并且人们可以自由地相互交流，从而可以实施更多这些创新和探索性的想法。

因此，我们可以看到敏捷方法论和自动化测试的基本理念之间存在矛盾。

敏捷测试自动化的基本要点

因此，在评估敏捷方法论与自动化测试方法和技术的结合使用时，我们需要考虑一些基本点。我们需要考虑设计和编码所需的时间、使用现有测试数据验证设计脚本以及将其用于测试（无论是功能测试还是回归测试）等基本点。因此，所有这些事件的真实情况是，为了执行所有这些事实，我们需要确保这些任务需要相当多的时间，而在一个平均冲刺需要1-2周才能完成的敏捷环境中，显然很难考虑为以这种方式自动化脚本提供如此多的时间。

另一个重要因素是敏捷方法论实施时出现的需求变更类型。敏捷方法论本身定义上就是一种非常有助于响应快速客户引发的变更需求的技术，因此它非常适合应用程序整个开发过程中的频繁变更。

相比之下，自动化测试在处理更稳定且变更不那么频繁的需求类型时非常有用。因此，根据定义，自动化测试不适合各种伴随敏捷方法论采用而来的频繁需求变更。

敏捷自动化工具

在敏捷方法论的总体范围内采用自动化测试时，选择合适的自动化工具也是一个潜在的非常重要的因素。例如，许可自动化工具在访问属于特定测试自动化框架的各种重要资源时，对不同类型和级别的用户施加严格的安全访问标准。

相比之下，敏捷方法论强调开放协作和团队成员之间的开放式互动，因此，直接影响用户方式的限制性政策将对团队内部的整体凝聚力产生负面影响，从而可能导致既无帮助也无益于项目整体成功的后果。

因此，过程的首要重要性应是确保在敏捷方法论规定的时间内交付高质量的自动化测试脚本；我们需要以更细致的方式选择将要自动化的潜在测试用例，以使这些自动化测试脚本能够很好地用于将来的重用，并确保它们能在分配的时间内（如敏捷方法论过程中所需）准备好。

在考虑了上述所有因素后，我们就可以意识到，即使在采用敏捷方法论时，我们也需要引入回归测试等类型的测试（因为即使在敏捷测试中，也需要将大量的测试工作投入到敏捷方法论中，以确保整体产品的更高质量）。

现在让我们看看自动化测试可以使用的最基本情况以及我们如何将其应用于敏捷测试领域。

应用于敏捷的自动化测试概念