JMeter——书写性能测试计划书

Posted 2023-03-16 kasia

第七章. 书写性能测试计划书

1. 性能测试报告组成结构：

• 项目概况（项目背景、测试目的、测试范围、指标术语定义、测试指标说明、测试责任人、测试时间）
• 测试概要（测试场景、测试环境、测试类型、测试工具）
• 测试结果（并发测试结果、压力测试结果、负载测试结果、稳定性测试结果）
• 风险及建议（如果没有，则写无、如果有，则说明情况即可 ）

某某某项目性能测试报告

word 可编辑修改-可在资源里寻找下载C站资源链接

修改记录

版本号	发布日期	编制人	审核人/批准人	修改的章节号
1.0	YYYY-MM-DD	张三
1.1	YYYY-MM-DD	李四

• 文章目录

1 性能测试概述

某某某项目性能测试报告

摘 要： 本文档为某某某项目性能测试报告，主要内容包括概述、测试环境、测试方法、测试工具等。主要的读者有性能测试脚本开发人员、性能测试执行人员、性能评估人员、开发人员、项目经理、用户代表等。

缩略语清单：

缩略语	全称	说明

1 性能测试概述

1.1 背景

这部分写入一些项目的信息即可。

1.2 测试目标

一、本次测试的目标如下表：

测试需求表

由以上性能需求可知，系统对成功率要求非常高，均为100%，并要求每个进程的处理能力达到20000/分钟。（即在资源保证的前提下，执行一个20000的任务系统需要在1分钟之内完成）

目标1：要求程序A可以处理20000/分钟的业务量；

目标2：要求DB查询程序可以处理20000次/分钟的业务量；

目标3：调度程序的稳定性至关重要；

目标4：***********************************************************

目标5：***********************************************************

​ …

目标n：***********************************************************

2 测试环境
2.1 硬件环境
2.1.1 测试环境拓扑结构图

2.1.2 测试环境软/硬件配置

据目前已知的测试环境，主要如下：

测试环境资源配置表

2.2 软件环境参数配置说明
测试环境部署过程中一些关键参数的配置。例如数据库配置、线程数、使用的第三方工具是否有限制等，都需要在这部分说明。

3 测试环境差异性分析

这部分阐述测试环境与生产环境的差异和区别，并说明可能产生的影响。

4 测试方法

4.1 测试流程

性能测试计划中的测试方法部分。

4.2 测试工具及性能监控工具

性能测试计划中的测试工具和数据采集部分，这部分是对计划中细化。计划中悬而未决的都将在这部分确定和详细描述。

在测试过程中监控以下数据:

资源采集监控表

测试过程中开发的程序或脚本如下：

开发脚本列表

5 测试脚本开发

这里主要描述测试过程中使用的测试脚本的开发方法和原则，例如是否进行了参数化、关联以及其他一些业务操作。

6 测试用例执行结果

6.1 A程序

6.1.1 并发用户及稳定性测试

测试过程记录与分析：

1. C模式，一个进程配置16个线程的结果：

A. 处理速度为：22419/分，处理速度达到需求。

B. 处理总量为400W，数据包大小为32K。

C. 服务器资源变化情况：CPU和内存变化没有出现异常

资源使用情况如下：

2. C模式，一个进程32个线程

A. 处理速度为：44388/分，处理速度达到需求。

B. 处理总量为3360200，数据大小为32K。

C. 服务器资源变化情况：CPU和内存变化没有出现异常

资源使用情况如下：

6.2 B程序

6.2.1 并发用户及稳定性测试

测试过程记录与分析：

C模式，一个进程32个线程
A. 结果描述。。。。。

C模式，10个进程32个线程
A. 结果描述。。。。。

6.3 DB查询服务
6.3.1 场景描述1：一次发送20个查询
该场景是对DB查询的模拟。每次发送20个请求给后台数据库。当TPS（每秒事物通过数）达到19.7时，可以满足每分钟20000的查询请求。

当压力达到TPS=19.7时（每个业务20个查询），结果如下：

整个业务DB查询的平均响应时间0.011s,其中90%的响应时间小于0.013s.

平均响应时间：

TPS数值：

数据库服务器资源使用情况：

CPU占用率大约1%(看13:48以前的数据)

数据库上的IO情况如下：

网络情况如下，对于100M网络该流量很小

6.3.2 场景描述2：一次发送1个查询

略！！！

7 性能测试过程中发现的问题
1） 在测试A程序时，发现某些时间的处理量为0，而且某些时间的处理量很少，使得处理速度为7858/分钟，经开发确认代码存在问题并修改代码后，处理速度达到了21830/分钟；

2） 在测试100个B程序并发处理时，发现程序出现了异常，经开发确认代码存在问题后修改了接口程序，异常情况已经不存在；

3） 。。。。。。。。。

8 性能测试结果分析和建议
A****程序结果分析：

1） 在C模式下，同样是单进程32线程，程序处理数据中存在图片和不存在图片结果差距很大。不存在图片的处理速度为15280/分，存在图片的处理速度为2581/分钟。有图片情况下，单独测试转换的速度为4223/分钟。经测试存储的写速度为100MB/s。测试过程中图片最大不超过8K。由次可以计算出存储并非瓶颈。转换缓慢的原因应该在程序本身。需对程序进行进一步的优化；

2） 在R模式下，不生成图片的情况下，1进程32线程和1进程256线程在运行过程中均达到90%左右。处理速度分别为80350/分钟和81603/分钟。由此可见，虽然R模式修改了代码，但至少证明，在被测系统内部，20000/分是可以达到的。同时也可以分析出，在程序充分运行的情况下，256线程并不比32线程更有优势，反而会由于线程过多导致CPU进行更多的上下文切换而占用CPU时间片。

3） …

4）…

综上所述，对于A程序，目前可以确认的结果是：不带图片处理速度至少可以达到20000/分。对于带图片的处理，无法达到20000/分。

DB****查询结果分析：

该项测试结果远远超过需求20000次/秒且响应时间迅速。
综上所述，整理的测试结果如下：

注：以上结果是在被测系统所运行的软硬件配置下得出的测试结果，无法通过一种环境下的测试结果准确的得出另一环境下的测试结果。