执行性能测试

性能测试环境准备：

特点：
• 独占性
• 尽量保持性能测试环境与真实生产环境的一致性
• 硬件环境
– 包括服务器环境、网络环境等
• 软件环境
– 版本一致性：包括操作系统、数据库、被测应用程序、第三方软件等 – 配置一致性：包括操作系统、数据库、被测应用程序、第三方软件等
• 使用场景的一致性
– 基础业务数据的一致性
– 业务操作模式的一致性：尽量模拟真实场景下用户的使用情况

测试数据的准备（插入10万条数据）：

目的：压测环境中的数据量尽量与生产环境中数据量一致 方法：为了快速创建大量数据，可以直接操作数据库进行添加
• 准备插入数据的SQL语句
• 循环执行SQL语句来插入数据Ø导包
Ø 连接数据库
Ø 创建游标
Ø 执行SQL语句
将SQL语句中唯一的字段，使用占位符{}来替换，方便在脚本中传递不同的值

​ 编写脚本，循环执行sql语句插入对应的商品记录
Ø关闭游标
Ø关闭连接

修改脚本

· 使⽤random函数，来保证每次运⾏登录时，使⽤不同的⽤户名进⾏登录

监控性能指标

· 系统指标：响应时间、吞吐量、错误率、并发数

​ ·聚合报告

· 资源指标：CPU、内存、磁盘、⽹络
· PerFMon

模拟并发

· 如果系统之前进⾏过性能测试，直接模拟TPS20的场景，进⾏性能测试，并监控指标。
· 如果系统之前未进⾏过性能测试，按照负载测试的原则，逐步增加负载量，观察性能的指标。

执行：

· 模拟5个⽤户并发，观察吞吐量TPS和响应时间
结果分析：
· ⽤例要求登录TPS为20，要求响应时间不超过3s
· 实际执⾏登录TPS为20.3（达到要求），实际执⾏的响应时间为244ms（达到要求），因此⽤例通过

补充：

当前⽤例测试时CPU利⽤率为98%，内存利⽤率为85.62%，超出正常的范围
如果在公司进⾏性能测试时，该⽤例不能算通过，因为资源使⽤率也是⼀个重要指标

在学习中由于虚拟机资源不⾜，暂时不关注资源使⽤率

进入首页脚本：

模拟5个并发：

· 实际TPS未达到要求TPS100，实际响应时间（1）未超过要求实际5s，⽆法证明是否存在bug，需要进⼀步增加负载量

模拟30个用户并发：

· 实际TPS未达到要求TPS100，实际响应时间（10s）未超过要求实际5s，说明⽤例测试不通过，需要提交bug

加入购物车脚本：

数据准备⼯作：

（1）修改待添加的商品库存为⾜够⼤，避免在性能测试过程把商品库存耗尽导致脚本失败
下面展示一些 内联代码片。

UPDATE litemall_goods_product SET number = '1000000000' where id =2;

脚本修改：

（1）使⽤随机⽤户登录，并添加购物⻋

运⾏并分析结果：

模拟5个⽤户并发：

· 实际TPS41.9达到要求TPS20，实际响应时间59ms未超过要求响应时间3s，⽤例测试通过

结算并下订单脚本：

修改测试脚本：

· 设置计数器

· 修改HTTP请求 - 登录

· 修改HTTP请求 - 下订单

执行测试脚本：

模拟5个⽤户并发：

· 实际TPS为29.5达到要求TPS10，实际响应时间为19ms（不超过要求3s），⽤例测试通过

业务流程的测试：

步骤：
· 准备测试数据
· 修改脚本
· 添加事务控制器，并把所有的脚本都放⼊到事务控制器中

· 添加性能监控
· 并发执⾏并分析结果

注意：
· 在进⾏业务流程的脚本性能测试时，前提必须保证该业务流程中所有的单接口性能测试结果都达标

稳定性测试：

稳定性用例设计：

· 确定出稳定运⾏的所有业务操作：（同时运⾏）

· 根据运营数据，分析出每个业务操作对应的虚拟⽤户数

稳定性测试执行：

· 所有的脚本同时执⾏（解除前后依赖）
· 每个脚本都是⼀个事务/业务 —— 事务控制器

· 按照要求设置虚拟⽤户数和运⾏时间
· 执⾏稳定性测试并监控

补充：
· 如果单个接⼝/业务流程还存在性能bug，需要再修复性能bug，再进⾏稳定性测试