接口测试

1、首先，我们先来理一下思路。 正常的接口测试流程是什么？ 脑海里的反应是不是这样的： 确定测试接口的工具 —> 配置需要的接口参数 —> 进行测试 —> 检查测试结果（有的需要数据库辅助） —> 生成测试报告（html报告） 那么，我们就根据这样的过程来一步步搭建我们的框架。在这个过程中，我们需要做到业务和数据的分离，这样才能灵活，达到我们写框架的目的。只要好好做，一定可以成功。这也是我当初对自己说的。 接下来，我们来进行结构的划分。 我的结构是这样的，大家可以参考下： ​​​​​​ common：存放一些共通的方法 result：执行过程中生成的文件夹，里面存放每次测试的结果 testCase：用于存放具体的测试case testFile：存放测试过程中用到的文件，包括上传的文件，测试用例以及 数据库的sql语句 caselist：txt文件，配置每次执行的case名称 config：配置一些常量，例如数据库的相关信息，接口的相关信息等 readConfig： 用于读取config配置文件中的内容 runAll：用于执行case 既然整体结构有了划分，接下来就该一步步的填充整个框架了，首先，我们先来看看config.ini和readConfig.py两个文件，从他们入手，个人觉得比较容易走下去哒。 我们来看下文件的内容是什么样子的： [DATABASE] host = 50

简单分解一下 接口测试框架设计: 主入口 -> 遍历接口/用例 -> 发送请求+接收响应 ->结果的对比 -> 生成报告 ->发送email 分成几大类： 主入口的py文件 src-核心代码文件 遍历case，发送请求和接收响应 存放case的 2、数据库里维护 3、excel里维护 包括的字段：编号，接口名称，地址前缀，请求地址，请求方法，请求数据类型，请 求数据，检查点，是否运行，测试结果，响应参数 公共函数：被多次重复调用，且没有依赖性 commans-存放公共函数库文件 2、数据库里维护 3、excel里维护 包括的字段： reports存放报告 excel 放插件的目录 log日志目录 1\先编写请求类,requests库里各类请求的封装 #! /usr/bin/env python #coding=utf-8 import requests import json #定义请求类 class Interface_Request: def req_get(self,url,params,headers): try: r = requests.get(url,params=params,headers=headers) #转换为python类型的字典格式,json包的响应结果，调用json(),转换成python类型 json_r = r.json() return json

互联网产品接入支付功能如何测试？ 现在有不少 测试 朋友做的项目中，可能也会涉及到支付相关的功能。比如：做商城的，做游戏的以及其他在线交易的网站、APP等。如果支付出了问题，或者用户拿少的钱通过篡改请求数据购买大金额的商品，如果是实物的话，发货前还有可能被发现。如果是虚拟商品话费、游戏币等就有可能造成损失。 　　所以，不管是实物也好，虚拟商品也好，涉及到支付功能时，大家在测试的过程中一定要重视，否则，会造成很大损失。之前可能大家也都看到过或者听过一个bug损失4.6亿美金的惨痛教训或者身边也有发生过其他因为支付功能的bug导致直接损失的案例。 　　给大家举个真实的案例：比如使用支付宝购买虚拟商品，往支付宝跳转时，篡改了小的金额，结果购买虚拟商品成功了。（原本10元的商品，0.01元就搞定了）。多么可怕的一个bug啊，当然这个问题可能对于一个做过支付有过经验的测试朋友来说，可能会想：哎呀，这个问题都发现不了，还做什么测试？是的，问题是很简单，对于一个刚入职场的测试朋友或者没有支付相关经验的测试朋友来说，很有可能会忽略。 　　那么，问题来了，对于支付模块的相关测试，我们应该如何进行呢？比如，针对游戏来说，使用第三方支付往游戏充值游戏币功能，看起来是不是很简单，大家主要思考下以下内容： 　　1、支付都是与第三方支付（支付宝、微信、财付通、QQ钱包、 短信 支付等）进行对接，那么

HTTP的接口测试工具有很多，可以进行http请求的方式也有很多，但是可以直接拿来就用，而且功能还支持的不错的，我使用过的来讲，还是postman比较上手。 优点： 1、支持用例管理 2、支持get、post、文件上传、响应验证、变量管理、环境参数管理等功能 3、支持批量运行 4、支持用例导出、导入 5、支持云端保存用例【付费用户】 可以说POSTMAN满足了HTTP接口测试的大部分功能，只有少部分的功能不被支持，比如：请求流程的控制；前面说了这么多，接下来我们就看看POSTMAN的安装与使用吧。 1、什么是POSTMAN POSTMAN是一个Chrome的一个插件工具，我们可以通过Chrome的应用商店进行搜索并安装，安装完成会在桌面上显示一个postman的图标，每次点击这个图标就可以启动POSTNA的界面。 启动过后就是上面的界面了，左边是用来管理用例的目录结构，右边是具体某个用例的请求内容的参数及响应内容；默认的postman会自带一个demo的项目叫“POSTMAN Echo”，里面有各种场景的用例demo，对于新上手的同学可以通过查看这些demo用例来学习如何使用POSTMAN。 2、新建一个项目 直接点击左边栏上面的添加目录图标来新增一个根目录，这样就等于新建了一个项目，我们可以把一个项目或一个模块的用例都存放在这个目录之下

