UI自动化测试平台的实践与应用

lsekfe

中文摘要

在漫长的历史进化中，人类为了解决问题，发明了各种各样的工具。故大部分工具的产生，都是以需求为导向的。软件自动化测试的出现也同样遵循这样的事物发展规律。随着社会的进步，智能设备的普及，软件应用已经渗透到生活的各个领域。过去单纯的手工测试已不能满足当下软件的发展规模和速度，如何确保软件的交付质量和效率，这是很多软件公司都需要思考和解决的问题。接下来，将以本人所在公司项目为依托，介绍我们的自动化测试平台实现方案及工作模式。本文的自动化测试主要偏向于UI层面的自动化探讨与实现，阐述这套自动化测试方案从无到有是如何建立起来的，测试人员又是如何使用这套方案提高测试效率替代繁琐重复的工作量的。不管什么类型的测试，究其核心依然是用例(文字用例)，自动化测试的根基是用例。所以，要实现自动化测试，必然要做好用例管理。本自动化平台是一套集用例管理、脚本开发、用例执行、报告生成于一体的多用途测试平台，这为测试人员提供了极大的便利。

关键词： UI自动化测试平台； SeleniumWebDriver； Java

Abstract

Throughoutthe long history of evolution, humans have invented various tools to solveproblems. Therefore, the generation of most tools is demand oriented. Theemergence of software automation testing also follows this development pattern.With the progress of society and the popularization of intelligent devices,software applications have penetrated into various fields of life. In the past,simple manual testing could no longer meet the current scale and speed ofsoftware development. How to ensure the quality and efficiency of softwaredelivery is a problem that many software companies need to consider and solve.Next, based on my company's project, we will introduce our automation testingplatform implementation plan and work mode. The automation testing in thisarticle mainly focuses on the exploration and implementation of automation atthe UI level, explaining how this automation testing solution was establishedfrom scratch, and how testers use this solution to improve testing efficiencyand replace tedious and repetitive workload. Regardless of the type of testing,the core is still the use case (textual use case), and the foundation ofautomated testing is the use case. So, to achieve automated testing, it isnecessary to do a good job in case management. This automation platform is amulti-purpose testing platform that integrates use case management, scriptdevelopment, use case execution, and report generation, providing greatconvenience for testers.

Key words: UI automation testing; SeleniumWebDriver; Java

前  言

近些年，随着软件应用复杂性不断增加，传统手动测试变得愈加耗时和困难。应用涉及多种技术、平台、设备，手动测试很难在短时间内覆盖所有可能的情况，同时，因为工作量的增加，导致人员疲劳或惯性思维，人为错误率也不断攀升。为了改善此种情况，越来越多的公司开始实施自动化测试，试图通过自动化测试来提高测试生产率，降低测试成本。但是，自动化就一定适合所有公司吗？如何分析自己的项目是否适合开展自动化测试，怎样搭建自动化测试平台，脚本后期维护迭代如何保证等。这些问题都是我们在着手自动化测试之前需要认真思考的，因为它直接关乎到自动化最终的成败，能否切实为你所用，提高工作效率。

1  自动化测试基础1.1  自动化测试的基本概念

自动化测试是通过使用自动化工具、脚本和软件来执行测试用例，以验证软件应用的功能、性能、安全性和可靠性等方面的正确性。

1.2  自动化测试演变历程

自动化测试技术的发展历程可以追溯到计算机软件的早期。上世纪60年代，对于软件，人们主要关注的是功能测试，那时候的自动化测试方法是通过编写脚本来模拟用户的操作从而执行测试，且这个是是没有界面的，使用的脚本语言通常是VBScript、Perl等。1970年代，开始出现一些自动化测试工具，入HP QuickTest和Rational Robot，这个时期的工具开始关注图形用户界面(GUI)的自动化测试。1980年代，随着面向对象编程的流行，软件系统的复杂性也逐渐增加，测试需求也变得更加多样化，为了应对这种多样性，性能测试、负载测试、安全测试等领域的自动化工具应运而生。1990年代，互联网初步兴起，Web应用程序开始进入市场，这一时期针对Web应用程序的自动化测试工具Selenium出现，Selenium是一款基于GUI的自动化工具和框架，它允许测试人员通过操作应用程序的用户界面来录制回放脚本执行测试，录制回放模式通常不需要测试人员有编程经验，适合新手快速入门自动化测试，但这种模式生成的脚本可维护性相对较差，脚本复用性也比较低，维护成本高。2000年后，引入了数据驱动和关键字驱动的概念，测试用例可以从外部数据源加载，脚本可以通过关键字驱动的方式执行测试步骤，这种模式下可实现脚本与数据分离，大大降低自动化维护成本。未来，随着机器学习和人工智能技术的不断成熟，自动化测试也将更加智能化，变得更加高效、准确和可维护。

1.3  自动化测试与手工测试的区别

