阿里雲移動研發平臺 EMAS 助力銀行業打造測試中臺，提高發版效能

隨着移動互聯網的發展，手機銀行憑藉低成本、操做簡單、不受時間空間約束等優點，正逐步替代傳統的網銀交易方式。愈來愈多的銀行開始了「業務移動化」轉型之路，「手機APP」已經成爲企業價值傳遞和關係維護的關鍵紐帶，客戶爭奪的主戰場已轉向移動端，事實上手機銀行的用戶比例早已超越了網銀用戶。

可是伴隨着銀行APP承載的業務需求日益增多、版本迭代速度不斷加快，以「手工測試」爲基礎的測試體系，已很難知足業務對測試效率和質量的要求。APP 測試急需完成從「純人工」到「人機協同」的範式轉換。

1、銀行 APP 的質量挑戰

銀行類APP所承載的業務，都是圍繞「錢」展開，好比轉帳、理財、支付等核心功能，都不開「錢」。而在實際研發過程當中，在肯定的發版時間約束下，版本實際開發完成後，每每留給測試團隊的時間很短，加上使用人工測試，功能覆蓋面難以保障，且人工測試效率低下，致使版本發佈後問題頻出。Top 10 金融APP測試經過率僅52%，無響應、白屏、顯示異常現象頻出，致使用戶體驗差。

總結來講，銀行在APP測試中，主要面臨兩大挑戰：

（1）功能測試場景：腳本自動化難、腳本維護複用難、參數管理難

（2）兼容性測試場景：沒有足夠多的機型覆蓋

1.一、功能測試場景

1.1.一、「手工」測試難以應對業務快速迭代的挑戰

• 業務需求多，發版節奏快

銀行業務轉型到手機APP後，APP 成爲企業「連接」用戶的主要載體，原有PC承載的業務，都須要在短期內遷移到APP，對研發和測試資源帶來很大的壓力。同時，市場快速變化，存量業務調整和新業務創新探索，也須要保障好質量。爲了快速知足業務訴求，將需求拆分爲多個版本，快速發版，已經成爲企業的剛需。一個月發一次版本，甚至幾個月才發一次版本，已經沒法跟上市場的節奏。

• 「人工」測試效率低，覆蓋不夠

傳統模式下，APP上線前主要依託於測試工程師規劃、設計測試用例，而後手動完成測試。可是，銀行業務，一般都是跟「錢」相關，對質量要求很高，業務須要更全面的覆蓋。

銀行類APP，每次須要投入幾十個測試人員來進行測試驗證。一些銀行，在引入阿里雲 EMAS 自動化測試平臺之前，用例自動化覆蓋率只有10%左右，甚至徹底沒有自動化，主要依靠人工的方式進行測試，用例多，測試周期長，發版週期也直接受到影響。

1.1.二、模擬業務場景困難

銀行業務鏈路一般都很長，不是一兩步就能完成，並且實際業務流程中，涉及到的測試參數多達幾百個。另外，傳統接口測試沒法模擬真實場景，致使測試結果和實際狀況有較大誤差，上線後出問題也是情理之中的事。

1.1.三、業務覆蓋率不夠，上線後問題頻出

實際研發過程當中，測試工程師所測試的版本並非固定不變的，尤爲是進入到發版階段後，幾小時就有一個新版本。面對這種狀況，測試工程師測試重點保障核心業務功能，沒法保障總體用例覆蓋率，這就給版本發佈埋下了隱患，致使版本上線後出現問題。

1.1.四、測試知識缺少數據化、資產化

傳統手工測試方式，主要依靠我的的主觀能動性和過往的經驗積累，實際測試過程當中，一些成功的測試用例場景、測試方法缺少沉澱，難以完成從「我的能力」到「組織能力」的昇華，進而沒法完成組織效能的躍升。

1.二、機型兼容性測試場景

1.2.一、機型多、分辨率多、系統版本多

國內手機廠商，通常每一年都有兩次新品發佈會，即春季和秋季發佈會，每一年累計有上百款機型發佈，幾年下來，累計的主要機型有上千款。以一個百萬月活的APP爲例，iOS 和 Android 兩個平臺一塊兒，一般須要覆蓋Top 150 款以上的機型，才能覆蓋自身80%以上的用戶，而若是想要確保覆蓋95%以上的用戶，則一般至少須要覆蓋Top 500 款以上的機型。

並且，不一樣的機型、不一樣的分辨率、不一樣的系統版本，也會引起更多的兼容性風險。這也是致使金融類Top 10 APP 總體機型經過率不足50%的重要緣由。

1.2.二、機型採購有限

做爲銀行，不可能購買全量機型，並常常更新，一般是購買主流旗艦機型，大概在50款之內。這樣的機型覆蓋度，能夠規避50%左右的用戶兼容性風險，但相對高質量的 APP 還存在很大的差距。

2、阿里雲 EMAS 解決方案

阿里雲 EMAS 移動測試平臺，針對銀行的「功能」和「兼容」兩種場景，都有成熟的解決方案。

• EMAS 提供私有部署的測試平臺解決功能測試的問題，提高腳本生產效能，保障業務覆蓋率
• EMAS 提供48小時一站式專家測試服務，APP上線前，650款主流機型全量回歸測試，解決機型兼容問題

