欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  IT编程

荐 深入浅出聊一聊自动化架构!

程序员文章站 2024-01-17 14:24:34
浅谈自动化架构 架构是个啥东西架构的设计思想为啥要使用架构类库的设计结构1.Web UI 自动化测试结构2.Appium 自动化测试结构使用架构遇到的坑面试官:小鱼,你来说说自动化测试架构是啥,怎么理解自动化测试架构?小鱼心想:挖草~ ~ 你这个坑,你这一个问题,我都能写一篇文章了。奈何心里这样想的,也不能就这样表达出来,于是乎,小鱼就说:嗯,这问题,我可以从以下几点来慢慢说。架构是个啥东西软件架构(software architecture)是一系列相关的抽象模式,用于指导大型软件系统各个方...


面试官:小鱼,你来说说自动化测试架构是啥,怎么理解自动化测试架构?
小鱼心想:挖草~ ~ 你这个坑,你这一个问题,我都能写一篇文章了。奈何心里这样想的,也不能就这样表达出来,于是乎,
小鱼就说:嗯,这问题,我可以从以下几点来慢慢说。

架构是个啥东西

软件架构(software architecture)是一系列相关的抽象模式,用于指导大型软件系统各个方面的设计。软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。在实现阶段,这些抽象组件被细化为实际的组件,比如具体某个类或者对象。在面向对象领域中,组件之间的连接通常用接口来实现。
----->>>>官方解释的比较模糊,可能没涉及到架构的大佬,对这还是有一些模糊,
----->>>>小鱼直接大白话说一下:软件架构就是软件的基本结构,架构的本质是管理复杂性。由各个组件及其接口、元素构成的一些能够完成特定行为的组合。
扩展一下:
架构模式虽然有很多种,但是常用的也就是这几种:
分层架构
事件驱动架构
微核架构(又称插件架构)
微服务架构
云架构
>>>关于这些架构模式的构成及思想,我们就不在这里讨论了,不然就跑题了 - -!

架构的设计思想

1.高复用性:
用一套框架,来解决不同产品线的基础服务构建工作,通过引用框架方便公司对不同产品线的自动化实施进行整合。
2.易维护性
如果对框架的技术进行扩展,则只需要维护这一套框架即可,不需要根据产品线的不同,维护多套框架,节省时间,节省成本。
3.人员分离,专一性
业务人员只关注业务代码的脚本编写,不需要去专注框架技术上的问题;
架构人员只针对框架技术的实现,不需要对业务线的具体业务知识进行学习。
4.架构师考虑点:
①编码的选择
>> java ,python,ruby等
②核心技术的选择
>> Web: selenium
>>APP: Appium
③编码规范
>>类、方法、变量的命名方式
④用例设计规范
⑤代码管理方式
>> git or svn

为啥要使用架构

核心:解决脚本录制的常见问题,使得自动化稳定

1.把架构人员、脚本编写人员、用例执行人员分开;
>>架构大佬:精通代码设计
>>脚本编写大佬:了解代码
>>用例执行大佬:可以不懂代码
2.把UI对象通过自定义变量的方式赋值,增强了脚本的易读性;
3.通过封装Webdriver的API,使其更加健壮;
4.把常用的业务场景封装成业务方法,便于常用业务的复用;
5.把共通脚本单独封装,避免了脚本执行人员对测试脚本代码的修改;
6.生成Debug级别的log,使自动化脚本调试人员方便调试程序;
>> 关于log的级别,可以阅读这篇文章,Python的logging模块
7.生成回归级别的测试报告,便于不懂脚本的人员查看测试结果;
8.引用Suite执行多个脚本,进行运行脚本的管理;

类库的设计结构

1.Web UI 自动化测试结构

config 配置文件:
把经常需要修改的信息(例如:用户名,密码,环境)保留在配置文件中,以便经常调用。

common 公共方法
提供与Webdriver无关,但与自动化测试相关的API,包括:
①读取文件信息
②启动浏览器
③获取当前系统时间等

report
①测试报告:向项目经理、产品经理和老板汇报;
②调试日志:便于自动化脚本编写人员调试代码;

objectView
保存页面中的元素,当UI变化时修改对应变量即可,将可读性差的UI元素按照统一规则命名

