众所周知，日益复杂的系统和日渐严格的用户体验，使得软件测试人员的任务愈发繁重，人工测试投入随之增加，也由于测试技能水平差异，导致软件质量输出不稳，故而，在实际工作中，我们经常会考虑如何把人为驱动的测试行为转化为机器自动执行，做到一定程度上的节流提效，保障测试覆盖度和质量。
苏宁一直致力于自动化测试能力建设，苏宁自动化测试工具（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 该方案具体实现过程：
用户从 Web 端选择执行终端，发起入参或数据处理请求作为开始；
Web 应用服务器接到请求后，判断终端类型：公共远程的 Agent 还是本地个人 PC 终端，并检查是否空闲，连接并锁定空闲终端；
按步骤 2 锁定终端后，从服务数据库的指令库里获取执行指令，通过 Socket 协议进行指令传输；
根据指令检查基础环境和待执行脚本 / 程序版本检测是否是最新，若不是，执行自动更新指令获取最新版本，更新后进入下一步骤；
在步骤 4 就绪后，执行传入待执行数据指令传输给 C 端并开始调用 SAP 自动化脚本；
将执行结果通过 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 自动化实操
我们先看结果，实操部分日志如下：
通过日志可以看到：
从开始连接 SAP 到执行生成 5 个凭证共耗时 97 秒；
分别执行 GXQ、TXQ 两套 SAP 系统；
涉及 SAP 操作有：数据接入检查、生成凭证操作、凭证结果校验、返回 Web 页面展示、凭证截图、过程 log 展示等。
以下是我们对该记账场景的实践过程的展示，如图 1 是涉及的前台 WEB 页面，发起执行请求，图 2 是实现过程动态效果。
图 1
图 24.3 结果分析
以上操作均可做到系统自动检查校验准确且完整，实际人力投入减少近 10 倍。
SAP 自动化执行效率比人员手工执行检查提升 5 倍以上。
测试人员操作更简单直接，执行效率高；执行结果无需切换系统查看，查询更直观；让机器替代测试人员检查及整理执行结果，问题定位和反馈精准，人力资源消耗成本降低。
五、总结
不得不说，自动化的初始成本非常高，从开始决定要解决这个交互问题，到实际框架落地和产品设计，再到最后代码实现和项目应用，我们测试开发团队共耗费 60 多人天，历时 2 个多月，但随之带来的收益也相当可观，经初步测算，近一年为我们团队节省近 5000 个工时。
从技术上来讲，单纯的通过 Python 代码实现 SAP 自动化并非难事，困难的是如何将 B 端与 C 端实现自动交互，并将 Web 应用的执行指令正确传达给 SAP 系统执行。在我们实现解决方案中，通过依赖 socket 通信自建接口和服务功能解决了最直接的交互调用问题，解决了本地或远程 Agent 终端调用问题，实现了建立指令库进行模块化管理，实现了持续迭代、自动部署脚本功能。
仲崇瑞，苏宁科技集团员工平台研发中心高级测试经理，有多年的业务及产品设计经验和测试管理经验，负责苏宁财务核算、财务共享、税务会计及智能应用等产品的测试及管理工作，涉及功能、性能、自动化、安全等测试领域，带领团队多次出色完成财务系统变革和切换的测试工作，致力于构建苏宁财务类自动化测试产品解决方案，打造高效便捷的测试应用产品。
为你推荐
