版本升级验证注意事项

Posted 2023-04-28

参考技术A 作为一名测试人员，除了进行常规版本测试之外，我们还要针对不同大小的版本做上线验证，不同版本升级时测试的力度是不一样的。

按照版本规模的大小和版本紧急程度，可以对版本做如下划分：

详细介绍下各个版本的特点：

补丁版本：线上出现突发情况，或者突发bug，问题影响用户正常使用，需要立马修复。

小版本：需求较少的迭代，改动的模块较少，涉及面教少，基本是小优化的集合，开发周期较短。

大版本：需求较多的迭代，改动的模块较多，涉及面较广，基本都是重大升级，开发周期较长。

针对这些版本，除了测试范围和测试侧重点不同之外，还有一些通用的上线测试步骤和点检内容可供参考：

一、升级前准备：

1.模拟用户场景生成测试数据

　　在这个阶段主要利用前期市场用户反馈的一些常用场景进行整理，列出用户经常使用的操作，生成尽可能全的用户数据和用户场景覆盖，创建数据的多样性。另外如果能够获取线上用户数据，最好考虑测试环境提前做一遍用用户数据进行的升级测试。

2.模拟用户环境配置

　　这部分也是需要获取客户配置信息，尽可能用测试环境模拟真实的线上用户环境。

二、升级后的验证：

1. 灰度测试

灰度测试的重点是模拟后端数据在测试环境上线，同时模拟用户使用新老版本的客户端来操作验证前后端功能、性能、UI等表现情况。

2. 线上测试

版本升级的线上测试跟全量版本测试还是有很多区别的，优先验证修改部分，其次验证核心功能，例如：支付，登录，数据管理等。

线上测试重点主要是在真实用户环境下针对上线客户端做模拟真实用户使用情况，涉及UI，易用性、功能性方面的内容。

三、需要点检的内容：

需要测试这边填写的一些checklist，此checklist结果需要附属在测试报告中。

App端checklist 项目：

升级依赖的注意事项

不同软件的版本号含义可能不同

MongoDB 版本号

对于 MongoDB 2.4.1，2.4 表示发行版本号而 .1 表示修订版本号。发行版本号的第二个元素（比如 2.4.1 中的 4 ）描述的是发行版本的类型。以偶数结尾（比如上面的 4）的发行版本号是稳定并且准备用于生产环境的，而奇数的仅用于开发和测试。

通常，发行版本号的变化（比如 2.2 到 2.4）表明引入了新功能并且可能会破坏向后兼容性。修订版本号的变化表示了修复 bug 的发布并且使向后兼容的。 -- 来自 https://docs.mongodb.com/manual/release-notes/#mongodb-version-numbers

MongoDB 驱动版本号

MongoDB 驱动使用语义化版本 -- 来自 https://docs.mongodb.com/manual/applications/drivers/#drivers-version-numbers

语义化版本：

版本格式：主版本号.次版本号.修订号，版本号递增规则如下：

1. 主版本号：当你做了不兼容的 API 修改，
2. 次版本号：当你做了向下兼容的功能性新增，
3. 修订号：当你做了向下兼容的问题修正。

可以看出，这个与上面的 MongoDB 版本号是不同的。

依赖的依赖

一个依赖也会有它自己的依赖。

比如 Python 的 Motor 依赖于 PyMongo

-- 来自 https://motor.readthedocs.io/en/stable/requirements.html#motor-and-mongodb

如果你是 Motor==0.4，那么你的 PyMongo 版本必须为 2.8.0。如果你不知道这点，安装了 PyMongo 3.0+ 从而覆盖了 PyMongo==2.8.0，就会出问题。

应对不兼容的升级

如果升级的版本含有不向下兼容的改动，那么就要注意是否会对代码造成影响。

• 如果单元测试全部覆盖到了，那么升级版本后使单元测试再次通过就行
• 如果单元测试覆盖率不高或者没有单元测试，那么就需要把所有用到该依赖的地方查找出来，然后人肉对比是否有不兼容的地方或者手工测试

总结

• 由于不同依赖的版本号含义可能不同，所以升级依赖前需要弄清楚版本号的意思
• 如果项目有版本号，那么需要说明版本号的意思，比如“本项目版本号使用语义化版本”
• 注意依赖的依赖
• 单元测试对依赖的升级很有帮助