我同意塔伦，并且正是出于你所说的原因。保留所有测试数据可让您有效地分析和调试测试结果。

如果您希望每次测试执行都有一个干净的测试环境，最好在为当前运行创建测试数据之前立即执行“拆卸”任务。

只要您 100% 确定在正确设置之前清理每个测试并且始终如此（例如，它的设置不会过时），就不会在拆卸时清理。如果您是唯一的测试人员和唯一使用您的环境的人 - 或者，如果您有一个很好的“清理环境并恢复到默认值”脚本/功能，所有测试人员在测试之前使用或线束自动运行 - 那么我认为能行得通。

但是，大多数软件不希望在失败后停止并坐下来保持原始故障状态，而来自错误的所有数据仍保持其原始形式。大多数软件项目需要有效地使用测试资源，这意味着清理并继续进行下一个测试。要出现可调试的故障，这意味着您需要在继续之前保存状态。复制错误文件和配置文件，备份数据库，将CPU / RAM /等机器信息转储到日志文件中，等等，并将它们全部放在一个地方，以便调查问题的测试人员轻松找到所有内容她需要。由于大多数测试人员无论如何都希望在测试结束之前保存状态，因此避免在拆卸过程中进行完全清理并没有太多优势。*

此外，如果您在拆卸过程中不进行清理，则当有更多配置选项可用时，您将需要维护旧测试，以便它们正确设置这些新选项。这可以通过在运行测试之前使用始终在测试之前调用的单个函数将机器设置为“默认状态”来避免，因此您只需更新该函数 - 但如果您选择在测试后不清理，则测试设置的可维护性是您可能想要计划的事情。如果您没有确保测试设置保持可维护性的流程（并且这种计划的可行性因公司而异），那么清理是一个好主意。

我知道在我的公司里，我不能依赖其他测试开发人员在开始测试之前清理所有东西——主要是因为我的公司计划在未来对 QA 做出巨大的改变，而我不能确定其他的使用我的工具的测试人员会很熟练，或者对系统有足够的了解，可以考虑他们需要清理的所有事情。我无权制定政策，我只能尝试影响它。我可以让其他测试开发人员因他们的坏习惯而受苦，但我知道这可能会在政治上反弹。所以，我总是尽我所能清理干净。

还有一种情况是，故障会严重破坏事情，以至于清理代码无法运行。在这种情况下，我个人喜欢将导致问题的实际测试的拆解报告为清理失败，而不是报告为下一个要运行的测试的设置失败。如果不出意外，向开发人员和管理人员展示并解释为一个失败的测试而不是两个更容易。

*在拆卸期间避免清理没有很多好处，但有一些好处：也许清理很昂贵，并且在安装和拆卸期间都这样做太耗时 - 安装期间的清理肯定更重要。也许您还没有时间开发“保存一切”的基础设施，所以您确实希望事情停下来，而不是让运行继续。也许您认为您的产品的测试人员在测试之前没有清理的情况非常罕见，您宁愿节省清理所需的开发时间，并相信这种 QA 文化在您的公司不会随着时间而改变.

我不相信“清除”意味着“删除”。它只是意味着您必须确保一次运行不会溢出到第二次运行。您可能需要考虑在擦除数据库之前转储数据库，或者只是为每次运行创建一个新数据库。

只要有清晰的分隔墙并且在同一输入上两次运行产生相同的数据集，就不会有问题。

如果您在他们自己的环境中运行自动化测试，您可以通过备份或快照来解决此问题，如果您的测试失败，那么您可以收集数据错误。当然，您还需要复制任何日志文件或任何其他集合，我注意到这总是被忽略，有时似乎是数据错误完全是另外一回事，然后我必须挖掘日志文件以找到我想要的一个 - 如果它还没有被覆盖的话。

有时我在我们的测试环境中运行自动化测试，但我们构建了我们的测试，因此我们不需要清除数据——在某些情况下，这比测试所需的要困难得多。由于我们需要生产数据并且在 Test 中安装非常耗时，而且我们不断地运行测试，所以我们围绕它进行了工作。你的旅费可能会改变。

对我来说，清晰的概念可以追溯到我想在测试前后进行数据库比较时，我知道我希望事情处于什么状态，这是确保数据正确和测试通过的方法。因此，在可以且为您提供价值的情况下进行明确是很好的，但您应该仔细定义明确的含义。