敏捷中的自动化是非常关键的。
想想在每个Sprint中添加和交付的许多特性。必须有一种方法来确保新添加的特性不会影响现有功能。
由于短跑持续时间较短，因此几乎不可能在每次产品在Sprint末端增加时执行整个套装。拥有一套自动测试服肯定会在这里扮演更重要的角色。
然而，引入自动化并使其成熟肯定需要一段时间。从长远来看，在规划和设计自动化活动方面进行初步投资肯定会有回报。
在敏捷中自动化什么？
每当我们计划在我们的项目中引入自动化时，我们中的大多数人都会立即投票选择“烟雾测试服”或“回归测试服”为最佳选择。自动化候选。当然，他们是，但当我们想到自动化测试金字塔，我们可以得出结论，这只是金字塔的顶层，我们正在谈论。
除了上面的层，我们还有服务层而单位层更重要的是。
那么，除了吸烟测试和回归测试之外，还有哪些测试可以成为自动化的好选择呢？
#1)构建和部署
在传统环境中，我们有预定义的构建，可以每周，每两周，有时甚至每月。原因之一是这些部署需要时间。这种方法的问题在于，我们必须等待预定义的日期才能修复bug或实现新特性，因此出现了延迟。
第二个原因是，当测试人员完成测试并发现错误和缺陷时，程序员已经转向不同的实现部分，并且对解决旧应用程序的bug不太感兴趣。这种方法还延迟了在生产中提供功能的时间。
构建和部署是重复的，有时甚至是无聊的实体。部署构建也需要几个小时，这会延迟测试，并最终延迟反馈。作为一个重复的任务，部署成为自动化的一个很好的候选。
实现自动构建部署的几个优点是：
没有可能发生部署错误(可以避免人为错误，例如复制不正确的文件或将文件复制到不正确的位置)。
bug/特性一旦修复就可以进行测试。
测试人员有更多的时间进行测试。
该功能可以在较短的时间内转移到生产中。
快速反馈
#2)单元测试/组件测试
我已经讨论过通过使用上一篇教程中的TDD方法.
这形成了金字塔的最低层，因此地基和任何基础都需要坚固的岩石。开发团队应该协作并共同工作，以便将大部分测试纳入这一层。
#3)API/Web服务测试
Web服务是两个应用程序在请求和响应方面交换数据或信息的媒介，而不涉及底层体系结构或技术。用更简单的术语来说-发出请求和验证响应是我们通常在Web服务测试中所做的事情。
测试web服务需要编写程序来调用那些Web服务方法，并验证它返回的值/s。我们甚至可以测试各种排列和组合的服务。拥有Excel表中的所有测试数据，您的程序就可以读取数据，并通过传递测试数据作为参数调用可测试服务，并验证结果。
这种特殊的测试是金字塔中间层的一部分。大多数功能测试都可以被推入这一层。解决这个层中出现的缺陷变得很容易，并且它们不会被推迟到UI可用。
#4)GUI背后的测试
相对来说，自动化GUI后面的测试要比自动化实际的GUI容易得多。另一个优点是，无论UI更改如何，功能都保持不变。即使某些UI元素被更改，特性的功能也不会改变。这种技术主要关注业务逻辑和规则。
测试用例大多是用表格格式或电子表格编写的，并编写了接受来自这些表的输入并返回结果的补丁/代码片段。结果会立即生成，并为非技术利益相关者运行这些测试并获得预期结果提供了一个很好的平台。实现此技术的工具之一是菲尼斯.
#5)非功能性测试
这，这个非功能测试技术基本上包括负荷、性能和压力测试。市场上有各种各样的工具可以用于自动化这些测试。
#6)数据比较
我们的许多测试要求我们比较数据文件，包括文本文件、csv或excel文件。
可以将这些文件与进行数据验证的基线进行比较。
比较可以是相同的数据，但格式不同。当我们从两个不同的源生成两个相同的文件时，这种情况基本上就会发生。
这些比较可能是重复的，因此是自动化的。
#7)搜索
从大量的文件中寻找一个特定的实体也可能很乏味，如果这是一项重复的任务，上帝会帮助我们。一个例子是搜索日志文件。如果这也是一项繁琐和重复的任务，那么我们应该考虑将其自动化。
#8)重复任务
任何从与最终用户交互开始的任务，或者编写开发它的故事，如果是重复的，都应该在自动化中考虑。我们应该理解，自动化并不意味着必须有一个复杂的工具/技术参与其中。它可以是一个简单的VB宏，也可以是一个带有Javascript的Java程序来解决这个问题。
从哪里开始？
没有一个要点或一步的指南来说明从哪里开始自动化。为团队启动自动化需要您集思广益，并对您想要自动化的方面进行深入的思考，或者自动化的最终目标是什么？
你可以从以下几个方面着手：
找出重复的任务，
识别应用程序的疼痛区域
确定测试挑战
如果您在旅游项目/团队中没有自动化，那么您可能会选择一种多层的方法，在这种方法中，单元测试可以首先成为自动化的目标。这会给你最高的投资回报。
同时，测试人员可以开始进行烟雾测试，然后进行回归。一旦团队获得了技能并感到舒服，就逐步转向自动化其他重复任务。
在没有评估你的需求的情况下，不要直接购买新工具。正如我前面所说，一个简单的程序或宏可以解决您自动化一些重复任务的目的。所以，在决定买工具之前，做POC并评估该工具是否有效使用。
请阅读这些文档，在这些文档中，我提供了更多关于如何为自动化选择正确的测试用例的详细信息，并在下面的文章中提供了一些关于评估自动化工作的见解。 自动化测试过程的挑战和硒自动化项目的试验评估。
一旦最终确定了自动化和工具的范围，接下来就是设计框架。
记住，在敏捷中，框架是进化的。不要先设计整个框架，然后再实现。设计和实现MVP(最低可行产品)，然后加强现有的框架，以包括更多的功能。如果您希望您的自动化套件是健壮的，您还需要应用良好的编码和开发实践。
一些最佳做法
不要一蹴而就的目标是100%的自动化。从小开始。记住，这是一个不断发展的过程。
遵循与任何软件开发相同的敏捷实践。自动化还需要适当的规划和设计。当你自动化的时候，你不会想增加你的技术债务。
创建测试自动化待办事项表。这个待办事项可以从实现新特性到增强现有特性。给你确定的项目的故事点，并相应地分配它。将这些待办事项带到您的Sprint中，并使用看板跟踪它
为您的自动化故事编写验收标准。这些接受标准可包括：
测试套件与CI的集成
将西装移植到一个集中的位置
通过电子邮件发送结果
提供在测试失败时发送错误日志文件
任何其他标准…。
不要花费过多的时间来评估一个新的工具。您可以创建一个优先级清单，列出您希望从新工具中得到的内容，并确定评估它的时间表。如果您没有在规定的时间内看到您的结果，请转到下一个。
对什么是自动化做出明智的决定。并不是每一块自动化都是有效的，并产生积极的投资回报率。不要仅仅为了自动化而自动化。
利用适当的开发环境。不要将代码保存在本地。有一个存储库来保存您的代码，并养成在一天结束时检查代码的习惯。
以类似的方式，尝试从一个集中的位置执行您的自动化测试。让它成为独立的人。应该是团队中的任何人都可以从他们的机器上触发脚本，并通过电子邮件获得结果。
可应用于自动化的敏捷原则是什么？
一些非常简单的建议：
保持简单。做必要的事。我见过很多情况，我们交付糖衣的实现，这使得自动化不必要地复杂。让我们避免那些不需要的东西
做简单的事情并不意味着做最简单的事情。这意味着采取初步的步骤来实现您的自动化目标。您可以使用一个简单的特性来实现自动化，但是自动化的实现可能会发生复杂的情况。
应用整个团队的方法。我相信每个人都是敏捷团队中的测试员。我们不要只对测试人员或开发人员限制自动化工作。为了实现项目的自动化，每个学科都必须互相取代。这种方法也能有效地解决执行过程中出现的任何技术问题。
该框架是在敏捷中发展而来的。。不要试图提供太多可能不必要地使自动化部分变得复杂的特性。
花点时间把它做好。花些时间来正确地设计它以避免技术上的债务。
获得频繁反馈
应用适当的编码标准和实践。设计应该简单，应用OOPS的概念，并试图保持测试相互独立。考虑一下试衣的“可维护性”等因素。
在敏捷自动化过程中，我看到了什么挑战吗？
敏捷世界中的自动化本身的挑战:
我们得好好计划。确定合适的测试套件、工具、框架和方法，都需要一个适当的策略。然而，我们应该记住不要过度计划。记住MVP(最小可行产品)
降低代码的质量，因为我们想要快速交付：我们必须记住，技术债务在自动化中也占有很好的地位。
大多数情况下，团队不遵循“整体团队方法”，而是将整个编码和维护自动化套件的责任留给测试人员，这就增加了测试人员的责任。
自动化功能测试比自动化UI更困难。
在所有这些挑战中，最关键的挑战是提升测试人员的技能。
为团队执行和维护自动化几乎就像程序员(开发人员)所做的编程(开发)活动。不仅是实现，而且集成自动化适应到CI是重要的，并要求测试人员学习和采用新的技能，学习新的工具和技术。
一些适合敏捷的开源工具
硒WebDriver-用于UI
硒栅-并行执行
黄瓜-用于BDD
JMeter-性能测试
苏普伊-网络服务
当Web服务不可用时，WireMock-Web服务测试。
Appium-用于移动
让我以著名的敏捷测试象限结束：
象限1是单元和组件测试，可以通过TDD方法实现自动化。
象限2讨论功能测试，在那里我们可以应用BDD方法。
象限3是唯一有手动测试范围的象限。
象限4主要讨论一些工具可以实现的测试。它负责负载测试、压力测试、卷测试和安全性测试。
结语
除了烟雾测试和回归测试之外，还有很多自动化的范围。因此，我们必须打破仅限于这些类型的测试的自动化的概念，这反过来意味着敏捷测试人员的技能集不仅仅需要找到bug和缺陷。
测试人员需要更多的协作和提高他们的编程/自动化技能。如果越来越多的测试是自动化的，这将给测试人员更多的时间来参与更复杂和更具挑战性的任务。
原文地址：http://blog.51cto.com/13879140/2154324