我们正在对生产中的主要应用程序部署更新。该更新已经在 QA 中进行了测试，看起来一切顺利。我们的客户想要在生产中进行测试。对于这种情况，我们将在生产中使用“测试数据”运行应用程序，一旦测试完成，我们将删除“测试数据”。
一些服务器管理员反对这一点，因为“测试数据不属于生产”。我认为这没关系，因为 QA 服务器和生产服务器具有不同的硬件，并且数据库容纳不同的应用程序（QA 有更多数据库，生产是专用的）。除此之外，还有其他事实可以用来支持我的观点吗？
编辑：添加上下文
该应用程序是一个自动接收和验证数据的工具。我们通过电子邮件接收文件，该工具会自动验证它们并将它们导入数据库。我们有一个 BI 系统，可以使用这些信息创建报告（Excel 文件通过电子邮件接收，然后进行验证，然后报告/视图出来，所有这些都是自动化的）。
“测试数据”将是代表真实数据的旧文件（以前的工作中的好文件和坏文件）（实际上它是真实数据，但存在问题或太旧）。
We are deploying an update to our main application in production. The update has been tested in QA and it looks good to go. Our client wants to do a test in production. For that case, we will run the application using "test data" in production and once the test has been finished, we will delete the "test data".
A couple of server admins are against this because "test data doesn't belong to production". I think it's OK since the QA server and the production server have different hardware and the databases house different applications (QA has more databases, production is dedicated). Besides that, are there other facts that I can use to back my opinion?
EDIT: adding context
The application is a tool that automates the reception and validation of data. We receive the files via email and this tool automatically validates them and imports them to the database. We have a BI system that creates reports using this information (excel files are received by email, then validate, then reports/views come out, all this automated).
The "test data" would be old files (good and bad files from previous efforts) that represent true data (actually it is true data but with problems or just too old).
发布评论
评论（3）
是的！但在生产中手动使用测试数据对我来说听起来不是一个好主意，因为它无法控制或监控。我下面的回答是假设测试数据用于自动化测试。
生产中的测试数据是“今天”所需要的。当自动化测试不是要求（或不存在）时，这不是要求。所以一般来说，这会被人皱眉。安全是主要原因。另一个原因是它会扰乱网站分析。这些都是真实且充分的理由。
人们无法决定有一天简单地将测试数据投入生产，尤其是在项目结束时。这需要从开发开始时就提出要求。因此，从第一次部署开始，测试数据就需要存在于生产中。其影响需要研究和记录。整个组织需要了解其好处和影响。
测试数据需要根据其类型、需求或上下文进行划分。例如：可检索的测试数据和可编辑的测试数据。第一步是提供可检索（只读，永不更改）的测试数据。也许这是我们在许多情况下可以走的最远的距离，但仍然会提供良好的结果。并且该只读测试数据的创建需要自动化并且最好记录下来。
在生产中拥有测试数据的好处是巨大的。应用程序的自动化测试比应用程序本身更珍贵。如果管理层意识到这一点，那么至少最初的“皱眉”会发生变化。我认为生产中的测试数据应该被视为需求/用户故事，并且所有针对它的问题都应该得到缓解。需要形成新的发展格局。
此讨论也与集成测试相关，本文重点介绍 它优于单元测试
Yes! But manual usage of test data in production does not sound like a good idea to me as it cannot be controlled or monitored. My answer below is assuming the test data is used for automated testing.
Test data in production is "todays" need. This was not a requirement back then when automated testing was not a requirement(or did not exist). So in general this will be frowned upon. Security is the main reason. Its impact in messing up site analytics is another reason. These are genuine and good reasons.
One cannot decide one day to simply put test data in production especially towards the end of project. This needs to be made a requirement from the time development starts. So the test data needs to be there in production from the very first deployment onwards. And its impact needs to studied and documented. Organization as a whole need to understand it's benefit and impact.
Test data needs to be divided based on it's type,need or context. eg: Retrievable test data and editable test data. First step would be to have Retrievable(read only-never changes) test data available. Perhaps this is farthest we could go in many case, still would provide good results. And creation of this read only test data needs to be automated and preferably documented.
The benefits of having test data in production is huge. An automated test of an application is more precious that then the application itself. If the management realizes that then at least the initial "frown" changes.I feel test data in production should be considered a requirement/userstory and all problems against it should be mitigated. And new patterns of development need to evolve in this area.
This discussion is also related to integration testing and this article focuses on the benefits of it over unit testing
您的管理员是对的。在生产中拥有测试数据将使您面临风险（安全漏洞）：
例如，如果您在生产中没有现有身份，您可以向他们付款。如果它们与真实的银行账户相关联，您就会在无法察觉的情况下损失金钱。
测试数据可以改变您的管理报告。当采取虚假行动时，有些可能会影响报告并影响做出的决策。这将很难追踪，更难纠正。
测试数据可以与生产数据交互。如果有人犯了错误，搞错了关系，生产数据可以根据测试数据进行更改。
如果您愿意标记的话，没有什么好的方法可以检测您是否拥有测试数据。所有数据都可以标记为测试数据。如果您在业务层中处理不同的测试数据，那么它就不是对您的生产环境的真正测试。
Your admins are right. Having test data in production will expose you to the risks (security holes):
For example if you have non excisting identities on production you can do payment to them. If they are linked to real bank accounts you lose money without the ability to detect it.
Test data can change your management reports. When having fake action, some can infuence reports and have impact on decisions made. This will very hard to track and even harder to correct.
Test data can interact with production data. If someone makes a mistake and make a wrong relation production data can be changed based on test data.
There is no good way of detecting you have test data, if you would mark it. All data can be marked as test data. If you handle the test data different in your businesslayer, it whould not be a real test of your production environent.
如今，最好的做法是让暂存环境与生产环境具有相同的基础设施配置，这样您就可以执行渗透测试、负载测试，并做任何您想做的事情，以确保生产环境按照您的预期运行。
Nowadays it is a good practice have Staging environment with the same infrastructure configuration like Production, so you can execute pentests, load tests, and do whatever you want to do to ensure that Production will behave as you expect.