性能测试整体流程分为以下几部分：

本次分享一下最后一部分：性能报告

a)  性能报告：

         i.      性能测试报告没有固定的格式，但是大体需要包括以下几个方面：

1.   整体结论：本次性能测试的整体结论。是否符合预期，是否可以上线。

2.   具体推算方式：主要指给出整体结论的参考数据、计算公式等。

3.   具体性能图标：服务器cpu、内存、网络IO、磁盘IO、TPS、responsetime等指标，涉及到数据库的还需要给出与数据库相关的指标。

一．     测试结论：（给出客观的测试结果及产品建议、评估方法）

一元夺宝服务器单台可以保持整组请求300QPS并保持稳定，其中charge/list.html接口是系统的主要瓶颈，请产品看下QPS是否符合预期，如果不符合预期，建议从这个接口着手继续优化。

具体接口QPS情况：

Charge接口主要包括：charge/index.html、do.html、list.html，其中QPS达到60时，charge/list.html接口的响应时间超过2s。

二．     具体测试结果：

HPS：

       本组结论：整组一元夺宝请求可以达到HPS300并保持系统性能稳定。

CPU占用：

       本组结论：整个打压过程中，cpu占用低于20%，符合预期

Mem占用：

从图中可以看出：

Response time：

本组结论：整个打压过程中，所有接口的response time一直小于1s（每个事务封装有多个请求），charge组合请求是导致QPS上不去的主要原因，后续优化时建议从charge请求着手。

三．     测试过程中发现的问题：

1、 Detail接口打压一段时间后，返回404错误。

解决方案：resin启动的时候 jvm参数配置中默认堆控件分配不足，增加Xms及PermSize配置后，不会再返回404错误。

2、 打压detail→shop序列请求QPS不到10时，服务器shop接口出现404错误，同时response time逐渐增加到5s以上。

解决方案：添加数据库监控后，发现是数据库查询逐渐增加到5s导致的，查看具体sql语句发现有一项查询会将所有表都查出来，导致效率很慢，而这项没有用，去掉后，QPS可以达到140左右。

3、 除了pay和charge的接口，整体打压时，发现order接口在高压下，占了5s以上。

解决方案：由于数据库没有添加索引，全表查询的，添加索引后，QPS可以达到200以上，问题解决。

四．     测试基本信息

测试任务名称：一元夺宝服务器性能测试方案

测试目的：检查在高并发的情况下一元夺宝服务器运行情况，并尝试找出系统瓶颈。

测试人员：曹承臻

测试环境说明

l   硬件/系统配置

CPU：Core 32核

内存：128G

操作系统：Linux

l   程序配置

无

l   测试数据

无

测试分组

a)      测试分组一

测试目的：并发较多一元夺宝服务器请求时，查看一元夺宝服务器各项性能。

持续时间：

1h

测试条件：

1.     一元夺宝服务器服务器可以正常提供服务并保持性能稳定

测试方法：

1.      模拟用户操作过程，组成打压请求脚本。

2.      使用Loadrunner向一元夺宝服务器打压

3.      每秒请求数为20个，每2分钟增加20个/秒，一直增加到500/秒并持续30分钟

4.      重点关注同时并发用户数，TPS，响应时间，server端的CPU和内存占用情况

5.      对比得到的性能结果数据，尝试找出性能瓶颈。

测试脚本逻辑：

1.     向一元夺宝服务器发送请求，随机组合发送一元夺宝请求序列，验证返回结果正确性 

{测试窝原创文章，作者：曹承臻}

作者简介：曹承臻，06届大学本科毕业，数学专业，6年软件测试行业经验。