弄清楚自动化测试与手工测试的区别，对于使用自动化测试工具来提高测试效率有很大的促进作用，如下将从7个方面阐述二者的不同之处：

n  执行方式：

自动化测试：使用自动化测试工具和脚本来模拟用户的操作和交互。测试工具可以自动执行测试步骤并生成测试报告。

手工测试：测试人员手动执行测试用例，通过实际操作应用程序进行测试。

n  效率和速度：

自动化测试：相对于手工测试，自动化测试可以更快地执行大量的测试用例，尤其在回归测试中表现突出。自动化可以显著提高测试效率。

手工测试：手工测试通常更慢且耗时，特别是在需要重复执行相同操作的情况下。

n  重复性和一致性：

自动化测试：自动化测试可以确保测试用例在不同时间和环境中的执行一致性，避免了人为误差。

手工测试：人工测试容易受到测试人员的主观判断和疲劳影响，可能导致测试结果的不一致性。

n  复杂性和覆盖率：

自动化测试：适用于复杂的测试场景，可以轻松处理大量的测试数据和各种情况。能够提高更高的测试覆盖率。

手工测试：在复杂的测试情况下，手工测试可能会变得困难且容易遗漏某些测试情况。

n  可维护性：

自动化测试：对于设置好的脚本，可重复使用，但应用程序发生变更时，需要及时维护才能保证继续执行。

手工测试：每次测试都需要人工操作，当应用程序发生变更时，手工测试需要相应的更新测试步骤。

n  探索性测试：

自动化测试：无法进行主观判断和探索性测试，因为自动化脚本是按照预定步骤执行的。

手工测试：适合需要测试人员主管判断、创造性思考和探索性测试的场景。

n  初始投入和技能要求：

自动化测试：需要一些时间来编写和设置测试脚本，以及熟悉自动化测试工具。需要一定的编程能力。

手工测试：无需编程知识，测试人员可以直接开始执行测试用例。

综上所述，自动化测试和人工测试是软件测试中的两种不同测试方法，它们有各自的优势和使用场景。自动化测试更适合于大规模、重复性的测试，尤其是需要频繁执行的回归测试中。手工测试则更适合探索性测试，用户体验评估和某些复杂情况下的测试。在实践中，我们需要根据具体的测试目标和项目要求综合考虑自动化测试和手工测试的使用比例。

1.4  正确认识自动化测试

自动化测试仅仅是一种工具或方法，并不适用于所有的情况。不是所有的公司或所有项目都适合做自动化测试。所以，我们在实施自动化测试之前，要想清楚如下问题：

（1）       如何判断项目是否合适用自动化测试?

n 项目稳定性和周期：自动化测试最适合功能稳定和周期相对较长的项目。如果项目周期很短或经常变更，那么对于自动化来说，脚本开发维护成本则很高，项目时间也有限，此种情况自动化可能不是最佳选择。

n 测试频率和回归测试需求：如果项目需要频繁进行回归测试，即需要多次重复执行相同的测试用例以确保新的代码没有对原有功能模块造成影响，那么，自动化测试可以大大减少重复性劳动和时间成本。

n 团队资源：开展自动化需要考虑团队资源充足，具备自动化测试所需的技术和一定的编程能力，且有能够支撑自动化测试运行的硬件资源。

（2）       正确认识自动化测试投入成本效益

自动化测试初始投入需要一些时间和资源，搭建自动化测试框架，构建调试用例脚本，脚本需要随应用程序的变更而更新和维护，这并非一个人能完成的工作，需要对团队进行技术培训，有些工具还需要额外的成本购买等。短期内自动化测试很难产生收益，而当前期工作都准备充分后，长期来看自动化测试可以更快速的执行大量的测试用例，节省大量手工测试时间，尤其对于频繁的回归测试和长期项目，时间节省更为明显。

（3）       有了自动化测试就不需要手工测试了?

这是很多测试初学者对自动化疑惑的问题，尽管自动化测试在许多方面可以提供效率和准确性，但它依然不能完全替代手工测试。自动化测试和手工测试在软件测试过程中各有优势，彼此之间是相互补充，共同来确保软件质量的。自动化测试无法替代人工的创造性思考和探索性测试，手工测试人员可以弥补这一类问题。在开发初期或频繁变更的项目，难以进行自动化测试，手工测试可以更加灵活的应对这类情况。手工测试可以更好地模拟真实用户的行为和体验，从而更好的评估用户界面、交互等一些其他机器无法识别的问题。

2  自动化测试工具与框架

自动化测试工具和编程语言是实现自动化测试的关键要素。测试人员需要根据项目需求、团队技术栈、要实现的测试目的等来综合评估判断要选择的自动化测试工具。本章节将对一些应用比较广泛的UI自动化工具及框架进行分析和介绍。

2.1  常用自动化测试工具2.1.1  QTP

