这个环境指的是服务还是指终端？

公司用的测试环境都是自己做的带不同软件的 GHOST，-。-好像没什么问题发现过

1，后端现在一般是把 server 放到容器里面，数据库使用同样的版本和表结构（涉及数据依赖变更的需要运维人员和 dba 处理）。 cache 等等我都是测试环境和正式环境只有容量和分布数量的不同，不存在版本和其他的不同。
ps：你这咋上线的，变更和修改不拉清单 check？

一般来说，这类问题会集中在数据库的旧数据兼容问题以及配置项没有对应做好变更。

能具体说下你们的问题是什么吗？这样信息量有点少，引不起讨论。

简单做法，一个 beta 环境，用线上的同一套环境，beta 环境验证 ok，上线就是很简单的事情了

—— 来自 TesterHome 官方 安卓客户端

我们现在 的做法是 线上环境的数据会定期迁移到测试环境 ，测试环境与正式环境的数据有个时间差 来模拟线上环境进行测试确保业务正常 不知道这种做法合适吗

我觉得这种问题可能是 不同环境 数据的不同 导致出现 的不知道 考虑的对不对

需要具体问题具体分析。我只是说我们常遇到的问题。

你们遇到的正式环境能出现，但测试环境不能出现的问题有哪些？具体原因是什么？

PS：无论怎么模拟，线上终究会和测试环境有区别的。建议通过增加灰度测试环节来降低这类环境问题出现的影响面。

@chenhengjie123 说的对 你要先汇总下问题 对症下药 环境的差异多是代码 配置 数据不一致导致的 每个都有对策 我感觉还是你们的环境没管理好

这个问题在我们这还真有段历史了。 过程不表了， 直接说我们的方案吧。 我们测试环境和线上 SAAS 都是用 docker+k8s 部署的，所以直接解决了环境不同的问题，开发，测试，线上用的都是一个镜像。 对于客户方的私有云部署， 我们有专门的部署测试。

这种方式挺不错，可以解决配置问题，但历史数据问题如何解决？

最近线上出现了一次异常，原因是一些数个版本前的数据库数据不是以 json 字符串形式存储的，而新的开发不清楚这个，没有对应加上 json 字符串校验，导致读取解析时报错。

这些数据大概是半年前的，测试环境也没有，是开发通过线上异常预警才发现的，所以测试环境也很难发现。

可以尝试下

针对这种情况我们是专门做的 migration 测试，我在上上家公司的时候，开发会专门研发出版本升级时的 migration 程序。而我们会有一个专门的拥有数据的环境进行测试 (环境部分我不太清楚，是美国那边的人搞得，据说是他们做的数据快照)。 而我现在的公司的做法比较类似，我们在不同客户那的版本是不同的 (TO B 业务)，而客户那时常会有版本升级的需求。 所以如果新版本数据库的变动和 hadoop 的更改不兼容老版本的话，就要在升级工具中引入 migration(刷数据)。所以开发那边专门做了升级框架，每个版本都有对应的升级到下一个版本的机制。 而相应的，测试这边就要对每个版本进行升级测试。 方法很暴力，因为我们是用 docker+k8s 部署的测试环境，所以每个版本的镜像我都存到镜像仓库里了。 我可以随时部署任何版本的全套环境。 部署完旧版本环境后开始跑自动化 (全量的，能造多少数据就造多少)。跑完自动化后开始升级，升级后继续跑自动化 (同样的 case，还是全量的)，然后配合手动的方式上去验证老数据是否正常，老任务是否能够重新运行等等，反正就是验证升级并没有影响老的数据。 验证完升级以后接着验证降级，套路都差不多。 这是我们 TO B 业务的玩法

Rails 的话，迁徙代码：
change_column_null(:users, :nickname, false, 'nickname')

把 users 表的 nickname 列设置为不可为 Null，如果有行 nickname 为 Null ，则把它设为 'nickname'
这算是 Rails 提供的 “最佳实践” 吧

如果有两个团队开发了两个应用，都在直接读写数据库使用 nickname 这一列，历史数据中有 nickname 为 Null 。
一个团队需要 nickname 不为 Null ，已经开发完成准备上线，另一个团队一个月后才能开发这个变更。
为了这一个月，第一个团队需要在应用代码中处理两种情况……
这个坑其实在 “两个应用都直接读写数据库” 的时候就挖好了。

如果还不能从根源解决，但能做到《持续交付》里说的，每次数据或数据结构变更必须使用在版本控制系统中的 SQL 文件完成。部署测试环境的时候就能知道有变更，对涉及的测试用例用两份数据执行两次。
目的不明确的视角 13 楼方法挺好。

感谢分享，这个实践不错。

我们的场景是这个是日志表，数据类型只是指定了使用 varchar ，但具体格式没有要求是 json ，是从某个版本开始要求全部用 json 字符串。所以后面的这个同学读取的时候直接就用 json 库解析了，遇到那个版本前的旧数据就跪了。

如果原来也是格式化的数据，应该也很容易转成 json
404 NotFound 20170801 转成 {"code": "404", "descript": "NotFound", "date": "20170801"}

不过不幸的团队各有各的不幸