自动化接口测试工作准备（接口自动化测试项目实战）

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

本文目录一览：

• 1、如何进行接口自动化测试
• 2、接口自动化测试流程是怎样的？
• 3、如何有效的开展自动化测试
• 4、如何简单实现接口自动化测试
• 5、Jmeter实现接口测试
• 6、如何创建 python+requests接口自动化测试框架

如何进行接口自动化测试

曾经有一段时间自动化接口测试工作准备，人们习惯于在MSExcel里面编写单元测试用例，然后开发人员就按照单元测试用例一步一步的来实现用例。这通常是很耗时的漫长的过程，尤其是如果应用很大或者UI很复杂的话。这一套单元测试的执行过程常常成为瓶颈，因为任何代码修改都会带来手工执行大量单元测试，以确保新的修改没有破坏原有功能。如今是个快节奏时代，人们希望工作能够无需人工介入、自动化的快速完成。每个人都喜欢执行一个命令就能把工作搞定，而且在执行期间不需要人工介入。需要做的仅仅是检查一下最终的输出结果。当这个世界正在迈向自动化时，自动化测试也不甘落后，不论是在功能测试方面还是UI测试方面。每天我们都能听说自动化测试方面涌现出的新软件。本文提供了一些信息给那些想用CodedUI自动测试框架来进行应用界面自动化的.Net开发者。什么是CodedUI?最近我一直在寻找一个自动化的用户接口测试的解决方案。用户接口测试需要用户多次进行手工输入操作，这是一个既枯燥又费时的过程。因此，我想寻找一种更智能的自动化UI测试的方案，这种UI测试在不需要人工干预下，能够被保存，记录并提供支持，快速测试代码的改变。CodedUI采用用户接口来驱动应用的进行自动化测试。这些测试包括UI控制的功能性测试。自动化接口测试工作准备他们使自动化接口测试工作准备你可以验证整个应用的功能是否正确，其中包括了用户接口。CodedUI尤其适合用于用户接口中存在校验或者其它的登录方式的测试，比如网页。CodedUI也可以用于人工测试用例的自动化。CodedUI测试帮助用户测试应用程序的用户接口。这些测试允许用户验证应用程序的功能。CodedUI多数时间用于帮助验证在UI层本身的有效逻辑。它能够验证值对用户接口的控制的正确性。其它方案市场有许多自动化用户接口的方案，比如HP的QuickTestProfessional,IBMRationalFunctionalTester.其它著名的，易于使用的开源工具解决用户接口自动化问题的有Selenium，也能够记录测试，需要的时候回放。市场上还有来自Microsoft的也能不需要太多努力做同样的事。用VisualStudioMicrosoft还有CodedUI的方案用于单元测试。CodedUI适合在哪儿用?大多数安装了VisualStudio的开发者都喜欢在VisualStudio的环境里进行单元测试，而不是使用第三方工具。由微软提供的CodedUI，在VisualStudio环境里可谓上手即用。在开发者的机器上无需另外安装任何东西。一旦你安装了VisualStudio的Premium版或者Ultimate版，你就同时也安装好了CodedUI。CodedUI可用性为了使用CodedUI，需要安装VisualStudio2010/2012/2013的Premium版或者Ultimate版。CodedUI测试的组成CodedUI测试的组成容易理解。它可分成下列文件：UIMap.uitest这个文件是UIMap类的XML表示。UIMap类包括视窗，控件，属性，方法，断言和动作。UIMap.cs对UIMap的自定义部分都存在这文件里。如果修改直接存在UIMap.designer.vb文件的话，那些修改都会在记录结束后丢失，因为这个文件重新创建了。给每个在测应用程序中的每个模块创建一个独立的UIMap文件。UIMap.Designer.cs这是部分类表达各种类。这各种类是给多样的控件和他们的范围，属性，方法的类。提示：不要直接修改UIMap.Designer.cs。加入你这样做，这个修改会被覆盖掉。CodedUITest.cs这类表示的实际的CodeUI测试类，方法调用，和断言调用，所有的方法和断言默认都是从UIMap.Designer.cs文件调用的。这类有具有【codedUITest]属性TestClass和包含具有【TestMethod]属性的多种方法。CodedUI的特性/好处进行用户界面测试的同时进行校验.生成VB.Net/C#代码.测试用例可以被记录和重放.集成了ALMStory能够作为每日构建的一部分来运行.根据需要进行高级扩展.和VisualStudio集成在一起，所以无需单独购买许可.CodedUI对Web和Windows应用同样适用.著名的Microsoft支持.创建CodedUI测试CodedUI测试可以用下列方式创建使用MTM进行快速自动构建从现有的记录(从手动测试中记录下来的操作)中创建CodedUI在CodedUITestBuilder创建的底稿的基础上创建一个新的CodedUI测试.自己写CodedUI.这个白皮书的范围仅限于“在CodedUITestBuilder创建的底稿之上创建一个新的CodedUI测试”。小贴士:尽量使用CodedUITestBuilder。CodedUITestBuilder每一个CodedUI测试的生成都需要遵从下列步骤.记录/停止/暂停编辑记录下来的步骤添加断言生成代码创建CodedUI测试创建新的CodedUI项目要开始使用CodedUI，首先我们需要创建一个测试项目，用来保存所有CodedUI测试。创建一个新的CodedUI项目包含下列步骤打开VisualStudio2012选择FileNewProject选择需要的语言模板(C#orVB.Net).我们选择了C#.选择CodedUIProject输入一个名字点击OK按钮添加CodedUI测试VisualStudio默认配置为创建CodedUI测试使用"GenerateanewCodedUITestfromscratchusingCodedUITestBuilder"提示：在测试的应用程序中，当你创建UI控件时尽量使用有意义的名称，从而对于自动生成的控件显得更加有意义和可用。一旦CodedUI测试工程创建完成，将会自动打开生成CodedUI测试代码的对话框，请给出以下选项的设置。记录操作，编辑UI地图或添加断言使用一个已经存在的操作记录默认情况下选择记录操作,编辑UI地图或添加断言，无需做任何操作，然后点击"ok"CodedUITestBuilder选择了上述选项后，CodedUITestBuilder就会被打开，同时VisualStudio窗口被最小化。这意味着我们已经为记录操作做好了准备。正如之前描述的，CodedUITestBuilder基于下列4个操作来做记录RecordStepsUpdateorDeleteStepsVerifyResults(AddAssertions)GenerateCode小贴士:如果用户界面(UI)变化了，就重新记录测试方法或断言方法，或者重新记录一个既有测试方法中受影响的部分。记录一个序列的操作.记录一个操作主要需要下列几步.StartRecording,通过选择Record按钮即可.PauseRecording,用来处理记录过程中的其它操作，即GenerateCode.Edit/Delete操作,以防错误的操作被记录。Generatecode为记录下来的操作创建编号。会给每一个记录下来的操作都生成编号。AddAssertions用来校验结果。小贴士:创建断言最好使用CodedUITestBuilder，因为它会在UIMap.Designer.cs文件中自动添加一个断言方法。为记录动作做计划任何事情的成功都取决于它计划得有多好。较好地计划最大限度保证了任务成功完成。这样总是比较好，在开始记录动作之前，我们计划好所有的所有要计划的步骤。这里我们将要使用应用程序Windows计算器来记录步骤。我们要自动地加和减两个数字。在记录加和减两个数字的时候，下面的步骤将会用到。。点击“开始记录”控件。到开始，点击执行。在执行窗口，输入”calc"。停止记录，看记录的步骤。删除错误的步骤（存在的话）。产生代码；提供和动作相匹配的名字。比如，打开计算器。提示：当你产生一个方法时候，使用一个有意义的方法的名字，代替默认名字。有意义的名字帮助识别方法的木的。。重新记录，提供第一个数字，暂停记录产生代码。重新记录，提供操作（加或者减），暂停记录，产生代码。重新记录，提供第二个数字，暂停记录，产生代码。。加断言提示：产生你的测试作为一系列记录的方法提示：可以的时候，限制每个方法小于10个动作。这模块化的方法让UI改变时候容易替换方法。我们已经看到了CodedUI可以使开发者的生活变得多么轻松，尤其是遇到每次都需要进行很多输入的复杂页面的时候。这时，测试用例只需要被记录一次，就可以按照需要执行任意多次。使用CodedUI比使用其它工具的好处是，它能自动适配Web页面和Windows窗口应用。CodedUI测试可以用VisualStudio2010来运行，也可以用任何版本的VS来运行，它们的功能正变得越来越强大。无需多说，CodedUI是一个由技术领导者提供的强大工具，想要体验CodedUI测试的强大，我们应该开始在项目中使用它看看它能带来多少ROI，我确信CodedUI不会让你失望。

