我将我的自动化分为两种不同类型的类。我有 1 个类用于测试实际需求。这些测试独立于任何其他测试，并分解为故事。在需要行业合规性的项目（SOX、PCI 等）的情况下，这些也可以作为我的测试证据。我不能说我过分担心这些的执行时间。

第二节课在我的回归套件中。尽管它们都不需要在任何一个之前运行单独的测试用例，但其中一些已经深入到 Web 应用程序中，如果没有与先前测试相同的步骤，它们就无法运行（例如，我无法测试如果登录功能不起作用，则登录页面后面的任何内容）。这些也会有一些重复，但是，它是最小的。尽管我没有在其中再次使用相同的“测试”，但我确实使用了一些相同的功能，同时使其达到所需状态。

执行时间可能很长，但是，如果针对最小重复进行编码（即：使系统进入正确状态的快乐路径），则可以将其减少到最低限度。

您也可以使用相关测试。保持它们独立的主要原因是防止一个故障隐藏第二个故障。如果第二个测试在执行其实际测试场景之前真正运行第一个测试，那么无论如何您都不会获得这种好处。

使用开源工具和虚拟化，自动化测试的横向扩展现在便宜得多，所以我用它来解决“需要更多执行时间”的问题。

下一个问题是我现在两次运行相同的测试，我怎样才能更有效。我可能会尝试提出一个场景，其中测试的 A 部分现在使用相同的功能，但在该空间中测试不同的事物或代码路径，例如使用不同的测试数据。

现在我有更多的时间，我可以应用不同的数据，我可以更有效地利用自动化来覆盖越来越多的测试扫描。

然后我重复这个循环并继续构建越来越多的测试，因为总会有另一种场景你可以想到并添加到组合中。

实际测试期间的失败并不是依赖测试用例的唯一问题。例如，在检查阶段可能会出现故障，这可能会导致依赖测试用例出现问题。您还可能有一个零星的问题，它只影响第一个测试用例的二十个案例中的一个。如果您的案例是独立的，即使第一个测试案例失败，您仍有 95% 的机会成功收集第二个结果。我还希望独立测试更容易连续重复多次 - 例如测试人员在尝试重现零星错误时会这样做 - 尽管这可能取决于您的测试框架。这些论点在涉及非常长的执行时间的情况下可能不够充分，但它们是需要考虑的额外因素。

有时，良好的产品设计和可测试性特性有助于缩短执行时间，尤其是在验证基本页面元素时（例如，按钮 X 调用函数 Y），其中到达那里的过程和沿途的状态不如最后一步重要。例如，在 Web 应用程序中，仅通过地址栏而不是通过 UI 导航到页面会很有帮助，而良好的设计可以在更多情况下实现这一点。但是，您仍然需要进行一些端到端测试。

我当时看到的基本方法是优先级和并行化。优先级只是运行最有可能经常发现最多数量的高优先级错误的测试用例，并且只偶尔运行其余的测试。应该优先考虑的案例是那些最有可能受到当前代码更改影响的案例，以及那些覆盖其执行时间最多的案例。并行化意味着让多台机器同时运行测试用例，并且使用虚拟机（并非适用于所有程序，但对于使用 GUI 的许多应用程序来说是一个很好的选择）和云服务（如 Amazon Web Services）变得更加可能. 一般来说，