在生产系统中测试帐户和产品 [英] Test accounts and products in a production system

问题描述

是否值得设计一个系统以期望测试帐户和产品在生产中存在并处于活动状态，或者测试实体不会污染生产数据库，即使您的运输人员知道不会将任何箱子运送到测试客户"?

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"?

我已经在规范中实现了具有 test="True" 属性的消息传递协议，并想知道现代架构是否应该包含用于标记订单、帐户、交易等的元数据作为测试实体，就像任何处理一样其他实体——但离花钱的地步还差得远.即:它伪造一张假想的信用卡收费并伪造包裹的发货.

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.

预计这不会替代完全分离的测试、开发和 QA 数据库，但即便如此，我们的生产系统中也始终拥有知名的测试 SKU 和测试客户.无害?

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?

推荐答案

在生产中使用测试帐户是我通常不赞成的，因为它会打开一个潜在的安全漏洞.人们应该努力在测试中尽可能多地复制生产环境，但显然在某些情况下这是不可能的.昂贵的生产硬件就是一个很好的例子.我会说，作为一般做法，应该不鼓励这样做，但与所有事情一样，如果您能提供一个对您有意义的理由，那么您可能会忽略一条硬性规定.

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.

这篇关于在生产系统中测试帐户和产品的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！