UAT数据应该是生产的一面镜子吗？如果是这样,怎么样？

Question

我们一直在想一个关于UAT可以用近实时数据进行测试的想法(比如最多一周).我坚信开发和QA环境应该控制自己的数据,但是UAT(生产前的最后一层)代表了一些灰色区域.所以我的问题是:

a)这是一个好主意吗？我是这么认为的,但却有些疑惑.

b)如果是这样,人们过去使用过的一些经过验证的技术是什么？

• 通过SqlCompare或类似手动
• 通过脚本自动化？
• 你如何处理UAT/Production之间的架构变化(除了在实时部署之后,UAT几乎总是领先于生产)？

Answer 1

(假设OP意图连续,实时架构和数据同步)

简答:

• 架构 - 否 - 在正在开发的不断发展的系统中,UAT可能已经领先于生产,UAT将进行更改以用于未来的生产推广.
• 数据 - 可能(为了获得好的,最近的,有代表性的数据),尽管可能需要调整任何模式差异.另一种方法是应用假数据生成器.

合理

通过'镜像',我假设您不是指实时直接镜像或复制(UAT测试通常需要设置可能被覆盖的艰苦数据测试用例).

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

在规定的时间间隔内,通常间隔约1个月

• 通过QA环境恢复最后的prod数据库备份(UAT刷新)
• 在还原后刷新的每个数据库上运行环境"转换"脚本(例如,指向点配置,或混淆敏感的财务,客户或用户数据等)
• 然后,所有尚未在PROD中运行的UAT脚本都会针对数据库运行(您需要通过脚本管理更改控制来轻松跟踪这一点 - 我们仍然无法始终保持正确状态).刷新后,我们不直接比较UAT和QA,只需将更改回滚到UAT.
• 这可以作为良好的烟雾测试/调试,因为在生产版本发布时需要针对Production运行这些相同的vNext脚本.
• 现代系统可能不需要显式/外部版本迁移脚本(例如,实体框架代码优先迁移将尝试在首次运行时升级数据库模式),尽管在将这些应用于旧数据库或共享数据库时可能存在这样做的风险.

其他一些考虑

• 在系统相互集成的企业环境中,建议同时刷新所有系统的数据库,以便共享数据和密钥"同步"
• 在许多企业中,UAT环境的变化(包括数据刷新)可能需要更改控制委员会的批准,因为UAT可用性对于新系统的推出至关重要,并且可能会影响许多项目.

在我们的环境中,只需注意"脚本"循环以同步模式:

• DEV对所有人都是免费的 - 任何开发人员都可以进行DDL或数据更改.
• QA和UAT被锁定 - 需要生成脚本(通常通过SQLCompare),然后发送给DBA执行(在QA中)以及批准和执行(UAT).(我们正在研究自动部署到QA的方法,但是我们确实需要将每个脚本保留在SCM中)
• 然后将这些脚本检入源代码控制并跟踪"每个环境"