在生产系统中测试帐户和产品

Question

是否值得设计一个系统以期望测试帐户和产品在生产中存在并且活跃，或者是否应该没有测试实体的生产数据库的污染，即使您的运输人员知道不发送任何发往“生产”的框;测试客户“？

我已经实现了具有test =“True”的消息传递协议。规范中的属性，并想知道现代模式是否应该包含用于标记订单，帐户，交易等的元数据作为测试实体，其处理方式与任何其他实体一样 - 但只是没有花钱的点。也就是说：它伪造一个假想的信用卡并假装一包的货物。

预计这不会取代完全独立的测试，开发和QA数据库，但即便如此，我们也始终在生产系统中拥有着名的测试SKU和测试客户。无害？

Answer 1

生产中的测试帐户是我通常不赞成的，因为它开辟了一个潜在的安全漏洞。人们应该努力尽可能多地复制测试中的生产环境，但显然有些情况是不可能的。仅昂贵的生产硬件就是一个很好的例子。我会说，作为一般惯例，它应该是气馁的，但是如果你能提供一个对你有意义的理由，那么你可能会忽略一个严格而快速的规则。

Answer 2

我认为最佳实践警察会说“未经测试过”的咒语。甚至可能会投入“开发人员不应该访问prod”。

但是，我在一个基于大型机的系统上工作，生产和测试/ qa / qc之间存在巨大差异;系统越大，这种情况就越可能发生。此外，与应用程序有关的组越多，这就越有可能。

我需要两只手来计算我们只能复制生产环境中的问题的次数。然后，该选项将创建测试表/用户/数据或使用实时客户数据。

有时我们也会在生产表中创建测试记录，因为一些用户/客户喜欢他们可以搜索/检索的内容总是在那里。

所以我的建议是，将测试帐户/产品投入生产是可以的，如果它有助于在上线后进行故障排除。

Answer 3

如果您的数据库是以自动方式从脚本创建的，那么这就成了一个问题。

在我的环境中，我们使用巡航控制进行连续构建。用于生成数据库的SQL脚本将使用其他所有内容检入CVS，并且每天从这些脚本重建数据库。

我们的测试数据是第二组sql脚本，它们为测试数据库运行，不为生产数据库运行。

鉴于我们的环境测试数据从未触及生产数据库。

这个解决方案对我们来说真的很棒。

Answer 4

我不会将任何测试数据放入生产系统中，也不希望作为开发人员访问此系统。

我在一个拥有非常敏感的医疗和财务信息的行业工作，并且拥有这些信息将无法将生产与数据区分开来。

恕我直言，最佳做法是将这两个世界完全分开，并投资建立一个准备全面测试环境的程序。

Answer 5

在ERP系统中（仅在内部可访问），我们有测试数据，因此当我们将更改从测试环境移动到生产环境时，我们可以测试整个过程。我认为数据是必要的恶，因为系统之间的细微配置差异可能导致灾难性的结果，所以一旦生产中的变化，我们完全在“释放”之前进行测试。它给用户。

正如我所说，这些只是内部应用程序，因此安全风险有所降低 - 这是一个非常有效的问题。

Answer 6

永远不要在生产中进行测试，即使这是产生所有收入/收集统计数据/魔术发生的地方......？

始终有生产测试计划。在产品上会发生问题，或者，如果你运气不好，只有 在prod上发生。如果你没有任何东西，第一次你需要在prod（通常是高压力的情况下）进行测试，你将在没有桨的情况下上河。

在prod上测试数据并不是无害的，你需要小心。