自动化的用户界面测试解决了什么问题？

我们目前正在研究自动化的用户界面测试（我们目前正在进行自动化的单元和集成测试）。

我们已经研究了Selenium和Telerik，并且由于后者的记录器更加灵活，因此选择了后者作为首选工具-我们真的不希望测试人员编写太多的代码。

但是，我试图了解整体利益。人们的看法是什么，什么样的事情行之有效，什么行不通？

我们的系统正在不断开发中，我们会定期发布（基于Web的）平台的新版本。

到目前为止，我们可以看到的主要好处是进行回归测试，尤其是在我们平台的多个客户端部署之间。

真正在寻找别人的意见。我们“认为”这是对的，但是在已经很忙的日程中，我们正在寻找更多的见解。

当我的团队实施自动化的UI测试时，发生了很多很棒的事情。

首先，质量检查团队在测试应用程序方面变得更加高效，并且对应用程序也更加精通。负责质量检查的负责人说，他能够通过将新的质量检查成员介绍到用户界面的测试套件中来使其快速成长。

其次，返回到开发团队的质量检查票证的质量更好。而不是“当我单击提交按钮时页面中断”，我们得到了失败的确切案例，因此我们可以看到输入到表单中的内容。质量检查小组还进一步检查了所有失败的案例，并测试了该页面上的其他场景，以使我们可以更好地了解发生的情况。

第三，质量检查小组有更多时间。有了这些额外的时间，他们就可以参加更多的设计会议。这样一来，他们就可以在开发人员编写这些新功能的同时，编写新的测试套件用例。

另外，我们使用的测试套件进行的压力测试值得一试。老实说，它知道我的应用程序可以承受扔给它的几乎所有东西，帮助我在晚上睡得更好。我们发现，有很多页面在上线之前就可以解决的压力下屈服。刚刚好。

我们发现的最后一件事是，通过QA团队的一些调整，我们还可以在我们的应用程序上进行一些SQL注入测试。我们发现了一些能够迅速修复的漏洞。

UI测试套件的设置花费了大量时间。但是，一旦存在，它将成为我们开发过程的核心部分。

自动化的UI测试是真正的集成测试。他们以实际使用时的方式测试整个系统。这使它们成为最有意义的测试。但是，它们也往往最易碎，执行起来也最慢。

密切关注成本/收益比（脆性是成本的一​​部分），不要犹豫，仅手动测试某些东西（但要确保已测试）。并且，如果有可能，开发人员可以针对自己本地运行的应用程序版本运行UI测试套件的特定部分，以便他们可以在开发期间从测试中受益。

当然，绝对必须在构建服务器上自动运行测试（每天至少一次）。

我们真的不希望测试人员编写过多的代码。

IMO这是一个白日梦。创建自动化测试就是编写代码。录音功能，可以帮助你编写一些代码的速度更快，获得与手工编写更快速启动（与你慢下来，非常如果你错过了在那里写代码手动变快了点），但最终手动编写代码是你什么会结束做很多。更好的希望您的测试框架能够很好地支持它，并且其开发还没有过多地集中在（非常可售）管道梦想上，该梦想允许那些不会编写代码的人进行自动化测试。

我们真的不希望测试人员编写太多代码

我们采取了相反的方法。我们希望测试人员编写代码。

这是我们开始采用的工作流程。做到这一点并不容易，因为管理并非绝对依赖于前端的自动化测试。他们愿意为“足够接近”。

1. 用户故事。

2. 经营理念。这个故事可能如何运作。设计回顾。

3. 屏幕草图：UI设计。看起来如何。

4. 硒脚本。如果脚本都能正常工作，我们就完成了发行。

5. 编码和测试，直到脚本工作。

自动化测试是证明该功能存在的唯一方法。

手动测试容易出错，并且会受到管理人员的追捧：“这足够好，那些失败的测试与按时发布无关紧要。”

“没有自动测试的任何程序功能都根本不存在。”

视觉呈现是另一个故事。手动测试视觉布局是一种例外情况，因为它可能涉及审美判断，也可能涉及在非常大且复杂的屏幕像素上查看特定（小）问题。

到目前为止，我们可以看到的主要好处是进行回归测试，尤其是在我们平台的多个客户端部署之间。

自动化回归测试是一件好事。这可以使您的测试人员腾出更多精力来做更多有趣的工作-通过添加更多的自动化测试，对您的应用程序进行压力测试或其他任何事情。

