是否值得设计一个系统来期望测试帐户和产品能够投入生产并在生产中投入使用，或者即使运输人员知道不运送任何发给"测试客户"的箱子，测试实体也不会污染生产数据库？

我已经实现了在规范中具有test =" True"属性的消息传递协议，并且想知道现代模式是否应包括用于标记订单，帐户，交易等的元数据，作为测试实体，就像其他实体一样， -但就没有花钱的地步。即：它伪造了一张虚构的信用卡，并伪造了包裹的托运。

预计这不能替代完全分离的测试，开发和质量检查数据库，但是即使有了这些数据库，我们在生产系统中也始终拥有知名的Test SKU和Test Customer。无害？

解决方案

我通常不愿在生产中拥有测试帐户，因为这会带来潜在的安全漏洞。人们应该努力在测试中尽可能多地复制生产环境，但是显然在某些情况下这是不可能的。仅生产昂贵的硬件就是一个很好的例子。我会说，不建议这样做，但是与所有事物一样，如果我们可以提供一个对我们有意义的理由，那么我们可能会忽略一成不变的规则。

我以为最佳实践警察会说"永远不要在产品中进行测试"，甚至抛出"开发人员不应该使用产品"的口头禅。

但是，我在基于大型机的系统上工作，在生产和测试/质量保证/质量控制之间存在巨大差异。系统越大，这种情况就越可能发生。此外，与应用程序相关的组越多，则可能性越大。

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

有时我们也会在生产表中创建测试记录，因为某些用户/客户希望他们可以搜索/检索始终存在的内容。

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

我不会在生产系统中放置任何测试数据，也不想以开发人员的身份访问该系统。

我在一个非常敏感的医疗和财务信息行业工作，拥有这样的信息将无法从测试系统中区分出生产性数据和生产性数据。

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

在外向型ERP系统(仅内部可访问)中，我们具有测试数据，因此，当我们将更改从测试环境转移到生产环境时，我们可以测试整个过程。我认为数据是必不可少的，因为系统之间的细微配置差异可能会导致灾难性的结果，因此，一旦生产中发生更改，我们将在"释放"给用户之前进行全面测试。

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

从来没有在产品中进行过测试，即使那是所有收入产生/统计收集/魔术发生的地方...？

始终有一个生产测试计划。产品上可能会发生问题，或者如果不幸的话，只会在产品上发生问题。如果我们没有准备好任何东西，那么第一次需要对产品进行测试(通常是高压力的情况)时，我们将一无所有。

在产品上拥有测试数据并不是无害的，我们确实需要小心。

如果数据库是通过脚本以自动化方式创建的，那么这将成为毫无疑问的问题。

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

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

鉴于我们的环境测试数据永远不会触及生产数据库。

该解决方案确实对我们非常有用。