接口自动化框架分层（接口自动化设计模式）

本篇文章给大家谈谈接口自动化框架分层，以及接口自动化设计模式对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享接口自动化框架分层的知识，其中也会对接口自动化设计模式进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、如何创建 python+requests接口自动化测试框架
• 2、接口自动化测试工具有哪些？
• 3、怎么学习自动化测试？
• 4、软件架构入门-分层架构、事件驱动、微服务架构和云原生架构

如何创建 python+requests接口自动化测试框架

工作原理: 测试用例在excel上编辑，使用第三方库xlrd，读取表格sheet和内容，sheetName对应模块名，Jenkins集成服务发现服务moduleName查找对应表单，运用第三方库requests请求接口，根据结果和期望值进行断言，根据输出报告判断接口测试是否通过。
1. 数据准备
数据插入（容易实现的测试场景下所需外部数据)
准备sql （接口需要重复使用，参数一定得是变量)
2.集成部署(运维相关了解即可)
平滑升级验证脚本加入自动化
3.自动化框架实现
调用mysql
excel遍历测试用例
requests实现接口调用
根据接口返回的code值和Excel对比
报告反馈
暴露服务
写一个简单登录的接口自动化测试
代码的分层如下图：
coding.png
一、写一个封装的获取excel表格的模块
excel.png
代码实现如下：
# !/usr/bin/python
# -*- coding: UTF-8 -*-
# 基础包：excel的封装
import xlrd
workbook = None
def open_excel(path):
"""打开excel"""
global workbook
if (workbook == None):
workbook = xlrd.open_workbook(path, on_demand=True)
def get_sheet(sheetName):
"""获取行号"""
global workbook
return workbook.sheet_by_name(sheetName)
def get_rows(sheet):
"""获取行号"""
return sheet.nrows
def get_content(sheet, row, col):
"""获取表格中内容"""
return sheet.cell(row, col).value
def release(path):
"""释放excel减少内存"""
global workbook
workbook.release_resources()
del workbook
代码封装后当成模块引用，这还是最开始呢。
二、引用log模块获取日志
准备工作：
需要一个日志的捕获，包括框架和源码抛出的expection。
代码如下：
#!/usr/bin/python
# -*- coding: UTF-8 -*-
# 基础包：日志服务
import logging
import time
def getLogger():
global tezLogPath
try:
tezLogPath
except NameError:
tezLogPath = "/data/log/apiTest/"
FORMAT = '%(asctime)s - %(name)s - %(levelname)s - %(message)s'
# file = tezLogPath + time.strftime("%Y-%m-%d", time.localtime()) + ".log"
# logging.basicConfig(filename=file, level=logging.INFO, format=FORMAT)
# 开发阶段为了方便调试，可不输出到文件
logging.basicConfig(level=logging.INFO, format=FORMAT)
return logging
三、引用requests模块接口测试
准备工作：
需要的请求类型和执行测试的方法。
代码如下：
#!/usr/bin/python#
#-*- coding: UTF-8 -*-
# 基础包：接口测试的封装
import requests
import tezLog as log
logging = log.getLogger()
def api_test(method, url, data ,headers):
"""
定义一个请求接口的方法和需要的参数
:Args:
method - 企业名称 str
url - 用户昵称 str
data - 参数 str
headers - 请求头信息 dict
非RESTful API请求另外的请求类型实际用不到。也不安全。
"""
try:
if method == "post":
results = requests.post(url, data, headers=headers)
if method == "get":
results = requests.get(url, data, headers=headers)
# if method == "put":
# results = requests.put(url, data, headers=headers)
# if method == "delete":
# results = requests.delete(url, headers=headers)
# if method == "patch":
# results == requests.patch(url, data, headers=headers)
# if method == "options":
# results == requests.options(url, headers=headers)
response = results.json()
code = response.get("code")
return code
except Exception, e:
logging.error("service is error", e)
def run_test(sheet):
"""
定义一个执行和断言的方法
:Args:
sheet - 服务名称 str（excel页脚名称识别的）
"""
rows = excel.getRows(sheet)
fail = 0
for i in range(2, rows):
#这里为什么从第二行开始跑，因为会先执行SQL进行数据准备如之前Excel展示的空白位置
testData = excel.getContent(sheet, i, gl.CASE_DATA)
testUrl = excel.getContent(sheet, i, gl.CASE_URL)
testMethod = excel.getContent(sheet, i, gl.CASE_METHOD)
testHeaders = eval(excel.getContent(sheet, i, gl.CASE_HEADERS))
testCode = excel.getContent(sheet, i, gl.CASE_CODE)
actualCode = request.apiTest(testMethod, testUrl, testData, testHeaders)
expectCode = str(int(testCode))
failResults = ' url: ' + testUrl + ' params: ' + testData + ' actualCode: ' + actualCode + ' expectCode: ' + expectCode
if actualCode == expectCode:
logging.info("pass")
elif actualCode != expectCode:
logging.info("fail %s", failResults)
fail += 1
if fail 0 :
return False
return True
四、关于参数中gl模块
准备工作：
所有的参数和常量我们会整理到这个文件中，因为设计业务和服务密码、数据库密码这里展示一部分。
代码如下：
#!/usr/bin/python
# -*- coding: UTF-8 -*-
# 脚本功能：全部变量
import time
import uuid
CASE_NUMBER = 0 # 用例编号
CASE_NAME = 1 # 用例名称
CASE_DATA = 2 # 用例参数
CASE_URL = 3 # 用例接口地址
CASE_METHOD = 4 # 用例请求类型
CASE_CODE = 5 # 用例code
CASE_HEADERS = 6 # 用例headers
SQL_ROW = 0 # 预执行SQL的行号
SQL_COL = 1 # 预执行SQL的列号
五、写一个run文件：只是用来执行的，业务和代码剥离。
代码如下：
#!/usr/bin/python
# -*- coding: UTF-8 -*-
# 验证包：接口测试脚本
import sys
import core.tezLog as log
import function.common as common
logging = log.getLogger()
"""1.外部输入参数"""
path = sys.path[0] # 当前路径
module = sys.argv[1] # 服务模块名
url = sys.argv[2] # 服务地址
host = sys.argv[3] # 数据库地址
user = sys.argv[4] # 数据库用户名
password = sys.argv[5] # 数据库密码
db = sys.argv[6] # 数据库名称
"""2.根据module获取Sheet"""
logging.info("-------------- Execute TestCases ---------------")
sheet = common.get_excel_sheet(path + "/" + common.filename, module)
"""3.数据准备"""
logging.info("-------------- Prepare data through MysqlDB --------------")
sql = common.get_prepare_sql(sheet)
common.prepare_data(host=host, user=user, password=password, db=db, sql=sql)
"""4.执行测试用例"""
res = common.run(sheet, url)
logging.info("-------------- Get the result ------------ %s", res)
"""这里的res是我们平滑升级的时候需要返回结果为TRUE才会继续下面走。"""
六、查看测试报告（部署到jenkins会通过控制台查看）