QTP(QuickTest Professional)是一款由Mercury Interactive(现在属于Micro Focus)开发的自动化测试工具。QTP功能非常强大，主要用于功能测试和回归测试。它的主要特点是：第一，QTP支持多种类型应用的自动化测试，包括Web应用、桌面应用、移动应用和API等。第二，QTP提供了一个可视化的脚本编辑器，可以使测试人员可视化的编辑测试脚本，同时，它也支持用户录制回放脚本，帮助快速创建测试用例。第三，QTP也支持关键字驱动和数据驱动测试，允许测试人员使用关键字来执行测试步骤，支持从外部数据源加载测试数据，以验证同一脚本不同数据。

当然，QTP这款企业级测试软件也有其缺点和局限：首先，QTP不开源，是一款商业工具，其许可证和支持费用较高，不适合预算有限的公司或个人开发者。其次，就支持的脚本语言、操作系统来说，QTP都比较有限，它只能在Windows操作系统上运行，仅支持VBScript编程语言。最后，随着测试用例数量的增加，它的维护相对会变得复杂，且QTP在运行时可能会占用较多的系统资源，包括内存和处理器资源等。

2.1.2  Selenium

Selenium是一款开源的自动化测试框架，用于测试Web应用程序的功能和行为。尤其Selenium2.0出现以后，开发者可以通过其WebDriver技术实现近乎与真人测试一样的场景操作，如点击、输入、提交表单，且能够支持多浏览器的兼容性测试，速度快稳定性强，如能在测试过程中有效使用，能够极大的替代测试人员的繁琐重复的测试，从而提高测试效率。Selenium支持多种编程语言，如Java、Python、Ruby等，可以选择自己熟悉的语言来编写脚本，极大的降低学习难度。

Selenium发展至今，为了应对不断变化的技术和测试需求经历了多次演变，从最初的Selenium1.0(核心是Selenium Core)到Selenium2.0(WebDriver的出现)，再到SeleniumGrid的推出，目前最新版本Selenium4.0，功能在不断完善，使得测试变得更加高效和稳定。如下图3-1是Selenium包含的重要工具套件及其功能特点介绍：

（1）       Selenium IDE:

Selenium IDE是一种浏览器插件，可以用于快速录制和生成测试脚本。尽管它的功能简单，但对于初学者来说是一个入门的好工具。

（2）       Selenium WebDriver:

Selenium WebDriver是Selenium的核心组件，提供了一组与浏览器通信的API，测试人员通过脚本调用这些API才能与浏览器进行交互，实现模拟测试的操作。

（3）       Selenium Grid:

Selenium Grid提供了分布式测试支持，允许在多个浏览器和操作系统上并行执行测试脚本，提高测试效率。

（4）       Selenium RC:

WebDriver出现了以后，解决了Selenium RC中的大部分问题，尤其是对浏览器的处理，不再使用JavaScript操作浏览器的方式，而是选择浏览器最容易接受的语言来处理，相比RC，使得Selenium变得更快，在Selenium3中，WebDriver与RC合并，Selenium RC被弃用。

图2-1 Selenium 工具套件

2.2  配套相关工具介绍

以下两款工具是做自动化测试时，很多团队通常都会配合使用的工具。一方面是它们的功能稳定，且有大量的文档和案例支持，另一方面其属于主流工具，很多公司使用它已有一定成果，可以大大缩短学习和试错成本。

2.2.1  TestNG

TestNG是一个Java测试框架，类似与Junit，但比Junit涵盖功能更全的测试框架，具有参数化、分组的特性，支持数据驱动，可以配置复杂测试数据满足测试需求。Junit过去主要是开发人员用来做单元测试(白盒测试)，而TestNG可用于做多种类型的测试，如单元测试、集成测试、端到端测试等。以下是TestNG的一些主要特点：

（1）       灵活的测试配置：TestNG通过注释或XML配置文件定义测试用例的测试套件、测试组、测试类和测试方法，以及执行顺序和并发性。

（2）       并发测试支持：TestNG提供并发测试的支持，可以在多个线程中并行执行测试，提高测试效率。

（3）       参数化测试：TestNG支持通过DataProvider或参数化注解传递不同的测试数据集，以验证多个数据组的相同测试逻辑。

（4）       依赖测试：TestNG允许在测试方法之间定义依赖关系，确保某个测试方法在其依赖的方法执行成功后才执行。

（5）       集成：TestNG可以与各种构建工具(如Maven、Gradle)和持续集成工具(如jenkins)集成，实现自动化测试的持续集成和持续交付。

总的来说，TestNG是一个功能强大且灵活的框架，有着丰富的特性和工具，使开发人员能够更有效地编写和管理测试用例。它在自动化测试领域很受欢迎，特别适合大型项目和复杂的测试需求。

2.2.2  Jenkins

Jenkins是基于Java开发的持续集成工具，用于监控持续重复的软件工作，实现自动化构建、测试和部署软件项目。Jenkins提供了友好易操作的可视化界面，用户可以轻松配置、管理和监控构建任务，它可以部署在不同的操作系统上，支持各种开发语言和技术，同时，它拥有强大的插件生态系统，满足用户的各种需求。

