API+UI自动化测试框架设计与开发_api测试+e2e测试+ui测试

前言

最近几个月根据扫码防错项目的经验，在UI 自动化测试框架上做了全新的探索和设计，在落地性，效益性，业务性等方面做了进一步思考和优化。

从需求设计到技术框架选型再到框架结构设计，最后项目验证验证，都由一个人独立设计开发完成的，挑战很大，但是能顺利完成，也算是收获颇丰。

框架从设计到落地（含业务场景脚本）大概花了三个月，基本下班与周末有时间都在写，5月主要是在总结业务需求痛点与思考框架方案设计与技术实现的可行性，功能架构的扩展性和易修改性 核心 demo 的实现 等方面进行研究和探索，6，7月份就是业务落地与项目脚本代码编写。

在整个研发过程中个人感觉6，7月份其实才是最核心的时期，毕竟不结合实际业务的设计和不优化技术框架设计的开发都是为对未来测试成功的不负责。

在此分享一下我在设计与开发过程中的一些心得体会：

UI 自动化的现状

UI 自动化测试之所以为自动测试金字塔模型的技术顶点，原因其实也很简单:

1.难度大。

接口自动化框架本质上都只是在围绕 request 做文章，到 UI 自动化框架，除了思考 selenium + appium（目前普遍都是这个核心），还需要去思考页面变化大，页面加载时间，vue框架下元素管理难度大，落地成本高，任务调度方式，用例执行方式等等问题，以及不一定会思考的问题，比如如何优化这些缺点，以及如何做进一步的提升？

2.成本高。

技术选型和学习成本：选择适当的技术栈和工具来构建UI自动化框架需要投入时间和资源进行研究和学习。这可能涉及到编程语言、测试框架、集成开发环境、版本控制系统等方面的选择和学习，以确保框架能够满足需求并提供可靠的测试。

架构设计和开发成本：搭建一个可扩展、可维护且稳定的UI自动化框架需要进行详细的架构设计和开发工作。这包括定义框架的组件、模块和接口，编写核心功能代码，处理错误处理和异常情况，以及优化性能和稳定性等方面。这些工作需要有经验的开发人员进行，并且可能需要大量的时间和精力。

测试用例编写和维护成本：一个完整的UI自动化框架通常需要编写许多测试用例来覆盖不同的功能、场景和边界条件。编写和维护这些测试用例需要深入了解应用程序和业务流程，并且需要花费大量的时间和努力。此外，由于应用程序的变化和演进，测试用例也需要进行周期性的更新和维护，这会增加框架的成本。

持续集成和自动化部署成本：对于大型项目或团队来说，持续集成和自动化部署是必不可少的。这涉及到配置和维护持续集成服务器、设置自动化构建和部署流水线、编写自动化测试脚本，并确保整个过程的稳定性和可靠性，需要花费相当的时间和资源。

3.发展快。

UI 自动化测试框架，除了 selenium，appium，其他优秀的框架比如 cypress 以及 playwright 都在持续不断地迭代优化，成为新秀。甚至，为了降低编写成本，很多的框架都支持通过录制的方式生成 UI 自动化脚本。当然录制有它的好，也有它的不好。

当前我们为什么要做UI自动化框架

• 当前公司大部分测试其实都是点点点，产品质量控制完全靠人工进行保障，在产品与项目日益增长的情况下，需要通过UI测试框架降低人工重复工作，减少重复的人力消耗。
• 目前已建成的Jenkins+Jmeter API巡检体系只能保证数据流正常，无法验证页面操作是否正确（接口正常，但是页面操作出现问题）。
• 通过以下对比，让我们来了解测试工作中手工测试与自动化测试之间的区别

我想做一个什么样的 UI 自动化框架

理论与技术指导

1.测试左移

测试左移，顾名思义就是测试工作的向左扩展，就是让测试介入代码提测之前的部分。比如，扩展到开发阶段，在架构设计时就考虑产品的可测试性，并尽量进行开发自测与API测试等。另外，测试可以更进一步扩展到需求评审阶段，让测试人员不只是了解需求，更要评估需求的质量，比如分析需求的合理性以及完整性等。

测试左移的关键不是发现问题，关联是在质量意识的生态闭环中，不断减少存量问题，进而不断减少问题的发生。换句话说就是通过测试左移，降低bug的数量，减少研发返工时间。

未进行测试左移

测试左移至单元测试阶段

测试左移至编码阶段

把瀑布式的、串行的工作，改为并行的、交叠的过程，这样测试人员就可以更早的介入测试工作了。对于目前团队来说，在开发人员不进行junit或其他单元测试的情况下，由测试人员提前介入开发，通过完成API业务流的方式进行简单有效的测试左移。这就需要框架需要框架支持API测试可以验证每个迭代研发的数据流以及对应表中数据的正确。

当前测试工作痛点

• 问题修复频率较高，确认本次修复bug的影响范围后，对可能涉及的功能进行再次回归，尤其是在一个迭代中存在多个fixed的小版本的时候（零部件MES项目发现的bug当天处理）。
• 进行全量回归测试会消耗过多时间（比如环境迁移），但是回归测试是很有必要的，因为每个迭代的变更都可能影响其他功能的情况下。
• UI 异常流程测试，经常遇到问题需要抓包工具或者API来对某个流程里面每个 url 的各个状态来进行mock 等。但是在问题修复完成之前只能通过手动修改数据库或者执行对应API来进行流程验证。效率非常低。

解决以上痛点应采取的方式

