怎么样才能让回归测试变得更加轻便快捷？
自动化战略在查看工具的许多选项和构建概念证明之前，第一步是问“为什么”这个问题。
可以说，启动UI自动化项目的最常见原因是“回归测试花费的时间太长”。每个版本，他们有一周的时间开发新功能，然后将新代码交给测试人员，然后有一周的时间对新工作进行测试和错误修复。当一切都完成后，仍然需要有人做一些调查，希望能发现最近所有的代码变动是否引入了任何令人惊讶的问题。最后一部分，回归测试，要么花费太长时间，要么时间紧迫。这就是有人想到所有实际操作的回归测试都可以自动化并立即完成的地方。
这样做的最终结果通常是一个中途构建的测试套件，并没有真正返回太多信息。而且，时间更短，因为进行回归测试的那群人现在正在同时进行回归测试和构建自动化。事实是回归测试花费了太多时间，因为开发流程很糟糕。
这就是要解决的问题。
这是UI自动化的另一种策略；使用它来推动功能更快地投入生产。
UI自动化通常是在至少一个 sprint 的延迟上开发的。现在正在编写的测试代码可能是针对已在生产中进行了数周或数月的代码更改。充其量，这只会告诉您页面上的某些内容何时发生变化。为什么不在冲刺中构建自动化？
自动化看起来像这样。开发人员在适当的地方编写他们的新功能，并在单元和 API 测试中进行。一旦 UI 接近完成，他们应该与测试人员更密切地合作。该测试人员可以开始构建自动化 UI 测试的骨架。他们可能会编写几行代码来导航到一个页面，然后开始填充一些文本字段，然后不得不停下来调查一个不接受 20 个字符长输入的字段。开发人员会查看那个点，修复一个错误，然后重新启动他们的本地服务器。然后测试人员会重新开始构建测试，同样写一两行，停下来调查一些有趣的事情，然后重新开始。
到构建该功能的重要覆盖范围时，已经探索了新的代码更改并进行了多轮错误修复。当更改准备好提交时，会有单元测试、API 测试和一些自动化的 UI 测试。该功能基本上已准备好用于生产。这也有防止过多 UI 自动化的副作用。
一旦流程到位，回归测试确实会更快，开发流程也会更加顺畅。不必在组之间进行交接，代码进入回归测试已经测试，检查通过 selenium 传递给该功能。在持续集成系统仪表板中添加一点探索和一个绿色条，团队可以为 sprint 发送代码。覆盖问题也变得容易多了。一个人不需要在 5 个不同的 Web 浏览器中执行类似的测试，而是一个脚本可以在所有浏览器中并行运行，同时一个人寻找更重要的问题。
框架选择
有许多 API 和工具可用于帮助人们构建 UI 自动化。对它们进行分类的一种简单方法是，构建测试的人是否记录了他们在浏览器中执行的步骤并随后添加了断言，或者他们是否正在编写代码。
录制和回放
Telerik Test Studio 和 HP 统一功能测试 (UFT) 是流行的记录和回放工具。使用这些工具，非技术人员可以主要靠自己来创建测试。他们可以创建对象库来引用页面元素，在必须重复执行某些系列步骤时调用可重用的函数。这些通常可以使用专有编程语言或 C# 之类的语言进行扩展。使用记录和回放工具创建稳定的测试可能很困难。
构建测试
使用 WebDriver 为用户管理页面构建测试的第一步是构建页面对象。该类应包含 enterFirstName()、enterLastName()、setBirthDate、deleteFirstName()、clickSubmitBtn() 等方法。这些方法中的每一种都是完全独立的。例如， enterFirstName() 将检查该元素是否存在、它是否可见并准备好进行操作，然后输入文本。
该用户管理页面的第一个测试可能如下所示：
enterFirstName("Justin")
enterLastName("Rohrman")
setBirthDate(03/02/1981)
clickSubmitBtn()这些步骤之后将根据您期望页面返回的内容进行断言。
在自动化 UI 测试中，在无法帮助您了解产品重要部分的质量的浅层测试套件和过度使用并跨越需要持续护理和喂养的门槛的套件之间存在细微的界限。（你做的检查越多，测试需要的维护就越多。）一个管理页面的单个用户创建测试可能是不够的。自动化进入您脑海的每个测试想法可能太多了。中间的一种方法，创建更新，删除 (CRUD)，可能更有意义。
此测试将执行以下操作：
· 创建一个新用户
· 断言新用户仍然存在并且值符合预期
· 更新该用户个人资料上的每个可更新字段
· 断言新值持续存在
· 删除用户记录
· 断言在搜索中找不到该用户
对于 Web 测试来说，这听起来像是一个复杂的场景，它可能确实如此。良好的架构和使用页面对象等设计模式可以使其既有用又可靠。
如果页面对象出现故障，那么当页面上的元素发生变化时，很多测试都会失败。无论使用哪种开发模式，这个问题都是真实的。页面对象模式的优势在于修复只需要在一个地方——页面对象——而不是每次测试。正确的设计模式和良好的 API 的结合意味着您只需在一个地方更改代码即可让事情再次运行。考虑到软件的本质是要改变的，这一点很重要。
有很多方法可以使 UI 自动化正确，也有很多方法可以弄乱它。首先了解团队的目标：开发团队有什么问题以及 UI 自动化如何解决这些问题。接下来，制定符合这些目标的策略：需要多少 UI 自动化、哪些地方需要覆盖以及团队应该从哪里开始。然后，选择正确的工具，一种与工具配合使用的设计模式，并开始构建测试。在那之后，游戏提出了很好的测试想法，将它们转换为代码，知道何时改变策略……以及何时停止进行新的测试。
页:
[1]
