如果它们可以在无人看管的情况下运行，则每周在周末运行它们。这将为您提供足够的运行时间，并在运行之间有足够的休息时间来修复错误并可能提高自动化程度。

至于分析结果，那是另一个问题。我发现将结果分组为特征或类别很有用。这样，我可以快速从结果集中看到最大的问题在哪里，并专注于它。

至于处理错误，这取决于返回结果的质量和错误的性质。结果应该不仅仅包括通过/失败。它们应包括相关的错误消息、测试操作和参数以及版本详细信息。这样它们就很容易变成错误。如果那不可能，那么它们相对容易手动复制并以这种方式记录为错误。

这取决于。对我来说，每次部署测试环境时，我们都会运行自动化。但可能会改变的是我们将运行的测试用例的数量以及我们将用于运行它们的机器的数量。

在我们上线 1.0 之后，我们通常会手动选择一些关键的测试用例，这会给我们一个高水平的测试通过。此测试通过将广泛覆盖功能，旨在快速识别可能需要更多关注的区域。

这里存在测试逃逸与执行时间平衡的真正风险。我还将增加 a) 最近发生变化的区域和 b) 已知历史上不稳定的区域的覆盖范围。

另一个挑战是，如果正在测试的应用程序发生变化，您确实需要运行所有测试以使它们保持良好的工作状态。

我同意布鲁斯的观点，这取决于。如果您的要求需要它们更频繁地运行，请将它们安装在您可以使用的地方。否则，如果您负担得起，您可能需要做的是建立一个环境来不断运行它们。我在一家需要持续运行这些测试的公司中做到了这一点，并在一个始终运行测试的 Longevity 环境中做到了这一点，我们只是在那里更新了版本。

我知道不是每个人都有这方面的能力，我现在的公司也没有，但是当你有很长的测试需要运行并且你必须在某个地方进行时，这是一种选择。对于我没有更新环境的地方，我会在休息时间、周末或假期或任何时候运行这些环境。否则，我会选择一个有代表性的子集并尽可能多地运行它们。

只要你能负担得起。毕竟它们是自动化的。如果它们很健壮并且不会给你误报，那么理想情况下，一旦编译和其他测试通过，每次提交，然后将它们启动。