敏捷/ Scrum方法论的自动化测试框架

在过去几年中，自从敏捷方法开始使用以来，它的创始人一直在大声疾呼，并且愿意摆脱传统瀑布模型单调和繁琐的现实以来，当谈到自动化测试时，也可以感受到同样的影响。

瀑布式自动化与敏捷性自动化

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

由于自动化测试的主要作用是节省时间和降低成本，因此就技术而言，自动化测试本质上不是探索性的。自动化测试并不意味着要找出新的缺陷。自动化测试主要是为了验证已经存在的功能。

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

现在，根据其定义，它谈论的是摆脱繁琐的文档，以便可以实施新的想法和创新，并且人们可以自由的相互交流，从而可以实施更多的创新和探索性想法。

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

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

因此，当涉及到评估自动化测试方法和技术相关的敏捷方法的使用时，我们需要考虑一些基本问题。如设计和编码所花费的时间，使用现有测试数据验证设计的脚本以及采用相同的测试（无论测试是出于功能目的还是回归目的）。因此，所有这些事件的真实情况是，为了执行所有这些事实,我们需要花费相当多的时间，并且在敏捷环境中，平均需要1-2周才能完成，因此显然很难考虑在这样的环境中提供如此多的时间来自动化脚本。

另一个重要因素仍然存在，那就是当敏捷方法论发挥作用时出现的需求变更的类型。根据敏捷方法本身的定义，它非常有助于响应客户频繁变更的需求，因此很适合在应用程序的整体开发过程中进行频繁的变更。

 相比之下，自动化测试在涉及到更稳定,频率更低得需求类型时非常有用。因此，