是否值得设计一个系统来期望测试帐户和产品在生产中存在并处于活动状态，或者是否应该不存在测试实体污染生产数据库，即使您的运输人员知道不运送任何发给“测试客户”的盒子?
我已经实现了在规范中具有 test="True" 属性的消息传递协议，并且想知道现代模式是否应该包含用于标记订单、帐户、交易等的元数据作为测试实体，就像任何其他实体一样被处理 - ——但还不到花钱的地步。即：它伪造了一张假想的信用卡并伪造了包裹的运输。
预计这不会替代完全分离的测试、开发和 QA 数据库，但即便如此，我们在生产系统中始终拥有众所周知的测试 SKU 和测试客户。无害？
我通常不赞成在生产环境中测试帐户，因为它会带来潜在的安全漏洞。人们应该努力在测试中尽可能多地复制生产环境，但显然在某些情况下这是不可能的。昂贵的生产专用硬件就是一个典型的例子。我会说作为一般做法应该不鼓励，但与所有事情一样，如果你能提供一个对你有意义的理由，那么你可能会忽略一个硬性规定。
我想最佳实践警察会说“永远不要在产品中测试”的口号，甚至可能会加上“开发人员不应该使用产品”。
但是，我在基于大型机的系统上工作，其中生产和测试/质量控制/质量控制之间存在巨大差异；系统越大，这种情况的可能性就越大。此外，与应用程序相关的组越多，这种可能性就越大。
我需要两只以上的手来计算我们只能在生产环境中复制一个问题的次数。然后选项变成创建测试表/用户/数据或使用实时客户数据。
有时我们也会在生产表中创建测试记录，因为一些用户/客户喜欢他们可以搜索/检索的东西总是在那里。
所以我的建议是，如果它有助于在上线后进行故障排除，可以将测试帐户/产品投入生产。
如果您的数据库是以自动方式从脚本创建的，那么这将成为一个非问题。
在我的环境中，我们使用巡航控制进行连续构建。用于生成数据库的 SQL 脚本与其他所有内容一起签入 CVS，并且每天都会从这些脚本中重建数据库。
我们的测试数据是第二组 sql 脚本，它们是为测试数据库运行的，而不是为生产数据库运行的。
鉴于我们的环境测试数据永远不会触及生产数据库。
这个解决方案对我们来说真的很棒。
我不会将任何测试数据放在生产系统中，也不想作为开发人员访问该系统。
我在一个拥有非常敏感的医疗和财务信息的行业工作，拥有这些信息将无法区分测试系统中的生产数据和数据。
恕我直言，最佳实践是将这两个世界完全分开，并投资建立一个程序来准备一个全面的测试环境。
在外部 ERP 系统（仅限内部访问）中，我们有测试数据，因此当我们将更改从测试环境转移到生产环境时，我们可以测试整个过程。我认为数据是一种必要的邪恶，因为系统之间的细微配置差异可能会导致灾难性的结果，因此一旦生产中发生变化，我们会在将其“发布”给用户之前对其进行全面测试。
正如我所说，这些只是内部应用程序，因此安全风险有所降低 - 这是一个非常有效的担忧。
永远不要在产品中进行测试，即使那是产生所有收入/收集统计数据/神奇发生的地方……？
始终有一个生产测试计划。在 prod 上会出现问题，或者，如果你不走运，只会在 prod 上发生。如果您没有任何东西，第一次需要在 prod 上进行测试（通常是高压力情况），您将在没有桨的情况下上岸。
在 prod 上拥有测试数据并非无害，您确实需要小心。