接口自动化测试流程是怎样的？

接口自动化：
如果是那种http协议的接口
那么第一种，使用eclipse
自己封装下httpclient
，然后自己写java脚本进行接口测试
这种要麻烦点
第二种，使用jmeter工具，这个是专门针对http接口的进行性能以及接口测试工具

如何有效的开展自动化测试

自动化测试不宜大力投入
不管是自动化测试还是接口测试，都不宜在前期大量投入。当前业务是否适用自动化，哪些框架或者工具更适合，适合做接口自动化还是 UI 的自动化？如何让自动化达到收益和效果？
这些问题都需要根据团队和业务具体的情况去尝试，找到合适的才行。如果前期投入太大，团队对其期望太高，非常容易在遇到一点挫折的时候对自动化丧失信心。
另外，投入太大，毕竟加大人力或者减少手工测试的投入，会造成测试资源的紧张。在项目时间和成本的压力下，测试管理者需要顶着巨大的压力，这本身就很难成功。
可以安排一些技术强或者技术兴趣浓厚的成员，在项目允许的情况下减少其手工测试工作量，让其可以利用部分工作时间和部分业余时间尝试做自动化，先局部功能尝试，能够有效果，在扩大范围。逐步达到一定的自动化规模。
以接口为主UI为辅
UI 自动化因其运行环境的问题，会导致运行速度慢，对环境依赖过高。同时因程序界面的多变性，导致自动化脚本维护成本大大增加。
接口测试有很多优于 UI 自动化的地方。但是接口测试也自有其短板，对流程性质的测试并不适合用接口自动化来覆盖。接口自动化更适合覆盖单一接口功能的检查。
所以我们可以采用核心业务流程使用 UI 自动化，单一功能使用接口自动化，两种层面的自动化结合的方式来进行。
不轻谈自动化测试平台
目前测试界开始流行起自己开发测试平台（以接口为主）。简单来说就是模仿常见的接口测试工具，用 Python 或者 Java 写成了一个 web 版本的。
当然也有其理由，“定制性更强！”但是毕竟是软件都需要进行测试，花大量精力开发的平台并不稳定，而本身功能和理念上并没有太多更新。而这样的一些功能，市面上的绝大部分测试工具都能胜任。
如果是为了提高个人能力，项目时间有空余，怎么玩都可以。若是要在实际工作中应用，那么就有点得不偿失了。
自动化测试中，工具的重要性始终是最低的。理念、思维和环境治理才是最重要的。
通过不断小范围试错，找到适合自己团队的自动化策略才是最重要的。任何技术脱离实际应用都是耍流氓。