Corelib
1.封装webdriver的api,使其更加健壮,形成自动化项目的api
2.提供断言的相关方法
3.自动化api提供详细的输出消息,便于调试
4.自动化api提供向测试报告中写入消息的方法

businessView
业务方法的封装,根据Corelib中的提供的API,把常用的业务场景封装成方法便于复用

data
保存输入的数据信息,作为架构与外部文件的接口

2.Appium 自动化测试结构

其实和Web UI的差不多,因为都是基于Pageobject 设计模式
这里就直接copy我之前写的框架结构就好。

app:测试包管理
|--------|-------如xx.apk

|-------baseView:一些基本类的封装
|--------|-------find_element()
|--------|--------find_elements()
|--------|--------get_window_size()

public:公共方法的封装
|--------|----------common_fun.py
|--------|-------------|--------check_cancel_Btn()
|--------|-------------|--------check_ship_Btn()
|--------|-------------|--------get_screenSize()
|--------|----------desired_caps.py
|--------|-------------|--------driver驱动封装
|--------|-------------|--------日志配置文件封装
|--------|-------------|--------启动APP配置参数
|--------|----------myunit.py
|--------|-------------|--------测试用例启动、关闭的封装
|
businessView:业务逻辑封装
|--------|----------loginView.py
|--------|-------------|--------登录相关的操作和方法
|--------|----------registerView.py
|--------|-------------|--------注册相关操作和方法

config:存放配置文件
|--------|----------caps.py
|--------|-------------|--------capability数据配置
|--------|----------log_conf.py
|--------|-------------|--------日志配置文件

data:存放数据驱动
|--------|----------account.csv
|--------|-------------|--------用户名、密码
|
log:存放生成日志
|--------|----------runlog.log

report:存放测试报告
|--------|----------report.html
|
screenshots:存放截图

test_case:存放测试类的模块
|--------|----------test_login.py
|--------|-------------|--------登录测试类封装:LoginTest
|--------|-------------|--------调用LoginView类的方法来编写用例
|--------|----------test_register.py
|--------|-------------|--------注册测试类封装:RegisterTest
|--------|-------------|-------调用RegisterView类的方法来编写用例

test_run:执行测试脚本
|--------|----------run.py
|--------|-------------|--------自动化测试用例执行入口
|--------|-------------|--------生成测试报告

如果觉得不太直观,可以参照小鱼写过的这篇文章:
《Appium自动化框架从0到1之 框架结构组成》
注:
因为不同的项目,可能封装的结构有区别,但是,万变不离其中,只要掌握了其中的思想,无非就是,如: log文件是单独拉出来,还是归于repor文件夹下。
就是这么简单。。

使用架构遇到的坑

接下来,小鱼就简单说几个,在项目中出现的遇到的坑。
1.页面元素变化,那么怎么更新ui的变量呢
>>只要更新objectView 即可
2.框架已封装的方法,编写脚本大佬不调用,怎么办?
>>这是小鱼在check脚本的时候,发现的,遇到这种问题,就要及时通知,及时提醒,及时修正。这就是不怕一万就怕万一啊!
3.脚本执行fail,怎么确定是架构的api问题,还是程序本身的缺陷?
>>这个问题,小鱼问过求职者,回答啥样子的都有,咱就不说了,咱直接说从哪里验证吧: 出现问题,无非就两点:
①先查看fail的原因,怎么查,看log;
②手工验证此功能;
4.当前架构的api无法满足当前项目的需要,怎么扩展?
>>直接重写架构的api或者添加api(看无法满足情况,再根据实际情况,一般添加api即可);
>>写一个新类继承架构中的Corelib,在这个类中完善api
注:一般情况,架构师就搞定了。
5.当架构需要添加新功能时需要如何接入?
>>写一些类完成所需功能,然后提供调用接口在架构中使用

大佬之所以叫大佬,都是踩着坑过来的;
不要去羡慕那些大佬,因为他们曾经也是菜鸟;

俗话说:
你不采坑,怎么成为大佬;
你不背锅,怎么成为老大。

愿每个人都能成为大佬中的老大。

本文地址:https://blog.csdn.net/wuyoudeyuer/article/details/107375408