銀行核心項目之測試階段

• 2019 年 10 月 6 日
• 筆記

最近有小夥伴留言說「想了解核心系統建設中，冒煙、SIT、UAT、回歸測試的重點，如何設計測試案例，或相關的資料推薦等」。

這個話題很籠統，測試這一塊兒除了業務測試，還有性能測試、安全測試等；以及不同的角色對案例的要求也是不一樣的，比如：行方業務人員喜歡寫將交易從頭到尾全部跑一遍的案例，而測試公司的人員喜歡寫的很細碎等等。

對此，因為沒有經過正規的測試方法訓練，主要是說說我的個人理解或感受吧。順帶總結了一些最關鍵的基礎知識和朋友的實際經驗，分享給大家，讓更多人能夠找到方向。

1、此文適合人群：

銀行從業人員、業務人員、測試人員。

2、此文解決問題：

對剛接觸銀行業務的測試人員來說，通過學習有助於系統的理解銀行系統相關的測試知識，對日後的工作有一定幫助。

3、此文分為四大部分：

一、銀行測試的主要任務

二、銀行測試的分類和依據

三、銀行測試的案例設計

四、銀行測試執行要求及準則

1

銀行測試的主要任務

銀行作為大家的理財顧問，對金錢非常敏感，頻繁甚至偶爾出現的軟件故障都會打擊顧客的信心，如果來個黑客攻擊，個人財產受到威脅，銀行也必然蒙受損失。所以銀行對系統的質量要求非常高，追求功能穩定、性能可靠、安全性高、最終達到客戶信任，保證銀行和個人的財產的完全。

而保障系統高質量的前提是測試，測試是整個核心項目中非常重要的一個階段，所以測試人員的角色很重要。就先從測試階段的主要任務說起。

（1）測試規則編寫

測試規則是通過分析需求得出來的，是對原始需求進行分析找到需要測試的要點，是測試工作的第一步。一般由中、高級測試人員編寫測試規則，寫的越詳細越精準，就表明對所測業務越了解，更容易發現系統問題和業務問題，更能把握測試的質量和進度。

若是測試需求分析的不明確，那麼測試規則的要點就不清晰，測試案例的編寫更是毫無根據。可能會造成時間或資源的浪費、測試工作量評估不準確，導致項目延期。那麼，該如何提升需求分析能力？

首先，通過閱讀需求文檔了解需求的實現背景、了解需求的目的和用戶使用的場景，在這過程中遇到疑惑先記下來，與業務多交流從而儘快熟悉業務知識；其次是分析需求的合理性，站在用戶或業務的角度進行分析、理解、思考，給需求或開發人員一些設計上的建議，避免被慣性思維束縛；最後，充分利用身邊或網絡上的學習資源，比如好的博客或公眾號，學習前輩的經驗並運用到實際工作中去。

我們再回到小標題，關於測試規則的編寫，對於初級測試人員來說，前面是模仿，照着有經驗的人寫出來的案例跟着寫。後續加上多學習、多思考、多總結和分享，需求分析能力會有非常大的提升，後面慢慢也就能流暢的編寫測試規則了。

測試文檔不需要太複雜，直接使用excel編撰就可以了，我們以核心系統存款模塊的定期部提交易為例，請看下圖：

（2）測試案例編寫

早在開發人員在設計和編碼的同時，測試人員就已經在不斷的細化和調整測試計劃，並完成測試案例的編寫。測試案例的編寫其實就是根據上述的測試規則，細化出具體的測試案例，包括測試目標、測試環境、輸入數據、測試步驟、預期結果等。

但關於測試要點細化到什麼程度，是一個度的問題，我們要把握好測試點細化的一個度的問題，太粗的測試點沒有指導意義，太細的測試點容易讓我們糾的太細，忽略整體的測試，反而也起不到一個指導的效果，所以一定要把握好測試點細化的度。那作為新手入門，都會遇到哪些問題呢？

比如，很對人不知道如何開始書寫測試案例，但遲遲不敢下手寫測試案例的話，又擔心影響整體的測試計劃因為自己的延誤而受影響。對於前怕狼後怕虎的心態，建議是不要顧慮自己的案例好與不好，先寫下來；或者是參考以前寫好的公共測試案例，甚至直接引用，這樣既可以避免一些不必要的時間浪費，但是參考不等於照搬，在引用的同時，也一定要思考本次需求自己特有的測試點。

其次，測試案例都會參加案例評審，有資深測試人員和業務人員進行把關，測試案例中的問題會被發現，評審人都會給每個人修改意見。所以，安下心來寫出自己想到的測試案例，這樣才能幫助發現問題從而更好地解決。

