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