接口自动化测试工具有哪些？

1、CTS，CTS 测试基于Android instrumentation 测试， 其又基于JUnit 测试。说白了， CTS 就是一堆单元测试用例。这也是Java 语言接口自动化框架分层的擅长部分。
2、 Monkey工具，Monkey是Android中的一个命令行工具，可以运行在模拟器里或实际设备中。它向系统发送伪随机的用户事件流(如按键输入、触摸屏输入、手势输入等)，实现对正在开发的应用程序进行压力测试。Monkey测试是一种为了测试软件的稳定性、健壮性的快速有效的方法。
3、ASE，ASE 意思为Android 脚本环境， 即接口自动化框架分层我们可以通过脚本（比如Python）调用Android 的功能，从而定制一些测试。比如打电话，发短信，浏览网页，等。我们可以扩充它的API（Java 部分）, 并用python 脚本调用这些API, 从而实现丰富的测试功能。用于API 部分可以访问到Android 全部API, python 又能灵活部署测试，所以ASE 的扩展性非常好。
4、Robotium，该工具用于黑盒的自动化测试。可以在有源码或者只有APK 的情况下对目标应用
进行测试。Robotimu 提供了模仿用户操作行为的API，比如在某个控件上点击，输入Text
等等。 http://mag.big-bit.com/
分层的自动化测试

