最近總有人問我做軟件測試到底什么項目最難測。我的回答一直沒變保險和銀行。這兩類系統(tǒng)業(yè)務規(guī)則密集、金額敏感、狀態(tài)流轉(zhuǎn)復雜外部接口又多很多bug在測試環(huán)境一測就過一上線就翻車。我把自己這些年攢下的軟件測試bug匯總按場景拆開結(jié)合真實排查經(jīng)驗寫成這篇匯總希望能讓剛轉(zhuǎn)金融項目或者正在被保險、銀行系統(tǒng)折磨的測試同行少走點彎路。這篇不是泛泛的功能測試清單而是圍繞保險銀行項目里最常見的bug類型從功能邏輯、并發(fā)權限、接口批量、報表對賬到排查實錄一次講透。1. 保險與銀行項目為什么容易“藏雷”1.1 兩類項目的業(yè)務差異決定了bug類型不同保險和銀行雖然都叫金融系統(tǒng)但在測試視角下完全是兩套邏輯。保險項目的主線是保單生命周期從投保、核保、承保、撤單、退保到理賠、續(xù)期每個動作都會改變保單狀態(tài)而且不同產(chǎn)品不同規(guī)則差異很大。比如重疾險的等待期、醫(yī)療險的免賠額、萬能險的結(jié)算利率這些業(yè)務規(guī)則通過規(guī)則引擎配置后測試人員如果不熟悉很難構造出有效用例。銀行項目的主線是賬務和資金流轉(zhuǎn)核心關注點在于資金不能多一分也不能少一分。轉(zhuǎn)賬、代發(fā)、代扣、理財申購贖回、貸款還款每一筆資金都要有完整的流水軌跡。銀行系統(tǒng)對事務一致性要求更高一個操作涉及多個賬戶時要么全部成功要么全部回滾不能出現(xiàn)半個交易。這個差異決定了測試重點保險多測狀態(tài)和規(guī)則銀行多測金額、并發(fā)和批量。如果拿測普通后臺系統(tǒng)的思路去測金融項目大概率會漏掉最致命的那類bug。1.2 測試環(huán)境的復雜程度遠超普通項目說一個我參與過的某保險項目測試環(huán)境要連核保引擎、支付渠道、短信平臺、電子保單服務還有一套用來模擬再保的接口mock光環(huán)境聯(lián)調(diào)就花了兩周。銀行項目更夸張核心系統(tǒng)、總賬、支付、渠道、風控一個完整的交易鏈路可能要跨五六個系統(tǒng)。環(huán)境之間數(shù)據(jù)版本不一致是家常便飯經(jīng)常出現(xiàn)測試環(huán)境復現(xiàn)不了、生產(chǎn)一下子就復現(xiàn)的情況。這種復雜環(huán)境下bug定位的難度直線上升。我見過很多測試新人一發(fā)現(xiàn)bug就只往自己系統(tǒng)里猜結(jié)果排查半天發(fā)現(xiàn)是上游系統(tǒng)返回了錯誤碼。所以金融項目測試第一步不是寫用例而是梳理系統(tǒng)交互圖搞清楚數(shù)據(jù)從哪里來、到哪里去。否則你連bug該記在哪個系統(tǒng)頭上都分不清。對保險和銀行項目來說環(huán)境拓撲越復雜“環(huán)境問題”和“代碼問題”就越容易混在一起測試人員必須具備基礎的鏈路分析能力。1.3 需求文檔里的隱性規(guī)則是bug溫床保險和銀行的需求文檔通常非常長但是真正容易出問題的不是主流程而是那些藏在“注意事項”“特殊約定”里的邊界規(guī)則。比如“猶豫期撤單不退還工本費”“保單未交費自動墊繳墊繳利率按約定執(zhí)行”“貸款提前還款違約金不超過剩余本金一定比例”。這些規(guī)則測試時很容易被忽略不是因為不認真而是因為用例設計時根本沒想過。我自己的習慣是拿到需求后先做一輪規(guī)則提取把文檔里所有帶“如果”“當”“未”“不”“僅”的句子單獨列出來再逐條轉(zhuǎn)成用例。比如“當保單處于退保申請狀態(tài)時不允許再次提交理賠申請”看起來很簡單但很多系統(tǒng)并沒有在狀態(tài)機里限制這個操作導致線上出現(xiàn)一筆退保中保單的理賠記錄。需求里的每一個“例外”幾乎都對應著一個bug點。測試保險和銀行項目不能只讀主流程文檔還要把附錄、備注逐字看一遍。2. 功能邏輯類Bug狀態(tài)、金額、日期三座大山2.1 狀態(tài)流轉(zhuǎn)Bug為什么“已失效”保單還能理賠狀態(tài)流轉(zhuǎn)是保險項目里出現(xiàn)頻率最高的bug類型幾乎每個版本都會遇到。典型問題是系統(tǒng)只判斷了當前狀態(tài)是否等于某個值但忽略了狀態(tài)的歷史路徑。比如保單已經(jīng)撤單狀態(tài)變成了“已撤單”但是理賠模塊的判斷條件是“狀態(tài)不等于已終止”于是已撤單的保單還能繼續(xù)走理賠流程。這個bug在測試環(huán)境不一定好觸發(fā)因為需要先把保單走到撤單狀態(tài)再走理賠流程如果用例只覆蓋了正常承保到理賠根本不會發(fā)現(xiàn)。解決這類問題最好的辦法是在測試設計階段畫狀態(tài)圖。把保單、賬戶、訂單等核心對象的合法狀態(tài)和狀態(tài)遷移條件全部畫出來再針對每個遷移做正向和反向用例。比如撤銷只有“已承?！焙汀蔼q豫期內(nèi)”才能操作那“等待核?！睜顟B(tài)下的撤單按鈕必須置灰就算按鈕沒置灰后端也要返回對應錯誤碼。狀態(tài)圖不需要畫得非常正式只要能覆蓋所有狀態(tài)和跳轉(zhuǎn)關系就足夠了。2.2 金額計算Bug一分錢的差距怎么來的金融項目里金額精度問題永遠排得上bug前三。我見過最典型的低層bug是用double類型存金額導致保費計算結(jié)果出現(xiàn)0.00000001的尾差最后試算保費和實際應收保費對不上。銀行核心系統(tǒng)一般會使用decimal或者Long以“分”為單位存儲和計算但外圍系統(tǒng)不一定遵守同一套約定聯(lián)調(diào)時就會出問題。一筆跨系統(tǒng)的交易這邊傳的是元那邊收的是分金額差一百倍這種事故真的是會發(fā)生的。除了存儲類型四舍五入規(guī)則也特別容易踩坑。保費、利息、手續(xù)費、違約金究竟保留幾位小數(shù)是按商品還是按訂單匯總后四舍五入還是每一項先四舍五入再加總這兩種方式在極端值下會出現(xiàn)一分錢的差異。銀行利息更麻煩本金、利率、天數(shù)、計息方式四者交叉一年按360天還是365天月末日是否計息都會導致結(jié)果不同。我建議所有金額用例都準備一組邊界數(shù)據(jù)比如0.01元、999999999.99元、0.000元再準備一組尾差用例比如0.005、0.015用公式先手動算出期望值再跟系統(tǒng)比對這樣踩雷概率會低很多。2.3 日期時間Bug生效日、到期日、節(jié)假日規(guī)則因為時間邊界導致的bug在保險和銀行項目里也是見怪不怪。保險最典型的是保單生效日和保險期間的銜接問題。比如投保申請在2024年12月31日提交約定次日零時生效系統(tǒng)計算生效日時用了當前日期加一天但沒考慮跨月結(jié)果生效日到底是2025年1月1日還是2024年12月32日不覆蓋跨年就會漏掉。很多bug管理員可能覺得這屬于低概率事件實際上銀行保險業(yè)務天天都在跨日期運行邊界時間就是最容易出錯的地方。銀行的時間問題更多集中在“節(jié)假日順延”和“日切時點”上。定期存款到期日如果遇到法定節(jié)假日應該順延到下一個工作日但順延期間的利息怎么算貸款還款日遇到節(jié)假日是提前扣款還是順延這些規(guī)則每個項目都不一樣必須用真實節(jié)假日數(shù)據(jù)去測試。我常用的方法是把系統(tǒng)中的日期控件和后臺服務器時間統(tǒng)一做邊界測試例如23:59:59、00:00:00、02-29閏年每個邊界點至少跑一遍。不要嫌麻煩時間bug一旦線上爆發(fā)客戶會直接打電話投訴。3. 并發(fā)、權限與安全類Bug銀行項目的高危雷區(qū)3.1 并發(fā)重復提交同一個賬戶被扣兩次銀行項目里最嚴重的用戶體驗問題就是重復扣款。用戶在手機銀行提交轉(zhuǎn)賬時網(wǎng)絡卡頓連續(xù)點了兩次“確認”如果后端沒有做冪等控制就會發(fā)起兩筆扣款。類似的情況還有保險投保時用戶重復提交訂單同一份保險被投保兩次簡直是災難。這類bug在功能測試階段很難發(fā)現(xiàn)因為人工操作達不到毫秒級并發(fā)必須靠自動化工具模擬。我現(xiàn)在的標準做法是測試用例里必加一條“同一請求重復提交N次”的場景用性能測試工具模擬并發(fā)或者直接用腳本循環(huán)請求。后端判斷是否重復的關鍵是冪等鍵比如訂單號、流水號、用戶操作唯一標識。測并發(fā)時重點看兩個點一是是否生成了兩條業(yè)務數(shù)據(jù)二是第二次請求是否返回了“重復提交”的提示。如果系統(tǒng)沒有冪等校驗哪怕功能測試全過也必須當成P0問題提出來。3.2 權限與越權柜員能看到別人的客戶信息權限類bug在銀行項目里屬于高危漏洞因為一旦出現(xiàn)越權輕則信息泄露重則違規(guī)操作。最常見的越權有兩種水平越權和垂直越權。水平越權是A柜員能看到B柜員名下的客戶資料垂直越權是普通柜員能執(zhí)行主管才能做的交易授權。這兩種bug用普通頁面流程很難測出來因為正常操作下頁面不會展示那些入口但接口層可能沒有做數(shù)據(jù)歸屬校驗。測試權限時不能只驗證不同角色的菜單可見性還要驗證接口層面的數(shù)據(jù)歸屬。比如A柜員登錄后手動修改請求里的客戶編號系統(tǒng)是否就能返回B客戶的賬戶信息。這種bug在頁面端可能被隱藏了入口但接口層沒做數(shù)據(jù)過濾很容易被鉆空子。我自己寫用例時會把權限用例拆成功能權限和數(shù)據(jù)權限兩類分別覆蓋功能權限管“能不能點這個按鈕”數(shù)據(jù)權限管“能看到哪些數(shù)據(jù)”。3.3 數(shù)據(jù)脫敏與日志泄露金融項目涉及大量客戶隱私脫敏是測試里的硬指標。經(jīng)常出現(xiàn)的bug包括頁面正常脫敏但接口返回報文里是明文日志文件里打印了完整的身份證號測試環(huán)境的驗證碼短信直接下發(fā)到真實手機號。前面兩種還好說最后一種屬于事件級別問題。做測試時我自己專門準備了一批敏感數(shù)據(jù)比如身份證號、手機號、卡號每個都做成固定測試值一旦在日志或接口里發(fā)現(xiàn)原文立刻定位是哪一個環(huán)節(jié)出了問題。排查脫敏問題最有效的辦法是抓全鏈路報文。從前端發(fā)起請求到后端返回響應再到日志輸出每一層都檢查一遍。重點看JSON字段、日志打印語句、數(shù)據(jù)庫導出文件、批量郵件附件。除了常規(guī)的身份證和手機號還要注意銀行卡號、密碼、CVC碼、支付密鑰這類數(shù)據(jù)。測試通過的標準不只是“頁面打碼了”而是“全鏈路無明文”?，F(xiàn)在很多公司對敏感數(shù)據(jù)都有自動化掃描工具但工具只能發(fā)現(xiàn)一部分人工抽查仍然不可少。4. 接口、批量與數(shù)據(jù)庫層Bug肉眼看不到的坑4.1 接口聯(lián)調(diào)字段映射和報文格式保險和銀行項目都是典型的多系統(tǒng)協(xié)作前后端之外還有渠道系統(tǒng)、核心系統(tǒng)、第三方支付接口聯(lián)調(diào)階段是bug高發(fā)期。最常見的有字段名對不上、類型不一致、報文長度不夠。比如金額字段核心系統(tǒng)用“amount”表示分渠道系統(tǒng)用“amt”表示元聯(lián)調(diào)時不轉(zhuǎn)換結(jié)果金額差一百倍。這種bug邏輯上不復雜但排查極費時間因為兩邊都覺得自己沒問題。我的排查思路是先確認接口文檔的標準定義再抓實際報文對比。測試時每個字段都要準備正常值、邊界值、空值比如一個字段定義為最長10位就要傳11位驗證系統(tǒng)的校驗邏輯一個日期字段規(guī)定為yyyyMMdd就必須測試“20241231”和“2024-12-31”兩種格式。接口回歸時我會做一次全字段比對把標準報文和實際報文逐字段核對基本能覆蓋大部分映射問題。保險和銀行項目的接口文檔通常都有版本管理聯(lián)調(diào)時一定要確認當前版本不要拿舊文檔對需求。4.2 批量任務定時跑批失敗的經(jīng)典場景銀行和保險公司都有大量批量任務日終批處理、批量代發(fā)、批量扣費、批量結(jié)息。這類bug的特點是白天測起來風平浪靜一過零點就出事。最常見的是批量任務重復執(zhí)行比如調(diào)度平臺因為超時重發(fā)指令同一個批量被觸發(fā)兩次導致客戶被重復扣費或者批處理中間某一步失敗前序已經(jīng)寫庫的數(shù)據(jù)沒有回滾。批量任務一旦出問題影響面通常很大因為一次跑批往往涉及成千上萬條數(shù)據(jù)。測試批量任務不能只測“正常跑完一次”至少還要覆蓋斷點續(xù)跑、失敗重跑、重復調(diào)度三個場景。我一般會在測試環(huán)境保留一份真實脫敏數(shù)據(jù)把批量任務的數(shù)據(jù)量做大一點比如一萬條再手動模擬失敗節(jié)點觀察系統(tǒng)是否能正確記錄失敗原因以及重跑后不會產(chǎn)生重復數(shù)據(jù)。批量任務日志必須包含批次號和執(zhí)行結(jié)果否則出問題根本沒法追溯。測試時還要注意批量任務的數(shù)據(jù)造數(shù)不是隨便造幾條就算完要造出不同狀態(tài)、不同金額、不同時間的組合。4.3 數(shù)據(jù)庫唯一約束與事務回滾數(shù)據(jù)庫層的bug很多不是代碼寫錯而是設計時漏了約束。最典型的是業(yè)務流水表沒有唯一索引導致同一筆交易因為接口重試插入兩條記錄。這類問題在功能測試時往往不會出現(xiàn)因為手動測試不會觸發(fā)重試但一旦線上調(diào)用方超時重試數(shù)據(jù)就重復了。寫用例時我會專門查一下核心表結(jié)構看有沒有唯一鍵尤其是業(yè)務流水號、批次號、交易請求號這類字段。事務回滾的問題則集中在多表更新場景。比如銀行轉(zhuǎn)賬需要同時更新扣款賬戶和收款賬戶如果代碼只對扣款賬戶的update開啟了事務收款賬戶的update單獨提交在第二步失敗時就會造成單邊賬。測試時要準備故障注入場景比如讓第二張表更新報錯驗證整個事務是否回滾。還有一個很容易被忽略的批量操作里循環(huán)調(diào)用單條更新沒有整體事務中間一條失敗其他數(shù)據(jù)已經(jīng)提交。這種場景在功能測試里不常測但線上批量跑批一旦出問題處理成本極高。5. 報表、對賬與前端展示Bug用戶直接罵娘的痛點5.1 報表統(tǒng)計Bug匯總口徑錯亂報表是保險公司和銀行內(nèi)部使用頻率最高的模塊之一但很多測試團隊對報表的重視程度不夠覺得“只要數(shù)據(jù)能查出來就行”。實際上報表的統(tǒng)計口徑非常容易出問題。比如“當日新增保費”是按保單承保日期統(tǒng)計還是按保單生效日期統(tǒng)計不同部門可能口徑不一樣報表做出來就有一個部門的數(shù)據(jù)對不上。這種問題在提測階段往往發(fā)現(xiàn)不了因為測試人員只驗證了報表能否展示數(shù)據(jù)沒有驗證統(tǒng)計口徑本身是否正確。另一個常見問題是對匯總數(shù)據(jù)的精度處理。明細表里每筆金額都保留兩位小數(shù)匯總時直接sum看起來沒問題但如果是四舍五入后的明細加總和按原始金額加總后再四舍五入會有尾差。報表測試必須有“核對來源數(shù)據(jù)”這一步用SQL從數(shù)據(jù)庫查明細重新匯總再跟報表展示結(jié)果比對。我一般會準備一張Excel把預期數(shù)據(jù)算好然后跟系統(tǒng)導出結(jié)果做逐項核對而不是只看頁面數(shù)字有沒有顯示出來。5.2 對賬不平Bug渠道流水與核心賬務對賬是銀行和保險項目特有的一類功能渠道系統(tǒng)和核心系統(tǒng)各自記了一筆流水每天需要比對是否一致。最常見的bug是兩邊處理時序不一致。比如同一筆支付渠道系統(tǒng)已經(jīng)記賬成功但核心系統(tǒng)因為網(wǎng)絡原因沒有收到通知導致當天對賬不平。這種問題有的不是系統(tǒng)邏輯bug而是對賬任務本身沒做“緩沖處理”。測試時需要人為構造“渠道已記、核心未記”的數(shù)據(jù)驗證對賬任務是否能夠正確識別差異并生成差錯記錄。排查對賬不平的思路是先明確以哪邊數(shù)據(jù)為準然后按流水號、金額、狀態(tài)三個維度做差異分析。測試時要人為構造差異數(shù)據(jù)比如渠道多一筆、核心少一筆、金額不一致、狀態(tài)不對應再跑對賬任務看差異報表是否能正確列出。對賬邏輯里最容易漏的是手續(xù)費和退款兩邊統(tǒng)計口徑不同對賬結(jié)果就會一直有差異。做測試時不要只看主交易流水的對賬結(jié)果手續(xù)費、利息、退款、沖正這些專項對賬同樣要覆蓋。5.3 前端展示Bug金額格式、滾動加載、重復點擊雖然前端bug在金融項目里不算最致命但用戶感知最強。金額顯示問題最常見比如數(shù)字千分位格式不對0.00顯示成0金額單位混亂。日期控件問題也很多比如只允許選擇自然日但業(yè)務上只允許選擇工作日很多前端日期選擇器沒限制用戶選了節(jié)假日提交后被后端報錯。這類bug不需要多高深的技術就能發(fā)現(xiàn)但需要測試人員有細心和耐心。前端交互的重復點擊問題前面說過更多的是按鈕在請求中未置灰導致用戶連點。還有列表分頁和滾動加載結(jié)合的場景滾動到底部觸發(fā)下一頁數(shù)據(jù)如果接口慢用戶快速滾動可能觸發(fā)多次請求導致數(shù)據(jù)錯位或重復。這些我都會放進常規(guī)回歸用例里雖然單個bug級別不高但發(fā)出去就是客戶投訴。保險和銀行項目的移動端遠比PC端敏感網(wǎng)絡弱、中斷、弱網(wǎng)切Wi-Fi、前后臺切換這些都是前端測試不能漏的場景。6. 我印象最深的三個Bug排查實錄6.1 撤單退費重復入賬有一次我所在的某保險項目上線后財務反饋當天的撤單退費金額對不上多出了一筆幾十萬的付款。排查過程很有意思。先從退費流水表查發(fā)現(xiàn)某批次號出現(xiàn)兩次再查批量任務調(diào)度日志發(fā)現(xiàn)上游調(diào)度平臺因為響應超時自動重發(fā)了指令同一個批次被執(zhí)行了兩遍。系統(tǒng)處理時沒有按批次號做唯一性控制就會把退費指令重復入賬。這個故障的影響不只是財務對賬還涉及批量任務冪等控制設計。后來我們在批次處理表增加了批次號唯一約束并且在任務開始前先檢查批次狀態(tài)已經(jīng)處理過的不再執(zhí)行。測試用例里也補了一條“重復調(diào)度同一批次”的場景從那以后再也沒有出現(xiàn)過同類問題。這個案例也讓我明白接口調(diào)用方的重試機制一定是測試中必須考慮的因素不能假設線上不會發(fā)生。6.2 日切時點重復扣款某銀行項目的客戶投訴讓我意識到并發(fā)測試的重要性?？蛻粼谕砩?1點59分59秒發(fā)起了一筆轉(zhuǎn)賬結(jié)果被扣了兩次錢。排查后發(fā)現(xiàn)他先后提交了兩筆請求第一筆請求被日切任務打斷系統(tǒng)返回超時前端認為失敗了用戶又提交了一次。第二次提交時第一筆實際已經(jīng)入賬但系統(tǒng)沒有任何提示導致重復扣款。這個問題涉及三個環(huán)節(jié)日切時點交易處理、渠道超時重試、冪等校驗覆蓋范圍。技術修復方案不復雜在轉(zhuǎn)賬請求入口增加一個以用戶操作流水號為主的冪等校驗日切期間短暫拒絕非查詢交易。真正難的是測試怎么模擬這個場景后來我們專門搭了一套日切測試環(huán)境把日切時間固定在某分鐘專門測邊界時段的并發(fā)請求。從那以后我養(yǎng)成了一個習慣凡是金融系統(tǒng)涉及時間切換的測試都要圍繞日切前后兩分鐘重點測試。6.3 批量代發(fā)部分成功未回滾還有一個印象深刻的bug來自批量代發(fā)工資。某銀行批量代發(fā)原本應該上千筆全部成功實際卻有一筆因為收款方賬號錯誤而失敗。更麻煩的是該筆失敗的記錄已經(jīng)寫入流水表但狀態(tài)是“失敗”而其余成功記錄也都已提交。業(yè)務要求這次代發(fā)要么全部成功要么全部失敗這樣便于差錯處理。由于批量任務是一條條處理的沒有整體事務出現(xiàn)了部分成功的情況。后續(xù)解決方案是按批次引入事務邊界或者至少增加“失敗清單”和“批次狀態(tài)更新”機制讓批量任務結(jié)束后能自動標記為部分成功并支持對失敗清單進行二次重發(fā)。測試時我也養(yǎng)成一個習慣批量測試不僅要看成功數(shù)據(jù)還要專門制造失敗數(shù)據(jù)觀察失敗后的數(shù)據(jù)一致性和業(yè)務流程是否還能繼續(xù)。很多批量bug只有在“成功失敗”混合場景下才會暴露測試用例如果只準備全成功數(shù)據(jù)等于白測。7. 如何系統(tǒng)化減少這些Bug流程、清單與復盤7.1 測試設計階段畫狀態(tài)圖與判定表避免金融項目bug最好的時機不是執(zhí)行測試時而是設計用例時。我現(xiàn)在的習慣是先畫核心對象的狀態(tài)圖再畫關鍵業(yè)務的判定表。狀態(tài)圖畫完狀態(tài)遷移的漏測點基本就暴露了判定表則能把復雜的規(guī)則場景分解成可枚舉的組合。該階段投入的時間越多執(zhí)行階段返工越少。以保險為例核心對象是保單狀態(tài)包括“待支付、已生效、已失效、退保中、已退保、理賠中、已理賠”。我會把每個狀態(tài)的操作權限列出來比如“待支付”狀態(tài)不能做理賠“退保中”不能做受益人變更。再比如銀行賬戶狀態(tài)包括“正常、掛失、凍結(jié)、銷戶”“凍結(jié)”狀態(tài)下轉(zhuǎn)賬交易必須被攔截。這些設計工作在需求評審階段就要開始等到寫用例時再做就已經(jīng)晚了。用狀態(tài)圖的方式做用例設計不僅適合保險和銀行也適合任何狀態(tài)多的后臺系統(tǒng)。7.2 金融項目通用測試檢查清單我整理了一份自己的檢查清單每次金融項目版本測試前都會過一遍。放在這里供參考分類核心檢查點優(yōu)先級狀態(tài)流轉(zhuǎn)核心對象所有狀態(tài)遷移是否覆蓋非法狀態(tài)操作是否被攔截P0金額精度是否使用decimal四舍五入規(guī)則統(tǒng)一尾差用例覆蓋P0冪等控制重復提交/重復調(diào)度是否產(chǎn)生重復數(shù)據(jù)P0時間邊界跨年、跨月、閏年、日切、節(jié)假日順延P0批量任務斷點續(xù)跑、失敗重跑、重復調(diào)度、部分成功回滾P0接口字段字段類型、精度、長度、枚舉、空值校驗P1權限控制水平越權、垂直越權、數(shù)據(jù)級權限P0數(shù)據(jù)脫敏頁面、接口、日志、導出文件是否明文P1對賬一致性渠道流水與核心流水、手續(xù)費、差異報表P1前端交互金額格式、日期限制、按鈕防重點擊、分頁P2這里的P0是我認為上線前必須全部通過的檢查項尤其是狀態(tài)流轉(zhuǎn)、冪等和權限一旦出了問題基本都是事故。檢查清單不能只停留在文檔里最好拆成測試用例的標簽用例執(zhí)行時自動關聯(lián)每次回歸時按標簽篩選執(zhí)行。7.3 Bug復盤與知識沉淀最后一個想聊的是復盤。金融項目的bug尤其線上問題一定要做根因分析不能只改表面。我常用的復盤框架是問題現(xiàn)象、觸發(fā)條件、根因、影響范圍、當前狀態(tài)、后續(xù)改進。觸發(fā)條件比根因更重要因為只有知道什么場景下會觸發(fā)才能設計出對應的回歸用例。復盤結(jié)果要沉淀成知識庫而不是開完會就結(jié)束。我參與過的團隊里每一條線上bug都會整理成一條“Bug模式”比如“批量任務無冪等”“狀態(tài)判斷忽略歷史路徑”“四舍五入規(guī)則不一致”。下一次測試直接在用例設計階段檢索這些模式把對應的檢查點加進去。時間長了整個團隊的bug預防能力會明顯提升。做測試越久越會發(fā)現(xiàn)真正值錢的經(jīng)驗不是記住了多少個bug而是總結(jié)出了多少條能復用的防坑規(guī)則。最后說點我自己的體會。保險和銀行項目里的bug大多數(shù)不是“不會寫代碼”導致的而是測試用力沒用對地方。狀態(tài)機、金額、時間、并發(fā)這四個詞做金融測試的每天都要在心里默念幾遍。這篇bug匯總里的場景很多都是我用一單單線上事故換來的經(jīng)驗寫出來是希望大家少踩同樣的坑。如果哪天你在測試環(huán)境真的撞上了類似問題別慌按狀態(tài)、金額、接口、數(shù)據(jù)四個維度先定位大概率能找到方向。后面我還會整理一些自動化測試和接口聯(lián)調(diào)的具體案例到時候再接著聊。