如何简单实现接口自动化测试

接口自动化有两种方式：
一种是借助第三方工具，例如postman、jmeter；
另一种是基于开源的框架做自动化测试，例如selenium；
selenium 包含适配java、python等不同语言版本。
希望我的回答能帮助你

Jmeter实现接口测试

利用Jmeter做接口测试怎么做呢自动化接口测试工作准备？过程真的是超级简单。

明白自动化接口测试工作准备了原理以后自动化接口测试工作准备，把零碎的知识点填充进去就可以了。所以在学习的过程中，不管学什么，我一直都强调的是要循序渐进，和明白原理和逻辑。这篇文章就来介绍一下如何利用Jmeter做接口测试的流程，主要针对的是功能测试。暂不涉及到自动化测试和性能测试的内容。

一把来说，主要的步骤都大差不差。

第一步：通过分析API文档和需求文档提取接口清单 。

也就是说，接口测试工作人员工作的开始就是从API文档和需求文档开始的。所以进入公司的第一件事情就是要拿到API文档和需求文档来了解，来看，来分析。从其中提取接口清单的话，主要是因为API文档中有很多冗余，不必要的信息。这些信息可能对于开发人员是有用的，但是对于我们测试人员是没有用的，所以要去除冗余，提取关键信息。

那么怎么提取呢？方法也很简单，从功能模块和方法模块对API文档中的内容进行提炼，提炼的关键是接口三要素：url+方法+参数+返回值。我的建议是可以先将所有的url提取出来，基本上一个url就是对应一个接口的，这样一条线把整体拎起来，就感觉混乱的局面清晰多了。

当然工作中，有的时候我们是可以直接拿到接口清单的，因为清单这个事情一个团队做一份就好了，并不是说要每个人都做一份。但是我们自己得会，得有这个能力。之前看到过一个面试题，问的是，如果没有API文档，怎么做接口测试？

其实问的就是如果没有API文档，应该怎么提取接口清单的问题。很简单，根据需求文档和原型图来提取。有的公司不正规，确实是没有API文档的。或者有的公司API文档写的不规范，那提取的时候，就很考验测试人员的经验和能力了。所以如果能找到遵循restful风格写的优秀API文档，那就好了，提取的时候很方便。