此外，通过使其自动化，您可以使您的开发人员运行测试，因此可以防止在以后的过程中发现问题。

我们已经研究了Selenium和Telerik，并选择后者作为它的首选工具，因为它的记录器更加灵活

我不确定您研究了多少。当然，还有其他选择。您是否看过Watir，WatiN，Sikuli等？

我们真的不希望测试人员编写过多的代码。

对于那些必须维护这些脚本的人来说，我感到很难过。通常，如果没有易于修改的代码，脚本会变得脆弱，修改脚本的时间要比重新记录脚本的时间长，这会浪费更多时间。

但是，我试图了解整体利益。人们的看法是什么，什么样的事情行之有效，什么行不通？

如果正确完成，测试自动化是一件美丽的事情。它节省了回归测试/检查的时间，从而为您的测试人员提供了更多时间来做他们最擅长的测试。暂时不要相信这是灵丹妙药。如果应用程序已经存在，但测试不存在，自动化脚本需要大量时间来开发，并且每个版本都需要不断更新。自动化测试也是让团队中的新人们了解系统应该如何运行的好方法。另外，请确保您的测试人员可以决定需要自动化的内容。如果这是一个小检查，不需要很多检查，非常单调且易于自动化，则从此开始。始终从通过自动化获得最大收益的检查开始，然后从那里开始工作。

到目前为止，我们可以看到的主要好处是进行回归测试，尤其是在我们平台的多个客户端部署之间。

它的主要好处是，如果设置正确，只需进行少量配置更改就可以测试您需要的大多数浏览器。

我们“认为”这是对的，但是在已经很忙的日程中，我们正在寻找更多的见解。

正如我之前所说，测试自动化需要付出巨大的努力，但是，如果正确完成，我还没有遇到一个团队，他说：“我希望我们没有设置测试自动化。”

没错，回归是巨大的。另外-

• 如果您的测试是模块化编写的，则可以通过混合和匹配测试集来获得更多收益

• 我们已经将自动化测试脚本重用于数据加载，因此我们不必为了进行大型测试而费解数据库

• 性能测试

• 多线程测试

• 在网络系统上-在浏览器之间交换和在操作系统之间交换。由于浏览器一致性问题，尽可能扩大基础是一件大事。

要跳过的事情-特别是在Web系统中，请注意用动态变化的ID创建显示元素的情况-通常自动测试脚本不能很好地解决此问题，您可能需要进行认真的重新设计以更新此问题。

只是一个例子：准确测量网页渲染的持续时间

使用自动化测试，测试Web浏览器的性能要容易得多。要测量您可能接受的最大响应时间，只需在测试脚本中设置一个常量，和/或将其作为函数参数传递，例如，在此伪代码中：$ sel-> wait_for_page_to_load（$ mypage，$ maxtime）。

以较低的值进行跨浏览器测试会很有启发性。

另一种选择是让员工使用秒表进行计时测量。

自动化的用户界面测试解决了以下问题的能力：

• 快速重复测试大量组件
• 记得每次都要测试大量功能
• 随着应用程序的增长，比较测试套件的运行和运行时间
• 建立具有数百种不同输入和可变条件的运行
• 使未编写测试的人可以运行它并查看任何视觉问题
• 允许最终用户以快速简便的方式查看正在使用的应用程序
• 将测试用户界面运行分发到网络，远程服务器或服务
• 使用并行机开始批量测试。

但是，正如其他人指出的那样：

Telerik ...

记录器更加灵活，因此是首选工具

对我们许多人来说是一个危险信号。

用这种方式记录的脚本不是长期解决方案，因为：

• 数据库/对象ID随情况而变化
• 手动记录的脚本通常依赖于经常更改的页面布局标签
• 需要重复编写常见操作，而不是允许重复使用（请参阅SitePrism和PageObject方法）
• 有时您需要使用xpath之类的工具来基于当前页面信息获取其他信息。一个简单的录制脚本不会执行此操作。
• 不鼓励编写代码的开发人员和测试人员使用CSS类，ID和HTML5数据属性，这些做法将导致更健壮，更可维护的测试。

Telerik确实具有一些应考虑的优点：

• 针对移动客户
• 内置工具来管理增长
• 处理Android，iOS和Windows Phone

可以弥合差距的一种方法是使用工具页面记录器记录初始脚本，然后将脚本更改为使用ID的类，类和数据属性，以便脚本可以持续使用。这是我实际上与firefox硒插件一起使用的方法。

