User interface Gui测试耗时太长-什么'；你的方法是什么？

我们有一个典型的web应用程序堆栈。针对应用程序执行了120个selenium（webdriver）测试。这大约需要1小时。我们将它们作为构建链“编译>单元测试>集成测试>gui测试”的一部分执行。gui测试占用了很多时间，我们想知道如何更好地构造它们。目前，它们是“快乐案例和不快乐”案例测试。它们非常稳定，即不会因为程序员错误而失败

我们希望缩短构建时间，最大的部分是gui测试。我们希望在“客户旅程”的基础上这样做，即指定（与业务人员一起）一些典型的用例并测试它们（快乐路径），而不是测试太多

你们是如何组织gui测试的？以下是我想到的一些想法

• 只执行快乐路径测试
• 进行“客户旅程测试”，即一次进行多个快乐路径测试（“点击页面”）
• 仅接受业务部门指定的“前10名”（任务关键型）
• 前10+“所有其他”夜间建造（一次）

我会很感激你的想法

谢谢

---

marcel

夜间是硒测试的最佳时间-你只需记住在你的电脑上贴上一张“不要关掉我！”的便条：）

此外，总有这样的情况：夜间时间太短，无法运行所有测试。使用Grid，您可以在多台机器上并行运行测试

---

我们有几种适用于不同情况的测试。在主要发布（测试、预调试、生产）之前，一切都在运行。通常（每天或甚至在高峰时段每小时）只有“用户通过应用程序的快速正常路径”套件运行。如果有人“修复”了一个大的bug，那么与应用程序的这一部分相关的测试就会运行。

一个小时对我来说绝对合适

一个建议可能是决定哪些测试属于烟雾测试，并且需要每晚运行。也就是说，显示web应用程序的核心功能仍然完好无损且正常工作的测试-其他更详细的测试可以在不同的时间运行（每隔几天一次？）

话虽如此，我们的测试大约需要2个小时——唯一的问题是当一个测试失败时，您需要修复它，提交它，但需要等待很长时间才能验证它在CI服务器上是否已修复。

允许在同一台机器上并行运行构建，因此gui测试不应该与单元测试和集成测试一起出现在构建链中。UI测试应该有单独的数据库和单独的构建，这样他们就不会浪费开发人员、手动测试人员或任何其他涉众的时间。TeamCity将收集所有统计数据，并发送关于构建失败的电子邮件等。
下一步是并行化。正如Slanec所说，您可以将网格（不需要多台机器）与（c#）或（java）一起使用。借助Grid，您可以将测试执行时间减少10倍，因此只需6（！）分钟即可运行所有测试。
此外，您还可以将一些测试组合到更大的测试中（但这将增加发现失败原因的时间，并使测试难以维护）。

---

在这些步骤之后，Gui测试可以在每次源代码提交后执行，并提供对应用程序错误状态的快速响应。

好问题，好答案

另外一个需要考虑的问题是，您可以对120个gui测试进行优先级排序：您可以按顺序运行它们，以便首先运行最重要的测试或最有可能失败的测试。 这无助于缩短构建时间，但有助于更快地从构建中获得有用的反馈

这个优先级（你的前10名）不需要固定，但可以根据发布/迭代/完成的故事/天等进行更改。 例如，您可能希望首先运行最新的gui测试。或者是最近改变的。或者是涵盖了最近更改的大部分代码的代码

---

据我所知，虽然在测试用例优先级方面有相当多的（学术）研究正在进行中，但没有任何工具可以立即支持这一点。

因此，您的所有建议似乎都是好的。尽量不要浪费别人的时间在白天运行测试。为什么不检查本地机器上的固定测试？当然可以检查本地机器上的固定测试，但是Selenium测试指向不同的数据库和软件副本。当然，app.config有一些更改，您可以在local.aleh上指向相同的版本，谢谢您的评论。我们已经设置了teamcity。对于每个测试场景，我们都有专用的数据库等。5个代理并行运行测试（在提到的链中）。@Marcel您是否在5个代理之间拆分了单元测试？Gui测试应该在没有任何链的情况下独立运行（单独部署），这样即使它们花了1个小时（好的，你会的，但不会太多）你也不会感到麻烦。不，每个链都在5个代理中的一个上执行。目前这对我们来说还不错，单元测试不会花很长时间。唯一让我们头疼的是gui测试。我认为我们需要将它们从链条中分离出来（只留下一个简单的烟雾测试），并在专用的时间段（可能是晚上）执行它们。对我来说，gui测试类似于“自动化QA人员”，可以测试页面。。。。如果开发人员更改了某些内容，他们应该在机器上或通过teamciy上的个人构建在该区域执行gui测试。@Marcel理解。然后我认为网格并行化是最适合您的方法（在开发人员更改某些内容后，错误出现在意外的地方，因此重新测试整个应用程序会更安全-使用网格可以非常快地完成）JUnit也可以进行并行单元测试：