1 概述
1.1性能测试概念
性能测试是通过自动化的测试工具模拟多种正常峰值及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载测试确定在各种工作负载下系统的性能，目标是当负载逐渐增加时，测试系统的各项性能指标的变化情况。压力测试是通过一个系统的瓶颈或者不能接受的性能点，来获得系统能提供的最大服务级别的测试。
1.2性能测试目的
性能测试的目的是验证软件系统是否能够达到用户提出的性能指标，同时发现软件系统中存在的性能瓶颈，以优化软件，最后起到优化系统的目的。
1.3性能测试目标
从安全，可靠，稳定的角度出发，找出性能缺陷，并且找出系统最佳承受并发用户数，以及并发用户数下长时间运行的负载情况，如并发100用户，如何对系统进行调优
性能测试主要包括一下几个方面：
（1）评估系统的能力：测试中得到的负荷和响应时长数据可以被用于验证所计划的模型的能力，并帮助做出决策。
（2）识别体系中的弱点：受控的负荷可以被增加到一个极端的水平并突破它，从而修复体系的瓶颈或薄弱的地方。
（3）系统调优：重复运行测试，验证调整系统的活动是否得到了预期的结果，从而改进性能。
（4）检测软件中的问题：长时间的测试执行可导致程序发生由于内存泄漏引起的失败，揭示程序中隐含的问题或冲突。
（5）验证稳定性、可靠性：在一个生产负荷下执行测试一定的时间是评估系统稳定性和可靠性是否满足要求的唯一方法。
1.4性能测试的常见分类
（1）负载测试：负载测试是指通过测试系统在资源超负荷情况下的表现，来发现设计上的错误或验证系统的负载能力。在这种测试中，将使测试对象承担不同的工作量，以评测和评估测试对象在不同工作条件下的性能行为，以及持续正常运行的能力。负载测试的目的是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外，负载测试还要评估性能特征，如响应时长、事务处理速率和其他与时间相关的性能指标。
（2）压力测试：在软件工程中，压力测试是对系统不断施加压力的测试，是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。例如测试一个web站点在大量的负荷下，何时系统的响应会退化或失败。
（3）容量测试：容量测试确定系统可处理同时在线的最大用户数。
2 系统简介
2.1参考资料
性能相关的测试资料
2.2要做的测试
压力测试
基准测试
2.3测试环境
（1）硬件环境
（2）软件环境
3 测试指标
测试时间：2018年10月10日～10月11日
测试范围：客户端请求信息时，服务器各项性能指标的性能测试
3.1 Jmeter指标
(由于Apache旗下性能测试工具jmeter收集的性能指标偏少，下面的数据选取代表性指标)
（1）Averge/ms:服务器处理事务平均响应时间（表示客户端请求到服务器处理信息且反馈客户端的时间）
响应时间=呈现时间+网络传输时间+服务器端响应时间+应用延时时间
在互联网上对于用户响应时间，有一个普遍的标准。2/5/10秒原则。也就是说，在2秒之内给客户响应被用户认为是“非常有吸引力”的用户体验。在5秒之内响应客户被认为“比较不错”的用户体验，在10秒内给用户响应被认为“糟糕”的用户体验。如果超过10秒还没有得到响应，那么大多用户会认为这次请求是失败的。
（2）Throughput/s:服务器每秒处理请求数（表示服务器每秒处理客户端请求数（单位：个/秒））
（3）Error%：采样发生错误的比率
（4）KB/s：服务器每秒接收到的数据流量（表示服务器每秒接收到客户端请求的数据量KB表示）
3.2 硬件指标
（1）%Processor time：CPU使用率（平均低于75%，低于50%更佳）
（2）System：Processor Queue Length：CPU队列中的线程数（每个处理器平均低于2）
（3）Mermory:Page/sec：内存错误页数（平均低于20，低于15更佳）
（4）Physical Disk-%Disk time：磁盘使用率（平均低于50%）
4 测试工具和测试策略
测试工具：Apache-jmeter
测试策略: 根据公司内部实际情况，以及业务分布设置数据库访问量即并发用户数
测试数据: 注册用户、店铺数据、商品数据
数据说明：选取数据均为代表性数据
测试场景：1）、访问机场东大厅、西大厅店铺、以及店铺商品
2）、业务全链路测试：注册、登录、添加信用卡，提交订单、支付
3）、订单查询
5 测试结果数据以及截图
前提条件：假定用户数为50个用户数时，并发访问后台
5.1 Jmeter 性能指标
5.1.1 店铺访问测试结果及分析
总体测试情况：
| 指标 |
测试值 |
| 压测时长 |
20分10秒 |
| 并发数 |
100个线程（等价100个虚拟用户） |
| 平均响应时间 |
10556毫秒 |
| 最大响应时间 |
41595毫秒 |
| 吞吐量 |
7.3/sec |
| 容错率 |
0.01% |
各项测试详情：
1.Average/ms
数据分析：
本图表示服务器处理请求的平均相应时间
最佳性能是随着并发用户数的增加，平均事务相应时间比较平缓
本图清晰的可以看到，随着并发用户数的增加事务响应也随着上升
2.Throughput/s
数据分析：本图表示服务器每秒处理请求个数
最佳性能服务器处理请求数是随着用户的增加而增加
本图可以直观看到服务器处理请求数的个数并未随着用户的增加而增加
3.请求总数与用户图数
数据分析:
平均响应时间超出预期，当并发超过60个用户时，达到用户体验糟糕的情况
5.1.2 提交订单和支付测试结果及分析
总体测试情况：
| 指标 |
测试值 |
| 压测时长 |
19分17秒 |
| 并发数 |
30个线程（等价30个虚拟用户，实际订单和支付的并发只有20） |
| 平均响应时间 |
15673毫秒（invoice+pay） |
| 最大响应时间 |
27040毫秒（invoice+pay） |
| 吞吐量 |
2.2/sec（invoice+pay） |
| 容错率 |
1.62%（invoice+pay） |
各项测试详情：
1.Average/ms
数据分析：
本图表示服务器处理请求的平均相应时间
最佳性能是随着并发用户数的增加，平均事务相应时间比较平缓
本图清晰的可以看到，随着并发用户数的增加事务响应也随着上升
2.Throughput/s
数据分析：本图表示服务器每秒处理请求个数
最佳性能服务器处理请求数是随着用户的增加而增加
本图可以直观看到服务器处理请求数的个数随着用户的增加而增加
3.请求总数与用户图数
pay接口错误返回：{"code":"102","message":"Reject by processor: Error 1062: Duplicate entry '1000-153924520194' for key 'acq'"}
5.1.3 查看订单测试结果及分析
总体测试情况：
| 指标 |
测试值 |
| 压测时长 |
15分19秒 |
| 并发数 |
50个线程 |
| 平均响应时间 |
9467毫秒 |
| 最大响应时间 |
30073毫秒 |
| 吞吐量 |
3.9/sec |
| 容错率 |
0.03% |
各项测试详情：
1.Average/ms
数据分析：
本图表示服务器处理请求的平均相应时间
最佳性能是随着并发用户数的增加，平均事务相应时间比较平缓
本图清晰的可以看到，随着并发用户数的增加事务响应也随着上升
2.Throughput/s
数据分析：本图表示服务器每秒处理请求个数
最佳性能服务器处理请求数是随着用户的增加而增加
本图可以直观看到服务器处理请求数的个数并未随着用户的增加而增加
3.请求总数与用户图数
5.2 硬件指标
观测后台两台主要的服务器，CPU使用率大部分时候介于50%～65%，高峰时达到70%到85%，最高峰是达到92.2%。
6 测试结论
6.1 Jmeter性能指标分析
由Jmeter性能指标最直观的可以看出网络性能的不足，客观的反映出服务器处理能力存在优化空间
1、店铺访问测试，主要是模拟用户未登录情况访问机场店铺的场景。模拟100个用户同一时间不间断查询店铺信息，在负载测试情况下，响应时间过长。
2、订单提交和支付测试，主要是模拟20个用户并发同时下单场景，吞吐量均为1.1/sec，相对于后台的invoice和pay这两个接口都是1秒只能处理一个请求。需要评估是否有优化的空间
3、查询订单接口测试，主要模拟客户端2秒请求一次订单接口的场景。响应时间也过长，这样会在订单状态变化中，如果不停请求，可能会出现新旧状态不停切换的情况，所以响应时间会跟不上2秒请求一次的时间间隔，频率是否可做调整。
优化建议：待定
6.2 服务器硬件信息监控数据分析
结合Jmeter性能指标和多个硬件监控图
优化建议：无