以某一用户名和密码 登录请求脚本_jmeter分布式导致重复登录的问题

点击蓝色“全栈测试笔记”关注我哟

加个“星标”，阅读我的文章，一起学习提升

经常收到微信好友的各种问题咨询，今天分享一个比较有代表性的，希望对大家有所帮助。

一位微信好友的提问

问题如下：

问题分析

先简单介绍下服务端的处理逻辑，关于登录，服务端的逻辑一般是：校验 用户名、密码(可能还有验证码，但是压测环境都会特殊处理)，成功后，会根据规则(比如拼接时间戳等字符串、加盐、加密)，生成一个tokenId，然后存入redis； 关于依赖登录的请求 ， 服务端的逻辑 一般是： 会校验传入的tokenId在redis中是否存在，存在，表示用户已经登录ok了，否则会返回登录超时之类的信息； 我们在压测的时候，有些接口是依赖登录的，常规操作是： 使用仅一次控制器，每个账号只登 录一次，登录成功后，正则提取到tokenId，此时就存入了当前线程的变量中，然后把此tokenId作为被压测接口的入参； 如果是分布式，我们需要手动把登录用户名参数化文件拷贝到负载机上(注意：loadrunner是自动把脚本和参数化文件分发到负载机上)，此时，多个负载机使用的参数化文件内容是相同的，分布式压测的时候，如果A负载机的某个线程先使用qzcsbj这个账号登录成功，tokenId也存入redis了，压测过程中，这个线程就会一直使用这个tokenId值，然后B负载机的某个线程也用qzcsbj这个账号登录成功，生成新的tokenId，此时会把redis里面A负载机生成的值更新，最后，A负载机上那个线程的请求都会失败，这就是这位微信好友的问题。

解决方案

方案一：各个 负载机上参数化文件内容不一样 ，这样就需要更多的用户名； 方案二：避免登录接口的影响，我们可以先单独操作依赖的请求，把需要获取的关联值tokenId存到文件中，被压测的请求就从这个文件中获取tokenId，这样，我们压测的脚本中就不需要登录接口了，只有我们的被压测接口， 有人可能会问，tokenId是有有效时间的，那是不是要频繁获取tokenId生成文件呢？当然不是，我们可以找开发帮忙把有效时间设置长点，比如24h，这样，获取一次，就可以用一天了 ；负载机参数化文件内容相同，如果被压测接口是修改操作，会有数据库锁等待，甚至锁等待超时的情况出现(参考这篇推文里的案例：性能测试：通过一个案例告诉你，性能到底要不要熟悉业务逻辑？ )； 方案三(推荐) ：基于方案二，各个负载机上参数化文件的内容都不同；

方案实现举例

下面简单介绍下如何将关联转换为参数化： 

1、删除已存在的参数化文件tokenId.txt

注意：因为后面要生成tokenId.txt这个文件，如果这个文件存在，我们先删除。

2、生成参数化的文件tokenId.txt

这里只是演示，假设需要100个账号，线程数设置为100，循环次数设置为1，即每个线程运行一次 a.登录接口需要的csv参数化文件userInfo.dat注意，此参数化文件中有两列，第一列是卡号，第二列是登录账号，下图抹掉了敏感数据 登录获取参数化文件中的登陆账号userAccount，而卡号cardNumber是被压测接口需要的参数 b.登录请求  正则提取tokenId c.把关联获取到的值写入文件，因为被压测的接口需要用到tokenId和卡号cardNumber，所以需要把tokenId和卡号配对写在一行上，第一列是tokenId，第二列是卡号cardNumber 生成的tokenId.txt文件，逗号分隔同一行的tokenId和卡号cardNumber两列数据，抹掉了敏感数据 最后，如果有N个负载机，就写个脚本把 tokenId.txt的内容拆分为N个文件，比如：to kenId_1.txt， tokenId_2.txt ...  tokenId_N.txt，但是，复制到负载机上，文件名都要改为 tokenId.txt

3、被压测接口

被压测接口略，这里只演示参数化文件这样，被压测接口就可以用上面生成的关联参数文件tokenId.txt了，下面变量名称和生成的tokenId.txt文件中变量顺序要一致

好了，就这样，是不是很简单？

如有不准之处，或者补充，请文末留言，谢谢。

声明：封面或正文部分图片来源于网络，如有侵权，请联系删除。

END

抛砖引玉，欢迎交流；

水平有限，难免有错，欢迎斧正。

更多干货，长按下图关注全栈测试笔记

猜你喜欢

点击阅读☞一篇文章告诉你怎么做性能测试

点击阅读☞如何面试性能测试

点击阅读☞面试题(造火箭必备技能)：请举例一个最有成就感的性能bug

点击阅读☞jmeter5.1分布式压

点击阅读☞性能测试案例：redis获取不到连接池，Timeout waiting for idle object

点击阅读☞性能测试案例：tps波动频繁

点击阅读☞性能测试案例：一个频繁fgc问题

点击阅读☞性能测试案例：获取不到redis连接池

点击阅读☞性能测试案例：数据库cpu高导致响应时间长

目前10000+人已关注加入我们

       

       

星标|在看|留言|转发分享，铁粉

后台回复 资料 获取测试资料 后台回复微信可向作者提问 后台回复提升加入提升圈子

分享是一种美德，

如有帮助，请帮忙转发分享，或点个“在看”~

未来的你，一定会感谢现在拼命的自己！

点击「」加入测试提升圈！