本文已参与「掘力星计划」，赢取创作大礼包，挑战创作激励金。
前言
开发性能测试脚本之前，需要能够娴熟的使用一款性能测试工具，或者本身不会工具，更擅长写代码也行；
毕竟设计一份合理的性能测试脚本是性能测试的良好的开端。
一、分析系统特点
分析系统的特点：做惯了各种http协议的接口性能测试，如果遇到其他协议怎么办呢：dubbo、soap、mq等等
1.1、Jforum论坛
它是 Java 实现的强大而健壮的讨论板系统，B/S架构，属于web系统，所以基本可以看得见是http协议的、jsp页面。
但是它又不同于咱们熟知的restful风格的api、或是json返回对象的接口、亦或是xml报文，在开发脚本时或许有些困难。
复制代码1.2、服务架构
它是围绕MVC框架开发的，可以部署运行在Java 8 的 Servlet 3.1 容器或应用程序服务器上；
简单粗暴的部署方式：tomcat/jboss+Jforum+mysql.
复制代码二、脚本开发
前面有一篇讲脚本开发，通过一点点分析和功能体验，那么这个系统的测试脚本，不适合通过抓包或接口文档来完成开发；
简易通过录制的方式来生成脚本，再完善它；方案：Badboy+JMeter、JMeter自身录制元件生成脚本。
2.1、脚本录制过程(略)
方案已经给出，只要去实战操作即可。最终调优生成的脚本结构如下：
2.2、完善脚本
这里不得不提一下完善脚本需要做些什么？
- 脚本开发完成，首先是回放，确认请求是否成功，业务是否成功。
- 再根据请求结果来完善脚本，增加合理性，健壮性。
- 用户是否需要参数化，有些系统设计是用户可以在单机反复登录。
- 上下文请求参数是否有关联，假设不同用户请求的数据有所不同，下一个接口的入参依赖就可能出错。
- 关于接口鉴权，登录接口不要只负责登录，后面的请求也学要携带令牌，后台需要检验是否通过鉴权才下发数据。
2.3、参数化
这是增强脚本的重要途径之一。关联处理也属于参数化的一种方式。
因为在实际业务场景中，请求是来自不同用户、响应数据也不尽相同。
- 介绍几个JMeter常用来做参数化的元件
- CSV Data Set Config：最常用，处理大量数据的时候用得上。
- Counter
- User Defined Variables
- Random Variable
其实还有前置处理器、数据库sql操作，如csv这个强大的数据源配置元件
- 介绍几个JMeter常用来做关联的元件
- JSON Extractor：常用来处理json对象的
- Regular Expression Extractor：正则表达式则对html或其他文本格式的数据提取非常好
- BeanShell PostProcessor
同样它也有很多选择，这里只选一些代表性的，这里也不复述。
- 介绍几个JMeter常用的函数,也可以用来做参数化
- ${__counter(,)}
- ${__CSVRead(,)}
- ${__iterationNum}
- ${__Random(1,10,)}
- ${__threadNum}
总结：关于参数化因为涉及JMeter工具本身对元件作用的使用，这里不赘述，推荐[JMeter官网](https://jmeter.apache.org/usermanual/index.html)，上面有详细的使用介绍。
三、场景设计
回到这里，脚本已经开发完成了，在这里需要提一个建议，就是所有脚本按最小单位业务场景开发，这样既保证它的独立性也能无缝组合。
3.1、独立脚本
先不叫独立场景，因为一个独立的脚本不受其他脚本的影响可以作为一个业务场景执行性能测试。
那么独立脚本咱们应该怎么做？还记得性能测试中，有没有对性能指标进行分析？必须要有，否则性能测试的依据呢、意义呢？
假设通过业务日志监控或系统监控得到如下数据：
| 业务占比 | 登录25% | 发帖10% | 回帖15% | 浏览50% |
|---|---|---|---|---|
| tps | 13.75 | 5.5 | 8.25 | 27.5 |
实际按场景来设立，登录不需要作为一个独立的脚本存在，因为咱们不做登录的性能测试，或者说性能问题并没发生在登录这个场景。
如下: 咱们需要发帖(在系统中是支持匿名发帖的)、回帖都需要登录，那么将登录与这两个操作组合成一个独立的脚本，那么浏览就是一个独立的脚本。
注意：所有脚本最小事务就是http sampler采样器本身，可以通过事务控制器来包含多个操作。
3.2、组合场景
通过前面的数据分析，必然性能测试场景是交叉的，也就是不可能同时所有用户去发帖、回帖等等，必然是有人在发帖、回帖。
既然已经知道了比例数据，那么在脚本开发完成时，就需要对脚本进行设计：不要将所有业务全部放在同一个线程组，毕竟业务复杂，
无法精准的做到采样按比例分配，建议是根据业务独立一个线程组，这样它本身好维护，二也好扩展，最重要的是它不影响执行顺序。
- 登录后去发帖
- 登录后去回帖
- 不登录去浏览
3.3、场景设计不是组合脚本
所谓设计是指更加贴合实际用户的操作习惯，即模拟用户行为。
- 它不是一股脑的蜂拥而至登录，可以是有规律或无规律的登录，假设30个用户，每2s登录5个，那么是12s登录完30个；
- 这里有一个误区，除非它是一次性控制器，否则它登录后就会立即执行其他的业务或者它本身
- 用户在实际中操作，肯定会思考的，不会去跟其他人约定好一起操作，只能说是想对意义的并发，所以思考时间也需要考量
- 为了能准确的找到性能拐点，系统压力必定是持续一段时间的，那么这个时间，可以从系统监控看那个峰谷，从什么时候开始上去慢慢降下来这段时间截取。
注意：线程迭代次数限制优先级小于持续时间，也就是持续时间为0的时候，受制于ramp up time(sec),它在几秒内结束，线程也就停止了。
四、总结
场景设计，不是单纯的设计脚本、组合场景，而是要符合用户行为习惯，模拟真实的生产业务行为。
性能测试前期的准备包括：环境搭建、构造数据、脚本开发
执行性能测试之前，应该有一个合理的场景设计，这样才能准确的定位性能瓶颈
性能测试执行中，一个是观察脚本运行情况，二是监控系统资源
最后的性能结果分析，是可以在进行中及最后通过监控平台再进一步分析
总得来说，性能测试这件事儿，不能纸上谈兵，更需要实战，过程没有孰轻孰重，只有先后顺序和凭借老道的经验披荆斩棘。
「欢迎在评论区讨论，掘金官方将在掘力星计划活动结束后，在评论区抽送100份掘金周边，抽奖详情见活动文章」。