数据库迁移：从 SQL Server 到 PostgreSQL( 二 ) _数据库

想要将同一套测试运行在两种不同的数据库系统上面，并且只维护一套测试数据，可以尝试下面的方法：

定下测试数据的单一来源 (SSOT) 。
开发或者使用一个命令行工具，配合流水线自动转换测试数据文件。
改造已有的自动化测试，可以通过参数决定使用哪种数据库文件运行自动化测试。
配合流水线在新数据库系统上运行已有全部测试用例。

文章插图

五、高效加载测试数据
为了避免因数据更改导致的测试随机失败，集成测试和端到端测必须清理/恢复被修改的测试数据。对于像 SQL CE 这样的文件型数据库系统，每个测试套件复制数据文件的时间成本是可以接受的。但是，对于像 PostgreSQL 这样的服务器数据库系统，每个测试套件导入数据文件的时间成本比简单复制文件更长，累积成本变得不可接受。
1.使用模板数据库为了加速测试，我们在PostgreSQL上采用模板数据库(Template Database) 。同时把数据文件的Hash片段作为Database的名字，测试框架代码就能判断这份数据文件是否已经被导入过。倘若已导入，则跳过导入步骤，直接在PostgreSQL内复制一份数据库供测试使用。

文章插图

更进一步，对于只做查询的测试用例，甚至可以跳过复制数据库，在“模板数据库”上直接运行测试用例，这样能进一步减少准备数据的时间开销。缺点就是需要谨慎维护“只读”测试用例，避免混入会修改数据的测试用例。

文章插图

2.回收存储空间随着测试的运行，废弃的测试数据会占用越来越多的存储空间。采取什么样的方法进行清理，可以依据测试数据库系统是统一维护，还是安装在测试Agent上来决定。
针对统一维护的测试数据库系统，可以创建一条夜间运行流水线去清除特定名称的数据库。也可以让每个测试集在测试完成时删除各自用过的数据库。
针对安装在测试Agent上的测试数据库系统，可以创建CronJob来清除数据库。如果测试Agent是早上自动创建、晚上自动销毁的虚拟机，则无须引入清理步骤。
六、写在最后
更换大型系统所使用的数据库系统，注定不是简单的事情。不仅要考虑框架、代码等具体的技术、基础设施，还要考虑测试、甚至企业部门之间的配合等诸多方面。具体的策略、步骤、任务数量多少，都是由企业和系统所处情况来决定的。