第二步：针对接口清单，做单接口测试和关联接口测试。

在实际测试过程中，单接口测试和关联接口测试的时间是不一样的，这涉及到业务逻辑测试和功能点测试等。但是在测试的时候，他们的逻辑和方法是类似的。

当然这里主要介绍的是单接口测试，因为单接口测试时会考虑各种可能的情况，而关联接口测试一般是建立在单接口没有问题的前提下的。换个角度来说，就相当于是两个层次，单接口测试是基础，而关联接口测试是拔高。

那么具体应该怎么做呢？比如我们这里已经选定而来某一个接口来测试。

首先，根据选定的接口来搭建测试框架 。

接口不是什么大不了的事情，无非就是url、方法、参数、返回数据这四块。这样就意味着，一个接口的框架是固定的，只不过每次传输的数据和返回的数据可能会不一样而已。所以我们要做的第一步就是搭建测试框架。

那么怎么搭建呢？这里就要用到从API文档中整理出来的接口清单和Jmeter了。从接口清单里，可以拿到当下接口的url+方法+参数+预期返回数据。这就是我们搭建测试框架的依据。接下来用Jmeter搭建。

首先需要打开Jmeter，然后基于测试计划，创建线程组，基于线程组创建HTTP请求。考虑到单接口测试，一个框架，要测试N多个数据，而且后面的接口可能也要用到同样的ip地址、同样的content-type，所以一般会先创建一个HTTP请求默认值，将一些可能会重复用到的信息填进去，比如说端口号、协议之类的。如有必要还需要添加HTTP信息头管理器，放一些user-agent、content-type等内容。

好的，有了这两个基础就可以来创建HTTP请求。在新的请求里，已经填写的端口号呀、ip地址呀之类的就无需填写了，只需要填写方法之类的即可。那么搭建框架在哪里搭建呢？一般会考虑para或者body里。比如说，要提交一段json格式的数据，那么就要用body（消息体）来提交，如下图所示。

将从接口清单里拿到的json数据填写到消息体数据里，然后将需要不断传入的数据进行参数化设置，那搭建测试框架就算是完成了。接下来只需要把数据一条一条传入进行测试即可。

那么如何把数据进行传入呢？

其实我们在下面的这篇文章里已经介绍了，传入数据的方法有四种，但主要使用的还是csv data set config 和函数。做功能接口测试，用csv就足够了。那么具体怎么用呢？

星空下：软件接口测试工具Jmeter使用核心详解12 赞同 · 0 评论文章

基于当前的线程组或者请求创建CSV数据文件配置组件。如果这份数据只有这一个请求会用，那么就基于请求创建即可。如果这份数据会被这个线程组里的多个请求使用，那么就基于线程组创建。

创建了以后就需要填入文件了呢？可是文件在哪里呢？这个时候就要稍微停一下jmeter的操作，先去针对当前接口设计测试用例并形成有关文档了。有关于功能接口测试的用例设计，我们之后会专门用一篇文章来介绍，这里先带过。这是因为设计测试用例是做测试过程中最核心的一步。

在测试用例设计完之后，可以将其保存在一个txt文档里，采用utf-8编码，保存到Jmeter脚本的同一父目录下。然后按照上面那篇文章里的设置方法进行设置即可，注意路径可以采用相对路径，便于数据文件的拷贝和使用。

csv组件设置好以后，数据源有了，变量名有了，变量名的赋值也有了，接下来就只剩引用参数就可以了。在测试框架里需要引用参数的地方引用，引用的格式是${参数名}。到这里，针对于某一个接口的测试工作就准备完成了。

然后在Jmeter里面添加查看结果树组件，执行请求，依次查看结果 。看一看返回的数据和我们的预期结果是否一致，不一致，那可能就是一个bug。

做一个小小的总结吧，用jmeter做功能接口测试，其实很简单的。逻辑和原理都是类似的，如果遇到新的项目，可能说会用一些新的组件而已，那百度一下几分钟的事情。在学习软件测试的时候，最重要的就是不要怂，不要看起来说怎么要学的东子这么杂这么多，只要能够拎出其中的线索和主干，然后把一些零碎的点给组装上去，就会感觉，哇，忽然之间，好有条理。

如何创建 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会通过控制台查看） 关于自动化接口测试工作准备和接口自动化测试项目实战的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 自动化接口测试工作准备的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于接口自动化测试项目实战、自动化接口测试工作准备的信息别忘了在本站进行查找喔。

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