人力投入少 10 倍：蘇寧 Web 應用與 Client 的自動交互實踐

眾所周知，日益復雜的系統和日漸嚴格的用戶體驗，使得軟件測試人員的任務愈發繁重，人工測試投入隨之增加，也由于測試技能水平差異，導致軟件質量輸出不穩，故而，在實際工作中，我們經常會考慮如何把人為驅動的測試行為轉化為機器自動執行，做到一定程度上的節流提效，保障測試覆蓋度和質量。

蘇寧一直致力于自動化測試能力建設，蘇寧自動化測試工具（Suning Automation Tester），簡稱“SAT”，基于 JAVA 語言實現，采用自動化測試架構中的關鍵字驅動（Keyword）思想，使測試設計和測試實現分離，將實現不同公共組件類、業務類 Keyword 集成到一個用例中運行，也最大限度地實現 Keyword 共享，降低測試組重復開發的工作量；從 13 年開始逐步實現集 WEB 頁面、HTTP 協議、手機終端應用、數據庫操作、LINUX 操作等方面的測試能力支持，產品已相當成熟。

本文涉及到的技術實現不再依賴 SAT 工具，而是基于 Python 語言實現的 Web 應用與 Client 應用的交互，主要結合數據驅動、結構化、關鍵字驅動等腳本技術思想，進而設計的完整交互方案。

該方案根據我們實際產品框架的情況定制設計了自動化測試框架，主要實現了業務數據交互，執行指令交互，任務執行交互，終端調用管理，腳本版本管理等，在腳本復用、迭代及代碼健壯性上都有極大提升；除實際業務數據外，其他均實現配置化，更容易維護，也可根據業務變化自由配置規則。以下就具體闡述我們的實現過程。

一、我們的目標及現狀分析

1.1 我們的現狀和目標

在介紹我們的目標之前，先通過圖 1 了解簡化版產品應用框架（實際產品框架遠比此圖呈現的復雜）、人工測試及自動化測試平臺之間的關系，特別說明 SYSTEM-A 和 B 均是無 UI 界面的底層應用系統。

因為產品應用架構中存在一些系統是屬于 B 端底層應用服務器的應用和 C 端的 SAP 系統，根本無可視化 UI 界面提供，測試人員只能被動接收這種無 UI 界面的底層應用和 C 端的測試，測試的入口是某個數據接收的接口，但測試結果檢查過程復雜且繁瑣，人工測試要花費大量的時間在底層應用上測試。

所以，我們的目標是要實現 B 端 Web 應用系統與 C 端客戶端應用兩套系統之間的交互，以解決底層應用檢查繁瑣以及與 C 端交互數據的處理等問題，實時監控測試數據處理過程和結果，具體來說，Web 應用與 SAP 系統之間自動化調用和檢查。

1.2 我們在用的系統

自動化測試平臺系統（testingland），是測試開發團隊完全自研的 Python 語言編碼實現的 B/S 架構系統，為重要產品線提供定制的自動化測試框架及服務，為 B 端和 C 端系統間自動調用交互搭建了橋梁，也作為測試入口進行自動化測試實施。

SAP，眾所周知，既是全球企業管理軟件與解決方案的技術領袖的公司名稱，又是其產品—企業管理解決方案的軟件名稱；而我們團隊所對接的是 SAP R/3 系統，涉及財務 FI、CO 模塊的賬務處理。

1.3 我們的調研結果、驗證和分析

現將 C 端 SAP 系統部署在 OS 為 Windows 系統上，如何實現 B 端 Web 應用調用 C 端客戶端的自動化操作呢？

調研結果

基于 1.1 提出的目標，經過調研，當前業內有兩種常用的方案：

• 方案一：通過 IE 的 ActiveX 直接調用本地客戶端，無需配置注冊表，但只僅限支持 IE；
• 方案二：通過 Url Protocal 協議調用本地客戶端，支持大多數常用瀏覽器 (Chrome，IE，FireFox 等)，但需要配置一系列的注冊表信息；

驗證經驗證，這兩種方案進行直接調用客戶端軟件，都只是簡單的打開本地軟件而已，是不能讓軟件自動執行后續操作的，例如：讓 SAP 自動記個賬，并把結果返回給 Web 端。除非 SAP“成精”，否則單單是打開 SAP，它是不知道你要干什么并自動操作自己的。

分析

