测试笔记（日志审计、幂等性）

日志审计

1. 日志的完整性：所有核心关键业务操作都必须产生的日志且必须完整，如放款操作是否有日志且完整，修改借款额度更新操作等是否有日志且完整，测试时必须注意所有触发日志的操作、日志触发点、触发后日志的完整性等；
2. 日志的准确性：比如借款利率从5%降到4%后，更改前的快照和更改后的快照是否准确，日志表中这个字段，修改前值是否准确，修改后值是否准确；
3. 日志不能删除和修改：日志只能增加，不能修改和删除；
4. 日志是否脱敏：根据法律法规，关键数据在日志中是否脱敏，如身份证号、银行卡号等信息；
5. 是否影响核心业务：如果日志写入影响核心业务的性能或者功能都不可以；如批量写入日志后，审核业务失败了；
6. 日志记录不需要像浏览器中http请求一样要求时效性，所以可以考虑使用消息队列，性价比高且不影响业务性能；

幂等性

1. 幂等性能够保证无论操作执行多少次，结果都和"只执行一次"完全一样。 尤其针对金融业务，它能确保"不多扣钱、不多放款、不重复生成账单"。
2. 为了防止如扣款业务这类操作多次重复，比如网络异常、超时、弱网等情况下，用户点击后没有反应可能会连续多次点击，导致金额多扣，产生业务致命缺陷，引发客户和商家冲突；
3. 针对资金交易接口，我们采用'双层防重'策略保障数据一致性，如业务层利用全局唯一ID+redis缓存实现幂等拦截，数据层引入乐观锁，控制并发冲突，两者结合即挡住重复请求又兜住了并发冲突。
4. 通过设置各种重复请求的异常场景验证幂等性拦截效果；

• 弱网：可以通过接口测试fiddler设置弱网、
• 消息队列（MQ）：手动设置超时时间，将时间设置短，触发MQ因未收到Ack而重新投递同一条消息；验证客户重复处理同一笔款项时，是否会重复扣款；
• 缓存：用户发起放款请求后，在缓存中删除幂等Key，然后再次发起请求，此时重启redis，核验是否会重复放款；

使用locust对放款接口高并发操作，验证数据库连接池是否用完，导致后面业务无法进行；