下面是小编为大家整理的软件开发项目性能测试报告(范文)（2022年）,供大家参考。
性能测试报告
Edition V1.0.0
第一章 概述 1.1. 编写目的
本次测试报告 ****V1.0.0 的性能测试总结报告，目的在于总结性能测试工作，并分析测试结果，描述系统是否符合 **x 系统的性能需求。
预期参考人员包括用户、测试人员、开发人员、项目管理者、质量管理人员和需要阅读本报告的高层经理。
1.2. 项目背景
项目背景 1.3. 测试目标
（简要列出进行本次压力测试的主要目标）完善系统，满足 500 个用户并发访问本系统。
1.4. 名词解释
测试时间：一轮测试从开始到结束所使用的时间 并发线程数：测试时同时访问被测系统的线程数。注意，由于测试过程中，每个线程都是以尽可能快的速度发请求，与实际用户的使用有极大差别，所以，此数据不等同于实际使用时的并发用户数。
每次时间间隔：测试线程发出一个请求，并得到被测系统的响应后，间隔多少时间发出下一次请求。
：
平均响应时间：测试线程向被测系统发请求，所有请求的响应时间的平均值。
处理能力：在某一特定环境下，系统处理请求的速度。
e cache 影响系数：测试数据未必如实际使用时分散，cache 在测试过程中会比实际使用时发挥更大作用，从而使测试出的最高处理能力偏高，考虑到这个因素而引入的系数。
：
用户习惯操作频率：根据用户使用习惯估算出来的，单个用户在一段时间内，使用此类功能的次数。通常以一天内某段固定的高峰使用时间来统计，如果一天内没有哪段时间是固定的高峰使用时间，则以一天的工作时间来统计。
预期平均响应时间：由用户提出的，希望系统在多长时间内响应。注意，这个值并不是某一次访问的时间，而是一段时间多次访问后的平均值。
最大并发用户数：在给定的预期平均响应时间下，系统最多能支持多少个并发用户。这个数据就是实际可以同时使用系统的用户数。
1.5. 参考文档
序号 文档名称 作者 版本/ 日 期
1 需求文档
2 技术文档
3 项目模型文档
第二章 测试环境说明 2.1. 软硬件配置 具体的硬软件和网络环境如下：
环境
资源
数量
型号/ / 配置/ / 软件名称/ / 软件版本号
硬件环境 数据库服务器 1 CPU：8 核，主频 1.6GHz 内存：80G 存储：500*9G IP 地址：10.1.189.213 Web 服务器 1
其它服务器 3
JMeter 压力产生器 1 笔记本电脑 PC（windows10）
CPU：双核，主频 1.60GHz 内存：1G/2G IP 地址：10.1.119.59/10.1.119.109 Jmeter 控制台
1 笔记本电脑 PC（windows10）
CPU：双核，主频 1.60GHz 内存：1G IP 地址：10.1.119.59 软件环境 核心服务器 1 Centos7 Tomcat6.0 Java：JDK1.8 Nginx: 数据库 1 Oracle11 中间件服务器 1
JMeter 压力产生器操作系统 1 Windows XP Professioanl(SP2) JMeter 操作系统 1 Windows XP Professioanl(SP2)
网络环境 LAN（10M）
2.2. 测试工具
序号
工具名称
用途说明
版本
1 Apache-JMeter 性能测试开源工具 apache-jmeter-5.1.1
第三章 测试策略 3.1. 人力资源 测试活动
测试时间
姓名
起始时间
结束时间
测试准备
测试执行
测试报告
3.2. 测试方案 （系统中需要做性能测试的功能点）
测试过程按三个步骤进行，即单独场景压力测试、混合场景压力测试、稳定性测试：
单独场景压力测试：针对某个功能点进行压力测试，分析测试结果是否满足用户要求的指标； 混合场景压力测试：根据实际用户操作，将多个单独的业务操作同时进行压力测试，分析测试结果是否满足用户要求的指标； 稳定性测试：选择某些业务场景对系统加载压力，持续运行一段时间，根据并发量或系统监控等来观察系统的稳定性。
第四章 测试场景 4.1. 场景一 4.1.1. 500 个用户并发访问命名分类页面
场景名称
500 个用户并发访问命名分类页面 场景编号
001 测试步骤
1、 部署性能测试环境 2、 用 JMeter 录制脚本，对脚本进行调试 场景设计
1、 设计用户数量为 500 2、 加压方案：每隔 5 秒自动增加 50 个用户登录系统，直到增加 500 个 3、 减压方案：每隔 5 秒自动停止 50 个用户，直到全部停止 4、 设计运行时间为 13 小时 30 分钟 5、 运行场景 执行时间
13 小时 30 分钟 预期结果
1、 页面响应时间平均值不能超过 10 秒 2、 CPU 使用率平均值不能高于 75% 3、 物理内存使用率不超过 70%
4.1.2. 测试结果 4.1.2.1. 测试结果摘要
4.1.2.2. 用户运行情况：（附图）
4.1.2.3. 错误数：（附图）
4.1.2.4. 事务响应时间：（附图）
4.1.2.5. 每秒点击数：（附图）
4.1.2.6. Windows 资源情况：（附图）
4.2. 场 场 景二 4.2.1. 500 个用户并发访问文档类型页面 场景名称
500 个用户并发访问文档类型页面 场景编号
002 测试步骤
1、部署性能测试环境 2、用 JMeter 录制脚本，对脚本进行调试 场景设计
1、 设计用户数量为 500 2、 加压方案：每隔 5 秒自动增加 50 个用户登录系统，直到增加 500 个 3、 减压方案：每隔 5 秒自动停止 50 个用户，直到全部停止 4、 设计运行时间为 13 小时 30 分钟 5、 运行场景 执行时间
13 小时 30 分钟 预期结果
1、 页面响应时间平均值不能超过 10 秒 2、 CPU 使用率平均值不能高于 75% 3、 物理内存使用率不超过 70%
4.2.2. 测试结果 4.2.2.1. 测试结果摘要
4.2.2.2. 用户运行情况：（附图）
4.2.2.3. 错误数：（附图）
4.2.2.4. 事务响应时间：（附图）
4.2.2.5. 每秒点击数：（附图）
4.2.2.6. Windows 资源情况：（附图）
第五章 测试结论 本次性能测试通过 500 个用户并发访问 2 个页面，在 13 小时 30 分钟内的 626 万多次请求中，约有 0.023%是失败的，失败原因如：
提示内部服务器错误，分析这些原因应与测试用的服务器硬件配置有关，因为这边测试机器使用都是普通的 PC 机，在每秒一千多次的点击中，机器在某些时刻受到其他程序的响应可能处理不过来，故产生一些错误。
响应时间平滑，无大波动，2 个事务的平均响应时间在 5s 以内，可以接受。
每秒点击数最大为 1047，最小为 1018，平均值 1028，波动不大，非常稳定。
服务器的 CPU、内存使用率平稳，达到预期结果。
没有错误，响应时间很平滑，无大波动，是因为脚本有 think time 的原因。
（虽然随着用户的增加，响应时间和服务器系统资源也在增加，但是事物响应时间基本维持在 4.5s 左右，还可以接受。但是错误数却很多，其中主要错误不是登录的这个事物，估计是登录的人太多，服务器处理不过来，使后面的用户不能打开网页。用户数超过 30 个的时候就发生了错误。）
（不通过。随着用户的增加，响应时间和点击率逐渐升高，响应时间远远大于预期。服务器的 CPU 和磁盘的利用率也逐渐升高。当用户在 40 个左右的时
候，开始出现错误。）
随着用户的增加，每个脚本的事物响应时间成正比，说明用户越多，服务器的资源使用就越多，处理的时间就越长。这样会急剧加重服务器负担，所以就会有错误的产生（从 windows 资源图可证明）
由于测试客服机和 web 服务器是同一台计算机，测试的数据会有较大的偏差（测试的性能比实际的要差很多），所以应该在 2 台计算机进行测试。
第六章 遗留问题分析 无 第七章 附件 无
说明：
web 性能测试需要记录的数据：测试时间、平均响应时间、成功次数、失败次数、web 服务器 CPU 利用率（平均、最大）、数据库服务器 CPU 利用率（平均、最大）
计算公式：
成功率=成功次数/（成功次数+失败次数）
处理能力=成功次数/测试时间 最短平均响应时间=min（平均响应时间）
最高处理能力=max（处理能力）*（1-cache 影响系数）
最大并发用户数=（最高处理能力－1÷（预期平均响应时间－最短平均响应时间＋（1÷最高处理能力）））÷用户习惯操作频率，此公式要注意各时间单位的不同和转换
推荐访问:开发项目 测试报告 性能 软件开发项目性能测试报告(模板) 软件工程测试报告
