性能测试实战30讲
高楼
前HP高级性能专家,7DGroup创始人
立即订阅
3601 人已学习
课程目录
已更新 10 讲 / 共 30 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词丨“老板,之前咱TPS是100,我优化完是10000”
免费
第一模块:性能测试基础篇 (6讲)
01丨性能综述:性能测试的概念到底是什么?
02丨性能综述:TPS和响应时间之间是什么关系?
03丨性能综述:怎么理解TPS、QPS、RT、吞吐量这些性能指标?
04丨JMeter和LoadRunner:要知道工具仅仅只是工具
05丨指标关系:你知道并发用户数应该怎么算吗?
06丨倾囊相授:我毕生所学的性能分析思路都在这里了
免费
第二模块:性能测试工具及性能场景篇 (3讲)
07丨性能测试工具:如何录制脚本?
08丨案例: 手把手教你编写最简单的性能脚本
09丨关联和断言:一动一静,核心都是在取数据
性能测试实战30讲
登录|注册

08丨案例: 手把手教你编写最简单的性能脚本

高楼 2020-01-01
通常我们会遇到要手写脚本的时候,就要针对一些接口编写脚本。这时候,我们需要知道接口规范和后台的数据是什么。而有些性能测试工程师写脚本时,并不知道后端的逻辑,只知道实现脚本,事实上,只知道实现脚本是远远不够的。
在这一篇文章中,我不打算讲复杂的内容,只想针对新手写一步步的操作,描述最简单的脚本编写。如果你已经具有丰富的脚本编写经验,会觉得本文很简单。
我没有打算把 JMeter 的功能点一一罗列出来,作为一个性能测试的专栏,不写一下脚本的实现似乎不像个样子。在脚本实现中,我们最常用的协议就是 HTTP 和 TCP 了吧,所以在今天的内容里,我简单地说一下如何编写 HTTP 和 TCP 脚本,以应测试主题。
我先画个图说明一下。
这样的图做性能的人一定要知道,相信很多人也画的出来。
我们知道 HTTP 是应用层的协议之一,现在很多场景都在用它,并且是用的 HTTP1.1 的版本,对应的是 RFC2616,当然还有补充协议 RFC7231、6265。
HTTP 中只规定了传输的规则,规定了请求、响应、连接、方法、状态定义等。我们写脚本的时候,必须符合这些规则。比如为什么要在脚本中定义个 Header?Header 里为什么要那样写?这些在 RFC 中都说得明明白白了。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《性能测试实战30讲》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(8)

  • 善行通

    感谢高老师无私分享,在刚开始学习性能测试的时候,一直不理解做脚本为什么要这样做,也报名参加过培训机构,也许培训机构的老师都不会,或者自己没有写过后端代码,更不会讲解后端怎么实现,还有调用关系,或者根本不想让学员知道,担心教会徒弟饿死师父。
    就像老师说的:【自己写一些 demo,去了解一些逻辑,然后在排除问题的时候,就非常清楚了】
    要是早早听到老师这样的课程,估计自己的水平能快速提高谢谢老师分析Jmeter调用后端简单逻辑【Jmeter-->controller--->interface--->service[业务实现层]-->Mappper-->DB】


    GET请求对于springboot框架来说是通@RequestMapping(method = RequestMethod.GET)中的@GetMapping来处理,这是框架定义好的接口,关键是get执行的业务操作是什么;
    POST请求也是springboot框架来说是通@RequestMapping(method = PostMapping.GET)中的@PostMapping处理数据;

    一般来说get是获取数据数据会在url上显示,post是提交数据,提交数据不会显示到url上, 而且Get方法提交的数据大小长度并没有限制,HTTP协议规范没有对URL长度进行限制。这个限制是特定的浏览器及服务器对它的限制。IE对URL长度的限制是2083字节;理论上讲,POST是没有大小限制的。HTTP协议规范也没有进行大小限制,起限制作用的是服务器的处理程序的处理能力【Tomcat默认2M】;对数据请求频繁,数据不敏感且数据量在普通浏览器最小限定的2k范围内,这样的情况使用GET。其他地方使用POST

    断言的作用是什么?
    理解断言是为了校验请求是否正确,只要增加合理的断言,才可以做性能测试,如果不加断言就不知道业务请求是否正确,再加没有断言TPS会很平稳,对实际压测结果意义不大。

    如何使用断言呢?
    理解:在请求结束后的响应增加断言。

    作者回复: 理解的很深刻哦。

    2020-01-01
    3
  • @zzw
    前面几个同学回答的蛮好,我在此补充下幂等性相关的区别吧。

    ## 什么是幂等性
    一次和多次请求某一个资源应该具有同样的副作用(对资源变更带来连锁反应或影响):f(x) = f(f(x))。

    ## 为什么要幂等性设计?
    系统解耦后,系统间服务调用存在三种状态:
    * 成功
    * 失败
    * 超时(中间状态)

    前面两种是明确的,超时是不知道什么状态,一般引起原因:
    * 请求没有到达服务方(网络延时或丢失)
    * 请求达到了服务方,服务方处理超时
    * 请求到达了服务方并且处理完返回结果,但接收方没有收到
    相关例子:订单创建、库存扣减、订单支付

    ## 怎么做幂等性设计?
    * 下游(响应方)提供查询接口,上游(请求方)对于状态疑异订单进行查询
    * 下游(响应方)系统坐幂等性设计:确保不会重复
    * 全局ID:Twitter 的 Snowflake 算法/UUID
    * 存储冲突来解决(唯一约束)
    * 插入重复无效,`insert into … values … on DUPLICATE KEY UPDATE …`
    * 更新状态:`update table set status = “paid” where id = xxx and status = “unpaid”;`

    ## HTTP幂等性
    - HTTP GET 方法用于获取资源,不应有副作用,所以是幂等的。
    - HTTP POST 方法用于创建资源,所对应的 URI 并非创建的资源本身,而是去执行创建动作的操作者,有副作用,不满足幂等性。
    - 只有 POST 需要特殊处理,其他都具有幂等性
    - 前端生成 token,后端存(唯一约束)
    - PRG 模式
    2020-01-02
    1
  • 律飛
    1.HTTP 的 GET 和 POST 请求,在后端处理中有什么不同?
     由于spring的RequestParam注解接收的参数是来自于requestHeader中,即请求头,也就是在url中,格式为xxx?username=123&password=456,而RequestBody注解接收的参数则是来自于requestBody中,即请求体中。
    因此如果为get请求时,后台接收参数的注解应该为RequestParam,如果为post请求时,则后台接收参数的注解就是为RequestBody。

    2.断言的作用是什么?如何使用断言呢?
    断言指的就是服务器端有一个业务成功的标识,会传递给客户端,客户端判断是否正常接收到了这个标识的过程。
    应该用有业务含义的判断标识。需要对业务进行分析,选取合适的判断标识。

    善行通已经说得很好了,画蛇添足一下。

    作者回复: 你也说的很好。

    2020-01-01
    1
  • 悦霖
    抓包信息看不懂怎么办😂

    作者回复: 说明需要补充网络知识。

    2020-01-03
  • 月亮和六便士
    老师,我还有问题想问:前面的文章中提到过,1. 什么叫压力补偿,压力补偿的作用是什么? 2. 还有为什么要动态扩展? 比如内存不够了,我们不应该找到谁占用了内存吗? 3.每次测试前需要清理缓存吗?比如我跑一轮脚本 就需要把redis 缓存清一下吗 ?
    2020-01-02
  • 月亮和六便士
    老师 ”要想解决这个问题,就要先确定服务端是可以正常连通的“ 确定了服务端可以联通,然后怎么解决timeout?

    作者回复: 拆时间看哪里长。

    2020-01-02
  • 新思维
    get请求,一般后端服务只是通过传过来的参数查询数据库,返回结果;post请求,一般后端服务会将请求所包含的内容更新到数据库,返回更新结果。

    断言判断后端服务返回的请求是否为所期望的请求结果。涉及到业务逻辑的断言需要对响应内容进行检查,包括关键字检查、或者数据处理逻辑结果检查等。

    作者回复: 理解的非常对。

    2020-01-02
  • 土耳其小土豆
    post的请求体放到body里、get的请求的消息体放到请求头里面、所以post请求相对较安全。

    作者回复: 话说的没毛病。不过在性能的专栏中就得说性能的话哦。

    2020-01-01
收起评论
8
返回
顶部