性能测试实战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
收起评论