JMeter——书写性能测试计划书（九）
第七章. 书写性能测试计划书
- 性能测试报告组成结构：
- 项目概况（项目背景、测试目的、测试范围、指标术语定义、测试指标说明、测试责任人、测试时间）
- 测试概要（测试场景、测试环境、测试类型、测试工具）
- 测试结果（并发测试结果、压力测试结果、负载测试结果、稳定性测试结果）
- 风险及建议（如果没有，则写无、如果有，则说明情况即可 ）
某某某项目性能测试报告
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 并发用户及稳定性测试
测试过程记录与分析：
- 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次/秒且响应时间迅速。
综上所述，整理的测试结果如下：
注：以上结果是在被测系统所运行的软硬件配置下得出的测试结果，无法通过一种环境下的测试结果准确的得出另一环境下的测试结果。
