性能测试报告不会写?最标准的模板来了 |
您所在的位置:网站首页 › 足球课程设计模板内容怎么写 › 性能测试报告不会写?最标准的模板来了 |
目录 性能测试报告 1. 测试概述 1.1 测试目标 1.2 指标和术语 2. 环境、工具 2.1 测试环境 2.2 测试工具 3. 测试方案 3.1 测试类型 3.2 业务模型 3.3 加密验签处理 3.4 压力梯度 4. 测试结果 4.1 聚合报告 4.2 系统吞吐量 4.3 资源占用率 5. 分析和建议 5.1 测试结论分析 5.2 问题 性能测试报告项目 XXX项目二期 版本 V1.00 作者 dayu 日期 2019.9.31 1. 测试概述 1.1 测试目标描述本次测试的意义和目标 本次测试的目的在于探查XXX项目二期重构环境的系统业务处理性能,以及在高负载情况下的系统表现。 1.2 指标和术语描述本次测试中涉及到的性能指标术语 术语 释义 并发数 测试时同时系统发出事务请求的数量,并发线程数用以模拟同时与系统建立连接的用户。 TPS(每秒事务数) 在每秒时间内系统可处理完毕的事务数。TPS很大程度体现系统性能能力。 错误率 经系统处理的事务出现错误的概率,对应着实际用户使用系统功能失败的情况。理想情况下错误率应保持极低水平。 资源占用率 服务器端各关键资源的使用比例,用于衡量系统硬件能力 2. 环境、工具列出本次测试所涉服务器、客户机和测试工具 2.1 测试环境服务器: 应用 机器 CPU、内存配置 API ip地址 16核CPU、内存16G MYSQL ip地址 16核CPU、内存16G 客户机: 操作系统 CPU 内存 Windows10 专业版 I3- 4170 3.70GHZ 8G 2.2 测试工具核心工具 版本 备注 Jmeter 3.3 提供并发请求能力 PerfMon Metrics Collector 2.1 Jmeter插件,用于收集服务器资源使用信息 ServerAgent 2.2.1 以伺服形式发送服务器资源使用信息 nMon 16h v2 实时收集服务器资源信息 3. 测试方案 3.1 测试类型不同的性能测试场景可能使用不同的测试类型,需要明确 本次性能测试将主要采用以下几种测试类型: l 基准测试: 在小并发条件下,探测系统各性能指标表现,作为后续比对基础。
l 压力测试: 由于无法准确预估用户访问量,因此考虑使用压力测试方法。压力测试旨在通过不断 增加系统并发处理事务数,增加系统负载,直到系统到达性能瓶颈。以此推算出系统 可承载用户和事务请求数。 l 稳定性测试: 将系统置于较长时间高负载场景下,探测系统是否出现稳定性缺陷。 3.2 业务模型针对系统接口,究竟哪些需要被纳入压测范畴?不同事务应该以何种比例被调用,这是需要建模设计的,也是性能测试的难点之一。 通过对于项目架构和业务场景分析,设计以下业务模型进行模拟和测试: 场景1:简单业务场景 业务名称 接口地址 请求类型 并发比例 登录 /login post 1 查询用户信息 /queryMemberInfo get 1
场景2:混合业务场景 业务名称 接口地址 请求类型 并发比例 登录 /login post 1 查询用户信息 /queryMemberInfo get 1 交易查询 /listOrderPage get 1 订单创建 /createOrder post 1 3.3 加密验签处理 由于系统对于所有事务请求都进行了加密验签处理,因此在本次性能测试中,需要对请求报文进行一致的加密和签名。处理逻辑如下: l 使用APP同样的加密签名代码,导出jar包做为加密工具类 l 使用jmeter前置处理器-beanshell处理器调用上述jar包方法实现请求参数加密 l 将加密签名后的请求参数存储为变量,后续接口调用时使用 3.4 压力梯度对于3.2所述场景,分别进行梯度加压,从100并发开始,每次递增100并发数,直至到达系统瓶颈。 4. 测试结果 4.1 聚合报告标签 样本数 平均(响应时间ms) 最小 最大 错误率 吞吐量(/s) 登录 50 28 20 38 0.00% 4.5977 查询member信息 50 1602 1292 2042 0.00% 4.07133 查看交易 50 705 512 920 0.00% 4.37828 创建订单 50 86 60 119 0.00% 4.55083 总体 200 605 20 2042 0.00% 15.11716 场景1-10并发-循环5次
标签 样本数 平均(响应时间ms) 最小 最小 错误率 吞吐量(/s) 登录 500 7612 40 26725 0.00% 15.84987 查询用户信息 500 30871 2369 49719 0.00% 6.96233 总体 1000 19241 40 49719 0.00% 13.91517 场景1-500并发-循环1次
标签 样本数 平均(响应时间ms) 最小 最大 错误率 吞吐量(/s) 登录 550 8326 33 22360 0.00% 20.34851 查询用户信息 550 36071 4362 58485 0.36% 6.7585 总体 1100 22199 33 58485 0.18% 13.51069 场景1-550并发-循环1次
标签 样本数 平均(响应时间ms) 最小 最大 错误率 吞吐量(/s) 登录 4500 12408 87 46269 0.00% 4.68807 查询用户信息 4500 35383 3792 65036 0.00% 4.63027 查看交易 4500 22832 711 46812 0.02% 4.64518 创建订单 4500 24973 81 58698 0.13% 4.67591 总体 18000 23899 81 65036 0.04% 18.50308 场景2-450并发-循环10次 4.2 系统吞吐量场景1-550并发-循环1次 场景2-450并发-循环10次 4.3 资源占用率最优负载条件下: CPU使用率
内存占用率 磁盘使用率 结合收集到的数据,给出对于系统性能关键点的分析 5.1 测试结论分析经过多次测试和数据报表分析,可以得出如下结论: 1) 当总体并发用户数为450-500时,系统具有最优性能表现;当事务并发数超过500时,事务失败率整体上升,系统到达性能拐点。 2) 多事务混合条件下,系统巅峰TPS在90左右,平均吞吐量在13-18/s。 3) 在小压力条件下(10并发),最大事务响应时间为查询用户信息事务的2042毫秒,平均在600毫秒左右系统。整体事务微观响应速度较优。 4) 满负载条件下,登录具有最佳的性能表现,平均响应时间为7000-12000毫秒;查询用户信息事务性能较差,平均响应时间在30000-40000区间。满负载条件下系统整体微观响应时间较差。查询用户接口由于其使用极为频繁,建议进行SQL效率调优 5) 系统资源方面,内存占用率始终处于高位水平(90%以上),磁盘空间由于日志写入而不断被占用。 5.2 问题 测试过程中发现了如下显著问题: 1) 加密验签功能并未生效-现阶段任何签名均可通过验签。属于功能性问题,不影响性能表现。 2) 日志文件由于不断写入导致磁盘占满,建议调低系统日志级别,并做好定期日志备份。 3) 内存占用处于高位水平,需要进一步探查原因。
|
今日新闻 |
推荐新闻 |
CopyRight 2018-2019 办公设备维修网 版权所有 豫ICP备15022753号-3 |