现在有不少测试朋友做的项目中，可能也会涉及到支付相关的功能。比如：做商城的，做游戏的以及其他在线交易的网站、APP等。如果支付出了问题，或者用户拿少的钱通过篡改请求数据购买大金额的商品，如果是实物的话，发货前还有可能被发现。如果是虚拟商品话费、游戏币等就有可能造成损失。 所以，不管是实物也好，虚拟商品也好，涉及到支付功能时，大家在测试的过程中一定要重视，否则，会造成很大损失。之前可能大家也都看到过或者听过一个bug损失4.6亿美金的惨痛教训或者身边也有发生过其他因为支付功能的bug导致直接损失的案例。 给大家举个真实的案例：比如使用支付宝购买虚拟商品，往支付宝跳转时，篡改了小的金额，结果购买虚拟商品成功了。（原本10元的商品，0.01元就搞定了）。多么可怕的一个bug啊，当然这个问题可能对于一个做过支付有过经验的测试朋友来说，可能会想：哎呀，这个问题都发现不了，还做什么测试？是的，问题是很简单，对于一个刚入职场的测试朋友或者没有支付相关经验的测试朋友来说，很有可能会忽略。 那么，问题来了，对于支付模块的相关测试，我们应该如何进行呢？比如，针对游戏来说，使用第三方支付往游戏充值游戏币功能，看起来是不是很简单，大家主要思考下以下内容： 支付都是与第三方支付（支付宝、微信、财付通、QQ钱包、短信支付等）进行对接，那么，是否了解了第三方接口有哪些？是否都能清楚我们的产品与第三方是如何交互的

1.在发起某些请求时，可能会要求必须是从某个页面进行请求，此时会验证页面的token 2.这个token是动态生成的，每次请求时值都是不同的， 不可以通过fiddler抓取的值作为固定值传入，通过fiddler抓到的是某次请求的一个值， 通过python发起请求时，又是新的请求了。 所以需要先获取，再传入。 有点类似获取随机数，再传递这个随机数 这里的例子是登录redmine，这个参数值是通过页面上的input[name=authenticity_token]标签传入的 3.可以使用BeautifulSoup获取： BeautifulSoup用于爬虫时解析网页，可以获取到网页的标签。 在这里用于获取input[name=authenticity_token]标签的authenticity_token值， 它的返回值是列表，内容是一个标签，获取标签中属性值时，先通过列表索引知道元素，再通过键取值 from bs4 import BeautifulSoup soup = BeautifulSoup(r2.text, 'lxml') tag = soup.select('input[name=authenticity_token]') data = {"utf8": "✓", "authenticity_token": tag[0]['value'], "username":

重定向： 301：资源永久转移 302：资源暂时转移到另一个地址了 1.如果请求接口时发生了重定向，python会自动跟随重定向，对重定向地址发起请求，最后只能得到重定向地址的响应结果。而看不到重定向的这一中间过程。 2.如果想要看到重定向返回的中间地址，在发起请求时，传入参数allow_redirects=False, 这样就不会自动去请求重定向的地址，而是返回一个302。可以通过响应头中的Location获取重定向地址 res = requests.get(url, allow_redirects=False) new_url = res.headers["Location"] 来源： https://www.cnblogs.com/come202011/p/12228782.html

现在公司项目是一个SDK的测试工作，我直接调用了接口，先生成并上传加密文档（json格式）文件没写进来，然后在服务器解密后返回下载文档并存储解析在当前工程目录中，然后做对比查看接口返回的数据经过加密-解密后有没有异常。。。 import os import time import requests import json from urllib3 import encode_multipart_formdata executable = ( 'python Daemo.py' ) def sleeptime ( hour , min , sec ) : return hour * 3600 + min * 60 + sec ; second = sleeptime ( 0 , 0 , 10 ) ; # 间隔时间10s while 1 == 1 : # 死循环 if time . time ( ) > 1579688855 : #默认为2020年1月22日18：27分 break time . sleep ( second ) ; p = os . system ( executable ) # 执行 else : sys . exit ( ) print ( p ) #打印执行结果 0表示 success ， 1表示 fail data = {

通过客户端给服务器发送请求报文 单元集成系统验收 在软件还没有成型的时候 测试人员写测试用例 开发人员写接口 前端人员研发页面 需求分析阶段就要介入测试 给需求文档做测试，看看有没有逻辑问题等等 页面跳转是a标签实现的，跟接口没有关系 如果前端页面开发好了，但是还没有和后端对接 那么前端页面点击登录按钮是可跳转页面的 接口是要向服务器发送请求的 跳转页面不用向服务器发送请求 通过接口向服务器发送请求 向服务器传递数据或者是获取数据都是通过接口来实现的 把接口赋到一个按钮上，那这个按钮就有发送请求的功能 get向服务器获取数据 post向服务器提交数据 put和delete都是用post实现了，所以put和delete用的很少 增删改–post 查–get 软件测试流程： 绝对不是购物网站成型后开始测试 需求文档–测试计划–测试用例– 测试是在有可视化界面之前去做 测试是在页面还没有出现，前端还没做好，接口还没写完的时候就开始对请求接口进行测试，测试范围很广：等价类、边界值、表单值、返回值。。 视频链接：https://www.bilibili.com/video/av51833741 来源： CSDN 作者： 飞翔的小仙女儿 链接： https://blog.csdn.net/weixin_43784779/article/details/103946642

前边说了如何去抓取及过滤本地的接口，方便我们在接口测试中去运用，当然这个桩的目的当然不是在我们接口测试，而是在我们整个内部方便去运用，去mock数据，当我们目前在本地可以去抓包，比如在我们开发过程中，或者说我们脚本中run_case的时候就可以抓到其数据 这里更新下代码 from mitmproxy import http class GetData(object): def request(self,flow): request_data = flow.request self.request_url = request_data.url request_pr = request_data.query request_form = request_data.urlencoded_form # print('url------------------>',self.request_url) # print('pr--------------->',request_pr) # print('form---------------->',request_form) def response(self,flow): # if 'imooc' in self.request_url: response_data = flow.response response_header =