周陸的时候开始找回确认邮件进到垃圾邮箱了,所以过期没成功
然后又重新填写信息找回,可是系统一直提示‘一个公众号微信授权号呮能同时找回一个账号’现在怎么办啊?
關注后可在公众号微信授权内接收相应的重要提醒。
请使用公众号微信授权扫描二维码关注 “公众号微信授权开放社区” 公众号
对于构建在公众号微信授权公众號的系统帐号体系往往使用公众号微信授权授权登录(如各类公众号微信授权商城应用系统)。
这样操作不仅可以实现静默注册对用戶几乎是无感的,同时也达到了区分用户获取用户基本信息(头像,昵称等)
使用公众号微信授权授权的模式可以说一次性替代用户紸册及用户登录。
也是基于上面优势我们平常也可以看到在公众号微信授权公众号上的应用有不少都是使用公众号微信授权的这种授权登录()
因为这种帐号体系是以公众号微信授权帐号为主体的,平时我们如果要对该类系统进行测试就必须使用到真实的公众号微信授權帐号完成登录或注册。
如果想要对登录或注册曾经进行性能方面的测试那会比较棘手(因为我们可能没有足够的公众号微信授权号)
以丅图为例我们先分析这个注册/登录流程
如图上面的12,3步都是在公众号微信授权APP里完成的(与我们作为测试对象的应用服务器未产生联系)
直到第4步骤公众号微信授权浏览器才向我们的应用服务器发送了请求(该请求负责将前面步骤得到的code传递到我们自己的业务服务该请求才是我们自己业务服务器开始验证登录的开始)
一般我们的服务器得到code后,会在向公众号微信授权服务请求用户信息拿到用户信息后處理自己的业务逻辑(注册或是登录)
所以能看出来,登录或测试的关键就是第4步这个接口
我们在进行性能测试时,设计的登录或注册邏辑(事务)主要就在于第4步请求测试数据的准备
因为我们应用服务从第4步拿到code后会用此code向公众号微信授权查询用户信息,即这个code是公眾号微信授权即时生成的我们是不可能提前拿到一批能用的code用来测试的。
现在如果为了测试可以选择修改服务逻辑让其接收虚拟code对虚擬code进行特殊处理完成虚拟的注册。但是这样为了测试来改变远工程的逻辑是十分不可取的测试的对象应尽量与实际用户使用到的维持一致,而且这里的场景就是为了测试注册或登录的性能为了测试而故意改了一份针对测试的注册或登录的逻辑显然不合适。
我们进一步分析业务服务的逻辑业务服务器会拿获得的code向公众号微信授权换取用户信息
如上图业务服务器使用code向公众号微信授权服务器换来了openid 及 access_token等关鍵信息 (第一幅图是公众号微信授权接口说明,第二副图是应用服务器向公众号微信授权请求的一个实例)
这时其实拿到openid即可以确定用户昰新用户还是老用户如果新用户可以进行新建用户的操作,如果是老用户则可以进行用户登录的逻辑
当然现实中应用服务可能还会使鼡access_token去向公众号微信授权拉取用户头像,昵称等信息()这取决于大家产品自己的业务。
如上所述不难发现如果使用错误的code,公众号微信授权服务一定会返回错误导致注册或登录业务中断。现在我们要克服的就是如何让错误的code也能有正常的返回。接口是公众号微信授權的公众号微信授权显然不会做这种事情。那我们在不更改业务服务的任何逻辑的同时能不能在我们应用服务器的网络层面上mock公众号微信授权的这个接口让不被公众号微信授权承认的code也能返回正常的数据。
答案是可以的上面这个需求是可以通过FreeHttp来完成对。借助FreeHttp可以截獲使用code换openid及access_token的请求然后返回我们自己构建的测试数据给业务服务使用。(FreeHttp 的说明及安装可以看这里 )
下面以一个实际公众号微信授权登錄场景为例说明如何使用FreeHttp完成公众号微信授权认证
为了完成需求我们首先要为业务服务器配置HTTP代理到我们的Fiddler上。
一般我们的服务器都是Linux这里我们以CentOS,应用容器Tomcat 为例说明代理配置过程
配置机器全局代理很容易
不过JVM可能不会使用系统HTTP代理所以我们需要单独配置Tomcat的代理
配置礻例如上图在以上位置加上指定参数即可(不同应用容器或服务框架都有自己的代理设置方式,大家可以在网络上搜索到)
添加配置信息後重启tomcat即可(记得服务器与代理服务所在网络上必须是能连通的)
还有一步添加fiddler证书到服务器(为了能解析HTTPS请求)
如上图在我们自己的电腦中导出证书
在服务器上进行如下操作
以上步骤完成后可以测试一下Fiddler是否能获取服务器发送的请求
触发服务器向外发送请求我们在Fiddler上应该能捕获相应请求(上图就是一个我们应用服务器发送给公众号微信授权的https请求)
FreeHttp作为第三方Fiddler扩展插件需要單独安装,安装方法十分简单(安装步骤见 )
按照我们前面的分析实际应用服务器是需要向公众号微信授权发送code()
应用服务器需要根據返回数据再进处理一步业务逻辑
那我们现在直接篡改这条请求返回值,让他对不合法code的请求也返回正常的返回数据
先添加一个参数化数據(用于使每次返回数据都不一样)
如上图我们添加一个逐步递增的openid参数数据(按图标注1,23步骤添加即可,注意红框部分选择参数类型及参数的格式)
这个参数表示以0001开始每次取值逐步递增(在类表处选取该参数可以重置或设置该参数的值)
因为是替换响应不需要将真实發送到公众号微信授权的服务器这里勾选Response Direct(同时为了模拟真实场景加上50ms的延时,反复测试公众号微信授权的这条接口响应时间都控制在50ms到100ms)
在图最大编辑框中设置相应数据(正确响应数据应该是什么格式抓取一个正常的请求就可以得到),同时我们为返回json里openid添加一个参数數化数据(实际就是TestOpenId加上一个递增的ID这个递增ID就是前面设置的参数化数据,这里为了方便演示仅对openid进行说明,实际其他几个返回项也昰有意义的)
红线处*#test_openid(+)*#即表示前面添加的用户参数(因为使用到用户参数需要鼠标右键在弹出框中把use Parameter Data 勾上)
设置完成后,点击右下角绿色確认按钮添加规则
完成以上设置后后注意在右侧Response Rule列表处,设置启用Response Rule,及勾选需要执行的规则(上图红框区域)
我们使用Fiddler的Composer构造这个请求(當然您可以通过其他测试工具甚至是浏览器构建请求进行调试)
如上图我们主要关注的code(我们这里自己构造code实际这个code不是一个真实的code)
點击Execute发送测试请求
如上图,可以看到服务器发给公众号微信授权的请求已经被我们替换掉了而且返回我们设置的“合法数据”。(我们峩应用服务器这个时候会认为是openid为TestOpenId0001的用户来登录或注册了然后会进入相应的业务)
通过数据库验证用户是否成功创建成功(当然正常情況下按不同业务需求,注册一个用户还有许多数据需要验证)
对登录业务进行压力测试同样可以使用很多工具,我这里使用常用的JMeter进行演示
注意JMeter默认不使用系统代理所以需要如上图手动配置代理
这里使用100个用户同时登录(持续时间30秒,当然实际测试中有更加复杂的业务持续时间跟用户数也会更多)
通过对数据库的检查,我们基本上可以确认30秒里这10个用户创建了311个账户(而实际上我们并没有使用311个公众號微信授权号)
简单的测试我们应用服已经表现出性能瓶颈(平均响应达到了8秒)
同时添加服务器监控可以查看测试中服务器的压力情況(上图表面测试中应用线程数量明显增多,JVM的GC也加快了可以反复尝试增加压力观察是否存在瓶颈)
最后我们就可以根据自己的业务,添加更多的业务场景进行有针对性的测试
上面只是一个例子,演示如何通过截获服务器与公众号微信授权认证服务器的请求以达到测試自己业务公众号微信授权认证登录的过程。
大家可以利用这个思路结合自己的需求,进行有针对性的测试