图2-2为Jenkins工作流程图：开发人员提交代码到版本控制系统(如SVN、GIT)后，Jenkins使用GIT(SVN)工具到代码库去拉取代码集成到Jenkins，通过jdk、maven完成编译、打包等工作，完成以后Jenkins会把jar包或war包推送到配好的服务器，最后，用户即可访问该应用。

图2-2 Jenkins工作流程图

3  UI自动化测试平台的设计与实现

上一章介绍了与UI自动化测试紧密相关的技术和工具，这一章将从整体上介绍将自动化测试引入团队的完整过程。搭建一套自动化测试方案就相当于是开发一个软件，且拥有这个软件一样的生命周期，即需求分析-软件架构设计-软件编码-软件测试-上线投入使用。本章节将大致按照这样的环节来一一说明。

3.1  自动化需求调研与分析3.1.1  业务背景及自动化引入说明

做自动化测试不能为了做而做，一定要在前期调研好需求，并加以分析，以确保所做的自动化测试软件满足使用者的需求，能够解决他们所面临的问题。下面结合第二章中正确认识自动化测试-如何判断项目是否适合引入自动化的条件来评估本公司项目：

公司业务介绍：本人所在公司是做线上二手车交易服务的，用户通过网上多种报名卖车入口报名，经过一系列的业务环节，最终买卖双方交易成功。在这条业务线中，测试人员通常要测的如每种渠道是否均能报名成功，报名成功后是否均能进入系统后台某个节点，每条渠道的数据是否都能交易成功或失败等。通常人工测试一条渠道的数据在页面上走完流程大约需要10分钟，非常耗时及繁琐。后来，测试团队便萌生了要做自动化测试的想法。

首先，从项目稳定性和周期上来说，我们的项目非外包也非其他主线业务变更频繁的项目，公司的核心业务一直都是围绕帮助用户实现线上交易快速高价卖车，虽会进行一些迭代，但不影响项目大体的稳定性。其次，测试频率和回归测试上，随着互联网科技和日益激烈的竞争环境的变化，系统升级也变得较以前更快，这意味着主线业务功能的完好性，需要持续进行测试回归来保障。最后，团队资源上，自动化测试趋于开发人员，需要编程相关技能及一些服务器等硬件资源支持，公司测试管理对这一块也极为支持，希望采取相关措施来提高工作效率及测试人员技能。

3.1.2  自动化测试流程

经过对公司项目实际情况分析，确认了自动化测试在测试团队中的使用定位，自动化测试主要用来配合测试人员完成一些原有功能的回归测试，增量功能由于不能确定其未来稳定性以及项目迭代周期较短，时间不允许，这一部分依然由测试人员手工测试。由此，我们的自动化测试流程则如图3-1所示：

前半部分流程与以往手工测试流程一致，会先制定测试计划，确认项目测试周期，何时何地何人完成什么测试内容，最终上线时间等，随后，详细分析被测需求，编写能够覆盖需求所述所有要求的测试用例。然后对该测试用例进行分析，确认是否有对历史功能进行回归测试的需求，如有，则对该部分用例进行脚本开发或将过去已开发好的自动化用例拿来即用。待项目提测，同时进行自动化用例运行及手工测试，自动化测试用例运行会通过断言或查看日志的方式来反应测试是否有问题，手工与自动化测试均测试通过，最终完成测试。

图3-1 自动化测试流程图

3.1.3  做UI自动化测试平台原因

传统的自动化测试一般都是测试开发工程师在自动化测试框架中编写测试脚本，然后将开发好的脚本集成到Jenkins中，在Jenkins中设置定时执行，以满足测试所需。这种方式的缺点是：一、脚本开发维护难度大，需要测试人员能够熟练使用某种开发语言及相关开发工具才能上手；二、要使自动化在测试工作中达到预期效果，自动化用例的覆盖率必定要不断扩大，即用例要不断增多，集成在Jenkins中的用例则会瀑布式的呈现，不利于快速查找及运行；三、Jenkins对于测试报告的支持不满足测试所需，当用例过多时，查看日志需要不断打开页面，非常混乱。

为了解决上述问题，再接合自动化测试的流程，我们决定开发一套UI自动化测试平台，可以自主根据需要开发相关功能，让自动化更好的辅助测试人员进行测试。

3.2  平台详细功能模块划分

根据上一节的自动化需求分析，我们得出一款切实有效的自动化测试平台应满足脚本能够稳定高效正确的运行、准确的反馈测试结果、灵活的新增维护脚本。为了实现这一目标，我们的UI自动化测试平台将划分为如下模块：脚本管理、计划管理、定时管理、系统管理，如下图3-2为平台整体模块设计。

图3-2模块设计

3.3  框架体系

