1. 前言 有近两周没有在公众号中发表文章了,看过我之前公众号的读者都知道,公众号中近期在连载<RobotFramework接口自动化系列课程>,原本计划每周更新一篇,最近由于博主在带一个新项目,实在是没空抽出时间来,所以向公众号中对连载课程一直期待的读者说声抱歉. 由于最近带微服务的项目,而对于微服务其实也是近从14年才流行起来,对于这块目前网上的干货内容还是较少,借着机会,小结一下知识点.所以今天也先不打算连载<RobotFramework接口自动化系列课程>,如果读者对连载的

在前一篇博客中我们讲到契约测试是什么,以及它能给我们软件交付带来什么价值,本次将介绍一个开源的契约测试框架Pact,它最初是用ruby语言实现的,后来被js,C#,java,go,python 等语言重写,此文将介绍Pact框架的相关知识并结合示例代码讲解在实际项目中应该怎么使用. Pact是什么? Pact是一个开源框架,最早是由澳洲最大的房地产信息提供商REA Group的开发者及咨询师们共同创造.REA Group的开发团队很早便在项目中使用了微服务架构,并在团队中对于敏捷和测试的重要性早

前言 在前几天的博客中,我转载了一篇文章,其中介绍了契约测试和pact是怎么实施的,的确很有帮助.但我经过研究,其实是pact本身也是有缺陷的,结合我近期在使用的服务型工具和我的实际情况,觉得实现契约测试其实有更有效率的解决方案,本文就通过我的视角看看我是如何快速实现契约测试的. 契约测试 因为前后端对接的过程中会出现信息不对称,以及工作进度不一致的情况,因此希望通过事先约定好API返回数据的文档,根据文档来开发后端代码,以及生产可以被前端调用的虚拟的API,帮助前后端能够同时开展工作并且保持前

背景 如今,契约测试已经逐渐成为测试圈中一个炙手可热的话题,特别是在微服务大行其道的行业背景下,越来越多的团队开始关注服务之间的契约及其契约测试. 什么是契约测试     关于什么是契约测试这个问题,首先先看一下Pact官方文档给出的定义:pact的官方文档,是另一个可以帮助我们理解契约测试的地方.它对契约测试给出了这样的定义:"Contract testing is a way to ensure that services (such as an API provider and a cli

简介 使用场景 主要用于在微服务架构下做CDC(消费者驱动契约)测试.下图展示了多个微服务的调用,如果我们更改了一个模块要如何进行测试呢? 传统的两种测试思路 模拟生产环境部署所有的微服务,然后进行测试 优点 测试结果可信度高 缺点 测试成本太大,装一整套环境耗时,耗力,耗机器 Mock其他微服务做端到端的测试 优点 不用装整套产品了,测的也方便快捷 缺点 需要写很多服务的Mock,要维护一大堆不同版本用途的simulate(模拟器),同样耗时耗力 Spring Cloud Contrct解决思

安装 官网下载地址:http://jmeter.apache.org/download_jmeter.cgi 下载完成后解压zip包 启动JMeter,双击JMeter解压路径bin下面的jmeter.bat即可 测试实例 请求方式:POST URI:/sys/v1/users/login Request Body 参数名称 参数类型 是否为空 说明 name string N 用户名 示例 { "name": "admin" } 新建工程: 添加线程组:点击“测试

cookie 是什么? cookie--------------在浏览器中的长相?火狐浏览器 -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

前言 现在很多接口项目在登录的时候返回一个token,登录后的拿着这个token去访问访问登录之后的请求. 本篇使用djangorestframework框架写一个登陆的接口,登录成功后返回token. 环境准备: python 3.6 django 2.1.2 TokenAuthentication django rest framework权限和认证有四种方式: BasicAuthentication 此身份验证方案使用HTTP基本身份验证,根据用户的用户名和密码进行签名.基本身份验证通常仅

前后端分离 按照现在的趋势,前后端分离几乎已经是业界对开发和部署方式所达成的一种共识.所谓的前后端分离,并不是传统行业中的按部门划分,一部分人只做前端(HTML/CSS/JavaScript等等),另一部分人只做后端(或者叫服务端),因为这种方式是不工作的:比如很多团队采取了后端的模板技术(JSP, FreeMarker, ERB等等),前端的开发和调试需要一个后台Web容器的支持,从而无法将前后端开发和部署做到真正的分离. 通常,前后端分别有着自己的开发流程,构建工具,测试等.做前端的谁也不会

如何基于Microsoft.Owin.Security.OAuth,使用Client Credentials Grant授权方式给客户端发放access token? Client Credentials Grant的授权方式就是只验证客户端(Client),不验证用户(Resource Owner),只要客户端通过验证就发access token.举一个对应的应用场景例子,比如我们想提供一个"获取网站首页最新博文列表"的WebAPI给客户端App调用.由于这个数据与用户无关,所以不涉

