我们有一个典型的Web应用程序堆栈。有120个针对应用程序执行的硒（webdriver）测试。这需要迂回1小时。我们将它们作为构建链的一部分执行“compile> unit test>集成测试> gui测试”。 gui测试花费了很多时间，我们想知道如何更好地构建它们。目前他们是“快乐案例和不快乐”案例测试。它们非常稳定，即它们不会因程序员错误而失败。Gui测试时间太长 - 您的方法是什么？
我们想要得到的生成时间下来，最大的部分是GUI测试。我们要立足于“顾客旅程”要做到这一点，即（与业务的人在一起）指定一些典型的使用情况，并对其进行测试（幸福路），而不是测试过多.....
你们如何结构你的gui测试？这里是来到了我的脑海里的一些想法
我将不胜感激你的想法
谢谢 马塞尔
夜间是硒测试的最佳时间 - 你只需要记住把一个“不要把我关闭！”粘滞便笺在你的电脑:)。
而且，总是有Selenium Grid当夜间开始太短运行所有测试。通过网格，您可以在多台机器上并行运行测试！
我们有几个测试suites了适用于不同的情况。在主要发布之前（测试，预先生产，到生产），一切都在运行。通常（每天甚至每小时都在高峰时间）只运行“通过应用程序加快用户的正常路径”套件。如果有人“修复”了一个大错误，那么与该应用程序相关的测试就会运行。
一个小时对我来说似乎绝对没问题。
一个建议可能是决定哪些测试来下烟雾测试，并要求每天晚上跑。也就是说，显示核心的测试您的Web应用程序的功能仍然完好无损并且正常工作 - 其他更详细的测试可以在不同的时间运行（每隔几天一次？）。
说了这么多，我们花了大约2个小时 - 唯一的问题是当一个测试失败，你修复它，提交它，但是必须等很长时间才能确认它在CI服务器上被修复。
为什么不检查本地机器上的固定测试？ –
当然，你在本地机器上检查固定测试，但是Selenium测试指向不同的数据库和软件副本。当然，有几个app.config更改，您可以在本地指向相同的版本。 – Arran
唯一的问题就解决了:) –
TeamCity允许运行在构建在同一机器上并行，所以GUI测试不应该在构建链单元和集成测试沿。 UI测试应该有单独的数据库和独立的构建，因此他们不会浪费开发人员或手动测试人员或任何其他利益相关者的时间。 TeamCity将收集所有统计数据，发送构建失败的电子邮件等。
下一步是并行化。由于Slanec说你可以使用网格（几个机器不需要）与Mbunit（c＃）或TestNG（java）。借助Grid，您可以减少测试执行时间，例如10倍，所以只需要6（！）分钟即可运行所有测试。
你也可以将一些测试结合到更大的测试中（但这会导致发现失败原因的时间增加，并使测试难以维护）。
完成这些步骤后，可以在每次源提交后执行Gui测试，并对应用程序错误状态提供快速响应。
aleh，谢谢你的评论。我们已经有团队设置。我们为每个测试场景都有专门的数据库等。 5个代理正在并行运行测试（在提到的链中）。 – Marcel
@Marcel你是否在5个代理之间拆分单元测试？桂测试应该独立运行没有任何链（单独部署），所以你不会打扰，如果他们甚至需要1小时（好吧，你会，但不是太多） –
不，每个链执行5个代理之一。目前这对我们很好，单元测试不需要很长时间。唯一让我们头痛的是gui测试。我认为我们需要将它们从链条中剥离出来（只留下一个简单的烟雾测试），并在专用时间段（可能每晚）执行它们。对我来说，gui测试就像是一个“自动化QA人”，它可以测试页面......如果开发者改变了某些东西，他们应该在他们的机器上执行围绕该区域的gui测试，或者通过teamciy上的个人构建。 – Marcel
伟大的问题，很好的答案。
一个额外的考虑因素是您可以优先考虑您的120个gui测试：您可以按照最重要的或最有可能失败的顺序运行它们的顺序来运行它们。 这无助于缩短构建时间，但它有助于更快地从构建中获得有用的反馈。
此优先级排序（您的前10位）不需要修复，但可以更改每个发布/迭代/已完成的故事/日期等。 例如，您可能需要先运行最新的gui测试。或最近改变的那些。或覆盖大部分最近更改的代码的代码。
据我所知，虽然在测试用例优先级领域有相当多的（学术）研究正在进行，但没有任何工具可以立即支持这一工作。
因此，所有的建议似乎都很好。尽量不要浪费别人的时间在白天进行测试。 –