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

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

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

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

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

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

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

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

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

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

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

相比之下，自动化测试在涉及到更稳定,频率更低得需求类型时非常有用。因此，根据定义，自动化测试不能很好地适应各种频繁变更的需求类型，而这些变更往往是伴随着采用任何敏捷方法。

敏捷自动化工具

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

相比之下，敏捷方法主要强调团队成员之间的开放协作和开放式交互，因此，限制性政策直接影响用户如何对团队内部的整体凝聚力产生负面影响，从而导致结果不佳也非常不利于项目整体成功。因此，该过程的首要重要性应该是确保为了在敏捷方法提供的规定时间内获得自动化测试脚本的高质量交付;我们需要选择我们的预期测试用例，这些测试用例将以更细微的方式进行自动化，以便这些自动化测试脚本适合将来的重用，并且确保它们可以在指定的时间段内准备好(就像敏捷方法过程中所要求的那样)。在考虑了以上所有因素之后，我们可以意识到，即使在采用敏捷方法的同时，我们也需要了解测试的类型，例如回归测试(因为即使在敏捷测试期间，也需要投入大量的测试工作，以确保更好的整体产品质量)现在，让我们看一下可以使用自动化测试的最基本情况，以及如何将其应用于敏捷测试领域。