本UI自动化测试平台采用前后端分离模式，二者互不干扰，前端使用vue.js，后端采用SpringBoot框架实现快速构建，MyBatis作为持久化工具，用来存储平台上的用例相关信息。自动化核心层以SeleniumWebDriver为基础，并对WebDriver进行了封装，根据业务需要提供了更便捷的关键字操作方法。底层用例层使用TestNg测试框，采用PO模式、关键字驱动、数据驱动的思想以达到页面、数据、用例三者分离，达到更高效的开发维护用例。实现平台能切实提高用户工作效率的最终目标。整个开发过程中，采用Maven作为构建项目工具，Git作为代码版本控制工具，从而实现管理项目的依赖和版本，多人协作高效开发。图3-3为自动化测试平台整体架构图。

图3-3 UI自动化测试平台技术架构

辅助系统这一层主要为UI自动化脚本执行时所用到的工具系统或框架，当用户在平台上点击某个用例执行，后台将会调用Jenkins空闲执行机接口，判断当前是否有执行机可用，当存在可用执行机时，Jenkins会拉取配置好的自动化api项目至编译机，编译好后开始运行由平台传递过来的用例，启动远程hub随机分配的docker中关于selenium/standalone-chrome镜像下的浏览器node节点，最后通过关键字驱动走selenium webdriver核心自动化用例脚本步骤。

其他服务主要是前端页面服务项目和Rabbit MQ，UI自动化测试平台鉴权登录成功后即会跳转至前端项目，Rabbit MQ主要是用例在运行时往MQ上推任务，然后MQ会进行消费，消费完以后才真正走用例运行前的逻辑，即去判断是否有可用执行机，有可用执行机采取更高jenkins job相关配置，最后拉取代码编译运行。

数据来源是为UI自动化测试平台提供数据服务的，用户运行用例时可以在平台上选择自动获取数据和手动录入数据，其它一些基础数据配置来自业务库。

平台展示层是用户真正操作的平台，通过页面的形式展示给用户，用户操作以后会将请求和参数传给后台相关服务接口，后端处理后会返回给前端页面。

3.4  数据库设计

依据前文章中节介绍的UI自动化测试平台功能需求，建立如下为数据库表结构，下面是对关键表结构的详细说明：

（1）       AUTO_ELEMENT：存储元素名称及元素定位表达式表。

表3.1页面元素表

（2）       AUTO_ELEMENT_POSITION：存储页面元素定位方式关键信息表。

表3.2元素定位方式配置表

字段名	数据类型	主键否	注释
ID	int(11)	TRUE	主键ID
POSITION_TYPE	varchar(100)	FALSE	定位类型名称
STATUS_ID	tinyint(4)	FALSE	状态：0-无效，1-有效
CREATE_TIME	datetime	FALSE	创建时间
UPDATE_TIME	datetime	FALSE	更新时间

（3）       AUTO_KEYWORD: 存储关键字信息表

表3.3关键字信息表

（4）       AUTO_KEYWORD_ARGUMENT: 关键字和参数关系表

表3.4关键字和参数关系表

（5）       AUTO_USECASE_INFO: 用例库表

表3.5用例库表

（6）       AUTO_USECASE_STEP: 用例库步骤表

表3.6用例库步骤表

（7）       AUTO_USECASE_TASK_DATA: 用例运行数据表

表3.7用例运行数据表

（8）       AUTO_USECASE_TASK: 用例执行任务表

表3.8用例执行任务表

（9）       AUTO_USECASE_TASK_LOG: 用例执行日志表

表3.9用例执行日志表

（10）       AUTO_TESTPLAN_INFO: 测试计划表

表3.10测试计划表

（11）       AUTO_TESTPLAN_USECASE: 测试计划与用例映射表

表3.11测试计划与用例映射表

（12）       AUTO_QUARTZ_TASK_INFO: 定时任务信息表

表3.12定时任务信息表

（13）       AUTO_QUARTZ_TASK_RECORD: 定时任务执行情况记录表

表3.13定时任务执行情况记录表

（14）    AUTO_SLAVE_MANAGE: 执行机管理表

表3.14执行机管理表

3.5  模块功能实现

相对于整个UI自动化测试平台的完成而言，作者仅仅参与了部分功能的后端开发，因此，该部分主要侧重介绍脚本管理模块及测试计划模块的功能实现，由于篇幅有限，前端或其他模块及运维部署将不在此详细说明。

后端主要以接口的方式提供给前端调用，数据格式为json，以实现功能交互。整个后端架构采用分层设计，即MVC模式，对应代码中的controller、service、dao。controller层是最靠近用户的一层，主要用来接受用户指令及返回数据结果；service层主要用例处理复杂的业务逻辑；dao层主要用来处理和数据库之间的交互。每个层次都有其独立的职责，它们之间共同协作提供完整的功能。

3.5.1  开发环境

如下表3.15为UI自动化测试平台所用到的开发环境及工具：

表3.15开发环境及工具

3.5.2  脚本管理模块功能实现

