性能测试报告模板
1. 文档用途
本报告是为了XX系统的XX模板的性能表现，检查在多用户并发访问的情况下系统的表现情况。
本次测试从事务响应时间、并发用户数、系统资源使用等多个方面，以专业的性能测试工具，分析出当前系统的性能表现，以实际测试数据与预期的性能要求比较，检查系统是否达到既定的性能目标。
2. 测试目的
对系统的哪些业务进行性能测试，作为XX项目上线第一次性能测试，本轮测试的目的定义如下：
- 保障系统多用户情况下系统的可靠性：通过实施不同的性能测试场景，评估并验证系统在高负载下核心功能的可靠性。
- 提供一轮系统性能测试情况，为下一轮生产环境的性能测试提供基线数据。
- 评估系统部署资源的合理性：不断搜集和分析性能测试过程数据，对接下来的系统部署所需的系统资源进行评估和建议。
- 优化和解决系统性能问题：在测试过程中，优化系统各项参数和解决发现的系统性能问题。
本测试报告为XXXX网站的性能测试报告，目的在于总结测试阶段的测试以及分析测试结果，描述网站是否符合需求。
3. 测试范围
按照数据量最大、高频率使用的页面的策略，确定功能场景包含登录...等核心业务场景，测试范围具体涉及可参考测试用例设计。
4. 测试环境与架构图
系统环境
|
描述 |
OS |
台数 |
CPU |
Mem |
IP |
|
|
|
|
|
|
|
|
描述 |
OS |
DB |
CPU |
Mem |
IP |
|
|
|
|
|
|
|
客户端环境
|
描述 |
OS |
台数 |
CPU |
Mem |
IP |
|
|
|
|
|
|
|
业务场景描述。Control中的场景设计策略描述。
5. 性能测试需求
5.1 业务量需求
根据客户提供的业务数据，按照高峰期持续时间，高峰期处理业务数，推算出每秒业务量的预期值，tps=(业务量*80%)/(业务完成时间*20%)
5.2 系统资源需求
高峰期，要求CPU利用率<80%,内存<80%
5.3 基础数据需求
关键图表分析，截图和文字结合分析
6. 测试场景
6.1 测试类型
性能测试场景通常包括单业务基准测试、单业务压力测试、单业务负载测试、综合业务基准测试、综合业务压力测试、综合业务负载测试、综合业务稳定性测试等7种测试场景。
- 单业务基准测试：测试某个具体业务是否满足系统设计或用户期望的性能指标。比如用户期望首页查询支持300个用户并发查询，如果满足了，则认为基准测试完成，否则失败。
- 单业务压力测试：测试某个具体业务在最大负载下，持续服务的时长，以此验证被测业务的稳定性。压力测试过程中所涉及的负载，是以系统基准负载为标准，如系统基准负载为50个并发用户，则压力测试的负载设为50个，通过运行时长的变化，验证服务器在系统预设负载下持续服务的能力。
- 单业务负载测试：测试某个具体业务能够承受的最大负载，验证被测业务能够承受的最大负载数，在最佳负载下，系统仍需满足各项性能指标。
- 综合业务基准测试：与单业务基准测试类似，但综合业务需考虑业务与业务间的联系，如果相互之间存在资源争用，则需单独组合测试。假设系统需测试的业务有三个：A、B、C,综合业务基准测试是将ABC一起运行，那么加上ABC三个基准测试，共计4个基准测试场景，分别是ABC、A、B、C,但A与C存在资源争用，则需单独将A与C组合，构成一个单独的测试场景，则一共为ABC、A、B、C、AC5个基准测试场景。
- 综合业务压力测试：与单业务压力测试类似。
- 综合业务负载测试：与单业务负载测试类似。
- 综合业务稳定性测试：综合业务稳定性测试通常为核心业务在基准负载的基础上运行相对长的时间，验证服务器持续提供稳定服务的能力。稳定性场景测试的时间由需求方设定，一般为7*24小时不间断执行。
6.2 场景设计
根据xxx系统确定本次性能测试的场景主要为首页查询并发基准测试、首页查询负载基准测试、登录并发基准测试、登录负载基准测试、订阅并发基准测试、订阅负载基准测试六个场景。
|
场景名称 |
场景类型 |
压测类型 |
用例组成 |
监控线SLA |
备注 |
|
1.单用户持续运行该业务场景10分钟 |
混合场景 |
基线 |
1.查询首页 |
CPU<80% |
单用户执行测试用例，并对测试数据进行采集 |
|
2.300并发用户持续运行该核心业务场景20分钟 |
混合场景 |
负载1 |
1.查询首页 |
CPU<80% |
|
7. 测试用例
|
用例名称 |
事务名称 |
步骤描述 |
事务响应可接受时间 |
|
1.登录 |
用户登录退出 |
步骤1：用户输入用户名和密码点击登录 |
<3 |
|
2.查询首页 |
查询首页 |
步骤1：游客用户打开系统首页 |
<3 |
|
3.提交申报信息 |
提交申报信息 |
步骤1：登录进入系统，点击管理列表 |
<3 |
|
4.审核通过申报流程 |
审核通过申报流程 |
步骤1：登录进入系统，点击管理列表 |
<3 |
|
5.提交机构解除申请 |
提交机构解除申请 |
步骤1：登录进入系统，点击管理列表 |
<3 |
|
6.提交数据填报 |
提交数据填报 |
步骤1：在每季末登录进入系统，点击数据填报 |
<3 |
|
7.审核通过数据填报流程 |
审核通过数据填报流程 |
步骤1：登录进入系统，点击数据填报 |
<3 |
|
8.提交数据填报 |
提交企业数据填报 |
步骤1：在每季末登录进入系统，点击数据填报 |
<3 |
8. 测试工具
8.1 脚本开发工具
在被测系统中通过抓包，将真实用户的操作步骤和使用数据全部记录下来，然后通过关联和参数化，编写形成可以多次重复并发运行的测试脚本，由jmeter执行脚本，并发执行业务，从而模拟真实生产系统的压力，形成对被测系统的加压，并监控和记录被测系统在这样的压力状况下表现出来的各种特征。
8.2 性能监控工具
通过jmeter在性能测试中的记录测试结果及其系统的运行状况，并将这些数据记录在测试报告的附件中，需要测试原纪录的内容主要包括以下几项：
运行前的系统配置、运行前的参数或者软件调整情况、运行过程中的内存使用情况、对比测试中的对比配置信息。
在性能测试过程中，需要通过azbbix或者其他监控工具监控主机、数据库、应用服务取的相关资源占用情况，主要包括如下几项：
网络级别的监控内容：单位时间内网络传输数据量
服务器系统级别的监控内容：CPU利用率、内存占用率
数据库级别的监控内容：数据库的并发连接数、数据库的SQL处理速率、数据锁资源的使用数量、top事件监控等。
性能测试完成以后，收集测试数据，这些数据包括以下内容：事务响应时间、事务成功率、tps等。
9. 场景执行计划
|
工作内容 |
起日期 |
止日期 |
状态 |
人员 |
|
1、性能测试准备 |
2020/1/1 |
2020/1/1 |
完成 |
|
|
1.1 测试讨论 |
2020/1/2 |
2020/1/2 |
完成 |
A,B |
|
1.2 测试方案制定 |
2020/1/3 |
2020/1/3 |
完成 |
A,B |
|
2、基础环境准备 |
2020/1/4 |
2020/1/4 |
完成 |
|
|
2.1 根据资源需求完成硬件环境准备 |
2020/1/5 |
2020/1/5 |
完成 |
A,B |
|
2.2基础软件(操作系统、数据库等)安装 |
2020/1/6 |
2020/1/6 |
完成 |
A,B |
|
2.3 平台数据库创建 |
2020/1/7 |
2020/1/7 |
完成 |
A,B |
|
3、测试前准备 |
2020/1/8 |
2020/1/8 |
完成 |
|
|
3.1 数据库造数、清数脚本准备和验证 |
2020/1/9 |
2020/1/9 |
完成 |
A,B |
|
3.2 测试场景准备 |
2020/1/10 |
2020/1/10 |
完成 |
A,B |
|
3.3 平台脚本准备及调试 |
2020/1/11 |
2020/1/11 |
完成 |
A,B |
|
4、测试执行 |
2020/1/12 |
2020/1/12 |
完成 |
|
|
4.1 混合场景测试 |
2020/1/13 |
2020/1/13 |
完成 |
A,B |
|
4.2 登录单场景测试 |
2020/1/14 |
2020/1/14 |
完成 |
A,B |
|
4.3 提交申报单场景测试 |
2020/1/15 |
2020/1/15 |
完成 |
A,B |
|
4.4 审核通过申报流程单场景测试 |
2020/1/16 |
2020/1/16 |
完成 |
A,B |
|
4.5 提交异常名录解除申请单场景测试 |
2020/1/17 |
2020/1/17 |
完成 |
A,B |
|
4.6 提交数据填报单场景测试 |
2020/1/18 |
2020/1/18 |
完成 |
A,B |
|
4.7 审核通过数据填报流程单场景测试 |
2020/1/19 |
2020/1/19 |
完成 |
A,B |
|
4.8 提交数据填报单场景测试 |
2020/1/20 |
2020/1/20 |
完成 |
A,B |
|
4.9 复测 |
43851 |
43851 |
完成 |
A,B |
|
5、测试分析 |
2020/1/22 |
2020/1/22 |
完成 |
|
|
5.1 测试结果整理与分析 |
2020/1/23 |
2020/1/23 |
完成 |
A,B |
|
5.2 测试报告编写与评审 |
2020/1/24 |
2020/1/24 |
完成 |
A,B |
10. 交付物
