記錄一次餘額遷移的坑（測試角度）
一、這是一個遷移流程圖；現在把action做個簡單的記錄：備註：本次遷移核心是遷移流水，通過流水的收入-支出-餘額=0，在平臺使用者最少的時候進行遷移（凌晨2點進行）；找出收入和支出有差異的--仔細對賬查賬；然後運維配合，流水扎帳，記錄最大的流水id；繼續賬單平賬，然後進行快照流水回放遷移，遷移完成後，進行對賬，收入-支出-餘額=0那就很好，恭喜你沒有采坑，系統健壯；我們就不是，然後就一點一點查賬對賬；賬單平了以後，可以繼續遷移，遷移增量（首先我們是熱牽），遷移增量可能 要進行好幾次，每次遷移都要對賬；
| No. | ACTION | REMARK | 執行任務 |
|---|---|---|---|
| 1 | 針對user_balance表執行一次獲取差異賬單（賬單一） | 查出賬單，通常是54筆 |
select u.code, u.nickname , u.available_balance, ( 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) ); |
| 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沒有進行評審，就上手了
- 遷移風險，遷移方案沒有完全吃透：如果遷移失敗，有回滾方案嗎？遷移的效能瓶頸？有些歷史資料處理--待入賬？接入新資料相容問題等，上線後，全面業務迴歸