有支持这一点的工具。SmartBear 的 TestComplete 可以 - 您可以配置为在失败后继续或在失败后停止 - 您将在下面找到一些关于我以前雇主的团队如何使用 TestComplete 处理依赖测试的详细信息。

我不认为这是一个糟糕的主意——我主要使用大型、复杂的应用程序，在这些应用程序中让每个测试独立是不可行的。

以下是您希望使用一系列相关测试的一些原因：

• 您必须为每个测试重复一长串事件（例如恢复已知数据库、安装应用程序的目标构建、运行应用程序、使用特定凭据登录应用程序、执行所需的配置。 ..所有在您进行您感兴趣的实际测试之前）
• 您拥有有限的资源来并行运行自动化测试，并且运行自动化测试的时间框架也有限
• 在每个测试或测试之后，您有很长的清理事件序列（退出应用程序、运行数据库验证、将应用程序数据备份到存档位置、将应用程序日志导出到存档位置......）
• 您有大量测试，其中设置步骤相同或几乎相同
• 您有大量在逻辑上依赖于先前操作的测试（实际上任何作为流程流操作的东西都可以落入这个桶中）
• 您有一个应用程序的启动/初始化时间很长（我使用的应用程序可能需要一分钟多的时间来启动和加载所有内容 - 而且数据集相对较小。大型数据集可能需要更长的时间）
• 由于准备和/或清理事件的序列很长，您需要大量数据来执行单个测试，并且这些数据中的大部分与其他测试相同。

我已经对这些点中的每一点都正确的应用程序做了很多工作——毫不奇怪，我们使用了很多依赖测试。在我们的案例中，每周运行一次 3 小时的配置脚本来设置所有内容（因为这比每天运行多达 90 分钟配置的 30 多个测试套件中的每一个更有效，并且重点我们的自动化是事务处理而不是配置），然后是每个测试套件的通用启动例程，该例程将从已知位置复制数据库和文件备份，恢复数据库备份，解压缩文件备份，安装目标构建正在测试的应用程序，设置所需的专门权限，然后运行应用程序。这通常需要大约 40 分钟。

即使有大量虚拟机和物理机，并且回归脚本尽可能高效，也无法在每台机器上运行一个套件，因此团队依赖相关测试并定义哪些类型的故障是致命的——对于致命的失败，我们将脚本配置为停止，执行拆卸，并在完全关闭之前发送电子邮件。

微软的 CodedUI 框架根本不支持这种风格。我对任何其他框架都不太了解，无法发表意见。

我不认为这是一个糟糕的主意，@Kate Paulk 已经提供了足够的理由说明为什么不是这样。

至于支持这种测试风格的工具。我不认为对此类功能的内置支持应该是选择测试框架\工具的主要标准，因为您始终可以自己实现这一点。例如：

• 如果工具允许读取测试结果，则只需从测试 B 读取测试 A 的结果，并在需要时引发异常\触发测试失败
• 从测试 A，您可以将任何您想要的（测试结果、需要传递给其他测试的数据等）写入文件\数据库\任何内容，然后从测试 B 读取此信息