为什么要进行redis缓存测试：
redis本身并不用测试，但因涉及到服务端对数据源的逻辑处理，比如一条订单信息，客户端发起了一个更改收货地址的请求，如果服务端只进行了mysql的更改，没有同步到redis进行更新，当客户端再次发起请求查询时可能查到的还是原来的地址，所以对于redis和mysql来说，要进行一个数据一致性的测试。
数据一致性的测试点：
测试策略核心是围绕数据源的crud，校验被测服务和redis crud的正确性。
1.生成缓存数据
场景模拟方式：通过文档描述或开发描述模拟对应场景，比方说请求生成订单接口就会缓存订单数据。
校验方法：
- 直接和redis交互，通过redis提供的get方法直接查询订单缓存数据是否存储在redis当中。
- 可能需要相信开发实现的代码逻辑，查询接口会查询redis，也可以通过删减mysql的数据确保结果是redis返回的，通过请求查询接口校验订单结果是否能正常获取。
2.查询缓存数据
场景模拟方式：前置设计缓存数据，比方说直接写入redis数据或者通过外部某些接口生成缓存数据，通过外部的查询接口再校验查询结果。
需要设计的缓存数据场景
- 无缓存（空内容）、mysql有数据
- 无缓存（空内容）、mysql无数据
- 有缓存（有内容）、mysql有数据
- 有缓存（有内容）、mysql无数据
校验方法：通过外部的查询接口校验，对齐文档内容或研发口径定义期望值，校验结果输出满足期望
3.缓存数据更新：
本质上就是数据存在缓存时，校验正常的业务更新外。
如果对某单一数据的处理同时存在多个数据源，就要考虑数据一致性问题。
场景模拟方式：前置存在缓存数据时，通过服务提供所有的数据更新方式（接口），再通过服务对外的查询方式校验结果是否是更新后的结果。
数据一致性的解决方案：
- 数据存在缓存时，触发更新接口，先更新数据的缓存，再更新数据库。但这种方法还是存在一致性的隐患，如果高并发触发，可能会读取到redis结果，但mysql数据写入失败订单生成失败
- 数据存在缓存时，触发更新接口，先清空缓存数据，再更新数据库
- 数据上锁，确保在当前服务下同一条数据同一时间只允许一个事务在处理，如果有其他事务介入直接拒绝。
4.缓存数据淘汰的校验
常见的缓存数据淘汰机制：
- 直接delete
- 校验方法：直接校验对外的查询结果是否查询不到当前数据
- 数据有效期，数据过期后
- 校验方法：校验过期时间的正确性，校验时间的边界值
- 自定义的淘汰机制，比方说根据时间排序淘汰离当前时间最远的
- 校验方法：校验机制是否符合业务预期，可能需要前置构建数据模拟场景