如何通过重新思考测试自动化来加快发布过程

Question

背景:网络安全公司被一家规模较大的公司收购。这是一家只进行手工测试的初创公司，在收购之后，测试自动化就开始了，它与一个承包商团队合作，主要使用Selenium进行UI测试。

当前进程是：

1. 我们有一个质量门，您必须运行所有的测试，以便能够合并您的代码掌握。我们有大约6000个单元，300个集成，1000个UI测试，大约需要70到110分钟才能执行。
2. 我们通过选择要发布的代码创建一个发布分支，并且在部署到RC之前再次运行相同的测试。
3. 在RC上有一个单独的测试套件，大约有550个UI测试。
4. 在金丝雀上，在发布到生产之前，我们还有20个UI测试要运行。

大多数问题都与第一步有关:问题是，在这种沉重的负载下，我们的测试基础结构非常不稳定，而进行1000次Selenium测试也没有帮助。这将导致我们的质量门是极薄的，导致大约40%的通过率。这是可能的，开发人员正在挣扎合并他们的代码数天，因为他们必须重新运行整个套件5-6次。现在，不幸的是，由于其他正在进行的测试项目，我们无法完成大的步骤，例如开始将UI测试重构为大规模的集成测试。

我有一些想法来调整我们的测试工作，但是由于我没有这样的经验，所以这些只是理论上的：

1. 正如我所提到的，我们有很多UI测试，这些测试的设计都是为了深入地覆盖特性，而不是在思想的广度上。我认为，拥有一套测试较少、覆盖更广泛的特性的套件将是一件好事。我们可以在合并到master之前执行这个较小的套件，并且一旦发布包最后确定，然后在升级到RC之前运行完整的套件。
2. 为较小的套件引入测试的执行时间限制。如果一个测试是缓慢但必要的，那么重构，引入快捷方式等等。
3. 新的测试应该主要写到集成级别。
4. 开始实现由前端调用的公共API，并将UI测试移到可能的API级别。

这些观点有意义吗？命令应该是什么？你们怎么做，从哪里开始？

如果有人遇到类似的问题，任何建议都会很感激。

Answer 1

“完美是实现的，不是在没有什么可补充的时候，而是在没有什么东西可以带走的时候。”--安托万·德圣-埃克斯伯里

一般来说，努力使UI测试更加横向(端到端，而不是深度)，使低级测试更垂直(深度)。

在我的自动化旅程中，我在UI测试中学到了很少的硬性经验，如下所示：

• 有较少的UI测试，因为简单明了。
• 不要在多个测试或多个测试级别上进行相同的验证。
• 让每一次测试都能通过，而失败的原因只有一个，集中的测试。
• 不要试图在测试中重新构建复杂的应用程序逻辑，否则它们很容易出现与应用程序本身相同的错误。
• 努力做到宽广，而不是深邃。
• 如果大多数测试都是不稳定的，那么测试代码质量就很低。
• 定期回顾它们，并且毫不犹豫地扔掉那些不再有价值的东西。(沉没成本理论 )

我的建议

在每个测试中添加一个度量标准，以便在每次发现bug时获得肯定点，并在适当的级别上为每个薄片failure.Add添加新的错误测试。

计算每个测试的相对点，并定期丢弃最低的测试点，这将使您的测试套件在一段时间内精益求精。

在您的情况下，我将从删除UI测试开始，这些测试在整个堆栈中增加了最低值。

如果UI测试在任何其他版本中都断断续续地失败，而且几乎没有发现实际的应用程序问题，那么这是一个很好的删除候选版本。

良好的阅读量测虚脱