2
业务测试过程中，redis缓存应该要注意哪些测试点？
了解更新存储机制，例如：
首次产生数据，数据库更新完之后写入缓存是否正确
redis中存在业务数据时，是否先从缓存读取
业务数据更新时，更新完db，再更新redis
将已经存在的redis中的数据删除时，业务再次请求数据时，会怎么处理
redis数据的过期机制以及过期之后的处理机制
关于redis持久化如果服务器遇到故障或者重启，是否存在数据丢失的风险，是如何进行持久化处理的（一般来说RDB或AOF）
缓存击穿某个热点的key在缓存中过期时，大量并发请求直接穿透到数据库的情况
4、缓存雪崩指大量key同时失效或Redis服务宕机，导致请求全部打到数据库
数据迁移类测试注意事项？
1、老表和新表之间的关系要搞清楚
a是从老表迁移到新表，表结构完全一致？老表拆成多张新表？多张老表合并到一张新表？
b无论是那种形式，新表和老表的对应各字段的对应关系都要完全搞清楚
c除了字段对应之外，字段定义的类型以及长度都要检查下，是否是一致的或者是兼容的
2、老数据对应的上游业务要搞清楚
a了解下有多少服务或者多少应用会去查这张表中的数据？
b确认下有操作这张表对应的服务是否都会接到新表上，或者是已废弃
3、如果数据量大的话，如果处理要搞清楚
a是否要考虑分库分表
b是否要考虑历史归档表，如果有，放入历史归档表的规则是什么
4、迁移全过程测试
4.1数据层面比对
a老数据是否都按字段的对应关系迁移到新表上
b迁移的数据量是否有多迁移或少迁移
cSQL脚本的检查
d注：尤其是除了单纯的新老表对应关系之外，还有其他规则，比如老数据中的重复数据，去从迁移；比如老数据中的某个字段为某各值的时候视为垃圾数据；日期的转化；空值的判断等等
4.2业务层测试-迁移前
根据业务实际情况，设计一批老数据，作为迁移前的数据老数据准备
4.3业务层测试-迁移中
迁移过程中因为还是不断的有新数据写入，这个迁移过程中会采用什么样的迁移方式？这个需要考虑到，和开发沟通清楚
a是停机迁移？
b不停机，是新老服务并存，双写？
c不停机，是老服务直接下掉，直接上新服务？
不同的类型要考虑不同的问题，尤其是双写的话，这些重复重复写入的数据会如何比对并可能需要再次迁移到新表中
其他存储机制有没有变，比如从mysql改成存manggo或者ES等等，如果有，则还要考虑不同的数据存储对象的特性可能会有什么新的问题产生
5、业务层测试-迁移后
a数据层面的测试参考3.1
b之前准备的老数据根据之前数据设计的场景，用老数据进行测试
c新的业务操作对应的新数据写入是否正确
分页组件的测试
首页、末页、上一页、下一页的按钮的单次或者连续的点击是否都能正常跳转到对应页面
直接输入存在/不存在的页码/负数的页码的处理是否正确
快速连续点击上一页或者下一页，列表跳转是否正确，是否有报错，或者做了友好性限制，避免暴力操作
?
分页数据的正确性
是否按要求的顺序进行展示
如果有查询条件，结合各种查询条件检查结果集的展示数据及顺序是否正确
如果存在数据查看权限的，是否不同的用户切换进来做了查看限制
上一页的最后一条和下一页的第一条是否会出现重复的问题
修改排序规则后，列表展示是否正确
?
边界及异常测试
空数据时是否隐藏组件
仅一页数据时是否隐藏组件
每页只显示一条数据时分页展示是否正常
pagesize改上限大小，比如999999是否的展示情况
弱网环境，数据展示受限，是否友好提示
?
前后端交互相关测试
后台新增或删除一条或多条数据时，前台分页的顺序、页码等是否都调整正确
前端停留在列表页，后端修改分页规则，前端刷新页面或者跳转到某一页时是否会按新调整的规则展示
?
性能相关测试
列表数据量较大时，页面的数据展示是否符合性能要求
跨越N页，比如直接跳转到100页的数据，是否能正确且快速的响应
?
浏览器兼容性
仅修改了配置项的值，测试人员该测些什么
配置是否生效
部分配置需重启应用才能生效，测试前确认服务是否已重启
?
功能影响范围
如果是业务功能的配置，需要对该功能进行业务测试
如果是框架层面的配置，比如数据库连接池参数，那需要需重测SQL性能
需要注意极端配置值（如超时时间设为0或极大值）是否引发异常
是否存在业务多版本兼容性问题
如果是影响全局的参数，要评估好执行用例的范围，并考虑性能方面的影响
?
环境一致性
确保开发、测试、生产环境的配置同步更新，避免环境差异导致问题
?
回滚方案
保留旧配置备份，出现问题时快速回退验证
?
线上验证与监控
线上的配置是否生效，是否没有问题，如果存在无法回归的情况，依然是要观察线上数据，确保有业务已经用到了该配置，业务功能正常。
pom依赖包升级，测试注意点