web自动化如何在不同浏览器运行_Web 应用自动化测试系统执行服务

图表 1Web 应用自动化测试系统执行服务架构图

1. 项目背景与意义

随着互联网技术的发展，Web 应用已经对我们社会的各个方面都产生了重大影响。根据 InternetLiveStats 网站统计，当前在线的 Web 应用个数已经达到了 17 亿，并且数量还在快速上升中。Web 应用的架构允许应用每发布一个新版本，其所有用户均能同步升级。为了将应用快速投入市场，开发者常常以多次迭代的方式进行 Web 应用的开发。软件测试作为保障软件质量的重要手段,是每次迭代中关键的一环，因此 Web 应用的测试方法和工具有着很高的需求。目前的一些 Web 应用的测试方法，依赖于人工进行自动化脚本编写或者流程录制。Web 应用每迭代更新一次，脚本可能也随之需要更新，编写脚本花费人力和时间成本高，测试效率低。同时，Web 应用与用户的交互方式随着前后端技术的发展也愈发复杂，Web 应用测试方法和工具必须广泛适配各种类型的应用。

2. 项目内容与技术路线

本文依托于慕测平台，设计了一个 Web 自动化测试系统。本文重点阐述 Web 应用自动化测试系统的执行服务，解决人工脚本编写效率不够高、测试工具需要适配各种类型应用的问题。执行服务采用基于有限状态机和约束的 Web 测试路径生成模型，结合分布式容器技术并行提升探测效率，采用真实浏览器驱动模拟用户操作流程，记录探测过程数据用于最终测试报告生成。执行服务是为系统的报告生成服务和分析服务提供原始测试数据的基础服务。根据功能内聚的设计原则，将执行服务划分为以下三个子模块：测试接入模块、任务调度模块和执行引擎单元。

测试接入模块。此模块是整个执行服务的入口，是整个自动化测试流程的起点。模块使用 Spring Boot 框架提供对外 HTTP 服务接口，接收用户测试任务。根据用户的测试需求，将整体测试任务根据需求划分为不同操作系统不同浏览器下的子任务。在后续的流程中，子任务将以多进程并行的形式启动，通过分布式并行提高任务整体的测试效率。由于整个自动化测试任务执行的时间较长，测试任务结果被设计为通过异步的方式返回给用户。遵循微服务的设计思想，子任务信息将以 HTTP 请求的形式发送给任务调度模块。整个模块最终构建为独立 Docker 镜像，以微服务的形式提供启动测试任务和获取测试结果的对外接口。

任务调度模块。此模块以 Celery 作为任务调度的基础框架。模块接收测试接入模块的测试子任务，并且将测试子任务分派到不同的 Worker 下。任务调度采用 RabbitMQ 作为中间消息服务。Worker 以独立进程的形式并发运行在分布式的系统节点中，通过监听 RabbitMQ 消息队列内容获取测试子任务配置并独立运行。任务调度过程被封装为一个独立的模块，整个调度过程对于测试接入模块和执行引擎集群而言都是黑盒的，方便未来测试集群的横向扩展。

执行引擎单元。此模块将会作为一个独立测试执行单元被构建为一个 Docker 镜像，在任意具有 Docker 服务的宿主机上运行，多个单元构成了执行引擎的集群。同一个任务名下可能存在多个执行引擎单元进程，采用不同浏览器并行探测 Web 应用以便提升测试整体效率。单元容器之间通过 Redis 提供的 SETNX 操作在并行中同步同一任务下单元的数量、测试任务开始和结束信号。此外，Redis 还承担了执行引擎单元与报告生成服务交换测试过程数据的职责。执行引擎单元与报告生成服务交换的数据将会被作为 Web 应用功能、性能、稳定性、健壮性评估的原始数据。执行引擎单元的应用运行在 Selenium Grid 构建的浏览器集群上，使用 WebDriver 控制真实浏览器的方式运行待测应用，因此保证了对使用各种技术构建的 Web 应用进行测试的通用性。

图表 2Web 应用测试路径生成模型

执行引擎单元采用基于有限状态机的 Web 应用测试路径生成模型。如图所示，有向图中的每一个顶点是一个 Web 应用状态，状态信息包含当前 Web 应用所处 URL 和 DOM 内容。有向图中的每一条边是一种可以由用户触发的 DOM 事件，如点击事件、键盘事件等，被视为一次测试输入。可触发事件的元素通过解析每个状态的 DOM 内容得到。因此，在获取 Web 应用初始页面内容后，就可以通过广度/深度优先搜索的方式探索 Web 应用的整体测试状态空间，并在整个执行过程中收集浏览器 Network 数据和 Console 日志、页面文本内容和截图提交至报告生成服务进行下一步的缺陷分析，这些成为了性能、稳定性、健壮性评价所需要的原始数据。Web 应用测试路径生成模型也反映了测试执行过程中的模拟用户交互步骤，将会成为功能和兼容性评价所需要的原始数据。更进一步，将初始状态 Index 到任意状态的路径提取出来，可以指导 Selenium 自动化测试脚本的生成。

3. 项目效益

在整个 Web 应用测试流程中，最简化的测试仅需测试人员填写提交待测网站 URL 即可启动。另一方面，系统也提供了丰富的配置供用户自定义测试流程。

图表 3 执行服务实验数据

执行服务关注于测试任务的执行过程，是生成 Web 应用测试路径，提供测试报告数据和测试脚本数据的关键服务。对执行服务的考察主要集中在面对不同技术构建成的 Web 应用是否具有普适性，能否减少人工介入提高测试效率方面。Web 自动化测试系统执行服务的实验选取了 50 个常见 Web 应用发起测试任务。每个应用的执行设置为：最长执行时间 3600 秒；最大搜索深度(每条路径最大操作数)为 3；任务中可操作的元素为 、、、。

如图 3(a)(b)(d)所示，统计实验的 50 个网站所使用的技术类型，并评估完成的检测状态数和找出的缺陷数。执行服务总体上平均能够探测 89 个状态，找出 83 个应用缺陷。如图 3(c)所示，在测试的效率上，考虑到 Web 应用页面的刷新和数据加载，执行服务能够达到每分钟探测 1.489 个应用状态的速率。该实验结果表明，执行服务不仅能够完全兼容任意技术开发的 Web 应用，而且在人工介入几乎为零的情况下，进行相同测试工作的效率是纯人工进行点击、表单填写测试效率的 2 倍左右，是从零开始编写脚本效率的 8 倍左右。

整个实验过程中并未出现系统无响应、崩溃、异常情况，证明系统稳定可靠。目前该系统已经上线使用，配置简单、使用方便、测试高效，为慕测平台教育版提供软件作品评分服务，为企业版提供应用自动化测试服务。

4. 致谢

本文由南京大学软件学院智能软件工程实验室 2018 级硕士生尹子越撰写。

感谢中央高校基本科研业务费专项资金资助项目：基于群智协同的众包测试技术(14380021)，2020-2020。