本文選自《金融電子化》2020年1月刊
作者：中國銀行軟件中心深圳分中心 萬芳
數字技術正在改變人們的金融消費習慣。隨著數據化進程的深入，互聯網金融產品如雨後春筍般湧現，對傳統銀行的支付結算和中間業務造成了不小的衝擊，傳統銀行為了快速滿足客戶不斷變化的多元化需求，如何進行敏捷可靠的架構之變？其中所用到的一些自動化測試框架工具，作者深入敏捷轉型項目開發過程中自動化軟件測試，希望通過本文拋磚引玉，拓展自動化測試思路，找到適合自身特點，安全可靠的自動化測試方法。
現狀分析
俗話說：“工欲善其事、必先利其器。”，工具對於開展自動化測試的重要性自不待言，對自動化測試人員有三方面的要求：
一是提升編程技巧。做為測試工程師要掌握一些高級語言，腳本語言，類似以java為重點phython等，如果常用web自動化測試，則考慮jsp、php等是必須掌握的。
二是具備系統與數據庫經驗。因為軟件自動化測試是構建在操作系統上的，需要用到操作系統技巧，例如：註冊表、環境變量、句柄等，同時也要善於利用數據庫知識去實現存儲及數據管理。
三是熟悉業務流程。掌握所從事的金融業軟件行業知識，需要加深瞭解銀行會計及國際結算等業務知識，在ISO及CMMI質量體系中，做到有章可循。
方法設計
自動化測試理念與軟件設計模式類似，作者深入到具體項目去學習。例如：java軟件界面測試（RFT、QTP的java插件等）、web界面測試（QTP、selenium等）、性能測試（loadrunner等）。入門先學工具，編程也是一項重點學習內容。建議從已經開展自動化測試的項目入手，則自動化測試入門會很快的。深入理解並掌握拓建自動化測試框架，性能測試關注環境構建方法，以及對測試結果的分析方法，性能測試關注分析和實現過程。
1.確定測試類型。首先我們要明確了自動化測試類型，定位好類型才去選擇用哪個自動化測試工具？測試類型包括：白盒測試、黑盒測試以及壓力測試、性能測試等。
2.選擇測試方法。不同的測試類型所選擇使用的自動化測試方法不同，例如，白盒測試主要針對代碼級的單元測試，黑盒測試主要面對用戶功能級和系統級的驗證測試。
3.人員技能要求。自動化測試要有一定編程基礎，能編寫測試代碼。功能測試分基於API和GUI的測試；基於API的測試，即應用腳本技術向設備模擬發送API請求，以達到控制設備的效果。基於GUI功能測試，即應用傳統的界面自動化測試工具如：RFT、QTP等控制界面控件操作的方法，以達到模擬用戶操作，這都需要有一定編碼基礎；基於API需要懂腳本技術例如:python等，RFT需要懂java或者.net等。像常用的loadrunner性能測試工具，測試軟件性能，例如多用戶操作等性能，也需要寫代碼，LR腳本支持的語言有：java、c、VB。默認的腳本生成語言為C；需要掌握其性能測試的方法很重要的。
應用架構
敏捷自動化測試特點是：高效+深入+協作，敏捷自動化測試所需條件比常規瀑布式開發項目標準更嚴格。作者參加了消費金融項目一個多月的封閉開發，這是涵蓋某銀行個人貸款審批、貸後管理、授後變更等業務，在敏捷項目試點過程中，使用到的自動化測試工具如下所示：
1. 代碼複查及監控。Jenkins任務調度+Sonar代碼質量平臺+PMD、Findbugs、CheckStyle、Jacoco靜態代碼複查工具。sonar是代碼質量平臺，不做代碼分析，可集成加載插件，從JENKINS調起MAVEN構建，成功後則用MAVEN構建完的執行碼用來跑JUNIT，接著調用soanr，使用插件如，checkstyle，pmd，jacoco（javacodecoverageLibrary覆蓋率工具可以嵌入到ant、maven中），findbugs代碼靜態分析工具，Sonar、Jenkins這些第三方的工具提供了對代碼靜態分析工具的集成。
我們通過命令調用sonar，在jenkins控制檯看到插件使用情況，多個批次並行開發，指定代碼存放的版本管理庫地址，開展源碼管理。配置好構建觸發器，以便於下班後的自動構建。
2.Junit單元測試。Jenkins任務調度+Maven構建+Junit單元測試框架。
3.接口功能測試。Admitester接口自動化測試工具，簡稱AD。
4.RFW界面WEB測試。UI是用戶界面的簡稱，RideRIDE是圖形界面運行測試的軟件。RobotFrameworkRF（簡稱RFW）框架，基於UI的自動化，RFW框架編寫基於web用戶界面的測試用例。RFW在用戶需求有變化時，已創建界面用戶功能測試案例需頻繁修改，為了規避此風險，項目組做法是：等到下一個迭代再完成編寫上一個迭代的測試案例，只測已穩定功能，即迴歸測試。若跟著迭代並行開展自動化測試，則會耗費大量人力。
圖 1 自動化工具
實踐改進
在封閉期間，組織逾百人並行開發，利用持續集成方法和自動化測試平臺，有效隔離了並行開發的相互影響,積累了豐富的敏捷實踐經驗。深入開展了新工藝方法及敏捷開發中的持續集成實踐，取得了顯著成果，且在短短一個半月內多批次測試案例的並行，圓滿完成任務。作者根據實施敏捷開發項目的現狀，提出三處可改進點。
一是維護成本大。項目成員剛接觸自動化測試工具，邊實踐邊學習，難度高、進度緩。加上系統功能點邏輯複雜，功能點案例編寫難度大，界面測試案例維護成本大，隨著業務需求不斷變化，版本快速迭代，維護案例越來越困難。
二是體系待完善。由於未搭建單元及組裝測試的敏捷內部自動化測試體系，加之自動化測試工具尚在完善，測試人員對於相關功能掌握不夠透徹。
三是缺陷時效性差。實現的自動化測試不是測試驅動，只是對穩定版本回歸測試。自動化測試進度滯後，加上批量等重要的模塊未開展自動化測試，無法快速響應迭代版本帶來的影響，不能及時發現系統缺陷。
消費金融項目伴隨著敏捷轉型，資源實驗快速分享，通過掌握自動化測試的方法，編寫了培訓手冊例如《AD自動化測試工具擋板使用》《AD案例開發說明手冊》《JUnit單元測試自動化案例的編寫規範手冊》，完善工具指引並組織內訓。
根據項目中期數據顯示，在批次內部測試工作中，該產品積累案例數自動化測試案例數位列第一，不僅將開發測試人員從日常繁雜重複的手工勞動中解放出來，從事更富創新與挑戰性的工作；而且能夠不斷增強技術底蘊，加大自動化測試工具的應用深度，培養自動化測試人員技能，提高開發測試效率。
自動化測試是提升產品軟件質量的一項重要舉措，推動傳統銀行科技事業的長足進步，只有厚積薄發的測試工藝改進與提升，最終實現技術飛躍。展望未來敏捷自動化測試之路，任重而道遠。
閱讀更多 金融電子化 的文章
