[测试面试问题]服务端服务器进行迁移，需要如何回归测试？

前言

在之前回顾2021，展望2022，今年要做一些分享，所以组建了三个新群，提了一些问题。让大家整理汇总，但是一直都是丢问题，但是没有整理，今天，抽空把之前的问题做些汇总。

正文

问题：服务端服务器进行迁移，需要如何回归测试？

大家都得到了积极的回复，因为大家的工作原因，可能没有这方面的经验，当然，我看到了一个大佬比较好的回答。我在这里汇总下最后的答案，但是这不是标准答案，只是参考答案。

前提：为什么有这次迁移，这次迁移的目的是什么?为了什么？迁移的机器的范围？迁移的时间？重大问题如何处理？提前预案？测试服演练等，都是要讨论确定的。

一位群友的答复：

首先 从自动化金字塔模型看可以分三个维度 ui 接口 单测

单测角度

开发负责跑所有服务的单测 优先保障服务可用性

接口方面

可以将服务端分几个维度进行考虑

1.内部服务 一般指自己部门的人使用的服务

2.二方服务 一般指集团内其他部门作为调用方

3.三方服务 外部客户作为调用方

假设时间有限情况下 那不同维度的服务侧重点就不一样 但都需要做多接口的场景回归测试

像内部服务更关注业务场景能跑通 对边界场景bug的容忍度相对高一点 可以只做多接口的回归

二方服务更关注接口的稳定性 除了做多接口的回归测试 还要做单接口健壮性测试 如果服务器迁移涉及硬件配置的改变 还需要对重要的接口做一次基准测试 保证迁移后的接口符合调用方原始要求

ui方面

三方服务除了上述列到的回归测试 还需要加个界面的主流程回归测试 起码要站在用户角度去使用一次系统服务

另一种角度就是服务优先级

高优先级跑单接口+多接口+ui回归

中优先级跑单接口+多接口

低优先级跑多接口

关于数据正确性有两种方式

1.本身接口回归有断言可以校验一部分

2.通过ui回归也可以验证

3.数据库一致性校验脚本

简单的回答

1.确定影响范围
2.多维度回归测试验证
3.整体验收线上
4.实时监控
5.做好预案随时处理故障

整体的目标是迁移过程不影响正常业务，尽量把用户影响降低到最小。

最后

上面呢，只是在不同的方面去做了一些思考，或者考虑，但是真正的使用，还是要结合自己的项目，进行评估。