性能测试场景设计方法（教科书版）

字数 1378阅读 6593评论 0赞 5

**其实如何设计性能测试场景是非常复杂的艺术，巴特（but），性能测试这个领域有个教科书一样的场景设计方法，笔者曾经带领团队参加中国合格评定国家实验室认可委员举办的软件效率能力验证，最终被评定为性能测试能力为“满分”。采用的就是下面要说的教科书般的场景设计方法。**

**咱们先不管这套设计方法是否是所处项目的最优解，先介绍了再说，作为性能测试的初学者是一定要掌握的**

#单交易基准测试
目的：单交易基准测试是在服务器没有压力的情况下，获取单支交易的处理时间，为后续场景提供依据。

执行策略：常规设置为单个用户迭代n次（比如100次）（Pacing为N秒），取平均响应时间。一般情况下不需要监控资源消耗、数据库处理等。但少数情况下，系统会出现TPS=1与TPS=100消耗的CPU资源差不多的情况，这种情况下，就是性能问题了。

![1.png](/home/attachment/201707/03/898849_149908451891726.png)
![2.png](/home/attachment/201707/03/898849_149908454233654.png)

#单交易负载测试
目的：获取系统单支交易的最大处理能力，以及几个性能指标之间的关联关系、变化趋势，例如：响应时间随TPS的变化趋势，TPS和响应时间随并发用户数变化的趋势、CPU利用率随TPS的变化趋势。

执行策略：单交易负载测试一般以逐渐加压的方式执行30分钟（无Pacing、无ThinkTime），观察处理能力拐点，需监控服务器资源消耗、数据库处理能力等。

拐点判断方式：
常规1) 通过Tps走势图观察拐点。Tps走势图会随压力的增大呈抛物线状，抛物线的最高点处，即为当前测试环境下该交易的单支最大处理能力。

常规2) 通过资源消耗判断拐点。比如测试中Tps仍呈上升趋势，但CPU资源使用率已高达90%，就以此时Tps值为当前测试环境下该交易的单支最大处理能力。
单交易负载测试可考察编码是否支持用户并发，是否存在性能隐患。
![3.png](/home/attachment/201707/03/898849_149908457859639.png)

#混合负载测试
目的：考察各交易按配比逐渐加压的情况下，系统随负载变化处理能力趋势，如响应时间、Tps、资源消耗等，极限情况下系统处理能力

执行策略：按交易配比，通过逐渐加压的方式执行1~2小时，需监控服务器资源消耗、数据库处理能力等。混合负载测试也需要判断拐点，判断方式与单交易负载测试相同，需注意各交易满足配比。

#稳定性测试
目的：系统长时间正常负载下的处理能力，是否有进程内存泄露、存储空间不足、inode数量不足、session未自动关闭、存量数据增长导致数据库执行计划不适用等隐藏问题。
执行策略：按交易配比，通过逐渐加压的方式执行8小时（也可以是4、6、12、24、24*7等，根据实际情况灵活掌握），需监控服务器资源消耗、数据库处理能力等。稳定性测试负载压力可以采用系统最大处理能力的70%或80%，或混合场景中某个压力值。

**微信公众号：性能测试与调优**
![](/home/attachment/201611/17/898849_1479376150.jpg)

性能测试场景设计性能测试

著作权归作者所有

如果觉得我的文章对您有用，请点赞。您的支持将鼓励我继续创作！

添加新评论0 条评论

Ctrl+Enter 发表

匿名评论

性能测试场景设计方法（教科书版）

添加新评论0 条评论

本文隶属于专栏

作者其他文章

相关文章

相关问题

相关资料