迁移测试用例怎么设计

发布时间:2026-07-08 14:52

迁移测试的目标只有一句话：证明新系统做的事和旧系统等价。等价不是完全一样，而是在约定范围内行为一致。 功能等价怎么测 用例优先从老系统的生产记录里捞，不要重新拍脑袋写。接口类系统把接口清单导出来逐个写对比用例；页面类系统按核心业务流程走完整链路。数据层可以直接比对： mysqldump --skip-extended-insert olddb | md5sum mysqldump --skip-extended-insert newdb | md5sum 哈希不一致时，用 checksum table 或按主键分段 diff 缩小范围。批量任务要覆盖边界日期：月末、季度末、闰年的 2 月 29 日。报表类功能单独建一组用例，固定输入数据和统计口径，新旧系统各跑一遍对数。 性能对比要有基线 压测前先在老系统采一组基线：典型接口的 P95 响应时间、每秒事务数。新系统用同样的脚本、同样的数据量再压一遍，两组数字放一起看。工具用 JMeter 或 wrk 都行： wrk -t4 -c100 -d60s https://new.example.com/api/order/list 偏差在 10% 以内一般可接受，超过就要查是架构差异还是配置遗漏。压测环境尽量和生产同规格，缩配环境压出来的结论只能当参考。 异常回退必须真演练 回退用例最常被省略，但它最关键。至少演练三个场景：切换后 24 小时内发现严重问题的完整回退流程；回退期间新增数据的补录方式；域名或负载均衡切回旧集群的生效时间实测，TTL 要提前调小到 60 秒以内。回退步骤写成带命令的文档，别靠某个人脑子记。 用例管理的朴素建议 把用例分成必过项和观察项，必过项有任何失败就延迟切换，观察项记录后评估。每条用例标注来源：生产反馈、需求文档还是临场补充，追溯时用得上。测试报告保留原始命令输出和截图，方便事后追溯。 测试用例的价值不在数量，在覆盖了别人不敢测的回退路径。宁可切换推迟三天，不要带着侥幸上线。