我们的 Web 应用程序很复杂，大多数现代应用程序也是如此。通常，在发布周期结束时，我们会分支代码并对代码执行回归测试。此外，正如预期的那样，所有新功能都经过了彻底的测试。
因为我们的应用程序很复杂，并且为了执行测试而填充一组数据非常耗时，所以我们的 QA 使用与之前测试相同的数据库。这个数据库很旧，大概一两年多吧。
我的立场是，针对“脏”数据集的测试是错误地处理事情。据我了解，当您执行测试时，您希望在数据处于受控和已知状态时测试应用程序。现在发生的情况是我们不知道数据的当前状态，因此当出现错误时，我们无法确定这些错误是新的、真正的错误，还是由不良数据造成的错误。这可以让我们追逐我们的尾巴，并可能导致大量的时间浪费。
我的问题是，我的立场是否正确，我们应该有一个干净的测试数据库，预先填充已知状态的数据？如果这是正确的，我如何让我们的 QA 相信这是正确的方法？
一如既往，“这取决于”。
有时您希望使用干净的测试数据库：
有时您想使用脏测试数据库：
两种测试方法都有价值，而且都有用。在我的工作场所，所有的自动回归都是从一个已知的（如果不一定是干净的）起点完成的，并且大多数测试人员将为我们需要测试的每个新主要版本开始一个新的、干净的设置，这将逐渐变得“更脏”我们测试的不同问题和发展越多。
我们发现非常有用的一种策略是保存和存档（在已知、可访问的位置）特定配置的数据集，尤其是最耗时且容易错误配置的数据集。这样，我们中的任何人都可以使用预设的环境来处理几乎所有事情，而不会带来太多痛苦。您可能会发现您的 QA 人员更愿意从包含他们需要的大部分内容的预设数据库开始半干净的想法，并使用更耗时的功能集存档数据库，以便每个人都可以从中受益。
有时我想这样做并且在过去，我的干净/启动数据被设置为在我需要时复制，并且我有我的黄金标准来比较。我每次都可以运行它，并且能够通过检查我的 Gold 来检查系统出错的地方。然而，事情发生了变化。随着客户环境的不断变化，快速的开发和发布周期以及需要提取生产数据以解决问题并根据现有数据检查新功能给我带来了问题。所以有我想做的事情，以及我必须对我所处的约束做些什么。
为此，我对环境做出了一定的考虑，尽管它们并不总是更好地为我们服务。
我想像这样工作吗？不是真的，但我了解业务限制，它们推动了我必须做的事情。我将测试设置为故事，以了解帐户需要哪些数据，然后将其调整为新数据，以便我可以运行测试。我有一套测试告诉我该站点正在运行，并且数据正在正确移动并且这些测试永远不会改变，如果它们失败了，那么我会弄清楚是什么。
我想我是一个肮脏的测试人员，但由于业务需求，它适用于我和我们的产品，我需要满足测试和生产中的那些，所以我必须能够在两个位置检查它们。不好玩，但我已经调整并相应地调整了我的测试期望。
根据您的描述，至少对于某些测试而言，使用干净的测试数据库是有一定意义的。它当然可以使分析一些错误变得更加容易。
也就是说，请意识到您可能会遗漏一类错误，这些错误只会出现在您的数据库中不存在的数据中。也许已经添加或修改了需要新数据来执行这些更改的功能。或者也许“野外数据”会呈现以前不可能出现的情况，或者以前没有考虑过。
我们经常同时做这两件事——我们使用一个固定数据集进行回归测试，然后随着功能的添加和增强而不断添加。但是我们经常使用生产数据的快照（野外数据）进行一些测试（屏蔽所有个人身份数据）。而且我们经常使用伪随机输入来合成测试数据以测试特定案例，有时还会使用自我识别字段，以便更容易调试。最后，我们有时会为压力/性能/负载测试创建特定的数据集。
这有助于您的测试可重复。如果您从已知状态开始，并且您知道在发现错误之前采取了哪些操作，那么您更容易向其他人描述这些情况。这对您、必须修复错误的开发人员以及必须测试修复的测试人员都有帮助。
另一方面，世界是不可重复的。它每时每刻都在变化，您希望您的软件在每一个时刻都能正常工作。您应该针对哪个时刻进行测试？可以在已知状态下进行测试，但您必须确定该状态是否代表现实世界。如果没有，也可能会有一个肮脏的、不可预测的起点，再加上额外的日志记录。