这个概念最近曝光度比较高，传统的自动化测试更关注的产品UI层的自动化测试，而分层的自动化测试倡导产品的不同阶段（层次）都需要自动化测试。
相信测试同学对上面的金字塔并不陌生，这不就是对产品开发不同阶段所对应的测试么接口自动化框架分层！我们需要规范的来做单元测试同样需要相应的单元测试框架，如java的Junit、testNG，C#的NUnit ，python 的unittest、pytest 等，几乎所有的主流语言，都会有其对应的单元测试框架。
集成、接口测试对于不少测试新手来说不太容易理解，单元测试关注代码的实现逻辑，例如一个if 分支或一个for循环的实现接口自动化框架分层；那么集成、接口测试关注的一是个函数、类（方法）所提供的接口是否可靠。例如，我定义一个add()函数用于计算两个参数的结果并返回，那么我需要调用add()并传参，并比较返回值是否两个参数相加。当然，接口测试也可以是url的形式进行传递。例如，我们通过get方式向服务器发送请求，那么我们发送的内容做为URL的一部分传递到服务器端。但比如 Web service 技术对外提供的一个公共接口，需要通过soapUI 等工具对其进行测试。
UI层的自动化测试，这个大家应该再熟悉不过了，大部分测试人员的大部分工作都是对UI层的功能进行测试。例如，我们不断重复的对一个表单提交，结果查询等功能进行测试，我们可以通过相应的自动化测试工具来模拟这些操作，从而解放重复的劳动。UI层的自动化测试工具非常多，比较主流的是QTP，Robot Framework、watir、selenium 等。
为什么要画成一个金字塔形，则不是长方形 或倒三角形呢？ 这是为了表示不同阶段所投入自动化测试的比例。如果一个产品从没有做单元测试与接口测试，只做UI层的自动化测试是不科学的，从而很难从本质上保证产品的质量。如果你妄图实现全面的UI层的自动化测试，那更是一个劳民伤财的举动，投入了大量人力时间，最终获得的收益可能会远远低于所支付的成本。因为越往上层，其维护成本越高。尤其是UI层的元素会时常的发生改变。所以，我们应该把更多的自动化测试放在单元测试与接口测试阶段进行。
既然UI层的自动化测试这么劳民伤财，那我们只做单元测试与接口测试好了。NO! 因为不管什么样的产品，最终呈现给用户的是UI层。所以，测试人员应该更多的精力放在UI层。那么也正是因为测试人员在UI层投入大量的精力，所以，我们有必要通过自动化的方式帮助我们“部分解放”重复的劳动。
在自动化测试中最怕的是变化，因为变化的直接结果就是导致测试用例的运行失败，那么就需要对自动化脚本进行维护；如何控制失败，降低维护成本对自化的成败至关重要。反过来讲，一份永远都运行成功的自动化测试用例是没有价值。
至于在金字塔中三种测试的比例要根据实际的项目需求来划分。在《google 测试之道》一书，对于google产品，70%的投入为单元测试，20%为集成、接口测试，10% 为UI层的自动化测试。

怎么学习自动化测试？

