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

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

一、銀行 APP 的質量挑戰

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

總結來說，銀行在APP測試中，主要面臨兩大挑戰：
（1）功能測試場景：腳本自動化難、腳本維護複用難、參數管理難
（2）兼容性測試場景：沒有足夠多的機型覆蓋

1.1、功能測試場景

1.1.1、“手工”測試難以應對業務快速迭代的挑戰

• 業務需求多，發版節奏快
銀行業務轉型到手機APP後，APP 成為企業“鏈接”用戶的主要載體，原有PC承載的業務，都需要在短時間內遷移到APP，對研發和測試資源帶來很大的壓力。同時，市場快速變化，存量業務調整和新業務創新探索，也需要保障好質量。為了快速滿足業務訴求，將需求拆分為多個版本，快速發版，已經成為企業的剛需。一個月發一次版本，甚至幾個月才發一次版本，已經無法跟上市場的節奏。
• “人工”測試效率低，覆蓋不夠
傳統模式下，APP上線前主要依託於測試工程師規劃、設計測試用例，然後手動完成測試。但是，銀行業務，通常都是跟“錢”相關，對質量要求很高，業務需要更全面的覆蓋。
銀行類APP，每次需要投入幾十個測試人員來進行測試驗證。一些銀行，在引入阿里雲 EMAS 自動化測試平臺以前，用例自動化覆蓋率只有10%左右，甚至完全沒有自動化，主要依靠人工的方式進行測試，用例多，測試周期長，發版週期也直接受到影響。

1.1.2、模擬業務場景困難

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

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

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

1.1.4、測試知識缺乏數據化、資產化

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

1.2、機型兼容性測試場景

1.2.1、機型多、分辨率多、系統版本多

國內手機廠商，一般每年都有兩次新品發佈會，即春季和秋季發佈會，每年累計有上百款機型發佈，幾年下來，累計的主要機型有上千款。以一個百萬月活的APP為例，iOS 和 Android 兩個平臺一起，通常需要覆蓋Top 150 款以上的機型，才能覆蓋自身80%以上的用戶，而如果想要確保覆蓋95%以上的用戶，則通常至少需要覆蓋Top 500 款以上的機型。
而且，不同的機型、不同的分辨率、不同的系統版本，也會引發更多的兼容性風險。這也是導致金融類Top 10 APP 整體機型通過率不足50%的重要原因。

1.2.2、機型採購有限

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

二、阿里雲 EMAS 解決方案

阿里雲 EMAS 移動測試平臺，針對銀行的「功能」和「兼容」兩種場景，都有成熟的解決方案。
• EMAS 提供私有部署的測試平臺解決功能測試的問題，提升腳本生產效能，保障業務覆蓋率
• EMAS 提供48小時一站式專家測試服務，APP上線前，650款主流機型全量回歸測試，解決機型兼容問題

2.1、功能測試場景

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

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

2.1.1、強大的用例庫

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

功能測試的重點在於用例庫，而用例庫的核心在於如下4點：
• 用例設計
• 用例腳本化
• 參數管理
• 腳本的高可複用

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

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

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

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

自身業務常用能力，也可以自己封裝為固定步驟，變成一個菜單，需要的時候，直接點擊生成腳本。

【圖5】常用步驟菜單

【參數管理】
銀行業務，由於參數有幾百個之多。EMAS 移動測試平臺在數據管理上，主要由兩個大的突破：
（1）在參數傳遞上，支持按變量傳遞，也支持直接傳固定參數值；
（2）為了解決多數據管理複用問題，提供了三層數據管理能力，即：
• APP 全局參數集：例如服務器 ip 地址
• 用例集參數：多用例公用的參數
• 用例參數：單個獨立用例使用的參數

【腳本的組合複用】
為了避免同樣的功能，重複錄製成多份腳本導致的資源和人力的浪費，平臺提供了用例的高可複用能力。

例如，登錄功能，錄製完成一份腳本後，可以作為單步驟，插入到其它業務腳本流程裡，極大提升複用率。同時，由於可以控制傳遞的參數，可以在正常和非正常的測試用例中複用，進一步擴大腳本的複用場景。

【圖6】“登錄”腳本，可以被複用兩次。如果業務功能不變，可以一直複用，跟其他腳本組合，覆蓋更多場景。

2.1.2、特殊場景覆蓋

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

【圖7】隨機密碼鍵盤

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

2.1.3、測試方法論

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

【圖8】“平臺能力”+“人工”的最佳實踐，提升效能

2.2、機型兼容性測試場景

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

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

三、總結

銀行類APP，在版本快速迭代中，面臨功能和兼容兩個維度的挑戰，阿里雲 EMAS 提供了兩個場景的解決方案
（1）功能覆蓋場景：阿里雲 EMAS 平臺可以提供在線錄製、用例管理、參數管理等能力，降低用例腳本化和維護成本；
（2）兼容覆蓋場景：阿里雲 EMAS 提供一站式專家測試服務，覆蓋650款以上主流機型，解決APP的兼容問題。

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