In-Sprint自动化回归测试-UI自动化解决方案

揭示自动化网站测试的一些重要方面以及自动化如何融入软件开发策略。

在谷歌上搜索用户界面测试自动化会显示很多工具的结果，但不会有太多好的实践。搜索有关 GUI 测试自动化的经验，您可能会得到一些代码（使用错误的编程语言），或者您会得到一些建议。最近的建议是包含一些 UI 自动化刻板印象——UI 自动化不稳定，UI 自动化很慢，记录/回放很脆弱，团队将花更多的时间来维护测试代码而不是实际测试。对那些人来说有一点道理。

本文涵盖了自动化网站测试的一些重要方面——优点和缺点、构建测试、框架选择以及自动化如何适应软件开发策略。

自动化战略

在查看工具的许多选项和构建概念证明之前，第一步是问“为什么”这个问题。

可以说，启动UI自动化项目的最常见原因是“回归测试花费的时间太长”。每个版本，他们有一周的时间开发新功能，然后将新代码交给测试人员，然后有一周的时间对新工作进行测试和错误修复。当一切都完成后，仍然需要有人做一些调查，希望能发现最近所有的代码变动是否引入了任何令人惊讶的问题。最后一部分，回归测试，要么花费太长时间，要么时间紧迫。这就是有人想到所有实际操作的回归测试都可以自动化并立即完成的地方。

这样做的最终结果通常是一个中途构建的测试套件，并没有真正返回太多信息。而且，时间更短，因为进行回归测试的那群人现在正在同时进行回归测试和构建自动化。事实是回归测试花费了太多时间，因为开发流程很糟糕。

这就是要解决的问题。

这是UI自动化的另一种策略；使用它来推动功能更快地投入生产。