该模块实现了脚本的开发与运行，其包含的子模块有元素管理、组件管理、用例设计、用例运行。本小节将分别介绍这四个子模块的后端功能实现：

（1）       元素管理模块功能实现

元素管理模块主要是帮助测试人员将测试场景中使用的web页面元素控件保存起来，并提供编辑和删除的功能。用户可通过该模块页面实现维护元素名称、元素定位方式、定位值的修改，以确保后续用例运行的稳定性。

在实现时，我们遵循三层设计模式，创建ElementController、ElementService、ElementDao及其对应的实体vo，如下图3-4为元素模块对应类图：

图3-4 元素模块类图

以新增元素功能为例，当用户点击【新增元素】，则打开元素新增页面，如图3-5，字段信息如下：元素名称、定位方式、元素定位值、备用定位、备用元素、元素归属、备注。元素名称以中文命名，格式为：业务模块名称/页面/某个控件(如A系统/登录/用户名)，此种方式命名主要是方便没有代码基础的人员快速识别每个元素是被测系统中哪个web控件;定位方式即selenium常见的8种定位方式：id、name、xpath、className、tagName、linkText、cssSelector、partialLinkText;元素定位值即通过某种定位方式的值，如通过元素的name定位，则取控件的name属性值，以此类推;备用定位和备用元素是表示为当前新增的元素配置第二种定位方式，设置备用元素的目的是为了提高脚本执行的稳定性;元素归属表示设置元素归属被测系统业务模块，方便统一维护。

其中前三个字段及元素归属为必填项，当这四个标星字段为空时则会分别提示-xxx为必填项，请填写。当所有项均填写完整，点击【确定】则会调用后端ElementController类中的saveElement方法，该方法会先调用service层的requiredElement校验必填项，通过以后，再调用service层的insertElement方法，elementService.insertElement调用dao层的insertElement，最终实现将页面上用户输入的元素信息插入至表中，实现持久化。新增成功后，元素列表页将会展示该元素，如图3-6所示。

图3-5元素新增页面

图3-6 元素列表页

（1）       组件管理模块功能实现

我们把页面中某个完整的操作且多个测试场景都会经过此操作，这样的一组动作定义为一个组件，组件里面实际上就是一些对页面控件的操作步骤。

代码实现上，创建ComponentController、ComponentService/ComponentStepService、ComponentDAO/ComponentStepDAO及其对应的实体vo，如下图3-7为组件模块对应类图。

图3-7 组件模块类图

以组件新增为例，当用户点击【新增组件】，则打开新增组件页面，如图3-8，填写组件基本信息字段：组件名称、组件归属、平台类型、优先级、备注。组件名称主要为概述该组件是做什么的，命名规则为被测系统名称-业务模块-操作名称，如A系统-登录模块-登录;组件归属主要为给当前组件划分归属业务模块，方便查找;平台类型表示该组件的执行是在WEB端还是APP端，为了方便后续扩展，暂时给出这样的定义;优先级主要为该组件的重要程度，一般有三个级别可选。以上字段除备注以外，其他四个均为必填项，当这些信息填写完成后，点击该页面下一步，则对上述填写的组件基本信息进行保存，调用ComponentController中的saveComponent进行必填项校验及保存至数据库的操作。保存成功后返回页面，页面将展示组件步骤输入页，如图3-9(该图为已输入步骤的情况，默认为空白)。

图3-8 组件新增页-基本信息

图 3-9 组件步骤

图3-10 组件步骤新增

返回值：表示当前步骤执行的关键字方法是否需要保存返回值，需要则以固定格式填写，在后续步骤中即可使用该返回值。

关键字：即当前步骤想要进行的操作，如输入操作，那么使用已经配置好的clearType关键字，点击操作，使用click关键字等，前提是已经在系统管理中配置好了，如图3-10。

参数：表示当前关键字操作对应需要的参数，需要什么参数类型，多少参数个数，这都是需要在系统管理中关键字配置的，且该参数与api包中的seleniumwebdriver中的关键字参数要保持一致。此处参数Element如上图所示，直接填写元素管理模块配置的元素中文名称。

操作：主要是用来调整步骤的顺序及删减操作，依次为向上移动(当前步骤)、向下移动(当前步骤)、增加一个步骤、删除一个步骤。

当点击下方保存时，调用ComponentController中的saveComponentStepsArgList，调用ComponentStepService中的requiredComponentStep进行必填项校验，接着判断步骤是否不为空，如不为空则调用组件新增addComponentStep，ComponentStepService再调用ComponentStepDAO中的insertComponentStep，组件保存成功返回组件页面列表，如图3-11。

图3-11 组件列表页

（3）       用例设计及运行模块功能实现

用例设计部分主要是对上述保存好的组件进行组装，组装好以后即是一个用例脚本。用例设计与用例运行很多操作相同，区别在于用例运行菜单仅显示状态为有效的用例脚本，它们的后端操作采用同一套，图3-12为用例设计/用例运行模块类图。

