【性能测试基础篇】测试实施要点

性能测试整体实施流程的五大阶段为：需求调研、测试准备、测试实施、诊断调优、测试报告及总结；我们绝大部分性能人员认为其中首位最重要和最难（需求、诊断分析、报告总结），其实五大阶段是同等重要的，其中一环出现问题都会造成质量雪崩；而我们觉得最简单的阶段测试实施（脚本编写调试、场景设计执行、结果收集）也是非常重要的，因为此阶段是性能结果数据的直接体现。

目录

一、测试实施-脚本编写调试

二、测试实施-场景设计与执行

三、测试实施-结果收集

四、性能测试资源分享

---

一、测试实施-脚本编写调试

我们首先要明白脚本的含义：使用模拟工具可识别的语言方式与被测系统建立通讯，进行数据交互。

脚本的实现方式跟工具息息相关，但是都需要我们有语言开发功底（Java/C ）,早先的Loadrunner我们编写脚本需要遵循LR的语法规范，不管是录制的HTTP脚本的增强，还是Java Vuser或者C Vuser；到现在我们使用的Jmeter一样要遵循其规范，特别是脚本增强中的前后置处理器。

脚本主要分类：

1、录制模拟类：将Web页面类系统手工操作业务流程的过程通过工具抓取汇总，主要是HTTP的请求。

2、手工编写模拟类：TCP、HTTP、Java请求、JDBC请求等，需要按照工具提供的组件规范进行脚本的组装和编写。

脚本增强：

不管是哪种类型的脚本，不管是使用何种方式实现，都需要完成脚本的增强完善，主要包含如下：

1、参数化：使用参数化方式能够更真实的模拟真实业务场景，参数化数据的获取一般是从存量铺底数据中获取，一般通过SQL语句获取（项目组提供，要求准确获取，筛选通过率基本达到100%），要求获取的数据要能够覆盖交易的业务流程，并且数据分布合理，重复率较低；数据量要求是执行场景预估TPS*执行时间*10%，特殊的情况除外。

2、断言：判断被测交易是否成功的唯一标识，脚本必须增加断言，可以使用Jmeter提供的丰富的断言方式（响应断言、BeanShell断言、JSR223断言等）。

3、关联：当前的请求中参数数据依赖于前一个请求返回的数据需要关联，关联在脚本中的使用也比较常见，可以使用Jmeter提供的关联组件（正则表达式提取器、边界提取器、各种后置处理器等）。

4、事务：事务我们理解为规范操作步骤的集合，经常使用到录制的脚本中，例如登录操作发生了很多个http请求，我们可以将关键的步骤进行归纳增加为一个事务；事务方便我们进行交易数据的统计。

二、测试实施-场景设计与执行

场景分类：

1、验证性测试场景

简述：验证性测试场景也可以理解为预执行，当脚本验证完成后形成我们可执行的场景，场景需要做最基本的2*2验证

方法：使用Jmeter工具设置大于等于2个线程数，执行大于2笔交易（一般执行50笔或者5分钟）；

目的：为基本性验证被测系统是否存在并发缺陷，以及脚本是否存在其他缺陷。

2、单交易基准测试场景

简述：单交易基准测试场景为验证单个交易串行情况下（无并发压力）的是否存在问题

方法：使用Jmeter工具设置线程数为1，每个被测交易分别执行5分钟。

目的：验证被测系统的交易接口在无并发压力情况下，是否存在问题，此阶段关注点为响应时间，如果此阶段响应时间超过指标值，可中断执行。

3、单交易负载测试场景

描述：单交易负载测试场景为验证单个交易接口在独占被测系统环境下获取对应性能数据。

方法：使用Jmeter工具阶梯型设置线程数（10、20、30、50），每个梯度的场景分别执行5-10分钟。

阶梯型探测方法：阶梯型探测的目的是获取被测交易的最优处理能力，由于被测系统的多样性其处理能力差异性很大，因此探测的初始线程数不建议过大（5-10最为合适）。

a、最通用的探测方法按照相同区间不断增加线程数方式（例如10-20-30-40等），可根据压测结果数据进行区间的调整上下探测。

b、执行任意一组起始探测场景，例如5并发的场景，获取响应时间和TPS，此TPS跟指标TPS比对，如果<目标TPS，下一组探测并发数=指标TPS*响应时间；获取本组的TPS，如果TPS>指标TPS，继续往上探测。如果小于指标TPS则继续往下探测。

目的：获取单个交易接口是否存在性能缺陷，其场景主要适用于获取新建系统的主要交易接口性能。

4、混合容量测试场景

