记录我在实际项目中针对微服务特性做的一些测试

一：A服务修改了某个接口的响应参数/请求参数，导致调用它接口的某个服务，或者它的下游服务会出现问题。

测试思路： 实际手工测试很难发现这类问题，那么可以在接口测试的基础上，增加类似于“契约测试”的策略。我们可以将接口的全部响应字段的key记录下来，在后续进行接口自动化时，校验这些响应字段是否发生改变（减少/修改），如果出现改变，那么就通知测试人员去推动处理。如果这些改变是必须的，那么就更改key记录信息。

二：如何保证数据一致性？比如有个服务A，它需要在自己的数据库里写入数据，然后再去调服务B，往B的库里写条数据。也许它自己库里写入成功了，但此时B服务恰好崩了或者其他情况，导致B库写数据失败了。

测试思路： 做这类测试，我一般会把B服务给干掉，做完业务流程后再启动B服务，模拟服务崩溃的情况，看数据能不能正确写入崩溃的服务。

三：对微服务常用中间件的测试

1）redis测试

redis常被用做缓存、队列、发布订阅。
对于缓存的测试：
1.当数据在redis跟db都存在时，测试curd是否正常
2.当数据在redis不存在、db存在时，测试curd是否正常；从db读取到数据后应当写入redis并返回给上层
3.当数据在redis存在、db不存在时：某些场景比如帖子的浏览量计数、转发量计数，会先在redis计数再同步到db，这种情况下需要检查数据一致。
4.当数据在redis跟db都不存在时，测试curd正常
5.当出现缓存穿透、缓存击穿、缓存雪崩时，数据库是否能抗压
6.缓存的过期时间是否生效

2）mq测试

从生产者角度：
1.消息是否推送到队列中
2.是否推送到对应的topic下
3.消息发送失败如何处理：模拟生产者连接mq失败，比如可以把mq服务停掉，项目可能采用消息持久化存到磁盘中。再重启mq服务，消息应当正确的被发送到队列中并成功被消费。
4.消息重复发送：可能网络出现问题，消息成功发到mq后，生产者没有收到mq的确认信息，这时候生产者会重复发生信息。针对这种情况，我们可以通过python的pika库连接mq，发送多条相同的数据。数据库应当只更新/增加一条数据，不应该出现错误情况。
从消费者角度：
1.消息能否正常被消费
2.消息被消费后有没有及时清除
3.消费者宕机，消息转发给其他消费者进行消费，不会出现消息未处理就被清除