性能实战之测试准备阶段

接上文性能需求分析阶段，这里说说接下来的准备工作

测试准备阶段

测试准备阶段是为测试执行而做准备，重点包括测试方案，测试环境，工具脚本。

这里我把测试方案放在前面，是因为方案是起指导作用的，为后续动作提纲挈领。

那如何写性能测试方案？

网上一大把，我这参考高楼老师实践建议列一下

1，背景：包括项目背景和性能目标

2，测试范围：包括需要测试的特性和不需要测试的特性

3，准则：包括启动准则与结束准则

4，业务模型和性能指标：包括业务模型、测试模型、业务指标、性能指标

5，系统架构图：包括系统技术栈、系统逻辑架构图、系统部署架构图

6，性能实施条件：包括硬件环境、工具准备、数据准备

7，性能设计：包括场景执行策略、监控设计

8，项目组织架构

9，成果输出：包括过程性输出、结果输出

10，项目风险分析

上面内容就是一个完整项目的测试方案，高楼老师的实战例子也说得很详细了。

我说说我遇到的一些问题：

• 性能目标，考虑到时间原因，项目要及时上，所以暂时没有稳定性和异常测试
• 测试范围，我先把主要流程的业务接口梳理出来了，但是后面发现其他接口容量场景会用到
• 准则，这块简单写写，毕竟是自家产品，没有条件就创造条件
• 业务模型，当时没有分析出来，是后面补上的，后面专开一篇文章说说
• 性能指标，这块是根据总并发分析计算来的，上一篇已经说过了
• 系统架构图，这块上一篇也说过了，直接贴上来即可
• 实施条件，环境与工具基本确定了，数据准备这块耗时比较久，毕竟是第一次
• 性能设计，基准场景倒简单，难的是容量场景设计，后面会单独说说
• 监控设计，这个也是自己搭建的，链路跟踪工具真的很香
• 项目组织架构，这块没写，侧面也看得出领导的重视程度
• 成果输出：我把执行过程与调优放在一起了，然后就是结果报告，风险分析也放在里面了

总体来说，写方案的目的就是把当前基本情况理顺，然后不能得出的结论后续可以持续更新，方案完成后，可以要求相关人员，参与评审，针对相关问题大家意见要达成一致。

那如何准备测试环境？

正常情况下，把线上环境复制或缩放一下，叫上运维部署一套性能测试环境即可。

可惜的是，没有线上环境，也没有架构师来拍板，反而说环境让我来定，经过性能测试后再决定线上环境部署方式。

于是就是前文列出的网络拓扑图与部署架构图，然后叫运维搭建就行，这里当然也涉及到开发这边。

分以下几步：

1. 分析当前情况，确定是本地环境还是云环境，我们选择的是阿里云主机
2. 确定服务器等硬件配置，比如买几台，选择几核几G，外网带宽、磁盘大小之类的，由于java运用比较耗内存，采用8核16G，带宽先按量付费等等
3. 购买服务器并配置相关账号，这里注意要同地域下的，直接可以内网访问
4. 搭建并验证应用服务，这块主要交给开发吧，这时相关的账号得要过来，比如数据库、redis等中间件得账号密码
5. 安装相关监控工具并验证，这里参考我之前搭建的jmeter监控平台与性能监控平台

搭建环境主要工作还是在运维和开发这边，但我们也要及时跟进。

那如何准备工具脚本？

压测工具

说到工具，我们首先想到的是压测工具，因为部署到阿里云上，于是可以自己搭工具，也可以选择阿里云的pts。

自己搭工具：

首先得买一台服务器做压力发起机，走内网压测，然后部署压测工具即可，如果压力不够，可能得买多台做分布式。

阿里云的PTS：

需要购买资源包，压力来自外网，更真实，不用部署压测工具，场景支持jmeter脚本文件，压力不够，购买包即可。

如何选择，大家算下成本即可，我考虑到可能会多次压测执行，费用会较高，还是选择自己搭建，也比较可控。

压测工具选择好了，就可以购买服务器并部署了，这里也要同地域内网访问。

这里提一下，为什么走内网压测不走外网压测，内网压测可以把外网的网络瓶颈先过滤掉，先专注应用架构内部的调优，后续再做内外网带宽的对比测试，最终给线上的带宽选择提供依据

监控工具

再说说监控工具，高楼老师提倡的是全局监控再到定向监控，全局监控是第一层的监控，可以判断整个系统的瓶颈点在那个方向，而定向监控是更细致的监控，可以跟进一步判断判断瓶颈在那个地方。

全局监控包括操作系统，也包括各种存储及中间件，我理解为表面原因，比如CPU消耗高、磁盘IO消耗高等

• 操作系统的这里我推荐Node_Exporters+Prometheus+Grafana，官方模版基本揽括服务器的全局计数器，也能监控mysql与redis。

定向监控可以看出各组件详细的数据，我理解为直接原因，比如A进程CPU消耗高、B线程磁盘消耗高等

• 操作系统的命令工具，各组件的监控组件，比如mysql的mysqlreport，java的工具jvisualVM，arthas等
• 链路跟踪我分别试用过pinpoint与skywalking，不建议直接上来就用，因为链路工具会影响接口的TPS，最好在瓶颈定位时用。

当然如果运维有其他工具推荐，也可以，只要能为定位瓶颈提供证据。

监控工具选择好了后，就可以着手搭建了，验证数据后就等待性能执行阶段了。

压测脚本

压测脚本其实就是压测场景的实现而已，只要做过性能执行，这块应该问题不大。

首先：

考虑到持续更新与数据存档的问题，建立后性能工程目录后要做好版本控制，我用的是git，这样你也可以在liunx服务器拉取。

其次：

压测脚本与数据要分离，我是单独放了个目录，目录最好不要有中文 。

最后：

可以根据业务模块来设计各种基准场景，以及容量场景。

我的性能工程设计目录如下

注：jmx放场景脚本，other放其他脚本，paramData放参数化数据文件，scenesResult放场景结果截图、文件等。

再提下脚本设计注意点：

1. 脚本名称最好见名知意，建议不要中文，我直接用的是接口名。
2. 脚本涉及的参数化文件路径，我分别设置了windows和linux的两个变量，这样拼接参数文件名就可以了。
3. 线程数的确定，可参考公式：线程数=目标tps/单线程tps，可以稍微大于这个数即可。
4. 持续时间的确定，主要是放缓压力的增加，方便观察压力的曲线变化情况，我设置是5分钟递增完成，一共跑10分钟。
5. 设置场景需要连续，递增，然后记住多跑几次，就可以确定相关的基准场景的参数了。

数据脚本

数据脚本就是准备数据的，一是为场景服务，二是为压测脚本服务。

一般形式包括SQL存储脚本、各种语言脚本、自动化工具调用三种，主要根据实际情况来设计。

 为场景服务：主要是场景执行前后的数据准备

1，拿登录来说，场景执行前，如果需要系统准备大量的铺底用户，你就得提前插入部分用户数据。

2，而场景执行后，你依旧需要脚本来清除压测过程的数据，当然也可以采用备份与还原数据库的方式。

3，如果有第三方服务，可能也需要准备一些mock数据。

为压测脚本服务：主要是准备压测时需要的参数数据

1，拿下单来说，一般都需要用户token，这时你就得准备一个token的参数化文件，方便压测脚本读取

数据脚本可以提前设计，也可以后面需要时设计，主要目的是减少准备数据的时间，提高整体的效率。