我们有一个由 2 位开发人员开发了 3 个月的应用程序。该网站相对较小，仅完成了 1/3，但测试相当全面。
在我们的开发机器上运行 Protractor 在串行运行时需要 60 分钟，而在运行 2 个并发会话的分片时需要不到 40 分钟。
在 2 个并发会话中针对具有 6 个兼容性的 BrowserStack 运行 Protractor 需要不到 4 小时。
为完成的产品推断这些测试时间（即 4 小时 + 200%）意味着总测试时间约为 12 小时。这超过了 travis-ci.com 上 120 分钟的限制，使我们进入了 Browserstack 上 999 美元/月的套餐。这也意味着，任何更改（包括错误修复）最多需要 12 小时才能生效。
其他人是否也遇到过同样的问题，如果有，他们是如何解决的？
在我看来，要么你应该改变你的测试策略并通过运行 sanity suite 开始发布新的特性/错误，要么你可以选择最少数最重要的平台来运行整个测试来发布。我知道这不是发布功能的理想方式，但至少它会给你很大的信心继续前进。
第二个选项使用 CI 工具中的多个作业在不同平台上运行测试，如果有任何财务限制，那么我会说让我们设置一个本地 CI 工具。也许你可以和詹金斯一起去。
我们刚刚完成了这样的 CI 实现（TFS + Jenkins）。我们还使用 Browserstack，我们为上一个项目进行了大约 150 个 e2e 测试。执行这些测试也需要相当长的时间。所以我们所做的决定不是在每次提交之后执行这些测试，而是每天作为夜间工作执行。早上可以查看结果并查看是否出现错误/构建失败的原因。我们使用最便宜的计划，我们有 4 个不同的配置文件（chrome/safari/firefox/iOS），每个配置文件有 4 个浏览器/平台设置。实际上有点棘手：即使您拥有最便宜的浏览器堆栈计划，您也可以并行执行 4 个测试而不会出现任何问题。
顺便说一句，我们使用了 Git + Bitbucket + Babmoo，它比 TFS + Jenkins 更加用户友好