以下案例将会以公司某个业务为例进行介绍。点击【新增用例】，打开用例设计基本信息页，如下图3-13所示：

图3-12 用例设计运行类图

图3-13 用例设计信息页

用例归属：指用例归属的被测系统业务模块，方便管理各业务用例的。

用例名称：概括性用例名称，命名规则被测系统名称-业务模块-用例核心点。

用例类型：我们按照用例的实现目的来定义它是实现的一个功能点检测，还是一条多个模块串连起来的业务流程用例。

标签：这是根据业务来划分的。

用例等级：用例重要等级，划分为三个等级。

自动获取数据：指该用例在运行时是否支持自动获取数据，支持则需要在系统管理-前置数据处配置该前置数据。

平台类型：指标识该用例所属类型的，是WEB端还是APP端。

当点击下一步按钮时，会调用UseCaseController中saveCaseInfo方法，通过相关必填项校验，调用service层保存用例基本信息，保存完以后页面会展示让用户组装组件的树形页面，如图3-14所示

图3-14 用例设计树形页

左侧树形展示的是每个被测系统模块下的组件，右侧为设计用例者从左侧移动(拖拽)过来的组件，用户选择左侧组件时需要根据要实现的脚本逻辑来组装，一个组件可在不同的用例中存在，实现复用。当组件选择完成后，点击下方保存，该用例即为调试状态，用例设计人员需要对该用例进行调试运行，运行成功则将该用例状态设置为有效。有效状态的用例将会在用例运行菜单中显示，如图3-15用例运行列表。

图3-15用例运行列表

点击用例运行列表运行，则会弹出运行参数选择窗口，如图3-16：

图3-16 用例运行参数

执行环境：用例在哪个环境上运行，一般分为测试环境、模拟环境。

前置数据：为用例设计时选择的运行时自动获取数据数据源。

数据类型、渠道、城市：这三个均根据公司业务线来定义的。

执行机：用例运行时要在哪个执行机上运行，不指定时系统根据空闲机来自主分配。

自动获取数据：当开启此开关则表明本次运行数据策略为根据前置数据来自动获取。

确认好运行参数后，运行则调用UseCaseController中runCase方法，进行用例Id、运行类型、运行环境判空，如为空则抛出相关异常，不为空调用CaseService中build方法，开始构建用例，生成一条运行任务，往MQ中推送该用例运行任务，MQ进行消费和相关空闲执行机判断，最后，更改Jenkins中空闲job参数，调用其运行接口，运行成功后返回状态至前端页面。如下图3-17为UI自动化测试平台整个用例运行流程图。

图3-17 自动化测试运行流程

3.5.3  测试计划模块功能实现

测试计划是为了方便测试人员在测试项目的时候能够快速准确的使用自动化用例配合测试，当测试人员确认他的项目中有一部分用例自动化脚本已经实现时，他可以创建一个测试计划，将这些自动化用例添加至该测试计划中，测试的时候，他就可以直接在测试计划中进行批量运行，并生成测试报告，如图3-18、3-19所示，该模块即实现图3-1自动化测试流程图中将用例加入待执行列表，这里的测试计划就是那个列表。

用户从用例运行列表按条件查找到目标用例，勾选用例前复选框，点击添加至计划，即可将这批选中的用例加入至测试计划，打开测试计划详情页图4-18，即可看到加入进来的所有用例。在该页面，用户可勾选用例，操作一键运行，即会调用测试用例controller中用例批量运行方法，开始排队运行。当运行成功，则结果字段会显示成功，运行失败，则结果字段会显示失败，有些能捕捉到的错误会反填到失败原因列，运行结束后，用户可在操作列查看详细运行日志，也可以操作重新运行。计划中用例全部运行完毕，用户可到报告统计页图3-19所示，一览所有用例运行情况，点击下方生成报告可根据需要将当前计划中用例执行的最新结果导出excel。

图3-18 测试计划详情页

图3-19 计划报告页

4  UI自动化测试平台推广与应用

4.1  UI自动化测试平台推广

这是一套及脚本开发、运行于一体的自动化平台，为了让平台能快速高效的服务于测试人员，实现提高测试效率的目的，平台上线后，我们与测试管理及测试人员进行了多次沟通、探讨，制定了如下推广策略：

（1）       整理平台使用文档说明

由于测试人员较多，开会演示也不一定所有人都在场，落实下来的文档则是能够固定存在且可随时查阅，能够提供良好的共享和协作功能，提高团队工作效率。

（2）       锁定被测系统稳定可自动化模块

自动化不可能替代所有的手工测试，但可用于一些稳定模块的回归测试，经与熟悉业务的测试人员沟通，确定了2个相对稳定的模块，并提取相关的用例场景。

（3）       项目上线前的主线回归测试

