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

lsekfe

中文摘要

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

前  言

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

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.1QTP

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自动化测试平台提供数据服务的，用户运行用例时可以在平台上选择自动获取数据和手动录入数据，其它一些基础数据配置来自业务库。

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

oliver.tang

感谢分享

噜啦啦啦

您好，大佬，看了您关于自动化的帖子，想问一下，我们公司想做app自动化，需要再不同的测试机上进行，不依赖PC，是需要辅助软件进行吗