jmeter并发测试实例，测试项目结构图如下： 1.新建测试计划，选中测试计划，右键，添加线程组 2.添加配置元件-用户定义的变量，用来放置ip和端口参数 3.添加配置元件-CSV 数据文件设置...但是要知道一个用户只能生成一个token，比如对一个登陆接口做并发测试，如果只用1个用户，设置500个线程，实现的只是1个用户先后调了500次登陆接口而已，并没有实现500个用户在某时某刻同时调登陆接口...在此案例中，我想测试对上传图片接口的500人并发测试，要实现该需求，首先我需要500个不同的token，因为token需要从登陆接口获得，而登陆接口的入参为手机号，和用户id，所以我需要500个手机号码和...默认为0 本案例中主要是测试上传照片的并发测试，所以登录接口中的集合点为禁用。...请求数，Average:平均响应时间，Error%:错误率，Throughput:吞吐量 为了验证是否实现了并发测试，可查看每次请求的时间，登录接口未设置集合点，请求时间是有变化的 而上传图片接口设置了集合点
打开我们的并发文件：wqrf_run_case.py 3. 找到我们当前的进度：(下面的部分注释重复和无效，请按照实际步骤跟写。) 4. 继续开发，请求体初始化： 5.
首先打开项目，找到我们的并发文件：wqrf_run_case.py 然后我们先回忆下，这个文件我们目前很多的初始化步骤，其实都是把请求数据从数据库step表中拿出来，拿出来的时候基本都是字符串
本章内容，开始正式开发一下用例并发。 本章主要目标：对用例的新字段：是否参与并发，进行增删改查等设计。...找到位置并添加这个字段的展示： 此刻页面如图所示： 接下来我们要做的就是 在设置中，增加对并发字段的设置和保存，展示等功能了。...首先找到设置按钮，看看它调用的函数，并给这个函数增加一下并发字段作为第三个参数：注意单引号哦~ 然后进入到这个show_small函数内。...好，然后我们测试下，刷新页面，打开设置，发现可以自动选中了： 接下来，就是如何保存的问题了。 我们没有设计保存按钮，所以我们要在用户选中raido的时候，就触发保存请求即可。 怎么写呢？...好了我们来测试下，更改下用例的并发，然后关闭再打开看看是不是能显示选择否了呢？ 测试成功。 下节课，我们要开始真正并发的功能实现了哦~
好的然后我们再次测试看有木有bug： 经过测试，毫无bug。而且加载速度大大提升（反正肉眼都是察觉不到） 好，我们开始要优化下这个弹层了，首先就是这个弹层有点太大了。。。...实际上，测试报告在目前的业内有些变得浮躁了，普遍追求更好看，更多功能，而忽略了【易理解性】，让很多人第一眼看过去就眼花缭乱，完全找不到自己需要的数据。...热饭认为，测试报告只要简洁，明了，可看统计和具体详情即可。在颜色上只要把关键信息醒目一些即可。 没必要做的花花绿绿，显得很高大上的样子。 因为这就只是个报告而已。
我这里选用了简单的通过接口去后台请求： 这里我们要注意一下，因为response碰巧中了关键字，所以必须改一下，我加了个后缀 _data 然后去urls.py中搞定这个映射： 后台实现： 然后我们来测试下...改成这样： 再次测试，成功： 本节课，到此结束 我们下节课就是对这个step弹层 进行美化....
postrequests() return login.post() try: i = 0 # 开启线程数目 tasks_number = 10 print('测试启动
本节课我们继续研发这个 并发的自研报告模板： 目前： 然后我们今天开发下面的那个模块：详情部分 这部分我准备用bootstarp的表格来展示比较好。...所以我们还是有俩种方案，一种是带着这个step_id 去后台通过接口拿数据来展示。 另一种是想办法把一开始带过来的数据通过某种方式放在bom层可用。 具体选哪种我们下节课再说.......弹层默认是隐藏的，点击后展示，并且填充数据（当然现在还没写这步骤） 测试下效果： 当然这个页面确实挺难看.... 不过我们后续会优化的哦~
时隔多日，随着中间插入的篇章【测试圈相亲平台】的完结，接口测试平台重新更新。不过最开始的篇章的很多设计都比较老旧了。大家其实可以不用一句一句跟，看个设计，混个眼熟，熏陶一下即可。...而接口平台的搭建，其实我更推荐用【测试圈相亲平台】的技术来重构，不过本公众号系列暂时就不从头再来了。毕竟这个教程里融合了很多粉丝的热情投稿和献计献策，所以重构还是放在未来吧。...我们先解决眼下的这个新的并发功能底层。 回忆了一下上节，我们貌似一直在写具体步骤step的请求，现在回头一看，这代码量是真的庞大且复杂，毕竟功能点太多了。...最终控制多用例并发的功能和整合报告的功能 应该在它的上一层文件中实现。 针对这种复杂的结构设计和高度定制化需求，市面上的一切已有单测框架都不会满足。所以我们只能走出自研这一步。...所以上一层控制并发的时候，要去数据库提取出参与并发的用例的结果并合并。这就决定我们的数据库报告表的设计，只能以具体小步骤为基础单位 存放。
目前长这样： 说到扇形图，我们可以利用我们接口测试平台主页的那个小扇形图，不知道大家还有没有印象？ 所以我们这里也可以使用一下了。...欢迎大家提供宝贵建议，该平台将作为启蒙测试平台，永久的更新技术和需求，大家可一定要追哦~
接下来就是要做一个属于我们自己的测试报告了......然后回到我们的views.py中的函数中，返回render： 重启项目，测试一下： 如图，这就是正常表现了。 到这里我们链路算是打通了，数据和html模板成功合体，并展示在了浏览器上。...缺点是前端比较难处理，因为目前过来的数据是给dom层使用的，bom层想用有俩种办法，一是通过接口去后台拿正常json，二是按照现在的格式，从某个输入框中取出来并处理。...然后下面的for循环，每发现一个用例失败，那么错误的+1 ，正确的-1 前端写上： 测试下： 结果正常！...结果： 到这里大家明白了一个道理，那就是【自己动手，丰衣足食】 这个测试报告，我们想怎么做就怎么做，想做成什么样就什么样，想有什么功能就有什么功能...
我们在上节课成功搞定了并发底层这个大活。并且把请求的数据都放在了数据库。 不过之前的数据明显不够，因为一个大用例内，居然只有一个步骤。 所以我们本节课追加步骤！...这样测试覆盖的能全一点： 然后为了清晰测试，清空了原来的数据库记录： 现在开始运行： 一瞬间就结束了，并发的速度确实快到离谱啊......数据库结果： 依次点进去看看，数据目前都是正常的： 好的，然后我们可以去开发查看报告功能了： 这里的结果，我们不打算使用任何第三方的报告，而是打造一个并发系统特有的页面报告...原因在之前就已经说过了，面对我们目前的高度定制化需求，大用例/步骤/接口/断言/返回值等 复杂数据。 一般的报告很难完整展现出来，只能自己重新做一个了......然后后台函数负责整理数据后，带上html一并返回给浏览器，用户就可以在浏览器上看到一个新出来的页面，而这个页面就是我们的并发用例在线报告，未来可能还要支持下载，监控等重要作用。
打了一些基础之后，我们就可以更加顺利的进行开发并发用例功能了~ 首先我们目前是已经做好了并发字段的修改和显示功能。...按照我们之前的设计逻辑，我们要做一个并发按钮，触发成功后，统计所有并发为true的用例，然后新启动线程去执行。...所以首先，我们先去用例页面，做出这个并发按钮吧~ 效果： 好的，我们先给并发执行按钮实现。 这里我们要探讨 下，是用a标签的超链接方式发出这个并发请求好，还是调用某js脚本发出请求？...优点：页面不触发刷新，则我们可以弄个提示，说正在执行并发功能。 缺点：只是单页面展示而已，不小心刷新下就没了，别人这时候打开网页同样看不出正在执行。...所以综上，考虑到我们之后的任务调度系统，还有比较正式的并发设置模块。所以我们选择第一种。
这里需要先测试下，打印res 打印结果： 打印的结果大家看着不方便，我加几个回车就清晰了： {'result': '', 'cases': [ {'case_id': 21,...result_case': '', 'steps': [ {'step_id': 67, 'step_name': '调用A接口步骤...result_case': '', 'steps': [ {'step_id': 68, 'step_name': '测试...} }, {'step_id': 69, 'step_name': '测试...大家看到自己公司的很多接口返回都是这样多层级，其实都是这样开发出来的哦~ 本节课我们到此结束，下节课，我们将要对此数据解决各层级的result结果问题。
好了，今天我们讲的够多了，明天大家继续阅读哈，不一定非要动笔跟下来，在成为测开之前，提前熟悉下平台开发思路也是很不错的哦~
（先预告下，公众号在接口测试平台之后，还是会重新捡起来数据工厂。之前因为技术栈陈旧的原因，断更了很久。...数据平台的归属，是流程自动化范畴，用到的技术是脚本自动生成/ui自动化/接口自动化等等。并不限制具体的办法，只要能实现任何需求即是好的。）...本节课继续进行并发报告的设计： 当前我们的后台函数为： 不要着急，让我们按部就班，一步步来实现它。...先拿到所有参与并发的用例列表：cases 然后别着急，我们先设计最终数据格式res: res是个字典 数据结构应该是这样的： 分级明确，所属清晰，各层都有自己的最终结果。
result_case': '', 'steps': [ {'step_id': 67, 'step_name': '调用A接口步骤...result_case': '', 'steps': [ {'step_id': 68, 'step_name': '测试...B接口步骤1', 'result_step': '', 'data': { 'request_data...也就是说这个接口步骤压根没有任何断言。 那么我们应该理所应当的，给tmp_step["result_step"] 写成True了。...不过我们现在要在第二个大用例的第二个步骤的断言中 手动写个False， 来测试一下： 测试结果 出现错误！！！ 我们来看这段代码： 大家发现我挖的坑了么？
美化弹层 关闭按钮： 注意代码位置 效果如下： 里面的Onclick函数叫 close_step() 于是，我们写个js同名函数： 测试，可以成功关闭。
查看并发报告功能 好，就是以上这几点。...让我们依次来解决： 首先是返回值处理： 注意，在原来我们的run_case.py中，是把提取出的临时变量放入了缓存的全局变量中，然后再之后接口用eval来尝试调用，而也正因为如此，才导致了我们多个用例并发时候的冲突问题
而这其中，还没有考虑上游接口的变量提取，如何给到下游接口的功能。 所以经过再三考虑，我把步骤请求三部曲，给合而为一。这样才能保证中间数据的正常流转。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
即时通信 IM
实时音视频