基于公司的上线传统，每周2天上线时间，所有测试通过的项目会在这一天一起合并到一个分支，等待上线，这对于整个业务来说是有风险的。因为测试阶段从未将大家的代码合并到一起测试过，于是可以将自动化对主流程场景的回归作为最后一关的兜底测试，以保障测试质量。

（4）       培训测试人员平台进行脚本开发维护

当被测项目较多时，后续的自动化脚本量也会不断攀升，那么，全体测试人员一同参与开发维护则是必然趋势，所以，我们对测试人员进行了UI自动化平台上脚本开发的培训。平台化后的脚本开发相对容易，只需要学习并练习半个月即可上手。

4.2  UI自动化测试平台使用效果评估

引入UI自动化测试平台两年多，公司核心稳定业务模块自动化用例均已覆盖，覆盖率达30-40%左右，总用例达300左右，凡有涉及这些业务模块的项目，测试人员仅需要专注于增量业务的测试，大大节省了测试人员工作量。同时，自动化作为公司的工作效率提升工具，也逐渐融入研发、运维团队。用于开发人员提测前自测，大大提升了项目提测质量，运维人员做相关硬件或服务器升级时，为了保证业务系统的可用性，可以用自动化运行关键用例，以确保系统正常。

回到UI自动化测试平台搭建的初衷，自动化应满足可靠稳定高效运行且可维护。下图为随机抽取的5次上线前自动化全量用例回归测试情况，以此为参考来评估自动化平台的稳定性、测试效率、可维护性。

图 4-1 自动化用例回归情况

用例总数会随着业务变更，脚本维护快慢、环境等问题而不断变更，所以，每一次有效执行用例总数均不一样。执行成功即用例顺利执行并断言成功的用例。失败用例我们根据业务情况分为四类失败原因：断言失败即表明实际结果与预期结果不一致，一般表示被测系统有问题，需要引起重视；数据源问题表明用例运行时自动获取或手动给予的数据有问题；脚本问题指因为脚本有误导致执行失败；被测系统环境问题表明服务器或其他依赖环境配置不正常导致失败。脚本稳定率没批脚本有效真实运行下来的用例占总用例的比例。总耗时所有用例从运行至结束所用时间，以分钟为单位。

（1）       稳定性

由上表可见自动化脚本的稳定执行率波动较大，平均大致在90%左右，这个与我们初期对自动化的期望相差不大。分析发现大部分问题在于数据源问题及脚本问题上，数据源主要是由于自动化用例使用的数据同时被其他人员使用，导致状态变更，用例执行失败。脚本问题大部分是因为某一部分业务变更，脚本未及时维护，回归时未提前剔除导致。当前，也在根据实际情况采取相应措施解决。

（2）       测试效率

接合公司的业务特性来看，通常上述表中用例手工执行情况下，正常路径构建每条测试数据至少在5分钟左右，测试时间最短1分钟，按每条用例6分钟执行完，300条用例1人执行时长在1800分钟即30个小时，而自动化执行下来平均时长在3小时，且自动化可不分昼夜无人值守重复执行，并100%还原测试路径。

（3）       可维护性

UI自动化依赖于前端页面，脚本需要及时维护。UI自动化测试平台提供了可视化脚本开发界面，大大降低了开发难度，普通测试人员可经过培训能立即上手，基本上处于一个全员皆测试开发模式，各自维护自己的模块，测试任务多时可灵活调取其他人员维护，不再局限于某几个人，很大程度上优化了人员配置，提高了脚本的可维护性。

结  论

本论文主要介绍了UI自动化测试平台的实践与应用。先从自动化测试理论基础说起，阐述其演变历史及发展过程，对比手工测试二者的区别，对自动化有一个正确的认识。而后介绍了自动化测试常用工具Selenium、QTP、Jenkins、TestNg，对比其特点及功能，我们选择了Selenium作为本平台的自动化测试基础工具。最后详细介绍了本文UI自动化测试平台从需求调研到具体功能模块实现整个实施过程。最后介绍该平台在公司的推广使用及其带来的效果。

通过本UI自动化测试平台，测试人员不再为繁琐的历史功能回归测试而疲惫不堪，他们可以将精力更多的集中在新业务及探索性测试上，他们也不再因为没有代码基础而无法开启自动化学习和实践，自动化的出现，一定程度上推动着测试部门技术的进步，测试人员不再只是点点点，而要深入技术，了解软件运行原理，以更全面高效的完成测试工作。

在整个UI自动化测试平台设计实施过程中，本人的主要工作有：根据公司实际情况进行自动化需求调研、页面功能菜单设计以及部分功能代码开发。在这个过程中学习并实践了需求文档的编写、Axure产品设计工具，技术方面学习了Selenium自动化测试框架，将其与TestNg接合构建一套了UI自动化内核，同时，也总结到使用Selenium过程中常见问题及其解决方式，大大提升了我的自动化测试经验。

赵佳乐SMILE

这么好的文章当然要收藏啦

oliver.tang

感谢分享，如果有项目源码，就更完美了