還有就是，每個人的測試案例都不能說完美全面，都是在不斷地評審過程中盡量的做到全面一些，覆蓋率高一些。不過老員工畢竟經驗和閱歷要比小白多，所以在寫測試案例的過程中，肯定有一套合適的方法。接下來，我們以手機銀行開立定期整存整取為例子，分享一下乾貨，讓所有測試的「巧婦」有米為炊。

（3）測試案例評審

測試案例編寫完成後，測試經理就會組織測試案例評審，也就是對測試案例進行檢查。時間一般在開發人員將交易或功能送測之前，行方業務或科技的主要干係人都要參與評審，一條一條的過案例，再次確認大家對需求的理解是否一致。測試案例評審是測試流程中極為關鍵的一環，案例評審何為如此重要？

首先，通過測試案例的評審不僅可以消除產品、開發、測試三方對需求文檔理解的偏差，還可以保證測試內部人員，即測試執行者和測試案例設計者在測試質量保障方面保持一致性；

其次，通過測試案例評審，產品和開發可以通過對案例合理性和全面性進行評估，指出案例設計不合理或遺漏之處，以便更好的完善測試案例，提高測試案例的質量。

再者，如果囿於各種限制條件導致開發無法展開技術評審會議，那麼在案例評審也可以和開發溝通確認實現方式，關注不同實現方式的測試點，以實現全面測試；

最後，常言道，測試人員是項目的前燈，是一個探路的角色，所謂良醫治未病，那麼測試人員就應該在項目前期多挖掘潛在的坑，並提醒開發注意，慎防掉坑，同時也降低了bug出現的概率，減少開發測試成本。

所以，因為很多需求的細節無法在需求階段考慮完全，就會採用反覆溝通的方式與相關人員不斷細化，一般來說，這樣評審會反覆三次左右，以便完善案例。後面基本都會因為項目排期太緊或是需求變動次數過於頻繁， 而對案例進行選擇性的快速評審。

（4）冒煙測試

測試案例評審通過，待開發提交測試以後，測試人員迅速完成一輪「冒煙測試」。冒煙測試的目的是為了確認基本功能是否正常，可以進行後續的正式測試工作，將正式測試未知的風險降至最低，防止bug阻塞導致測試進度阻塞。不過也有項目是評審到一半的時候就會開始冒煙測試，邊評審邊冒煙。

站在核心開發組的角度，一般在通知測試人員冒煙測試之前，開發組內部會提前進行一些交易的驗證，特別是在遷移冒煙測試階段，各方領導都特別關注，因為遷移冒煙出現的問題直接影響到UAT的開始時間或是能否如期投產。所以基本都是發現如果存在問題，是要求即時解決，馬上驗證，或是當天內解決，並且會有項目助理持續跟進，逐個確認、收集反饋等。

另外，關於冒煙測試案例的建設，有兩點建議：一是測試案例管理員與開發經理溝通確認新增功能點；二是確定原有案例中有哪些在新項目上仍然有效，刪除不再適用的測試案例，由此建立一套新的測試案例。

（5）功能評審

在測試人員開始執行測試案例的同時，業務人員會組織一次「功能評審會」或是叫「演示會」，利用測試環境，把可以使用的功能在第一時間展示給相關干係人，更進一步確保做出來的東西就是大家想要的。

（6）測試

接下來，測試人員會做多輪測試，是一個「發現Bug，開發修復，複測，發現新Bug」的循環過程，從第二輪開始就可以叫做「回歸測試」，經過多輪測試後，項目會要求行方各用戶代表做更詳細的UAT。

一般來說，在SIT末或進入UAT初期，是缺陷最多的時候，也是開發人員最難熬的時間段（個人感覺，不知道測試人員在此階段是啥體會）。

在這段時期會遇到各種問題，比如參數不一致、功能反覆修改後仍與需求不一致、打印輸出字段不對、版本沒管理好導致測試成功的案例出現複測失敗、解決一個bug導致出現新的bug、解決時間超期、以及夜間批量各種報錯、是不是有人催進度等等，讓人應接不暇，手忙腳亂。

其實越來這種時候越不能急，越到淡定，天大的bug也得挨個處理。調整個人狀態和做事的方法，挺過這段時期，後面就會好很多。當經過多輪UAT測試，在Bug都處理處理妥當之後，會進入UAT收尾、程序版本封板、參數核對及封板、演練及投產準備工作等。

此時，商業方面的準備工作也早已動起來了。業務人員可能要準備面向用戶的功能、買點介紹的文檔，產品更新的公告；培訓服務人員和銷售人員；運營人員可能已經在策劃推廣方案；銷售人員可能在更新銷售說辭······多個部門協同，很有大家在一起戰鬥的感覺。

