目录
一、实操
1.项目背景
2.需求
3.场景
4.监控
5.步骤
二、报错的原因
三、总结
一、实操
1.项目背景
某网站。
环境:windows
2.需求
并发登录的性能。
3.场景
1s增加2个线程。运行2000次。
分别看20、40、60并发下的表现。

4.监控
成功率、响应时间、标准差、cpu、mem、io等。
资源监控需要在windows下部署监控agent(server agent)。
5.步骤
badboy录制。
导入Jmeter。
参数化、检查点。



指标监控,资源监控。
报告。
演示脚本。

二、报错的原因
问题1
设置1秒,1秒跑20个线程,循环1次,2个参数用户,我理解的是每个线程都登录一下这两个用户。为啥10个线程就没事,20个线程,就有部分登录接口的断言报错了?

你比较一下错误的response body和正确的response body就知道原因了。
因为错误的response body里面不满足你断言的条件。断言条件是response body里面需要包含登陆的用户名。
这情况有可能是性能问题,也可能是你出发了一个多线程的bug。
要找到开发人员,然后把错误的请求时间和请求的细节告诉他,让他看后台服务器日志,才能知道是什么bug。
可能是并发太快,服务器处理不了,自动跳转错误页面。所以也可能不是bug,是触发了限流或者触发了性能瓶颈(是后台手工限制了并发数或者服务器性能不够)。
后来发现这个登录接口,选择自动重定向,1秒运行10个线程,循环1次,有时候运行成功,有时候运行失败。
所以这个登录接口应该是有bug。
问题2
badboy录制下来的脚本导入Jmeter后需要修改该脚本的配置,包括目录结构和参数。脚本的调试是重要的步骤,否则会报错。
三、总结
1.了解被测系统的业务,包括具体的请求以及请求里参数的含义。
2.badboy录制出来导入Jmeter进行相应的加工。(参数化、检查点等)。
3.设置场景的并发。
4.加上监听器。
5.运行。
脚本链接:https://pan.baidu.com/s/1KXjt_sgm6GVcl93dGj1lNw?pwd=1234 提取码:1234
欢迎关注《清菡软件测试》,感谢点赞与在看!