BUG標題：
事務處理過程中數據加鎖不合理，導致同一數據源在交易過程中被其他交易改變
BUG影響：
1688極速到賬、賬期支付等場景下并發下單失敗或金額占用不準確現象，造成擔保方金額虧損
BUG發現過程：
1）前期參與開發代碼review，梳理1688極速到賬、賬期支付等場景事務處理過程和鎖使用機制，識別代碼風險點；
2）
測試設計階段：針對性地設計各種交易復雜場景高并發壓測；
3）測試過程中：編寫數據校驗腳本，在上億條日志中檢查每筆交易訂單正確性，并找到必現條件；
原因為：交易過程中要用到的數據源被其他買家與該賣家交易時改變，導致失敗卻沒有進行回滾，必現條件如下圖所示：
BUG解決方法：
在數據源被鎖住的代碼里再次添加查詢剩余額度代碼后再進行金額占用，并保證失敗后能進行數據回滾（注：第一次查詢剩余額度目的是查詢需要用到幾種授信源和各自的剩余金額進行數據鎖定，開發認為在查詢和數據鎖定之間時間極短不可能發生改變，故在鎖內未加入再次查詢節省性能開銷），同時在回歸過程中評估修改影響，注意鎖內操作變多帶來的接口性能下降問題，經測試確實下降3MS左右幸好滿足預期。
GBA傳承
1、針對
數據庫鎖測試時，一定要考慮并發測試場景，并確保查詢和使用數據源都在鎖內進行，避免數據不準確；
2、性能壓測過程中除了觀察接口調用返回正確性，還需要觀察產生的數據是否完全和預期相符，數據量大時建議用腳本或者編寫小工具進行校驗，在上億條日志中不要放過任何一條可疑日志。
個人感受：
1、事務處理和數據鎖相關測試，需要介入代碼review，并理清各種約束條件和觸發場景設計壓測用例；
2、需求評估階段單純的認為接口壓測僅需要把各種接口串聯在一起進行并發測試，只需要觀察接口返回正確性就OK，差點疏忽了復雜場景下接口返回是成功了但數據可能不一致的場景；
3、涉及金額的測試，出現概率就算再小也是大事，需要多留一份心。