2.一、功能測試場景

阿里雲 EMAS 移動測試平臺提供私有部署輸出服務，主要解決銀行功能測試場景的訴求。私有部署不只知足銀行安全、政策合規的要求，並且，獨享的自動化測試平臺，還能夠基於OpenAPI 聯動 DevOps等其它系統平臺。

【圖1】EMAS 移動測試系統架構圖

2.1.一、強大的用例庫

【圖2】EMAS 移動測試平臺，用例庫立體結構

功能測試的重點在於用例庫，而用例庫的核心在於以下4點：

• 用例設計
• 用例腳本化
• 參數管理
• 腳本的高可複用

【用例設計】

作事以前，先規劃。用例設計就是進行測試以前的總體規劃，會涉及到不一樣的項目組，不一樣的業務線。EMAS 測試平臺提供了「項目組」的概念，能夠有效解決多項目組協同的問題。同時，用例設計落到具體的業務功能上，就要求測試人員在進行總體「用例腳本化」以前，從更高的層面設計總體用例結構，明確規範。阿里雲 EMAS 平臺能夠輸出對應方法論，指導具體實踐。

【用例腳本化】

腳本化即程序化。EMAS 移動測試平臺，提供了在線錄製腳本的能力，能夠不用學習 Appium 框架、Python 或 Java語言，就能夠完成基本用例的程序化，極大下降上手成本。同時，因爲是基於開源的測試自動化框架 Appium 做爲基礎升級改造而成，可用於原生,混合和移動Web應用程序測試，兼容性好。

【圖3】在線錄製腳本-左側是APP頁面，右側是錄製的步驟

【圖4】錄製完成後，能夠錄製回放步驟，左側手機能夠看到實時效果

自身業務經常使用能力，也能夠本身封裝爲固定步驟，變成一個菜單，須要的時候，直接點擊生成腳本。

【圖5】經常使用步驟菜單

【參數管理】

銀行業務，因爲參數有幾百個之多。EMAS 移動測試平臺在數據管理上，主要由兩個大的突破：

（1）在參數傳遞上，支持按變量傳遞，也支持直接傳固定參數值；

（2）爲了解決多數據管理複用問題，提供了三層數據管理能力，即：

• APP 全局參數集：例如服務器 ip 地址
• 用例集參數：多用例公用的參數
• 用例參數：單個獨立用例使用的參數

【腳本的組合複用】

爲了不一樣的功能，重複錄製成多份腳本致使的資源和人力的浪費，平臺提供了用例的高可複用能力。

例如，登陸功能，錄製完成一份腳本後，能夠做爲單步驟，插入到其它業務腳本流程裏，極大提高複用率。同時，因爲能夠控制傳遞的參數，能夠在正常和非正常的測試用例中複用，進一步擴大腳本的複用場景。

【圖6】「登陸」腳本，能夠被複用兩次。若是業務功能不變，能夠一直複用，跟其餘腳本組合，覆蓋更多場景。

2.1.二、特殊場景覆蓋

銀行業務裏面，還有不少特殊場景，好比隨機密碼鍵盤、驗證碼處理、還有一些文字的識別、上傳身份證處理等

【圖7】隨機密碼鍵盤

針對這些特殊場景，阿里雲也提供對應的解決方案，保障腳本自動化的時候，不被打斷。

2.1.三、測試方法論

爲了確保平臺能發揮出最大的效能，基於阿里多年的經驗積累，輸出EMAS 測試平臺最佳實踐方法論。

【圖8】「平臺能力」+「人工」的最佳實踐，提高效能

2.二、機型兼容性測試場景

私有部署的 EMAS 移動測試平臺，側重在功能場景的覆蓋，可是因爲機型有限，也不太可能同時購買幾百款機型。爲了解決機型覆蓋兼容的問題，阿里雲 EMAS 提供了一站式48小時的專家測試服務，能夠覆蓋安卓Top 600款機型，iOS top 70款項機型。

【圖9】48小時一站式專家測試服務

3、總結

銀行類APP，在版本快速迭代中，面臨功能和兼容兩個維度的挑戰，阿里雲 EMAS 提供了兩個場景的解決方案

（1）功能覆蓋場景：阿里雲 EMAS 平臺能夠提供在線錄製、用例管理、參數管理等能力，下降用例腳本化和維護成本；

（2）兼容覆蓋場景：阿里雲 EMAS 提供一站式專家測試服務，覆蓋650款以上主流機型，解決APP的兼容問題。

相關資料：

（1）EMAS 移動測試官網：https://www.aliyun.com/product/mqc

（2）EMAS 移動測試業務說明地址：https://help.aliyun.com/document_detail/93530.html

（3）EMAS 移動測試，聯繫咱們：https://help.aliyun.com/knowledge_detail/101478.html

（4）EMAS 專家測試服務：https://www.aliyun.com/service/mobiletesting

（5）EMAS 專有云服務介紹：https://help.aliyun.com/document_detail/67127.html

（6）EMAS 專家測試服務價格說明：https://help.aliyun.com/document_detail/93617.html

釘釘搜索35248489，加入阿里云云原生應用研發平臺EMAS技術交流羣，探討最新最熱門的應用研發技術和實踐。（或釘釘掃碼加入）