【性能测试】真实企业，性能测试流程总结分析（二）

---

前言

4、性能测试用例设计

1）单场景

场景描述：模拟用户进行登录操作
并发量：分别模拟并发用户数为1、10、50三种情况进行测试
压测时间：每次15分钟
数据量：MySQL的user表中有70万账户
集合点：不使用集合点

重点关注指标：响应时间、事物成功率、应用服务器资源使用情况(CPU、内存、IO)、MySQL数据库资源使用情况(CPU、内存、IO)、应用日志是否有死锁等错误、数据库日志是否有死锁等错误、JVM内存使用情况和GC情况

预期指标：响应时间在2秒内、事物成功率为100%、应用服务器和数据库服务器CPU使用率≤60%、没有内存泄漏、数据库死锁、线程死锁等现象

2）混合场景

混合场景不是把所有的测试场景糅合在一起形成一个大的场景，而应该先考虑不同的混合场景组合，如数据库查询操作的混合场景、数据库写操作的混合场景、数据库查询与写操作都包含的大混合场景。

如下：
场景描述：模拟系统不用用户进行数据库读写操作的混合场景，场景包括用户登录、广告词默认查询、新建广告组、广告词默认创建、广告审核、广告生效、广告词按价格排序。

并发量：总共模拟300个用户同时操作，其中登录操作占比20%、广告词默认查询占比25%、新建广告组占比15%、广告词默认创建8%、广告审核10%、广告生效15%、广告词按价格排序7%

压测时间：每次15分钟

数据量：MySQL的cpc表有150万条数据、plan表有10万条数据、group表有50万条数据、audit表有100万条数据，MongoDB的report表有1TB数据、user表有90万条数据。

集合点：不使用集合点

重点关注指标：响应时间、事物成功率、应用服务器资源使用情况(CPU、内存、IO)、MySQL数据库资源使用情况(CPU、内存、IO)、应用日志是否有死锁等错误、数据库日志是否有死锁等错误、JVM内存使用情况和GC情况

预期指标：登录、广告词默认查询、新建广告组等操作响应时间在2秒内，广告词默认创建、广告审核、广告生效、广告词按价格排序等操作响应时间在3秒内，事物成功率为100%、应用服务器和数据库服务器CPU使用率≤60%、没有内存泄漏、数据库死锁、线程死锁等现象

3）稳定性场景

场景描述：模拟系统不用用户进行数据库读写操作的混合场景，场景包括用户登录、广告词默认查询、新建广告组、广告词默认创建、广告审核、广告生效、广告词按价格排序。

并发量：总共模拟300个用户同时操作，其中登录操作占比20%、广告词默认查询占比25%、新建广告组占比15%、广告词默认创建8%、广告审核10%、广告生效15%、广告词按价格排序7%

压测时间：持续2*24小时
数据量：MySQL的cpc表有150万条数据、plan表有10万条数据、group表有50万条数据、audit表有100万条数据，MongoDB的report表有1TB数据、user表有90万条数据。

集合点：不使用集合点
重点关注指标：JVM内存使用情况和GC情况
预期指标：无内存泄漏现象或迹象发生

5、性能测试环境准备与搭建

性能测试环境包括软件环境、硬件环境和网络环境。这三大环境不仅是指应用服务器环境，还包括数据库服务器、缓存服务器、文件服务器以及其他中间应用服务器环境。

硬件环境包括：CPU、内存、磁盘等基本因素。

软件环境包括：操作系统版本号、配置，Linux磁盘分区、JDK版本、位数、厂商，中间件版本号、位数，数据库版本号、位数，以及这些软件的安装路径也最好与线上环境一致。配置文件包括JVM配置、中间件配置、数据库配置文件等。

网络环境包括：网络协议及网络带宽。

集群环境包括：应用相关服务器的负载均衡环境、数据库的热备或主从环境、集群环境等。

申请线下仿真测试环境的时候，应遵循以下原则：

1）硬件环境尽可能地保持与生产环境一致

2）如果是集群环境，测试环境就不可能申请到那么多台服务器，那么可以考虑申请3台与线上生产环境一致的机器来作为线下的性能测试机器。

在性能测试的过程中，可以分别测试单机、双机和三机负载均衡时候的性能表现，然后根据3种情况下性能表现计算出线上生产环境（比如说100台）进行负载均衡时的性能损耗率，从而较为真实的计算出线上100台机器进行负载均衡时候的性能指标。

3）如果数据库集群环境太庞大，比如数据库是8组32台，那么线下测试不会申请32台机器进行性能测试。一般这种情况只会申请一组数据库（一主三从）作为性能测试的数据库即可。

因为大型数据库的集群基本都是采用拆库分表策略，所以会导致数据库集群庞大。申请一组数据库机器就可以开展性能测试，只需要保证性能测试所用的用户数据都落在申请的这组数据库即可。

4）如果实在无法保证硬件环境与线上一致，那么只能按照低配置环境进行测试，如果低配置环境测出的结果能满足线上要求，那么线上高配置环境肯定也能满足既定的性能要求。

如果无法满足，则不建议做建模估算，因为如果CPU颗粒数、高速缓存、物理内存大小、磁盘转速不同，性能建模得出的性能结果也不够准确。

如果在低配置的机器测试达不到要求，则要在测试报告中写明测试环境，并说明不能保证因为测试环境的提升而达到要求。

Mock Server准备：
在互联网行业叫Mock Server，在银行等金融行业叫做性能测试挡板。有时候系统的业务联调需要调用到其他系统的接口，但是其他系统的开发并未完成。

对于这种情况，常见的解决方案是搭建一个临时的server，模拟那些服务，提供数据进行联调和测试。

Mock Server的使用通常会带来以下好处：
隔绝由其他模块或系统出错引起的本模块的测试错误。
隔绝其他模块的开发状态，只要定义好接口，不用管开发有没有完成。
一些速度较慢的操作，可以用Mock Object代替，快速返回。

6、做脚本

这里就不做详细描述。

7、跑场景

根据测试用例来跑测试场景。

8、做监控

在性能测试的过程中，先用命令来监控，发现有问题再连上工具进行监控。

9、分析调优

每一个调优后，配置信息及测试结果都需要详细的记录下来。

10、回归测试

回归测试后，全部的目标达成后编写性能测试报告并发送给项目组成员。

11、出图写报告

1）测试目标
哪些场景、并发用户数、响应时间、TPS

2）测试结论
通过/不通过

3）本次测试的优化
某某场景：开始测试的时候TPS为5，优化后TPS达到30，发现了什么问题，怎么解决的。

4）优化改动项
代码
JVM
数据库
中间件
Linux服务器

5）具体测试情况
系统架构
测试环境
测试方法
测试结果

6）后续优化建议

下面是我整理的2023年最全的软件测试工程师学习知识架构体系图

一、Python编程入门到精通

二、接口自动化项目实战

三、Web自动化项目实战

四、App自动化项目实战

五、一线大厂简历

六、测试开发DevOps体系

七、常用自动化测试工具

八、JMeter性能测试

九、总结（尾部小惊喜）

在每一次坚持与努力中，我们都能超越自我，迸发出内心的巨大潜力。不放弃，不畏惧，勇往直前，只有这样，才能成就属于自己的辉煌人生。

不论前方有多少荆棘与坎坷，只要我们坚定梦想，砥砺前行，就能够跨越重重难关，创造出属于自己的辉煌人生。相信自己，勇往直前，无所不能。

奋斗是我们追逐梦想的征程，不畏艰辛，勇往直前。每一次努力都铸就坚强的内心，每一次挑战都磨砺出无限可能，只要坚持不懈，成功将属于我们。