與時俱進「風險系統保障質量之路」非同尋常

作者：梁鼕鼕

風險系統複雜且又龐大，質量如何保障需要我們付出一點一滴的努力來澆灌系統之花

一、大促備戰，求有序，求穩定：

大促是每年例行高考，把人和系統的各項能力激發，衡量系統健壯，容錯性；凌晨 3 點的身影就像一束光，奪目耀眼；今年的大促與往年不同，倡導綠色，節能減排，降本增效，把各種資源做到利用最大化，產生更大的價值，讓大促備戰產生了一絲溫度

1）壓測備戰時間表（統籌整體，從 4.21-6.23 我們把劇本編制到細枝末節，是一條生命線）

2）伺服器擴容縮容計劃（節能減排，把資源利用合理化，讓價值體現最佳）

3）系統最佳化清單（風險策略的不斷增加、迭代，對系統是實時的挑戰，透過不斷最佳化系統，讓系統輕鬆應對大促）

3）壓測目標與評估（精準預估流量，透過流量複製形式生成相關壓測資料，保證資料的還原程度，壓測輪次減少，壓測質量不減，反而增強）

4）壓測介面清單表（計劃壓測介面，壓測輪次，分層分次，僅僅有條）

5）大促備戰準則與規範（備戰規範是我們的方向標，準繩，像大海中的指南針指引方向不能偏航）

6）備戰注意事項（把常規事項羅列清晰，把事情做到最佳）

7）監控與看板（系統風險的兜底方案，我們監控的有力保障，最短的時間發現、定位、解決問題）

8）備戰待辦事項清單（把大促工作相關待辦項羅列清晰，有條不紊的進行展開）

9）備戰會議室與運營（因為疫情，我們把戰場分成線上，線下相結合，提前做好準備工作，打一場勝仗）

二、預警監控，求全面，求精準：

預警監控是質量的最後一道關卡，同時也是質量的兜底方案，我們格外重視建設這塊的能力。

預警全面性：預警分為業務預警、系統預警、資源預警三大類，業務預警在三層最上端，也是對業務結果的檢驗檢測，經過我們長期對業務資料分析，對預警的閾值不斷調優，對預警的等級分層等，業務預警的覆蓋度不斷顯著提升；整體配置預警 1000+，業務預警的覆蓋度穩步提升，同比去年提升 56% 左右，整體覆蓋了核心場景。

1）梳理業務結果資料（對業務細化，業務熟悉度更高）

2）接入風險洞察系統（透過資料來源接入到實時風險洞察實時計算平臺）

3）配置資料集（透過 sql 配置不同的資料加工邏輯）

4）設定相關告警閾值（透過線上資料分析，得出精準的閾值結論）

5）手機相關接受人，預警等級，預警方式，預警資訊等（把相關的干係人，預警的等級方式統一配置齊全）

6）測試預警觸達（驗證預警的有效性）

7）預警啟用（啟用後，正式運營告警）

8）透過設定預警機器人相關核心預警項，增強預警的監督與及時性（透過機器人運營，把應用負責人跟預警強關聯起來，力保發現的線上問題，在最短的時間內通知到干係人，處理以及監督解決）

預警的精準度：提升預警的精準度，是為了及時發現以及精準定位線上問題 以及 降低預警運營成本最有效的方案；透過我們一年多來研究業務預警，把風險系統的業務預警拆分成多層，透過四分演算法等機制已經形成了一套標準化、統一化、流程化的預警運營的方案，至今事故級別預警精準度達到 100%，準事故級別預警達到 99.6% 左右，高危級別預警在 76% 左右。

1）事故級別預警（精準度缺失無法容忍 block 級別）

2）準事故級別預警（精準度容忍略微缺失，精準度至少在 99% 以上）

3）高危級別預警（高危級別預警類比系統精細化預警，容忍精準度缺失，講究覆蓋度與精準度的平衡，精準度要求在 80% 以上）

3）高危級別預警（精細化運營類的告警，容忍有精準度缺失，80% 以上）

三、自動化覆蓋度，求效率，求變化

在不變中求變，在變化中不變；交付的質量與交付的效率本身是一件衝突的事，可以把衝突的事做成不衝突，要客服種種的困難，不達目的不放棄的精神

移動端篇：裝置指紋是風險側技術能力建設的重要工具以及手段，裝置指紋會以 SDK 或者 JS 的方式嵌入到業務的 app 或者頁面裡，獲取相關的風險資訊，達成風險識別的能力；裝置指紋的自動化涉及到兩個方面：

1）裝置指紋的穩定性：透過調研線上崩潰的區域，容易發生崩潰 orANR 的部分多數是來自於資料介面的互動導致崩潰，前期透過對業務的呼叫鏈路梳理，把相關崩潰風險的區域，做成了 UI 自動化，透過指令碼控制手機，執行相關的業務邏輯操作，透過迴圈次數 以及 執行時間控制重複操作來模擬操作，校驗是否會出現崩潰等異常情況；這塊我們已經透過封裝開源的工具，把執行指令碼，採集相關 logcat 相關的崩潰或 ANR 資訊列印到測試報告內，透過發郵件的方式，最終收集相關的報告結果，大大提升了測試的效率的同時提升了裝置指紋的穩定性；

2）裝置指紋的自動化：裝置指紋自動化採用 UI 模擬方式進行自動化，自動化有主控 master 透過分發的形式，把測試任務下達給每一臺裝置，最終形成分散式的執行自動化的效果，大大提升了自動化的執行效率，同時也提升了裝置指紋的裝置相容性；