★名詞解釋

冒煙測試(Smoke Test)：可以理解為該測試耗時短，僅用一袋煙功夫足夠了。也有人任務是形象地類比新電路板基本功能檢查。任何新電路板焊好後，先通電檢查，如果存在設計缺陷，電路板可能會短路，板子冒煙。

UAT(User Acceptance Test)：用戶接受度測試。當然，更好的做法是直接讓用戶來測試。

驗收測試(Acceptance Test)：指除了把系統所有功能、性能概要測試一遍之外，還需要檢查項目交付物，比如項目階段文檔、用戶手冊等是否齊全、是否符合規範。

回歸測試(Regression Test)：修改的代碼部署版本後，複測之前的出現的BUG、驗證版本的正確性。往往一個系統上線，都要經過多次回歸，有的公司採取多輪次，第一輪、第二輪、第三輪等，都是回歸測試的展現形式，只不過每輪次（回歸）的測試重點不一樣。

Bug：指缺陷或故障，區別在於項目上線之前發現的叫缺陷，項目上線之後發現的叫故障，通常故障會對用戶造成傷害，團隊里也針對故障制定了分級制度，針對責任人制定了相應的懲罰制度。

2

銀行測試的分類和依據

在計算機行業，開發人員在實際的開發工作中會有自己涉及的主要領域，cobol,java,python,php,C等。測試人員也一樣，因此銀行測試的分類是有很多種的，按測試的內容可以分為：功能測試、性能測試、安全測試和其他性質。

（1）功能測試

功能測試可以分為模塊功能測試、業務功能測試、場景功能測試和報文功能測試。我們繼續以手機銀行整存整取功能為例：

模塊功能測試，如增刪改查、下拉框的選擇、值域的輸入、點擊按鈕後的反應；業務功能測試，如定期轉活期功能測試；場景功能測試，如定期存款流程、提前銷戶、提前部分支取，將業務功能串成一條；報文功能測試，如與支付系統或核心系統交互報文測試。

（2）性能測試

功能測試可以分為大容量場景測試、端對端並發測試、加擋板測試、業務壓力測試。

（3）安全測試

安全測試可以分為報文加密測試、密碼安全測試、穿透測試（防火牆）、通道傳輸安全性測試。

（4）其他性質

其他性質分為系統測試、硬件測試（POS機，智能櫃檯）、周邊測試（ATM）。

接着我們聊聊測試的依據。

測試的依據可以分為六點：1.銀行業務規則，如《銀行支票中關於中文大寫的相關規定》；2.業務場景要求，如轉賬業務場景；3.會計記賬規則，如借貸記賬法；4.中央銀行下發的各種文件，如人行《關於落實個人賬戶分類管理制度》；5.各需求文檔輸入，如定期存款功能書；6.其他，如系統原型等。

3

銀行測試的案例設計

（1）案例設計分類

（2）要求及準則

（3）注意事項

4

銀行測試執行要求及準則

（1）測試執行要求及準則

1.執行要嚴格依照業務場景和業務流程進行。

2.所採用的測試數據一定是可靠的、完整的數據。

3.測試執行結果數據一定是正確存儲，且計算正確的。

4.執行後特別注意證跡的核對及保留。

5.測試執行過程中一定需要考慮不同用戶實際操作情景，且一定需要在執行時涉及不同機構、崗位、密碼等權限控制的控制情況。

（2）執行注意事項

1.嚴格依照案例執行，保證測試和案例內容的一致性。

2.測試數據是依照業務流程做出來的可靠、有效的數據，非手工添加的隨意性數據。

3.批處理交易重點在於被處理的批量數據的狀態變化、計算變化以及遷移正確性等。

4.特別注意與案例中的預期結果不一致的問題。

5.儘可能的安排交叉測試。

結束語

早前還有小夥伴提出想從測試轉開發崗或需求崗，我覺得主要還是要看自己擅長或喜歡哪方面。比如擅長溝通或協調，那做需求比較好；再如喜歡轉眼技術，那轉到開發崗能更好的施展拳腳；又如擅長逆向思維、善於發現主幹之外的異常和分支，那麼做測試就非常好。關於測試的話題就先聊到這，感興趣的小夥伴可以關注，有機會可以擴展一下。

參考文獻及注釋：

1.《測試用例設計總結》

2.《測試大佬對功能測試的總結和反思 》

3.《ATesting分享會-銀行業測試 》

文章轉載自公眾號 小代嘚吧嘚 ， 作者 代堂鳴