UI自动化测试详解

测试大圣

于 2024-08-20 17:28:04 发布

阅读量728

点赞数 22

文章标签： ui python 自动化测试软件测试测试工具测试用例职场和发展

本文链接：https://blog.csdn.net/HUA1211/article/details/141363710

版权

🍅 点击文末小卡片，免费获取软件测试全套资料，资料在手，涨薪更快

测试都起什么作用

是项目的保险，但不是项目的救命草；测试无实际产出，但作用远大于实际产出；测试是从项目维度保证质量，而不是测试阶段。

UI自动化

基于UI进行自动功能测试，以Web端作为例子，一般的UI功能自动化都是基于HTML的Dom内容进行操作，一般都是使用webdriver + JavaScript的方式进行，目前最流行的一套基础框架就是Python + Selenium。

什么时候进行脚本开发

很多测试人员或者项目负责人都认为，自动化测试一般都在项目稳定之后才使用脚本对项目进行稳定性测试或者一些回归测试中，但随着项目组织架构的完善和目前大环境太卷(?)了，其实每个迭代的新需求都可以直接使用自动化测试来进行，前提是需要：

1. 开发人员需要尽早提供完善的Dom结构内容

2.测试组全部人员都需要具备脚本开发能力。

自动化脚本只有20%的作用，最重要的是测试案例的选取，一切的测试依据都来自于测试案例，记住自动化的用处，是用来找快速找缺陷的。

目前项目组的所负责的系统需求较多，测试案例数量也较多，测试场景复杂，测试数据制作复杂，并且有部分系统已经趋于成熟，所以打算开始进行UI自动化测试。

UI自动化测试其实是一门【水】很深的工作，因为UI自动化测试是需要根据前端页面元素，也就是HTML脚本来进行元素提取、操作、验证的测试流程，另外再加上项目的测试环境软件硬件的因素，在编写自动化测试脚本的时候需要考虑到很多的情况出现而要去判断当前页面出现的元素到底是什么情况，不然脚本的稳定性很不好，维护工作也会非常的高。另外在编写自动化脚本的时候，你会慢慢的熟悉你项目系统前端页面的代码，当下很多前端开发人员在制作新的项目前端页面时都会直接用现成的组件生成，这种HTML代码会使你开发脚本时难上加难，因为里面的标签命名根本就是乱来的（可以说是看得出一个前端开发人员的水平？）

目前项目组中所负责的需求分为两种：手机端(Native+H5)，PC Web端。

因为我们是属于App的一个渠道方，Native方面并不是我们组内人员开发的（其实主要大公司在代码方面管得很严无法拿到Native的iOS和Andriod的代码所以这个需要和他们管沟通，不然无法做App的UI自动化），我们的前端开发主要做的是里面的H5页面，并且手机端的需求现在还经常有变化，所以手机端的UI自动化还不纳入UI自动化的执行范围，我们主要做的是PC Web端的UI自动化。

这篇文章（其实可以说是笔记）主要来讲一下我在做这个项目的UI自动化测试的过程以及心得。

文章主要讲的是：介绍UI自动化、组内UI自动化的架构、测试脚本的编写规范/心得

什么是UI自动化测试

UI自动化测试，指的就是使用工具或者脚本对需要测试的软件的前端界面在预设的条件下和已经的测试数据下运行系统或者应用程序，并获取其前端页面显示的数据结果进行校验，评估得出测试结论。

UI自动化测试可用于哪里

基于测试渠道可分为：手机App、Pc web端、手机Web端等；
基于测试阶段可分为：冒烟测试、回归测试、生产验收、兼容性测试

为什么要使用UI自动化测试

目前测试案例数量过多导致人工执行测试案例耗时过长，并且会出现无法执行完该执行的测试案例导致版本无法按预期上线；
案例的步骤繁琐，场景复杂，制作测试数据的过程复杂，导致人工执行时间过长；
需求简单，无前端功能开发的需求可以使用UI自动化进行测试并得出结论；
可以帮助开发人员进行自测。

哪些测试可以执行UI自动化

已经比较成熟的项目，暂无任何大的改动需求的项目；
人工执行耗时长，流程繁琐的项目；
单纯的数据校验，列表功能校验；

怎么执行自动化测试

开发提测前自用，配置环境和工具，下载脚本执行，可通过测试报告查看执行情况和结果；
冒烟测试中，测试在开发提测后执行，通过测试报告查看执行情况和测试结果；
回归测试中，测试人员执行执行纳入回归测试的测试脚本并执行
生产验收，UI自动化测试脚本可用于生产验收中，无须手动操作就可验证生产的情况。

哪些可以做，哪些不能做？

*验功能不要验样式

ui自动化是无法识别你当前页面的图形形状以及颜色这类，就算是兼容性也只能从功能层面来验证，当然除非使用了图形识别组件这类功能的话另说。

UI自动化测试的利与弊

利处：快捷、方便、无须手工操作

对回归测试来讲一般情况下，回归测试里面的案例都很多都是之前的版本需求中的案例，在迭代多了之后回归测试中的案例就会慢慢的增加，到最后就会出现一个在封板之后执行回归测试案例时会执行不完的情况，使用UI自动化测试之后，以前的回归测试案例可以不需人工执行，等脚本执行完之后查看脚本测试报告和截图，成功失败一目了然，然后测试人员可以把注意力放在了当前迭代的需求中。
对于冒烟测试来讲（无前端改动的需求前提下），开发提测前都需要进行自测，他们可以在电脑上配置好UI自动化测试的环境后，利用工具自己执行进行自测；测试人员也可以利用脚本在开发提测之后使用进行自测。

弊端：脚本编写成本高、案例开发时间长、需要长期维护

一脚本编写成本高主要是分为要懂代码，对系统熟悉程度高，懂得一些编程的规范；为什么要懂代码？这里说的并不是说要非常厉害的那种，主要说的是最起码要可以阅读html、Js、Python、Java等，因为在对页面元素进行提取的时候你必须要根据Html页面上的代码来写的，这种基础的知识还是需要有的；对系统熟悉程度高是指的是你很熟悉你要写脚本的系统的业务流程很熟悉，包括他正常情况流程怎么走的，出错情况下会是怎么走的，会有什么提示这些你都要知道，因为这些场景都必须在写脚本的时候考虑进去，从而提升你脚本的稳定性，减少维护成本，为什么懂编程的规范其实和上一条差不多，主要是提升脚本稳定性，减少维护成本，后面脚本的编写心得会讲一下这个。
部分案例开发时间长，主要说的是一些场景比较复杂的流程，和数据制作的过程比较繁琐，需要你不停的调试你自己的脚本。
长期维护是必须的，因为你的系统的一些需求可能会使其他功能有变化，这个时候你的测试脚本需要考虑到这些场景的时候，你就要去修改你的脚本了，另外还有就是你的数据，有时候系统原因或者你的测试数据是其他关联系统的导致数据失效了，这个时候你必须保证你的数据是有效的，所以必须有个前置步骤来检查你的数据，这个后面如何维护数据会详细再写一下。

项目结构

目前自动化项目处于初期试实行阶段，并没开发得很强大的功能，因为首先要保证可以走得通走得稳，并且每个测试同学都可以用的前提下去开发的，所以采用的是Python 3.6+ Robot Framework Ride + Selenium2Library（PC Web）这一套比较传统的框架，代码由GitLab上管理，其实这一套框架即使是没什么代码基础的测试同学或者还是懂代码的测试同学也好，用起来也是非常的方便的。

有AppiumLibrary，针对手机端做自动化的，但是目前手机端做起来比较困难，暂时不考虑，这里也不先写。