UAT数据应该是生产的镜像吗？如果是这样，怎么样？

我们一直在尝试使用近实时数据（例如最大一周的旧数据）来测试UAT。我坚信开发和质量保证环境应该控制他们自己的数据，但是UAT（生产前的最后一层）代表了一点灰色地带。所以我的问题是：UAT数据应该是生产的镜像吗？如果是这样，怎么样？

a）这是一个好主意吗？我认为是这样，但有些唠叨疑惑。 b）如果是这样，过去人们使用的一些已证实的技术是什么？

2012-03-01 mwjackson

（假设OP预期持续，实时模式和数据同步）

答案很简单：

理由

通过“镜像”我假设你并不意味着实时直接镜像或复制的（UAT测试通常需要艰苦的数据测试用例进行设置，其将获得覆盖）。

下面是我们如何做到这一点在企业环境中，FWIW

在定义的时间间隔，通常在大约最后的督促数据库备份恢复在QA环境1周月的时间

（UAT刷新）
环境“转换”脚本在恢复后刷新的每个数据库上运行（例如，指向配置或混淆敏感的财务，客户或用户数据等）
所有UAT脚本然后在PROD中对数据库进行运行（您需要对脚本管理变更控制进行良好的纪律处理，以便轻松跟踪这一点 - 但我们仍然无法始终保持正确）。刷新后，我们做而不是直接比较UAT和QA，并简单地将更改回滚到UAT。
这是一个很好的烟雾测试/调试，因为这些相同的vNext脚本需要在Production发布时针对Production进行运行。
现代系统可能不需要显式/外部版本迁移脚本（例如，实体框架代码优先迁移将尝试在第一次运行时升级数据库模式），但在将这些数据应用到传统数据库或共享数据库时执行此操作可能会有风险。

一些其他方面的考虑

刚上“脚本”循环记同步模式 - 在我们的环境中：

DEV是免费提供给所有 - 任何开发铅可以使DDL或数据变化。
QA和UAT被锁定 - 需要生成脚本（通常由SQLCompare），然后发送给DBA执行（在QA中）以及批准和执行（UAT）。（我们正在寻找自动化部署到QA的方式，但我们确实需要保留每个脚本SCM）则
这些脚本“每个环境”签入源代码控制和跟踪

2012-03-01 08:49:10 StuartLC

真的没有测试用例的要求，我们的UAT更多的是分期/最终标志的关闭从客户。功能测试用例在流程的早期处理。 – mwjackson 2012-03-01 11:02:22

我想我的问题是，你只是每个月使用一次数据库备份，然后向前滚动迁移？ – mwjackson 2012-03-01 11:05:21

是的 - 通常有多个系统和团队受到UAT DB刷新的影响（例如核心系统，仓库饲料，报告系统等），所以每月一次的时间表在所有适用的利益相关者，测试用户等方面变得“根深蒂固”。任何搞砸UAT环境的人都会被关在热水中。 – StuartLC 2012-03-01 11:09:20

这里是东西我们为我工作的最后一家公司做过。我们有许多州政府的项目和合同。以下是我们在某些项目中使用的环境级别的示例。在下面的例子中，质量保证是为我们服务的，UAT是为客户服务的，Pre-Prod是我们有时创建的另一种环境，但并非总是如此;只取决于项目。

DEV ==> QA ==> UAT ==> PRE-PROD ==> PROD

一旦所有的数据进行了验证，我们从PROD向下复制到刚才的一切的UAT和QA，包括任何DB有关。

我们还有一个为某些方面编写的工具，而不必总是使用SQL。我们有一个基于网络的程序，我不记得它写了什么。我们称之为CTM - 控制表管理。在那里，我们可以对表格中的某些更改进行更新，更正，下拉菜单，拼写和语法错误，以及任何其他问题。任何东西。有单选按钮来提交更改和框来检查您想要更改的环境。

希望这是对任何人的帮助或给人一些想法。 :-)

感谢，

约翰

2016-08-09 19:09:39

回答