敏捷团队如果不使用框架来实现各种开发过程的自动化，包括测试、构建、测试环境等，就不会繁荣。理解所有敏捷团队的首要目标是成功地向客户提供真正的价值 ，这可以理解为在冲刺后提供功能性软件，这对于理解为什么缺乏自动化导致失败是必要的。在这篇文章中，我将讨论 "在敏捷项目中什么可以自动化，什么不应该自动化 "这些核心问题。
在敏捷环境中，我们可以实现什么自动化？
大多数类型的测试都受益于自动化，从基本的单元测试开始到系统测试。但是，如你所知，单元测试并没有提供足够的覆盖率来捕捉系统回归失败。在每次签到前运行一套手工测试，可能一天要做几十次，这并不实际。当开发人员不能通过按下按钮来运行测试时，他们就不会有积极性。
让我们来谈谈最适合自动化的测试种类。自动化始于一个自动化的框架，它允许开发人员经常检查他们的代码，并快速收到关于其影响的反馈。所以让我们先从这个开始。
持续集成（CI）系统
这就是我们创建自动化最重要的，尽管是合乎逻辑和直接的基础规则的地方。由于敏捷软件开发的性质，它比其他任何方法都要快，敏捷团队应该把重点放在开发软件所涉及的任何重复或繁琐的工作的自动化上。
在这一点上，没有人比作为敏捷开发过程一部分的自动构建创建更合适。由于敏捷开发的快速性，团队应该每天创建许多构建，特别是测试新添加的代码。
CI系统在敏捷环境中是至关重要的。持续集成和构建过程是任何自动化工作中投资回报率最显著的两个系统。
- CI允许在单元测试层面上的即时反馈（如果你有相关的单元测试来支持它）。
- 它减少了在没有测试的情况下添加新代码所涉及的许多风险。
- 它允许团队创建和部署许多（稳定的）构建，并提供每天的多次检查。
- 它改善了沟通，因为一旦构建完成，团队成员可以收到通知，而不需要检查状态。
- CI系统通过减少单元级的错误数量，在这些错误在测试过程的高级阶段变得明显之前，加快了测试时间。
基于上述情况，敏捷团队必须尽快实施持续集成并构建框架。虽然它需要持续的维护，但这是敏捷团队在大型复杂项目中取得成功并减少技术债务的唯一选择。
基于这些简单的事实，你可能会看到，敏捷团队必须实施持续集成并尽快构建框架。尽管它需要持续的维护，但这是敏捷团队在大型复杂项目中取得成功并减少技术债务的唯一选择。
开发和测试环境
敏捷团队需要在一个快速变化的环境中进行测试和开发；因此，创建和维护工作环境的空间较小。敏捷团队可以使用环境的自动化部署，而不需要多个小时的手动工作。此外，团队可以使用自动化来处理与他们的工作环境有关的许多其他领域。
- 测试数据和配置的创建和清理。
- 设置特定的拓扑结构和架构。
- 模拟一个特定的场景来重现一个错误。
用户界面（UI）的测试
敏捷开发过程接受的方法是，团队必须在每个迭代结束时提供一个增量的工作功能；因此，团队通常会在GUI层面执行基本的自动回归测试。
正如我前面提到的，我是一个自动化测试的忠实信徒。不过，在某些情况下，我们还是需要考虑是否要使用它，特别是当我们要测试一个GUI发生变化的应用程序的用户界面时。
为了克服GUI测试的挑战，选择最合适的工具是非常重要的，一个易于维护和足够灵活的工具来吸收变化。这可能是成功的GUI自动化的最关键的关键。
测试应用程序的所有层次
我非常相信自动化解决方案可以将人工测试工作减少到必要的最低限度。它从应用程序的第一层开始，通过运行单元测试，我们都同意这对减少问题至关重要，在该层测试中发现的问题不会成为以后更重要的问题。
接下来，我们有第二层的组件测试。程序员通过使用模块产生的一组输入和输出，将组件作为一个整体模块进行测试。第三，对我来说，测试策略中最关键的部分是集成测试，模块作为一个套件一起测试。如果这还不够，为什么不通过运行第四层系统测试来测试整个系统呢，它将整个应用程序作为一个整体系统来测试。
性能、负载和压力测试
假设你曾经参与过的测试过程中，包括上述类型的测试之一。在这种情况下，你可能知道，使用手动测试方法作为运行它们的首选方式几乎是不可能的，无疑是无效的。此外，有大量的测试是在没有自动化工具的情况下无法运行的。此外，使用手动测试不会提供我们可以通过使用专门的自动化工具来实现的准确的测试结果，这些工具可以模拟准确的场景，没有任何可能影响测试过程的人为干扰，因此，结果也是如此。
什么是我们不应该自动化的...？
如果你熟悉我的测试方法，你可能已经意识到我对自动化框架的大力支持，这些框架使团队能够开发出更有效、高效和可靠的编码和测试过程。然而，测试程序的某些部分仍然需要人类的智慧、常识和视力。
可用性测试
可用性测试与其他决定软件质量的测试类型非常不同。它不能自动化，因为它需要有人与软件一起工作，以确定它是如何被体验的，以及用户体验中的差距在哪里。
GUI测试（它值得投资回报率吗？）
GUI测试是对自动化最具挑战性的领域之一。我见过太多的组织在自动化其产品的GUI方面投入了数千小时的人力，但最后发现这是浪费时间，没有提供预期的投资回报率。一些GUI测试可以用来确保GUI中没有意外的变化。尽管如此，你还是应该问问自己，这是否值得花钱和投资，而不是改善其他质量问题，以提供更好的投资回报率和减少该领域的风险。
不值得投资的测试
我曾经参与过一个自动化项目，测试团队自动化了一千个提供的测试（至少在纸上）。那么这里有什么问题呢？他们几乎自动化了所有可用的测试场景，却没有真正考虑到投资回报率。
该团队投入了数周的时间来自动化标记为低风险的测试、永远不会失败的测试，以及失败后对软件影响机会很小的测试。整个自动化过程是基于 "让我们把一切都自动化 "的精神，而不是问这个自动化项目提供的投资回报率的简单问题。
在某些情况下，一些测试的编写并没有真正考虑到它们是否是必要的。一旦自动化项目开始，团队就会把这些测试自动化，只是因为他们从来不想重新运行这些测试（因为他们知道有0%的机会会产生变化）。
只需要执行一次的测试
自动化测试的主要目标是让团队专注于软件开发生命周期中的重要事情。自动测试场景只运行一次，不值得团队在设计、创建和执行这些测试时投入时间。
探索性测试
在我看来，探索性测试是敏捷团队在任何测试过程中使用的最好和最有效的方法。探索性测试可以用于学习目的（在测试时你可以了解更多关于软件的信息），或者提供一种快速的方法来评估软件的整体质量。然而，当涉及到真正的测试工作时，一个熟练的测试人员必须设计和执行测试。
探索性测试应该由人完成，而不是由自动化脚本完成，因为自动化脚本不会让测试人员接受他从探索性环节产生的新信息，并利用它来改进未来的测试和开发过程。
此外，尽管探索性测试是一个很好的测试方法，但确实需要自动化测试，使团队能够专注于他们的探索性会议，而不必担心自动化测试应该覆盖的任何回归问题。
