【BUG SHOW】一个由高并发引起的缺陷分析

软件质量保障: 所寫即所思｜一个阿里质量人对测试的所感所悟。

缺陷介绍

平台有这样的两个功能：

​功能01: 用户发起支付，成功则将表pay单据状态推进SUCCESS，然后发出支付结果消息；反之如果支付失败，则状态保持INIT不变，结束流程，并且不发消息。如果用户发起幂等重试，支付成功则可以继续推进状态到SUCCESS。

功能02: 定时任务会自动捞起pay表状态INIT的单据，并且捞到数据后只需更新这条数据的gmt_modified为当前时间，不做其他处理直接return。

高并发场景下，功能01和功能02同时执行，出现同时执行同一条数据的情况，而功能02在获取数据后没有加锁，导致功能01将pay表数据推进SUCCESS后；功能02又将此数据状态重置成INIT，导致sendMsg数据的状态为INIT,影响上游对此数据的处理，与预期不符。

缺陷还原

我就以伪代码模拟一下这个缺陷场景。

缺陷修复

修复功能02：

1. 给功能02作为一个事务处理

2. 通过select...for update方式加锁获取pay单数据

3. 如果状态已经推进到SUCCESS，则直接 return

测试验证

分布式下搞并发场景不易验证，所以测试可以从（1）业务角度 （2）加锁是否生效维度进行验证。

业务角度

锁是否生效

缺陷思考

高并发的场景不太好验证，但是对于代码中加锁的代码一定要验此锁是否生效。