在生产系统中测试帐户和产品
是否值得设计一个系统来期望测试帐户和产品在生产中存在并处于活动状态，或者是否应该不存在测试实体对生产数据库的污染，即使您的运输人员知道不运送任何寄给“测试客户”的盒子？
我已经实现了在规范中具有 test="True" 属性的消息传递协议，并且想知道现代模式是否应该包含用于标记订单、帐户、交易等的元数据，作为像任何其他实体一样进行处理的测试实体 - -但还没有到花钱的地步。 即：它伪造假想的信用卡收费并伪造包裹的运输。
预计这不会替代完全分离的测试、开发和 QA 数据库，但即使有了这些数据库，我们在生产系统中始终拥有众所周知的测试 SKU 和测试客户。 无害？
Is it worth designing a system to expect test accounts and products to be present and active in production, or should there be no contamination of production databases with test entities, even if your shipping crew knows not to ship any box addressed to "Test Customer"?
I've implemented messaging protocols that have a test="True" attribute in the spec, and wondered if a modern schema should include metadata for tagging orders, accounts, transactions, etc. as test entities that get processed just like any other entity--but just short of the point where money gets spent. Ie: it fakes charging an imaginary credit card and fakes the shipment of a package.
This isn't expected to be a substitute for a fully separated testing, development, and QA database, but even with those, we've always had the well-known Test SKU and Test Customer in the production system. Harmless?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
我通常不赞成在生产环境中使用测试帐户，因为这会带来潜在的安全漏洞。 人们应该努力在测试中尽可能多地复制生产环境，但显然在某些情况下这是不可能的。 昂贵的纯生产硬件就是一个典型的例子。 我想说，作为一般做法，应该不鼓励这样做，但与所有事情一样，如果您能提供一个对您有意义的理由，那么您可能会忽略一条硬性规定。
Having testing accounts in production is something I usually frown upon because it opens up a potential security hole. One should strive to duplicate as much of the production environment in testing as possible but there are obviously cases where that isn't possible. Expensive production only hardware is a prime example. I would say as a general practice it should be discouraged but as with all things if you can provide a reason which makes sense to you then you might overlook a hard and fast rule.
我想最佳实践警察会说“永远不要在产品中测试”，甚至可能会加上“开发人员不应该访问产品”。
然而，我在一个基于大型机的系统上工作，其中生产和测试/质量保证/质量控制之间存在巨大差异； 系统越大，出现这种情况的可能性就越大。 此外，在应用程序中拥有权益的团体越多，这种情况发生的可能性就越大。
我需要两只以上的手来计算我们只能在生产环境中重复一个问题多少次。 然后，该选项变为创建测试表/用户/数据或使用实时客户数据。
有时，我们也会在生产表中创建测试记录，因为一些用户/客户喜欢拥有可以搜索/检索的始终存在的东西。
所以我的建议是，如果有助于上线后的故障排除，那么将测试帐户/产品投入生产是可以的。
I imagine the Best Practice Police would state the mantra "never ever test in prod" and maybe even throw in "developers should not have access to prod".
However, I work on a mainframe-based system where there are huge differences between production and test/qa/qc; the larger the system, the more likely such a situation is. Additionally, the more groups that have a stake in the application, the more likely this is.
I need more than two hands to count how many times we could only duplicate a problem in the production environment. The option then becomes creating test tables/users/data or using live customer data.
At times we do also create test records in production tables, as some users/clients like having something they can search/retrieve that is always there.
So my advice is that it is OK to put test accounts/products into production if it will help to troubleshoot after go-live.
如果您的数据库是通过脚本以自动化方式创建的，那么这就不是问题了。
在我的环境中，我们使用巡航控制进行连续构建。 用于生成数据库的 SQL 脚本与其他所有内容一起检入 CVS，并且每天根据这些脚本重建数据库。
我们的测试数据是第二组sql脚本，它们针对测试数据库运行，而不针对生产数据库运行。
鉴于我们的环境测试数据永远不会接触生产数据库。
这个解决方案对我们来说确实非常有效。
If your database is created from scripts in an automated fashion, then this becomes a non-question.
In my environment we use cruise control for continuous builds. The SQL Scripts for generating the database are checked into CVS with everything else, and the database is rebuilt from those scripts on a daily basis.
Our test data is a second set of sql scripts, which are run for the test database and are not run for the production database.
Given our environment test data never touches the production database.
This solution really works great for us.
永远不要在产品中进行测试，即使这是所有收入产生/统计数据收集/魔法发生的地方......？
始终有一个生产测试计划。 产品上可能会出现问题，或者，如果不幸的话，仅会发生在产品上。 如果你没有准备好任何东西，那么第一次需要在产品上进行测试时（这通常是高压力的情况），你将在没有桨的情况下沿着小溪前进。
在产品上拥有测试数据并不是无害的，您确实需要小心。
Never ever test in prod, even though that is where all the revenue is generated/stats are collected/magic happens...?
Always have a production test plan. There are going to be problems that happen on prod, or, if you are unlucky, only happens on prod. If you don't have anything in place, the first time you need to test on prod (which are usually high-stress cases) you'll be up the creek without a paddle.
It's not harmless to have test data on prod, you do need to be careful.
在外部 ERP 系统（仅限内部访问）中，我们有测试数据，以便当我们将更改从测试环境转移到生产环境时，我们可以测试整个流程。 我认为数据是一种不可避免的罪恶，因为系统之间细微的配置差异可能会导致灾难性的结果，因此一旦更改投入生产，我们就会在将其“发布”给用户之前进行全面测试。
正如我所说，这些只是内部应用程序，因此安全风险有所降低 - 这是一个非常合理的担忧。
In out ERP systems (internally accessible only) we have test data so that when we move changes from test to production environments we can test the whole process. I view that data as a necessary evil, since subtle configuration differences between systems can cause catastrophic results, so once a change is in production we test is fully before "releasing" it to the users.
As I said though, these are internal apps only, so the security risks are lessened somewhat - that's a very valid concern.
我不会将任何测试数据放入生产系统中，也不想作为开发人员访问该系统。
我所在的行业拥有非常敏感的医疗和财务信息，拥有这些信息将无法区分测试系统中的生产数据和数据。
恕我直言，最佳实践是完全分开这两个世界，并投资建立一个程序来准备一个全面的测试环境。
I wouldn’t put any test data in a production system nor would I want to have access to this system as a developer.
I’m working in an industry with very sensitive medical and financial information and having such information would make it impossible to distinguish productive from data out of the testing system.
IMHO the best practice is to completely separate these two worlds and invest in setting up a procedure to prepare a comprehensive testing environment.