從以上兩種方案來看存在的一些問題，首先，缺乏可持續性的執行，其次，不靈活，只支持本地，不支持遠程 Agent 終端，也就是說，要打開客戶端，必須先在同一臺機器上打開某個瀏覽器。

針對以上分析結果，我們需要設計新的方案去解決以下問題：如何在 Web 端自動化操作 Windows 客戶端，而不是單一啟動？如何自動操作本地或遠程 Agent 終端？

二、我們的解決方案

針對上述問題，設計了一個自動化應用框架（見下圖），作為 Web 應用與 SAP 系統定制的自動化實現解決方案。

該方案不僅解決了自動啟動 SAP 系統、后續的關聯系統操作和檢查，而且實現了用戶自主配置 Agent 信息以及自主選擇本地或遠程操作 Agent 終端，還增加實現了持續迭代、管理、應用以及執行自動化腳本，同時也做到了對結果實現閉環檢查和展示。

2.1 該方案具體實現過程：

1. 用戶從 Web 端選擇執行終端，發起入參或數據處理請求作為開始；
2. Web 應用服務器接到請求后，判斷終端類型：公共遠程的 Agent 還是本地個人 PC 終端，并檢查是否空閑，連接并鎖定空閑終端；
3. 按步驟 2 鎖定終端后，從服務數據庫的指令庫里獲取執行指令，通過 Socket 協議進行指令傳輸；
4. 根據指令檢查基礎環境和待執行腳本 / 程序版本檢測是否是最新，若不是，執行自動更新指令獲取最新版本，更新后進入下一步驟；
5. 在步驟 4 就緒后，執行傳入待執行數據指令傳輸給 C 端并開始調用 SAP 自動化腳本；
6. 將執行結果通過 Socket 服務傳輸給 Web 服務器和前端展示。

2.2 具體問題的解決方案

首先，解決 SAP 客戶端啟動和后續操作的問題。

在 Python 中，我們可以通過 selenium 操作瀏覽器，可以通過 win32，SAP-API 操作 SAP（值得一提的是，SAP 對自動化操作支持非常友好，比如 session.findById 的使用），也能通過 pywinauto 操作常規的客戶端。

在本方案里，通過 Python 腳本代碼實現對客戶端的具體操作：使用 Python os 模塊執行 cmd 命令和 win32 模塊的方式打開并連接 SAP，當獲取到 SAP 窗口的 session 并進行連接后, 使用 SAP 提供的 API 進行組件的定位、操作 (對于未提供 API 的程序, 可以使用 Python 的 pywinatuo 模塊，通過 title、control 等方式定位其組件進行操作)，這些操作是在 OS 為 Windows 系統上是可運行的，進而形成相應的腳本和執行指令。這些腳本代碼 (或已封裝的可執行程序) 也會自動部署到在腳本 / 程序版本庫中進行管理和使用。

其次，解決遠程操作 Agent 終端的客戶端。

先準備若干臺 OS 為 Windows 的機器作為專用的 Agent 終端，啟動 Windows 代理機器上的 Python Socket 服務，根據 Web 下發的指令自動下載、更新、部署自動化執行程序或腳本代碼到 Agent 機器本地，之后 Socket 服務繼續監聽后續指令的到來，根據不同的指令，自動執行后續的步驟，并將執行結果返回服務器直至在 Web 頁面展示執行結果。

第三，遠程 Agent 終端機器太少或太忙無空閑，怎么辦？

在解決方案中完全支持個人本地 PC 來作為單體終端，只需要提前做一些初始環境準備工作，比如部署相應版本的 Python 軟件及模塊等。

有人就會有以下疑問：那不就和 C/S 架構沒什么區別了嗎？不還是要人工把代碼 / 打包好的軟件部署在本機上嗎？項目的改動導致用戶頻繁變更自動化程序帶來的弊端不還是存在嗎？放在個人 PC 本地的不是 C 端運行程序，而是一個已封裝的 Socket 服務端，與遠程 Agent 終端同理不同端而已?？傊?，無論是公共的遠程 Agent 終端還是個人 PC 終端都是支持自動調用的，服務調用內容和過程參照下圖：

三、我們用哪些主要核心技術

3.1 Socket 服務

利用 Python socket 模塊實現 Socket 兩端服務啟動和定制功能，并連接 B 端 Web 應用與 C 端 SAP 系統，使用 pyinstaller 進行打包封裝。

Socket 服務提供方（也稱服務端）功能: 1. 監聽客戶端請求并接收請求數據 / 指令；2. 檢測 / 下載 / 更新自動化執行腳本 / 程序；3. 執行自動化腳本 / 程序并獲取執行結果；4. 返回執行結果給客戶端；

