記錄一次餘額遷移的坑(測試角度)
- 2019 年 10 月 3 日
- 筆記
一、這是一個遷移流程圖;現在把action做個簡單的記錄:備註:本次遷移核心是遷移流水,通過流水的收入-支出-餘額=0,在平台用戶最少的時候進行遷移(凌晨2點進行);找出收入和支出有差異的–仔細對賬查賬;然後運維配合,流水扎帳,記錄最大的流水id;繼續賬單平賬,然後進行快照流水回放遷移,遷移完成後,進行對賬,收入-支出-餘額=0那就很好,恭喜你沒有采坑,系統健壯;我們就不是,然後就一點一點查賬對賬;賬單平了以後,可以繼續遷移,遷移增量(首先我們是熱牽),遷移增量可能 要進行好幾次,每次遷移都要對賬;
No.
|
ACTION
|
REMARK
|
執行任務
|
---|---|---|---|
1 | 針對user_balance表執行一次獲取差異賬單(賬單一) | 查出賬單,通常是54筆 |
select u.code, u.nickname , u.available_balance, ( |
2 | 取一次流水表最大id | 取出流水表中的最大的id(MAX_ID) | SELECT MAX(id) from user_balance ; |
3 | 再獲取一次獲取差異賬單(賬單二) | 查出賬單,通常是54筆 | select u.code, u.nickname , u.available_balance, ( (select sum(ub.balance) from user_balance ub where ub.user_code = u.code and ub.status = 1 and ub.bi_type =1) – (select sum(ub.balance) from user_balance ub where ub.user_code = u.code and ub.status = 1 and ub.bi_type =2) ) as ‘收入減支出’ from user u where available_balance <> ( (select sum(ub.balance) from user_balance ub where ub.user_code = u.code and ub.status = 1 and ub.bi_type =1) – (select sum(ub.balance) from user_balance ub where ub.user_code = u.code and ub.status = 1 and ub.bi_type =2) ); |
4 | 驗證賬單一和賬單二是否一致 | ||
5 | 進行差異賬單平賬 | 差異賬單進行調整,通過資金後台功能,導入excel,自動進行平賬 |
需要提供導入平賬的能力; fund-manager已提供http接口 |
核對差異賬單正確性 |
SELECT * FROM user_account WHERE 1 limit 100; SELECT * FROM org_account where 1 limit 100; |
||
6 | 進行快照流水遷移 |
從0開始遷移到MAX_ID為止到流水,進行業務回放 |
需要提供從0到N流水號回放的能力 fund-manager已提供http接口 |
7 | 遷移完成後進行資金系統對賬 | 收入-支出 -餘額 = 0 |
select u.account_id, u.account_name, u.user_code, ( |
8 | 檢驗是否有差異 | 正常情況下應該是0 | |
9 | 進行差異數據單筆重試 |
需要提供單筆業務重試的能力 fund-manager已提供http接口 |
|
10 | 對資金系統進行備份 | sg_account庫 | |
11 | 增量遷移 |
提供增量遷移能力,記錄老系統ID和新系統ID,在執行業務之前,需要進行冪等(執行轉賬業務之前,fund-manager), user_balance存在order_no為 |
需要提供從X到Y流水號回放的能力(和從0到MAX_ID的能力是同一個) fund-manager已提供http接口 |
12 | 應用發佈(含業務回歸驗證) |
應用發佈 |
|
13 | 再次進行增量遷移 | 提供增量遷移能力(可執行之前一樣的操作) |
需要提供從X到Y流水號回放的能力(和從0到MAX_ID的能力是同一個) fund-manager已提供http接口 |
14 | 遷移完成後進行資金系統對賬 | 收入-支出 -餘額 = 0 |
select u.account_id, u.account_name, u.user_code, ( |
15 | 進行系統間對賬 |
系統內對賬: 資金系統快照2 – 資金系統快照1 = 增量流水軋差 + 新業務流水 系統間對賬:老系統增量流水和新系統遷移流水進行對賬 |
增量流水獲取 |
16 | 針對差異數據進行單筆調賬 |
需要提供單筆業務重試的能力 fund-manager已提供http接口 |
二、開發踩得的坑,測試流的淚
1. userbalance表, serialNo/orderNo 重複, 與遷移程序唯一單號生成策略衝突,導致部分數據丟失。
eg: 接口並發,同一筆訂單可能生成多筆,我就看到一個用相同訂單號有17筆;
2. userbalance有記錄,但user表沒有用戶 引發bug、賬不平。
eg:用戶userCode被修改,或者直接被刪除,但是有消費過,balance裏面沒有被處理
3. account-business 對於已存在的commonbill賬單,再次申請會進行數據覆蓋,導致後面重複的單號數據會覆蓋前面轉賬成功的數據,從而account-business與account-core賬對不上。
4. account-business調用轉賬時,金額小於等於0會直接變成成功,不走account-core。 應改為金額等於0直接成功,不走core。金額小於0報錯
三、測試需要關注點:
- 測試用例質量和checklist是否清晰明了:第一次接觸餘額遷移,我知道必須重視,可是我還是重視不夠,寫出的checklist沒有進行評審,就上手了
- 遷移風險,遷移方案沒有完全吃透:如果遷移失敗,有回滾方案嗎?遷移的性能瓶頸?有些歷史數據處理–待入賬?接入新數據兼容問題等,上線後,全面業務回歸