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

  1. 性能测试报告组成结构:
  • 项目概况(项目背景、测试目的、测试范围、指标术语定义、测试指标说明、测试责任人、测试时间)
  • 测试概要(测试场景、测试环境、测试类型、测试工具)
  • 测试结果(并发测试结果、压力测试结果、负载测试结果、稳定性测试结果)
  • 风险及建议(如果没有,则写无、如果有,则说明情况即可 )

某某某项目性能测试报告

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

修改记录

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

1 性能测试概述

某某某项目性能测试报告

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

缩略语清单:

缩略语 全称 说明

1 性能测试概述

1.1 背景

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

1.2 测试目标

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

测试需求表

JMeter——书写性能测试计划书(九)-小白菜博客
由以上性能需求可知,系统对成功率要求非常高,均为100%,并要求每个进程的处理能力达到20000/分钟。(即在资源保证的前提下,执行一个20000的任务系统需要在1分钟之内完成)

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

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

目标3:调度程序的稳定性至关重要;

目标4:***********************************************************

目标5:***********************************************************

​ …

目标n:***********************************************************

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

image.png

2.1.2 测试环境软/硬件配置

据目前已知的测试环境,主要如下:

image.png

测试环境资源配置表

JMeter——书写性能测试计划书(九)-小白菜博客
2.2 软件环境参数配置说明
测试环境部署过程中一些关键参数的配置。例如数据库配置、线程数、使用的第三方工具是否有限制等,都需要在这部分说明。

3 测试环境差异性分析

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

4 测试方法

4.1 测试流程

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

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

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

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

资源采集监控表

image.png

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

开发脚本列表

image.png

5 测试脚本开发

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

6 测试用例执行结果

6.1 A程序
6.1.1 并发用户及稳定性测试

JMeter——书写性能测试计划书(九)-小白菜博客
测试过程记录与分析:

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

A. 处理速度为:22419/分,处理速度达到需求。

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

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

资源使用情况如下:

image.png

image.png

image.png

JMeter——书写性能测试计划书(九)-小白菜博客
2. C模式,一个进程32个线程

A. 处理速度为:44388/分,处理速度达到需求。

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

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

资源使用情况如下:

image.png

image.png

image.png

6.2 B程序
6.2.1 并发用户及稳定性测试

JMeter——书写性能测试计划书(九)-小白菜博客
测试过程记录与分析:

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.

平均响应时间:

image.png

TPS数值:

image.png

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

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

image.png

数据库上的IO情况如下:
在这里插入图片描述

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

image.png

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次/秒且响应时间迅速。
综上所述,整理的测试结果如下:

image.png

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