我们有一个典型的Web应用程序堆栈。有120个针对应用程序执行的selenium（webdriver）测试。这需要约1小时。我们将它们作为构建链“compile＆gt;单元测试＆gt;集成测试＆gt; gui测试”的一部分执行。 gui测试占用了大量时间，我们想知道如何更好地构建它们。目前他们是“快乐案例和不快乐”案件测试。它们非常稳定，即它们不会因程序员错误而失败。
我们希望缩短构建时间，最重要的是gui测试。我们希望基于“客户旅程”来做这件事，即指定（与业务人员一起）一些典型的用例并测试它们（快乐路径）而不是测试太多......
你们如何构建你的gui测试？这里有一些我想到的想法
我很感激你的想法
感谢 烫发
答案 0 :(得分：7)
夜间是Selenium测试的最佳时间 - 您只需要记住“不要让我失望！”你电脑上的粘滞便笺:)。
此外，当夜间开始太短而无法运行所有测试时，始终存在Selenium Grid。使用Grid，您可以在多台机器上并行运行测试！
我们有几个适用于不同情况的测试suites。在主要版本（测试，预生产，生产）之前，一切都在运行。通常（在每天甚至每小时的高峰时段）只运行“通过应用程序的用户加快的正常路径”套件。如果某人“修复”了一个大错误，那么就会运行与该部分应用程序相关的测试。
答案 1 :(得分：4)
我觉得一个小时对我来说绝对没问题。
一个建议可能是决定哪些测试是在烟雾测试下进行的，并且需要每晚运行。也就是说，显示Web应用程序的核心功能的测试仍然完好且正常 - 其他更详细的测试可以在不同的时间运行（每隔几天一次？）。
话虽如此，我们需要大约2个小时 - 唯一的问题是当一个测试失败，你修复它，提交它，但是然后必须等待很长时间来验证它是否已在CI服务器上修复。 / p>
答案 2 :(得分：1)
TeamCity允许在同一台机器上并行运行构建，因此gui测试不应该在构建链中以及单元和集成测试。 UI测试应该具有单独的数据库和单独的构建，因此它们不会浪费时间开发人员或手动测试人员或任何其他利益相关者。 TeamCity将收集所有统计信息，将发送有关构建失败的电子邮件等
下一步是并行化。正如 Slanec 所说，你可以使用Mbunit（c＃）或TestNG（java）来使用Grid（不需要多台机器）。在Grid的帮助下，您可以减少测试执行时间，例如10次，所以你的测试只需要6（！）分钟
此外，您可以将一些测试组合在较大的测试中（但这会导致发现故障原因的时间增加，并使测试难以维护）。
完成这些步骤后，可以在每次提交源代码后执行Gui测试，并对应用程序错误状态提供快速响应。
答案 3 :(得分：0)
很棒的问题，很棒的答案。
额外的考虑因素是您可以优先考虑120个gui测试：您可以按顺序运行它们，以便最重要的一个或最有可能失败的那些先运行。 这无助于缩短构建时间，但它有助于更快地从构建中获得有用的反馈。
此优先级（您的前10名）无需修复，但可以根据每次发布/迭代/完成的故事/日等进行更改。 例如，您可能希望首先运行最新的gui测试。或者最近改变的那些。或覆盖最近更改的大部分代码的那些。
据我所知，虽然在测试用例优先级方面正在进行一些（学术性的）研究，但是没有工具立即支持这种工具。