在之前的产品测试中，我遇到过一些由于redis缓存逻辑导致的bug，因此想总结一下关于redis缓存测试的策略作为之后测试过程中的参考。
Redis缓存测试的思考
在准备Redis缓存测试用例之前，我们需要先了解以下几点：
1. 了解Redis的缓存机制
2. 了解业务逻辑中不同数据缓存的存储时长。
3. 数据在什么时候进行缓存？
4. 数据什么时候会被淘汰？
- 缓存过期机制
- 缓存淘汰策略
5. 未命中缓存时，业务逻辑如何处理？
6. 确认缓存的更新策略。例如：
- 先更新数据库，再更新缓存
- 先更新缓存，再更新数据库
以上6项是我们测试人员在准备测试用例之前需要明确的内容
在确保以上6项内容之后，我们可以继续制定测试策略。
Redis 测试的维度
对于Redis的缓存测试策略，我们通常可以分为两个维度进行考虑。一方面是业务功能的的角度，一方面是 外部接口的角度。
业务功能的测试
对于业务功能的缓存测试来说，主要有以下几个测试点：
1. 验证业务数据正向的增删改查，先确保基本数据的读写没有问题。在进行这一步时，不仅要确保基本数据的读写没有问题，还要关注操作的边界情况。
- 对于数据插入，测试插入超长字符串、特殊字符（如 SQL 注入常用字符）、最大允许数值等边界值时，能否正常插入并被缓存正确处理。
- 对于删除，验证删除不存在的数据时系统的容错能力，以及批量删除操作对缓存一致性的影响。
- 查询方面，除了常规查询，还要测试模糊查询、多条件联合查询等复杂查询场景下，缓存能否准确返回符合条件的数据，且不影响系统性能。
2. 模拟写入缓存场景，验证页面结果渲染：当模拟数据写入缓存后，不仅要确认页面渲染列表存储了该数据，还要检查数据在页面上的展示格式是否正确。比如以下几点：
- 日期字段是否按照预定的格式显示
- 图片等多媒体数据是否能正常加载与展示
3. 先模拟缓存生成的场景，立马查询页面结果渲染的数据源是否存在前置构建这条数据。
这一步骤主要是为了验证从数据源到缓存构建这条数据链路的及时性与准确性，确保在缓存数据生成的起始阶段，数据源能正确无误地为缓存和页面渲染提供所需的原始信息，避免因数据源端的延迟或错误，导致后续缓存数据有误或页面展示异常。
4. 先模拟缓存生成的场景，等待缓存数据超时或者淘汰后，在查询页面结果渲染的数据是否正确。
- 一方面，确认超时或淘汰机制是否严格按照预设的时间或规则执行
- 另一方面，在缓存失效后，再次查询数据时，能否从DB中获取数据并缓存。
5. 对业务数据进行更新后，验证页面结果渲染的列表是否存储的是更新后的数据。（例如，在数据更新后，页面结果没有变化，可能是业务逻辑只更新了sql DB中的数据，但是没有更新缓存数据）
- 正常情况下，单个用户进行数据更新后，检查页面结果是否显示为最新数据，另外检查缓存和DB中的数据是否一致。
- 对同一条数据并发更新，检查页面中数据显示是否正确，缓存和DB中的数据是否一致。
外部接口的测试
在外部接口的角度来说，我们需要校验被测服务和redis数据库底层交互逻辑正确性。因此，需要注意以下几个测试点：
1. 未命中缓存时：Redis中还没有当前请求的缓存数据
- 当查询的数据是真实存在的数据时，没有命中缓存的情况下，会返回SQL DB中对应的数据详情。在这种情况下我们需要查看被测服务的外部接口会返回什么结果。（通常需要补充额外的校验点来确认是mysql返回的结果）
3. 命中缓存时：当请求数据在Redis缓存中存在时，需要校验底层是不是查完redis 直接返回结果，而不是从mysql查询的结果。前置需要模拟redis存在数据 mysql 不存在数据的情况
4. 数据一致性：如果存在多个数据源就可能存在数据一致性，在某些业务逻辑下可能存在数据在不同数据源下不一致的情况。
例如，一个订单数据在数据库和消息队列中都有记录，当缓存未命中后从数据库获取订单数据后，要检查消息队列中的订单相关消息是否与数据库中的订单数据一致（如订单状态、金额等关键信息）。可以通过查询消息队列中的消息内容并与数据库数据进行对比来验证。
4. 数据淘汰机制： 一般情况下，对于缓存数据开发人员都会对缓存设置过期时间，用于数据淘汰。对于设置了过期时间的缓存数据，要测试过期策略是否有效。以及可以在缓存数据过期后，检查是否能正确地从后端数据源重新获取数据并更新缓存。
- 过期时间设置的准确性测试：需要确保缓存数据能在规定时间内淘汰。
- 过期时间对缓存更新的影响测试：在缓存更新过程中，要确保更新后的数据与DB中存储的数据一致。
- 高并发场景测试：高并发场景下，多个请求同时查询过期数据并触发缓存更新的情况。需要测试是否会出现数据冲突、重复更新或更新不及时的问题。
特殊场景验证
1. 缓存穿透
当构造一些不存在的数据查询请求，例如向系统发送查询一个不存在的商品 ID 的请求。观察这些无效请求是否能穿透缓存直达数据库，以及系统的处理方式。（系统能够按照期望结果返回响应的处理结果）
2. 缓存雪崩
可以将大量缓存数据的过期时间设置为相同值，如果大量缓存同时失效，验证系统功能是否正常，观察数据库的负载情况、响应时间以及系统是否出现卡顿甚至崩溃现象。
3. 缓存上限
这一点与Redis配置文件中配置的最大可用内存值有关。如果业务逻辑中设定了可用内存的最大上限，我们需要验证缓存淘汰机制与配置相符。另外，我们可以验证一下，当达到maxmemory限制时 对缓存数据读取和更新操作能否及时处理；在数据淘汰过程中，确保被淘汰的数据不会导致系统功能异常。