简述：混合容量测试场景为获取被测系统整体性能，是性能测试场景中最为重要的场景之一，是掌握被测系统的性能容量的依据。

方法：使用Jmeter工具，按照设计的测试模型比例（按照方案设计的测试模型使用吞吐量控制器设置），阶梯性的增加线程数，每个梯度的场景分别执行10分钟。

阶梯型探测方法：可以参考单交易负载测试场景中的阶梯型探测方法。

备注：按照混合比例，将单交易最优TPS数据按照混合的测试模型比例计算获取混合理论情况下最大TPS，以此作为标准，进行下探。

目的：验证被测系统整体性能是否存在性能缺陷，获取性能数据衡量系统性能。

5、稳定性测试场景

简述：稳定性测试场景为了验证被测系统在长时间运行情况是否符合指标要求。

方法：使用Jmeter工具设置中等压力的线程数（混合容量场景最优处理能力的70%-80%的压力），执行时间为8（8*5系统）或者12（7*24系统）小时。

目的：验证被测系统在长时间运行情况下是否存在性能问题（OOM、TPS大幅度波动）。

6、批处理测试场景

简述：批处理测试场景分为日间和日终批处理，主要是考察规定时间窗口内和不同的数据规模下批处理完成情况。

方法：

1）批处理验证：通过工具的方式或者命令行方式触发批处理启动，阶梯性的增加批处理使用数据量的规模（50万-100万-150万），通过日志或者数据库获取批处理完成的时间窗口。

2）批处理和联机交易影响性验证：联机交易混合场景（中等压力水平）作为背景压力，执行批处理最优场景，观察相互之间的影响性，要求联机交易整体运行平稳不能出现大幅波动影响，批处理处理时间窗跟单独执行批处理的差异不大。

目的：验证批处理的处理时间窗在规定时间内完成，并且不能对联机交易造成影响。

7、高可用测试场景

简述：高可用测试场景主要是验证系统的整体健壮性和稳定性，在发生单一或者多种故障情况下，获取故障的恢复时间及交易运行情况。主要故障包含：应用系统级别、操作系统级别、网络级别、服务器硬件、突发突增异常、数据库级别、容器化的异常级别等。

方法：使用Jmeter工具发起中等压力的测试场景，执行15-30分钟；平稳执行5分钟场景，触发故障操作执行，观察故障情况以及场景结果直到故障恢复，场景TPS恢复正常情况下平稳运行5分钟结束。

目的：验证系统整体发生故障异常情况下，故障恢复以及对交易的影响性是否符合预期。

8、全链路测试场景

简述：模拟真实的交易链路场景，链路中所涉及的系统都使用真实环境，验证整个链路下性能表现，以及链路下各个参数的合理性。

方法：测试方法可以参照混合容量测试场景方法，阶梯性增加并发压力探测最优处理，需要监控收集链路中每个系统涉及服务器的资源消耗。

目的：验证整体链路下的性能表现，最真实的模拟了生产链路的业务场景，其数据的准确性较高。

三、测试实施-结果收集

结果收集是性能测试场景执行后的最直接的体现，也是测试实施阶段的产出物。通过结果数据我们能够清楚的看到我们测了哪些场景，这些场景对应的性能数据，结果数据主要包含：

1）、性能测试执行记录：场景描述、主要参数描述、调优分析内容、报错异常信息、测试结果分析、关键项截图（TPS、响应时间趋势图、报错异常日志）。

2）业务指标数据：执行时间、并发用户数、交易名称、TPS、响应时间、成功率。

3）资源指标数据：被测系统各个服务器的资源CPU、内存、磁盘IO、网络吞吐。

温馨小提示：

1、脚本编写尽量轻量化，减少客户端加载消耗对整体性能结果数据的影响。

2、阶梯性探测最优处理能力的方法，要精准合理，不能盲目探测，灵活掌握不同系统类型的探测手段。

3、测试结果数据要进行反推验证，通过平均响应时间和并发用户数推导出TPS跟压测的TPS对比（并发用户/平均响应时间=TPS），不能存在较大偏差。

4、执行阶段和结果收集一定要认真严谨，数据容不得半点马虎。

 如果文章对你有帮助，记得点赞，收藏，加关注。会不定期分享一些干货哦......

四、性能测试资源分享

最后感谢每一个认真阅读我文章的人，看着粉丝一路的上涨和关注，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：

这些资料，对于想做【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！凡事要趁早，特别是技术行业，一定要提升技术功底。希望对大家有所帮助……加入我的学习交流群一起学习交流讨论把！！！！