首先，想从事自动化测试，必须先了解What/Why/How，也就是常说的去了解什么是自动化测试、为什么要进行自动化测试、该如何进行自动化测试，这类的资料在网上有很多，这里就不做重复了； 其次，需要根据项目的特点，选择合适的自动化测试工具，并了解工具的特性。以QTP为例，该如何去掌握它呢？对于初学者，大多数都是通过录制的方式来生成脚本，这个阶段应该掌握的基础知识有：1) QTP是如何去识别对象的，对于新手经常会出现录制的脚本回放的时候报错的现象，这个时候就应该考虑为什么呢？如果很了解QTP识别对象的原理啊，我想就能很快定位到原因了2) 去掌握一些QTP对象的方法，如GetROPreperty、GetTOPreperty、ChildObjects等等，对于相似的方法应该去搞清楚到底区别在哪？像GetROPreperty、GetTOPreperty有什么区别等3) 什么是Action参数、什么又是Test参数？两者有什么区别，又有什么联系，在同一Test和不同Test间这些参数如何工作4) 什么是环境变量？环境变量是如何建立和使用的，环境变量在参数传递中和action参数、test参数有什么不同5) 了解检查点的知识，明白什么是内置检查点，什么又是自定义检查点。并搞清楚在什么时候该如何使用检查点6) 掌握对象库的操作，了解对象库对于测试的意义，象是否启用智能识别对测试脚本有何影响、为什么同一对象识别起来会有_1、_2之类的后缀等都是需要去研究清楚的问题这几个问题都搞清楚的话，那基本就能够利用QTP生成正确的脚本了，当然以上只是部分必须掌握的内容，其实还是很多细节的设置，就需要在实际运用中去掌握了。接下来，就可以进一步提升自己的QTP运用水平了，这个阶段就需要去学习vbs知识和如何运用描述性编程实现脚本了，同时在这个过程中还需要去学习html知识、DOM、XML、以及像excel、word等的API知识了，总的来说，这个阶段应该掌握的内容大体上包括：1) VBscrīpt的基础知识，熟悉常用的方法和函数，掌握文件对象的操作等2) 熟练掌握XML技术；excel、word等API对象，可以根据需要创建日志等3) 熟练掌握DOM和HTML知识，能够结合这些技术对Web页面进行解析4) 掌握数据库的基本操作语句，能够利用ADO对象进行数据操纵5) 熟练掌握正则表达式，很多时候处理对象问题相当方便6) 掌握如何调用dll进行工作7) 能够利用QTP的自动化对象模型创建出需要的运行模式8) 掌握WMI知识以上只是我考虑到的部分，并不全面，呵呵，供大家参考，当然这些技术主要是针对Web系统运行，因为我们的系统就是B/S的，呵呵。如果这些知识都能够扎实的掌握的话，个人认为，基本上能够处理自动化过程中的绝大多数问题了，这个时候你对自动化测试的技术应该是有一定积累了。接下来就需要考虑自动化测试框架问题了。当脚本规模到了一定的程度，就会面临一些问题，如：1) 如何有效的管理并调度脚本2) 如何实现脚本运行的无人值守，测试过程中能够自动进行错误处理并进行日志记录3) 如何生成简介明确的测试报告4) 如何能够更加高效的维护测试脚本5) 实现框架代码和业务代码的分层、业务脚本和业务数据的分离这个阶段主要体现的是测试人员的测试思想，是可以脱离工具独立存在的过程。当然各个公司项目的实际情况不同，导致设计出来的思想不同，但总体上来说一般包括数据驱动和关键字驱动两种模式。后者实现的技术难度大于前者，大多数公司目前都采用的数据驱动模式。这个阶段不应局限于技术运用上，而需要从测试全局考虑，进行分层设计、模块化实现，减少代码之间的耦合。如果以上三个方面都能够做的很好的话，那么恭喜你，你已经可以独立负责项目的自动化测试建立工作了，呵呵！总之，学习自动化测试需要在实际项目中进行，这样提高的会比较快，项目中运用了很多种技术，自动化实施过程会碰见各种各样的问题，是很好的学习机会，关键要善于总结、积累经验，只要能够把各个细节做好，那么你一定能够成为一名优秀的自动化测试工程师。

软件架构入门-分层架构、事件驱动、微服务架构和云原生架构

软件架构（software architecture）就是软件接口自动化框架分层的基本结构。

合适的架构是软件成功的最重要因素之一。大型软件公司通常有专门的架构师职位（architect）接口自动化框架分层，只有资深程序员才可以担任。

O'Reilly 出版过一本免费的小册子《Software Architecture Patterns》（PDF）， 介绍接口自动化框架分层了五种最常见的软件架构，是非常好的入门读物。

软件架构就是软件的基本结构。架构的本质是管理复杂性。 如果你觉得架构不重要，可能是你做的事情不够复杂，或者是你没有管理好复杂性。架构模式虽多，经过抽象沉淀之后，也就那么几种：

1. 分层架构（比较传统的单体架构）

2. 事件驱动架构 （一般适用于应用局部场景，用来实现异步解耦）

3. 微核架构（又称插件架构，开发难度较高，一般用来做工具软件开发，如Eclipse，不太适合分布式业务场景）

