将生产数据复制到质量检查环境

#1 楼

在我的公司中，我们使用单独的测试环境，每天复制生产数据。定期使用这种环境来检测类似您遇到的问题。

我们的绝大多数测试都是使用合成的非生产数据进行的。其中一些是手工制作的，但大多数是由我们构建的脚本制作的。我们会定期分析生产中的数据，以改善创建测试数据的方式。尽管如此，在某些情况下仍可以更好地复制生产数据。

这不仅仅是复制数据的问题。每天早晨在预定的时间将数据复制到通用测试环境中。
我们会整理数据以修改所有个人身份信息（PII）以及任何其他敏感数据。这通常称为混淆或“问候”数据。此PII被逻辑上正确但非个人的数据代替。这项任务并非总是容易完成，但是我们的安全和隐私标准要求这样做。与测试相关的内容-我们将其删除以简化测试）

每天早晨，在测试人员进入之前，我们都会获得一份生产数据的新副本。仅模式，否则他们可以将其复制到各自的测试环境中，根据需要进行修改并在测试期间使用。

#2 楼

我还没有听说过这项技术的标准化术语，但是它是常用的。我们在我目前的公司中经常这样做，但是即使在很多情况下它可以大大提高我们解决问题的能力，我在Microsoft工作时也几乎完全避免了这样做。在Microsoft，他们认为暴露私人客户数据的风险太大了，而测试和故障排除的灵活性提高了我们所获得的收益。如果这样做，则需要考虑一些事项。


您在生产中存储哪些数据？它是私有的还是敏感的，还是由第三方拥有的？如果是这样，您可能需要一种模糊数据或简单地删除或过滤掉敏感数据的方法。
与测试数据集相比，生产数据将消耗多少空间？您在测试环境中是否有能力处理那么多数据？如果不是，您是否可以根据日期或其他方式拆分数据？
您的数据是否保持多种状态？例如，我们拥有以多种方式解析和处理的日志文件，最终将它们存储在各种数据存储中（sql，hadoop，cassandra等）。您要下拉初始日志，还是要从数据存储中提取数据，或两者都提取？您需要对每个过程进行什么样的处理？
假设您在测试环境中提取生产数据，运行测试并修改该数据，当您需要再次从生产中提取数据并覆盖数据时会发生什么情况？变化？这会破坏您的测试吗？您将需要设置一个流程来处理此问题，因为有时需要从生产中刷新，频率是多少？这有多大破坏力？
您的数据是否依赖于其他数据？有时我们会从生产中提取某些数据，但仍然无法重现该问题，因为该问题仅在某些情况下发生，或者使用我们也需要从生产中提取的某些帐户或用户设置发生。 >

#3 楼

这实际上取决于您的公司类型或要测试的产品。这也取决于您的测试方法。您是根据可用数据进行测试，还是要创建测试所需的数据。

恕我直言，最有效的方法是获取生产数据的副本并对其进行分析。


去重复数据。
对数据执行“等效分区”以标识测试数据记录，而不同的测试完全相同。 />然后使用该分析生成涵盖生产场景的基本数据集，然后在此基础上，添加测试场景所需的任何其他数据。

测试数据与生产数据的对比是，测试人员和开发人员倾向于按设计的方式使用系统，实际用户倾向于将字段留空，遗漏密钥或插入垃圾数据。因此，这比大多数数据“脏”得多测试数据套件。

如果将其插入电子表格并在其中运行一些宏，就很容易发现。

因此，完全可以回答您的问题问题：


测试人员绝对必须有权分析生产数据。
您可能遇到数据隐私问题，无法在测试环境中以原始形式使用它要求使用模糊和匿名的数据并投资于工具来做到这一点。不能混淆的数据，并且需要原始数据。例如，在高度复杂的金融和监管工具（其中美元价值和个人，有序条目对测试至关重要）中，与股票交易相关的总分类账信息，那么我们将使用与数据保护和隐私控制相同的测试环境来对待测试环境。任何生产环境。

#4 楼

我自己在很多地方都做了此操作，我们复制了生产数据，因为它在排除仅在客户数据中显而易见的问题时非常有用，并且还提供了其他测试场景和数据结构，而这些我们并不需要一直重新创建。这是非常有用的，如果您的开发团队不愿意这样做，您可能想找出原因，也许它们过去被烧掉了，或者看不到价值。我过去曾经让开发人员使用测试数据来检查问题，并且在我目前的工作中，我们不仅将生产数据复制到测试环境中，而且还复制到开发人员环境中，但并没有那么频繁。

我有一些脚本，可以将自动化所需的数据播种到生产数据中，因此生产中没有测试帐户。这提供了一些自动化测试，并且为了确保有关通知的确定，我们确保未将SMTP设置为在我们的域外设置，这样我们就不会在不需要或不需要的地方发送恶意电子邮件，清理。

提取生产数据很有用，但是您肯定需要围绕它进行清理数据，放入测试数据并验证其是否正确导入的过程。我还发现学习您通常可能不会接触的生产系统的其他方面很有用。

#5 楼

生产数据的问题在于案例涉及面广泛，但并不详尽。生产系统中可能没有出现系统应考虑的许多情况，如果质量检查是生产的副本，则在进行生产时将不进行测试。

测试用例应成为功能规范的一部分，功能团队应从中建立测试环境。

#6 楼

我看到的一种替代方法是让公司在其域内设置“测试”环境，然后为公司中的特定人员提供访问权限。该设置有两个好处：它提供了部署前的测试环境，可以在受保护的环境中根据生产数据直接评估新版本，还提供了一个平台，可以在生产环境中直接运行缺陷分析。该解决方案允许与客户进行一定程度的交互，否则将无法实现，从而使卖方，买方和最终客户受益。

#7 楼

这是一种传播行为，但请注意法规含义。在法规严格的行业和国家，这很难做到或根本做不到。在这种情况下，尽管事实如此，但必须以可以测试的方式设计系统。过去，我使用匿名化和其他技术将生产数据转换为质量检查数据。这些技术考虑了数据采样，并且没有修改数据的性质。这些步骤由一些“脚本”以安全方式在执行确认的两个步骤下完成。

#8 楼

使用大规模生产数据的问题在于，您无法找到不知道要查找的内容。抽查500M记录不能很好地工作，因为您会迷失在正确的看似数据之中。

查询（生产）数据以查找不可能的事情，并尽可能地修复数据/首先弄清楚它是如何得到的。 >

#9 楼

我们称其为prod parallel run，不确定任何标准的行业术语。