• 采用PO（Page Object）模式，将页面的结构和行为封装到页面类中，使得测试代码更加清晰、易读和易于维护。通过调用页面类的操作方法和检查点，可以直观地描述测试步骤和预期结果。同时减少了重复编写相同的元素定位和操作代码的工作量。如果页面发生变化，只需在页面类中进行修改，而不需要修改所有调用该页面的测试用例。
• 将 UI 逻辑与测试数据从旧有的测试脚本中分离，增强脚本的可读性和可维护性。
• 处理 UI 自动化中的常见的需要处理的问题，比如对重要的的测试过程页面自动截图。
• 编写一些通用工具库，使得 UI 自动化能提高投入产出比，少走弯路。

测试框架设计思路整理

技术框架设计

执行流程设计

测试框架结构设计

project/
├── cases/	//用例文件夹
│   ├── api/
│   │   ├── __init__.robot
│   │   ├── test_authentication.robot
│   │   ├── test_user_management.robot
│   │   └── ...
│   └── ui/
│       ├── __init__.robot
│       ├── test_login.robot
│       ├── test_homepage.robot
│       └── ...
├── resources/	//资源文件夹
│   ├── api/
│   │   ├── keywords/
│   │   │   ├── __init__.robot
│   │   │   authentication.robot
│   │   │   ├── user_management.robot
│   │   │   └── ...
│   │   ├── variables/
│   │   │   ├── __init__.robot
│   │   │   ├── authentication.robot
│   │   │   ├── user_management.robot
│   │   │   └── ...
│   │   └── ...
│   └── ui/
│       ├── keywords/
│       │   ├── __init__.robot
│       │   ├── login.robot
│       │   ├── homepage.robot
│       │   └── ...
│       ├── page_objects/
│       │   ├── __init__.robot
│       │   ├── login_page.robot
│       │   ├── homepage.robot
│       │   └── ...
│       ├── test_data/
│       │   ├── __init__.robot
│       │   ├── login_data.robot
│       │   ├── homepage_data.robot
│       │   └── ...
│       └── ...
├── results/	//过程/临时文件夹-output datas
│		├── api/
│   │   ├── api_log1.yaml
│   │   ├── api_log2.yaml
│   │   ├── api_log3.yaml
│   │   └── ...
│   └── ui/
│       ├── ui_log1.yaml
│       ├── ui_log2.yaml
│       ├── ui_log3.yaml
│       └── ...	  	
├── modules/	//模块模板文件夹
│		├── api/
│   │   ├── api_module1.yaml
│   │   ├── api_module2.yaml
│   │   ├── api_module3.yaml
│   │   └── ...
│   └── ui/
│       ├── ui_module1.yaml
│       ├── ui_module2.yaml
│       ├── ui_module3.yaml
│       └── ...	
├── reports/	//报告文件夹
│		├── api/
│   │   ├── api_reports1
│   │   ├── api_reports2
│   │   ├── api_reports3
│   │   └── ...
│   └── ui/
│       ├── ui_reports1
│       ├── ui_reports2
│       ├── ui_reports3
│       └── ...	
├── datas/	//测试数据-input datas
│		├── api/
│   │   ├── api1.yaml
│   │   ├── api2.yaml
│   │   ├── api3.yaml
│   │   └── ...
│   └── ui/
│       ├── ui1.yaml
│       ├── ui2.yaml
│       ├── ui3.yaml
│       └── ...	
├── requirements.txt	//pip安装文件
├── screenShots	//截图文件夹
│   ├── screenShots1
│   ├── screenShots2
│   ├── screenShots3
│   └── ...	
├── argsfiles   //执行层
│		├── api/
│   │   ├── api_argsfile1.yaml
│   │   ├── api_argsfile2.yaml
│   │   ├── api_argsfile3.yaml
│   │   └── ...
│   └── ui/
│       ├── ui_argsfile1.yaml
│       ├── ui_argsfile2.yaml
│       ├── ui_argsfile3.yaml
│       └── ...	
├── allure
│   ├── allureReport/
│   │   └── ...
│  	├── allureTmp/
│   │  	└── ...
└── ...

结构设计说明：

tests文件夹包含了所有的测试用例文件，分为api，ui和public三个子文件夹，分别用于存放API，UI以及公共自动化测试用例。每个测试用例文件都应该应该由测试的功能命名，例如Suite1.UI-标准装箱-出货检测.robot。

resources文件夹包含了所有的资源文件，同样分为api，ui和public三个子文件夹。api文件夹中包含了所有的API测试用例所需的关键字和变量，每个关键字和变量都应该单独存放在一个文件中，例如authentication.robot和user_management.robot。同样，ui与public文件夹中包含了所有的UI与公共测试用例所需的关键字、页面对象和测试数据以及第三方操作工具，比如钉钉机器人调用程序。

datas文件夹用于存放测试数据文件，例如1.0.股份随箱卡信息.yaml和2.钉钉配置.yaml。

results文件夹用于存放测试过程数据文件，reports文件夹用于存放测试报告文件。

requirements.txt文件用于记录项目所需的Python依赖包。

使用结果

目前此框架已经在扫码防错项目的回归验证上使用，主要是用于每次更新后的全量回归，在最近的几个迭代以及WAF环境的验证中取得了不错的效果。具体表现为：

1.节省了大量手工回归测试的时间，可以利用午休或其他非工作时间自动验证已完成的9个主要业务场景，测试时间从2天节省到1天至1天半（全量回归时间节省）；

2.测试质量较高，自6月开始执行至今未发现通过自动化回归验证出现bug遗留与逃逸的情况；

3.更新较为容易，采用PO模式研发，新增发运抽检功能只消耗了1个小时，就完成了从编写到调试的全过程；

未来研究方向