软件质量保障: 所寫即所思｜一个阿里质量人对测试的所感所悟。
缺陷介绍
平台有这样的两个功能：
功能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）加锁是否生效维度进行验证。
业务角度
锁是否生效
缺陷思考
高并发的场景不太好验证，但是对于代码中加锁的代码一定要验此锁是否生效。