3）介面測試篇：風險系統偏底層服務居多，決策業務的是否有風險之本。在風險側展開介面自動化是為了更好的支撐業務，同時也是為了保障質量。為了響應公司的號召，為了達成支援業務最大化，今年開始陸續把自建的平臺關閉，關停了一些 ROI 低的工作，把相關的業務自動化測試用例，陸續有條不紊的遷移到更佳優秀的介面測試平臺上，把自研開發平臺的人力加到業務支撐，介面的自動化今年覆蓋度從年初的 18% 到年中的 40% 左右，實現了主流程鏈路的覆蓋，業務使用率達到 32% 左右，從行雲裡的資料來看，上半年無論是從測試交付的週期還是吞吐量都有較大的改善，真正的做到了自動化賦能業務，業務交付顯著增長的結果；

4）精準評估需求影響範圍：需求評審、以及測試用例的評審是拉齊研發，測試，產品對需求認知的一場不錯的會議，所以今年 P0P1 級別需求都要求強制用例評審，評審用例的同時，把大家的資訊拉通，達成一致；今年，在需求評審會里，增加了一個環節，就是透過我們自研的針對增量程式碼的（本次需求）鏈路分析，以及影響的方法範圍，產出一份血緣關係圖，在需求評審的同時，可以精準的圈定影響的範圍，讓影響範圍更加量化，可度量；

5）度量測試質量：作為質量負責人，更關心的是如何管理好質量，那麼質量團隊每個人測試質量的好與壞，或許也是需要度量，可把控；今年推進測試程式碼覆蓋率的執行，透過位元組碼的方式，在測試人員執行用例的同時，可以精準的定位出來，測試用例覆蓋程式碼的行數，來評估測試是否都覆蓋全面，事後知道可度量，可追溯；

6）策略測試自動化：策略測試是風險側獨有的一種測試場景，策略是分析師長期積累的結晶，精華，是風險人的智慧，策略質量的好與壞是對系統有牽絆的。今年透過與策略效能組共建測試平臺，達成了從策略包測試，自動生成案例，再到策略包介面的流量複製，透過線上天然的流量驗證策略配置的準確性，已經形成了一套方法論並落地，今年會加大推廣力度實現策略測試一體化，平臺化，智慧化；

7）混沌工程：混沌工程為大促而生，今年 618 非同尋常，主戰場為線上線下相結合，在各種的不確定性中我們尋求系統的更加的穩定，健壯。今年引入了混沌工程，把一些核心依賴介面的超時，快取異常，DB 當機，伺服器資源各種異常模擬復現，預知了系統風險，大促穩中求穩，不斷求新；

8）UI 自動化測試篇：UI 自動化歷經數年，UI 自動化已經相對穩定，但業務的日新月異，對前端的不斷變更，對 UI 自動化運營是個不小的難題。綜合看，風險測的 UI 自動化達成的主要是不頻繁修改的，主流程的，達成覆蓋度 100%。非核心場景的，經常變更的，由手工執行，做好 UI 的用力分層，分類至關重要；

四、質量卡點與風險識別，求全面，求質量

設定質量卡點，是質量體系的線上化的一種方式，說的直白點就是把風險側質量體系相關的規範準則，透過線上化的形式，設定卡點或者實時預警，透過卡點或及時觸達來規避流程、操作風險等

質量卡點是我們重中之重，組之大器，紅線，底線，不可逾越。今年我們最佳化了多處準則規範，為了增強大家的質量意識，形成有效的規範規則，有效的保障質量。

1）上線監控：無論是 Jone、jdos、JCI 上線都需要走嚴格的審批上線，杜絕順風車，AB 異常審批，不經過測試等等上線審批異常行為，透過把 JDOS 審批流資訊接入風險洞察系統，配置了相關的實時監控，把異常行為監控一覽無餘，杜絕踩踏質量紅線

2) 效率監控：測試交付的效率，交付的吞吐量是度量測試效率的重要指標之一，需要實時的發現問題，解決問題，做到每一個需求，每個人資料透明化，今年也是把效能交付週期配置了相關預警，當交付週期長時，相關的預警會觸達效能小組的相關人，告知效率風險，有人對應跟進分析，給出結果；

3）缺陷與用例監控：測試用例，缺陷都是測試人員的產出物，透過監控分析這些資料，對以後識別系統好與壞，以及測試人員執行的情況最有利的支撐。

4）核心系統上線評審：核心系統上線評審是對系統上線的敬畏，今年核心系統上線，我們都會組織架構師、負責人等相關干係人一起評審業務，程式碼，以及影響範圍；增加一道上線評審，規避質量風險發生；

5）測試用例強制評審：需求評審、以及測試用例的評審是拉齊研發，測試，產品對需求認知的一場不錯的會議，所以今年 P0P1 級別需求都要求強制用例評審；

6）配置相關風險：配置變更、遷移變更、規則修改、策略變更等等，配置類的釋出是最容易忽視的區域，也是今年要納入測試的範疇的點，配置要經過測試並透過審批流程後方可上線；

7）排期風險：資源投入、倒排期、外部依賴、缺陷處理時間等等，都需要我們關注，要保證專案需求進度無風險，按時交付，力保業務；

8）安全合規風險：資料洩露、洩露使用者資訊、誘導使用者、敏感資料等等都是風險合規的重中之重，需要我們在測試業務的過程中識別出來這種風險，提出風險，規避風險；

9）客戶自損類風險：風險策略攔截、企業授信放款、AB 系統銜接、規則漏洞等等都會產生相關的風險，在系統層面把控風險尤為重要

10）系統風險：系統上線風險、系統不穩定、效能不達標、依賴介面異常等等，在功能測試後，要全面評估系統的影響面影響 的種類，提前做好預發預案；

還有未考慮到的方面，歡迎大家補充交流