Socket 服務消費方（也稱客戶端）功能: 1. 發送待執行數據 / 指令給服務端；2. 接收服務端返回的執行結果；

通過上圖交互方案中可以看出，在連接時只要滿足服務提供方與服務消費方是一致的 ip 和 port，再設置接發數據格式，就可以啟動相應的消費方服務，最終實現 B 端的 Web 應用與 C 端 SAP 系統的連接。

3.2 進程指令調用

利用 subprocess 調用指令執行腳本，保證 Socket 服務與腳本相互獨立；通過 subprocess 的 PIPE 管道進行傳參以及結果 / 異常的獲取。

3.3 適當運用終端系統的 cmd 或 dos 命令

利用 Windows 系統的 cmd 命令自動獲取 SAP 安裝路徑 / 登錄等操作，安裝路徑獲取具體代碼如下：

# 獲取 sap 安裝路徑os.system("start saplogon.exe") # 打開進程cmd = 'wmic process where name="saplogon.exe" get executablepath' # cmd 命令sb = subprocess.Popen(cmd, shell=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE) # 執行命令

3.4 SAP 腳本編寫

使用 win32 進行連接 SAP 并調用 SAP GUI Scripting API 進行相關自動化腳本編寫；SAP 控件的定位路徑可使用 SAP 錄制的腳本查看，也可使用 Scripting Tracker 工具（Development Tool for SAP GUI Scripting 工具）進行查看。

3.5 整體技術方案

可見下圖，不再詳細贅述。

四、我們對實際場景應用及分析

針對某記賬場景進行實際對比。

4.1 人工測試所需工時

測試人員從打開 SAP 客戶端并登陸開始生成 1 個憑證約 2min，憑證結果檢查約 1min，生成多個憑證會按系統按訂單成倍數增長，截圖并保存整理成 word 文檔約 2min。

4.2 自動化實操

我們先看結果，實操部分日志如下：

通過日志可以看到：

1. 從開始連接 SAP 到執行生成 5 個憑證共耗時 97 秒；
2. 分別執行 GXQ、TXQ 兩套 SAP 系統；
3. 涉及 SAP 操作有：數據接入檢查、生成憑證操作、憑證結果校驗、返回 Web 頁面展示、憑證截圖、過程 log 展示等。

以下是我們對該記賬場景的實踐過程的展示，如圖 1 是涉及的前臺 WEB 頁面，發起執行請求，圖 2 是實現過程動態效果。

圖 1

圖 2

4.3 結果分析

1. 以上操作均可做到系統自動檢查校驗準確且完整，實際人力投入減少近 10 倍。
2. SAP 自動化執行效率比人員手工執行檢查提升 5 倍以上。
3. 測試人員操作更簡單直接，執行效率高；執行結果無需切換系統查看，查詢更直觀；讓機器替代測試人員檢查及整理執行結果，問題定位和反饋精準，人力資源消耗成本降低。

五、總結

不得不說，自動化的初始成本非常高，從開始決定要解決這個交互問題，到實際框架落地和產品設計，再到最后代碼實現和項目應用，我們測試開發團隊共耗費 60 多人天，歷時 2 個多月，但隨之帶來的收益也相當可觀，經初步測算，近一年為我們團隊節省近 5000 個工時。

從技術上來講，單純的通過 Python 代碼實現 SAP 自動化并非難事，困難的是如何將 B 端與 C 端實現自動交互，并將 Web 應用的執行指令正確傳達給 SAP 系統執行。在我們實現解決方案中，通過依賴 socket 通信自建接口和服務功能解決了最直接的交互調用問題，解決了本地或遠程 Agent 終端調用問題，實現了建立指令庫進行模塊化管理，實現了持續迭代、自動部署腳本功能。

作者介紹：

仲崇瑞，蘇寧科技集團員工平臺研發中心高級測試經理，有多年的業務及產品設計經驗和測試管理經驗，負責蘇寧財務核算、財務共享、稅務會計及智能應用等產品的測試及管理工作，涉及功能、性能、自動化、安全等測試領域，帶領團隊多次出色完成財務系統變革和切換的測試工作，致力于構建蘇寧財務類自動化測試產品解決方案，打造高效便捷的測試應用產品。

關注我并轉發此篇文章，私信InfoQ“領取資料”，即可免費獲得 InfoQ 價值4999元迷你書資料包！