您多久运行一次？
如何在如此大量的测试中处理错误（失败的测试）？
#1 楼
如果可以在无人看管的情况下运行它们，请每周在周末运行它们。 >对于分析结果，这是另一个问题。我发现将结果分为功能或类别很有用。这样，我可以从结果集中快速看到最大的问题所在，并集中精力解决问题。关于处理错误，这取决于返回结果的质量以及返回结果的性质。错误。结果不仅仅包括通过/失败。它们应包括相关的错误消息，测试操作和参数以及版本详细信息。这样一来，它们很容易变成bug。如果不可能，则可以相对轻松地手动复制它们，并以这种方式记录为错误。
评论
请注意，2011年的发布是每月或每年。现在到2020年，每天或每小时或每分钟很常见。如果是这种情况，那么“周末”将不再是可行或有用的策略。
–迈克尔·杜兰特（Michael Durrant）
20 Mar 4 '13 at 19:19
#2 楼
这取决于。对我来说，每次部署测试环境时，我们都会运行自动化。但是可能会发生变化的是，我们将要运行的测试用例的数量以及用于运行它们的机器的数量。在1.0上线之后，通常我们会选择一些关键测试用例，这使我们获得了高级测试合格。该测试通过将广泛涵盖所有功能，以快速确定可能需要更多关注的领域。
这里存在测试转义与执行时间平衡的真正风险。我还将增加以下方面的覆盖率：a）最近更改过的区域，b）已知历史上不稳定的区域。需要运行所有测试以使其保持良好的正常运行。
#3 楼
我会同意布鲁斯的看法，这取决于。如果您的需求需要这些以使其更经常运行，则将它们尽可能地适合它们。否则，如果您负担得起，您可能需要做的是建立一个不断运行它们的环境。我是在一家需要持续运行这些测试的公司中进行的，并且是在长期运行测试的Longevity环境中进行的，我们只是在那里更新了版本。为此，我不在目前的公司工作，但是当您需要进行长时间的测试并且必须在某个地方进行测试时，这是一个选择。对于没有较新环境的地方，我会在非工作时间，周末或休假日或任何时候运行这些环境。否则，我将选择一个有代表性的子集并尽可能多地运行它们。评论
我认为这是一个很好的折衷方案：选择一个有代表性的测试样本，然后在其他无用时间（周末或夜间）进行测试。也许在周末运行全套套件，而有代表性的样品则在一夜之间运行。
– Peter K.
2011年5月9日12:37
#4 楼
只要您负担得起。毕竟它们是自动化的。如果它们很健壮并且没有给您带来误报，那么理想情况下，一旦编译和其他测试通过，每次提交都将被执行。评论
每次提交之后，要花2天才能完成的测试必须完全是个地狱。无论如何，这是最初的问题。我想您可能在彻底阅读了最初的问题之后想改变策略。
–pavelsaman
20年3月4日在18:51
#5 楼
强制性：每次发布（对解决方案团队来说）
每天的基本负载变化都是核心或影响超过一个已经交付的功能区域br />大量错误修复。
可选：
#6 楼
当您转向每周一次，每天一次，每小时一分钟地发布时，您的整个策略必须改变。除了需要花费很多天和几周的时间来处理大量传统的长时间E2E案例以外，您需要切换到使用“敏捷测试金字塔”和“敏捷测试象限”来真正消除大量运行端到端测试。大多数测试应该是单元级别的。
E2E测试也应该在代码（BDD）之前编写，并且有许多实践需要采用这些实践。
在这个旅程中，教练或指导者会很有用，以避免重新发明轮子，就像发现所有这些真相感到很好。
评论
自动化的用户验收测试？我不懂是否熟悉您的用户的想法？那将是一个用户接受测试。还是脚本执行此操作？那将是一个自动化测试。除非您可以使实际用户对应用程序的响应自动化，否则我不确定您可以进行自动用户接受度测试。我可能在这里错过了一些基本的东西...我指的是尽可能忠实于客户/用户要求的自动UI测试。
然后进行自动化功能测试。 :-)
@glowcoder“验收测试”是一个笨拙的描述，但实际上是一个常见的描述。 （我本人不太喜欢该术语，因为两个词实际上都不是正确的，但是这似乎是人们使用的术语。）