它使“专家测试”（类似于“探索性测试”，但是由最终用户或具有大量业务知识的团队成员执行）更易于执行，记录结果，进行度量和自动化。

我来自不同的背景。在我以前的雇主那里，我们开发了商业自动化测试工具（QALoad，QARun，TestPartner，SilkTest，SilkPerfomer）。

我们看到自动化的UI测试扮演着两个角色：

1. 全面回归测试

2. 自动设置测试环境

我们非常依赖工具来每晚进行回归测试。我们根本没有人力来测试所有按钮和对话框，以验证我们在UI和业务逻辑之间没有破坏任何东西。

对于更重要的测试，我们发现一个人可以启动多个虚拟机并使用脚本来进行真正的测试。它让他们专注于重要的方面，而不是尝试遵循24步测试用例。

自动化测试的唯一问题是习惯将过多的测试倒在盒子上，而没有任何监督以消除重复或不必要的测试。有时我们不得不回去整理一下东西，这样套件才能在12小时内完成。

任何类型的自动化测试都提供回归测试；通过运行曾经可以运行的测试，您可以验证它是否仍然有效（无论是否添加了其他功能）。无论测试是集成测试（通常不涉及UI）还是AAT（通常需要 UI），这都是正确的。

自动化的UI测试允许像用户单击按钮一样对系统进行测试。因此，此类测试可用于验证系统中的导航，标签和/或消息的正确性，特定测试环境中的性能和/或加载时间等。主要目标是减少质量检查人员花费在单击按钮上的时间，就像集成和单元测试对程序员一样。他可以一次设置一个测试（通常是通过记录自己的鼠标单击和数据输入到脚本中），一旦测试正常运行，他就必须做所有工作以验证被测系统的正确性。一些框架（例如Selenium）允许在浏览器之间迁移测试，从而允许测试站点应在其中正常工作的几种环境。

没有自动测试，您将受到质量检查人员数量和速度的限制；他们必须从字面上动手操作系统，测试您的新功能是否符合要求，以及（同样重要的是）您没有破坏现有功能。

测试确定许多不同的事物。这些测试中的许多可以自动化，以消除繁琐的工作，并完成更多工作。为了确定您的测试是否可以自动化，您首先需要查看他们提出的问题是否合适。

• 您是否正在确定某个组件是否按照规范运行？
• 您是否要测试所有可能的输入和输出？
• 压力测试组件？
• 还是您要测试“它有效”？

其中大多数可以自动化，因为它们本质上是机械的。新函数接受输入，那么当我们向它扔随机数据时会发生什么呢？但是有些测试，例如测试系统是否正常工作，需要有人实际使用它。如果他们不同意，您将永远不会知道用户的期望与程序的期望是否相同。直到系统“崩溃”为止。

以我的经验，自动用户界面测试涵盖了许多空白，包括：

• 缺乏文档（例如：使用自动测试运行器演示现有功能）
• 由于范围蔓延而导​​致过时的需求（例如：通过在测试运行期间捕获屏幕来识别需求和代码之间的差距）
• 开发人员和测试人员的高流失率（例如：在开发人员工具打开的情况下，通过在测试运行期间捕获屏幕来对旧版JavaScript进行反向工程）
• 通过XPath回归测试来确定是否违反标准命名约定（示例：在所有DOM属性节点中搜索驼峰式名称）
• 识别只有计算机才能发现的安全漏洞（例如：从一个选项卡注销，同时在另一个选项卡中提交表单）

我想分享我们团队的经验。我们一直在使用我们自己的UI测试工具Screenster来测试我们和客户的Web应用程序。它已被证明是Selenium的有用替代品，可用于视觉/ CSS测试任务。Screenster是一种测试自动化工具，可以对不同版本的网页执行基于屏幕截图的比较。首先，它为页面创建可视基线，并为每个用户操作拍摄屏幕截图。在下一次运行期间，它将在每个步骤中获取一个新的屏幕截图，并将其与基线中的屏幕截图进行比较并突出显示差异。

总结起来，Screenster具有以下优点：可视基线：在测试记录期间为每个用户步骤捕获屏幕截图基于屏幕截图的比较：Screenster将回放期间捕获的图像与基线图像进行比较，并突出显示所有差异智能CSS选择器：测试人员可以选择屏幕截图上的CSS元素并对其执行操作-例如，将它们标记为忽略区域以排除在进一步比较之外