<?php </FuncFlag>                             </xml>);         curl_setopt($ch, CURLOPT_RETURNTRANSFER, ];                       $urll = );         curl_setopt($ch, CURLOPT_REFERER, ){          return $json['response'];         }     }   }

JSON Web Token,简称 JWT, 是一个开放的标准(RFC 7519),它定义了以一种紧凑的.自包含的 JSON 对象在各方之间安全传输信息的方式.该信息含有数字签名,可以被验证和信任. JWT的介绍这里就不说了,想了解的可以看一下这边博客:JSON Web Token 入门教程 或者直接参考官方网站:https://jwt.io 项目是SpringBoot2.0,下面直接上代码. Maven配置: <dependency> <groupId>com.auth0<

随着互联网的不断发展,技术的迭代也非常之快.我们的用户认证也从刚开始的用户名密码转变到基于cookie的session认证,然而到了今天,这种认证已经不能满足与我们的业务需求了(分布式,微服务).我们采用了另外一种认证方式:基于token的认证. 一.与cookie相比较的优势: 1.支持跨域访问,将token置于请求头中,而cookie是不支持跨域访问的: 2.无状态化,服务端无需存储token,只需要验证token信息是否正确即可,而session需要在服务端存储,一般是通过cookie中的

一般情况下我们Django默认的用户系统是满足不了我们的需求的,那么我们会对他做一定的扩展 创建用户项目 python manage.py startapp users 添加项目apps INSTALLED_APPS = [ ... 'users.apps.UsersConfig', ] 添加AUTH_USRE_MODEL 替换默认的user AUTH_USER_MODEL = 'users.UserProfile' 如果说想用全局认证需要在配置文件中添加 # 全局认证from rest_fra

在做接口测试时,经常会碰到请求参数为token的类型,但是可能大部分测试人员对token,cookie,session的区别还是一知半解. Cookie cookie 是一个非常具体的东西,指的就是浏览器里面能永久存储的一种数据,仅仅是浏览器实现的一种数据存储功能. cookie由服务器生成,发送给浏览器,浏览器把cookie以kv形式保存到某个目录下的文本文件内,下一次请求同一网站时会把该cookie发送给服务器.由于cookie是存在客户端上的,所以浏览器加入了一些限制确保cookie不会被

先来一个简单的测试 # curl -XPOST "http://192.168.9.155:9200/_analyze?analyzer=standard&pretty" -d 'PHP是世界上最好的语言' //_analyze表示分析分词:analyzer=standard,表示分词方式standard; -d表示测试的一段文字 测试结果 { "tokens" : [ { "token" : "php", , , &

一. 引流测试产生背景 日常大部分的测试工作都是在测试环境下,通过模拟用户的行为来对系统进行验证,包括功能以及性能.在这个过程中,你可能会遇到以下问题: 用户访问行为比较复杂,模拟很难和用户行为一致,模拟不够真实; 线下模拟场景有限,会出现业务覆盖不全的情况. 引流测试的出现就是为了解决以上问题,它的本质是:通过把线上的真实流量复制到线下环境,解决测试环境模拟不够真实,或覆盖不够全面的问题. 二. 引流测试常见方案 目前不少公司对引流测试进行了实践探索,常见的有以下4种引流方式(不限): 引流方

消费者驱动的契约Consumer Driven Contracts (CDC) A contract between a consuming service and a providing service, stating what the consumer wants from a providing service, in a defined format. CDC有那么些特点: 在启动阶段,服务功能的描述必须能在多种场合下被重用:粒度既不能粗到仅在一种特定场合下能被重用,也不能细到要做大量

作者 | 王菜鸟1993 来源 | cnblogs.com/JamesWang1993/p/8593494.html 在做接口测试时,经常会碰到请求参数为token的类型,但是可能大部分测试人员对token,cookie,session的区别还是一知半解. Cookie cookie 是一个非常具体的东西,指的就是浏览器里面能永久存储的一种数据,仅仅是浏览器实现的一种数据存储功能. cookie由服务器生成,发送给浏览器,浏览器把cookie以kv形式保存到某个目录下的文本文件内,下一次请求同一

简介 前面我们已经学习了一些EOS的基础知识了,但是在EOS主网上的很多操作(比如:抵押.赎回.买卖内存)都是需要EOS链被正式激活后才可使用,而激活EOS链还需要很多的准备操作,我打算在单独的一篇文章中介绍,为了大家可以先上手使用EOS主网或者模拟测试,我们今天就先学习下如何使用EOS的jungle测试网. EOS基础全家桶(八)jungle测试网的使用 简介 EOS测试网介绍 创建账号 水龙头领取EOS 启动测试网节点 获取测试网的P2P节点地址 获取测试网的RPC API接口地址 钱包中配