数据库迁移测试——功能测试

lsekfe

在上一期的文章中，我们对数据库表结构及迁移数据的测试方法和测试经验进行了介绍。有想了解的同学可以戳《据说连数据库测试都因为太实用被人盯上了》进行回顾。在本期文章，我们将继续以实际项目测试经历为依据，对数据库迁移完成后的功能测试的方法及经验进行总结，供测试人员参考。
　　有的同学可能会想，只要后台数据库表正确迁移完毕且验证完毕，那么前台程序自然不会有什么问题。但是要知道，数据库迁移测试的目标是保证数据正确、一致、可用。我们可以通过编写脚本提取新旧库表数据并使用文本对比工具（例如Beyond Compare）或MD5值对比来验证数据的正确性及一致性。但针对数据的可用性，则需要通过黑盒测试去进一步验证。因此，对于数据迁移而言，黑盒测试是十分重要的一环。我们要在后台验证数据库表正确迁移的基础上，针对性地开展功能测试。
　　一般而言，数据库迁移是伴随着系统功能的迭代而进行的，因此我们进行数据迁移功能测试的前提就是确保新系统本身的业务功能是可用、完善的。如果新系统本身的功能就未经测试，存在大量BUG，此时直接进行功能测试，就难以定位是系统兼容老数据的错误还是系统本身的BUG，无形中给测试增加了成本。所以，在进行针对数据迁移的功能测试之前，要首先确保新系统本身的可用性。在新系统业务功能得到充分验证前提下，我们可以从以下几个关注点出发验证迁移数据的可用性。
　　一、既然是数据迁移，首要目的自然是验证迁移过来的存量数据在功能上是否有效、可用。这时候我们可以从以下几个维度考虑：1、如果数据是前台可以展示的（直观展示或者数据字典转译到前台），那么可以验证存量数据迁移后能否在前端进行正常地查、改、删操作。如果迁移过程中新表涉及到新增或删除字段，那么还可以进一步验证改动的字段能否正常展示或修改；2、梳理迁移的存量数据相关的业务逻辑，在迁移后，要验证存量数据涉及的主要业务流程是否可以使用存量数据跑通，关注存量数据在后续生命周期的应用。譬如迁移的是用户登陆数据，那么就需要验证登陆、以及登陆后的一系列操作能否正常进行，以此来充分确认迁移的可用性。当然，这就需要测试人员与业务、开发去进行充分沟通，准确的了解业务逻辑，完整地梳理出数据与业务的对应关系，这一点往往也是比较难的，所以可以在迁移方案制定伊始就去沟通了解，充分发挥测试前移的思想；3、迁移过程中新表如果涉及到新增字段，还需要关注存量数据在该新增字段上是否填充了默认值或空值，以及其在系统功能上能否正常使用。再以用户数据为例，假如迁移后用户表中新增了一项权限。此时就要区分两种情况：（1）迁移后对该字段填充了默认值（即有或没有该权限），那需要进一步验证该默认值下，该条用户数据在业务功能上是否能进行此操作。（2）迁移后对该字段置空，那么首先要从业务逻辑上去确定空值是有权限还是无权限，从而去做进一步地验证。
　　二、验证迁移后的新表中的增量数据是否有效、可用。迁移除了存量数据地迁移，往往伴随着表结构地变化，所以在新的表结构下，增量数据地验证也是我们关注地一部分，与存量数据类似，可以从以下几个维度考虑：1、验证系统前台功能是否可以正常新增数据，并验证其其进行查询、修改、删除功能是否可用；2、关注增量数据涉及的主要业务流程是否能跑通，关注其在业务上的整个生命周期中的应用。
　　三、验证迁移后新表中存量、增量数据的功能上的交互，可以从两方面去关注：1、存量数据是否可以管理或制造增量数据。譬如老用户可以新建用户、管控新用户。2、增量数据是否可以管理存量数据。譬如新建用户是否可以管控老用户，对其删改等操作。当然，这个举例较为简单，实际测试中可以根据所测系统业务逻辑的去进一步挖掘两类在功能上的交互，以达到测试充分性的目的。
　　由于数据库迁移通常涉及底层的模块较多，除上述测试关注点外，还是建议进行全系统的回归测试。但在实际测试中回归测试工作量往往是巨大的，这时候合理安排测试人力资源尤为重要。以我们组建的测试团队为例，采取了部分测试人员绑定存量数据用户，部分测试人员绑定增量数据用户的方式，在系统中同时进行操作，验证功能时存量数据、增量数据交叉进行。同时，通过手工测试和自动化测试相结合的方式，尽可能提高测试效率和测试覆盖率。
　　关于数据库迁移测试，在上期和本期中我们已经从数据库结构、迁移数据、功能测试的维度进行了介绍，希望能够对大家提供测试的帮助。后续我们还会介绍关于数据库迁移性能测试内容，敬请期待~