4. 微服务架构（当前比较流行的服务化架构，解决单体架构面临的问题，适合敏捷开发，快速迭代）

5. 云架构（现在的说法是云原生架构-Cloud Native，基于Docker、Kubernetes、Service Mesh 云原生架构）

在原文的基础上，我按照自己的想法，进行了小幅调整。

分层架构（ layered architecture ）是最常见的软件架构，也是事实上的标准架构。如果你不知道要用什么架构，那就用它。

这种架构将软件分成若干个水平层，每一层都有清晰的角色和分工，不需要知道其他层的细节。层与层之间通过接口通信。

虽然没有明确约定，软件一定要分成多少层，但是四层的结构最常见。

有的软件在逻辑层（business）和持久层（persistence）之间，加了一个服务层（service），提供不同业务逻辑需要的一些通用接口。

用户的请求将依次通过这四层的处理，不能跳过其中任何一层。

优点

缺点

事件（event）是状态发生变化时，软件发出的通知。

事件驱动架构（event-driven architecture）就是通过事件进行通信的软件架构。它分成四个部分。

事件驱动架构（event-driven architecture）核心组件：

对于简单的项目，事件队列、分发器和事件通道，可以合为一体，整个软件就分成事件代理和事件处理器两部分。

优点

缺点

事件驱动架构在通信产品中应用得也非常广泛，典型的如状态机处理。 事件驱动架构不适于做顶层架构，但适合做局部实现，几乎遍布在通信软件的各个角落。

微核架构（microkernel architecture）又称为"插件架构"（plug-in architecture），指的是软件的内核相对较小，主要功能和业务逻辑都通过插件实现。

内核（core）通常只包含系统运行的最小功能。插件则是互相独立的，插件之间的通信，应该减少到最低，避免出现互相依赖的问题。

优点

缺点

微核架构的设计和开发难度较高，这就注定它在企业产品中用得不多，虽然它的优点还不少。

微服务架构（microservices architecture）是服务导向架构（service-oriented architecture，缩写 SOA）的升级。

每一个服务就是一个独立的部署单元（separately deployed unit）。这些单元都是分布式的，互相解耦，通过远程通信协议（比如REST、SOAP）联系。

微服务架构分成三种实现模式。

现在开源的微服务框架比较多，如常用的有Spring Cloud、Dubbo、ServiceComb等等。

优点

缺点

云架构（cloud architecture，现在的说法是云原生-Cloud Native）主要解决扩展性和并发的问题，是最容易扩展的架构。

它的高扩展性，主要原因是可以基于云上计算资源弹性伸缩。然后，业务处理能力封装成一个个处理单元（prcessing unit）。访问量增加，就新建处理单元（Docker容器）；访问量减少，就关闭处理单元（Docker容器）。由于没有中央数据库，所以扩展性的最大瓶颈消失了。由于每个处理单元的数据都独立分库。

这个模式主要分成两部分：处理单元（processing unit）和虚拟中间件（virtualized middleware）。

虚拟中间件又包含四个组件：

随着Docker、Kubernetes等容器化技术的快速发展，上述关于云架构描述有点陈旧了。当前最新的云原生架构，以Docker+Kubernetes为核心，尤其是容器编排Kubernetes 已经成为事实上的行业标准。

云原生架构图的主要特征：

主要目标：

1. 让开发人员聚焦业务逻辑的实现，其他交给容器云平台来完成；

2. 支持业务系统的快速迭代，支撑业务的快速变化和发展；

3. 构建以共享服务体系为核心的业务中台；

下面是我针对某新零售企业设计的云原生架构图，以云和微服务架构为基础构建云原生应用，这里云可以是公有云、私有云、混合云等等。

以上是从不同的视角，对架构进行了分类。实际应用中，各种架构并不是孤立的，可以根据业务环境和业务诉求，对各种架构进行综合和嫁接。每种架构都有其优点和缺点。优点不必多说，缺点则几乎都是通过工具工程（比如自动化发布工具、自动化测试等等）能力的方法来规避，工具工程对软件架构非常重要。

关于接口自动化框架分层和接口自动化设计模式的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 接口自动化框架分层的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于接口自动化设计模式、接口自动化框架分层的信息别忘了在本站进行查找喔。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。