目录

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 问题

总结：

---

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. 分析和建议

结合收集到的数据，给出对于系统性能关键点的分析

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) 内存占用处于高位水平，需要进一步探查原因。

总结：

感谢每一个认真阅读我文章的人！！！

我个人整理了我这几年软件测试生涯整理的一些技术资料，包含：电子书，简历模块，各种工作模板，面试宝典，自学项目等。欢迎大家点击下方名片免费领取，千万不要错过哦。