本文将带你了解软件测试技术之性能测试流程之性能报告篇，希望对大家学测试技术有所帮助

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

本次分享一下最后一部分：性能报告
;
 
a); 性能报告：
;;;;;;;; i.;;;;; 性能测试报告没有固定的格式，但是大体需要包括以下几个方面：
1.;; 整体结论：本次性能测试的整体结论。是否符合预期，是否可以上线。
2.;; 具体推算方式：主要指给出整体结论的参考数据、计算公式等。
3.;; 具体性能图标：服务器cpu、内存、网络IO、磁盘IO、TPS、responsetime等指标，涉及到数据库的还需要给出与数据库相关的指标。
 
 
一．;;;; 测试结论：（给出客观的测试结果及产品建议、评估方法）
一元夺宝服务器单台可以保持整组请求300QPS并保持稳定，其中charge/list.html接口是系统的主要瓶颈，请产品看下QPS是否符合预期，如果不符合预期，建议从这个接口着手继续优化。
具体接口QPS情况：
;;;;;;;;;;;;;;;;;;;; 


 
 
 接口名称
 
 
 QPS
 
 
 
 
 Pay
 
 
 550
 
 
 
 
 Charge
 
 
 65
 
 
 
 
 Detail/index
 
 
 2000
 
 
 
 
 Usercenter
 
 
 300
 
 
 
 
 其他
 
 
 1500
 
 


;
Charge接口主要包括：charge/index.html、do.html、list.html，其中QPS达到60时，charge/list.html接口的响应时间超过2s。
;
二．;;;; 具体测试结果：
HPS：
 
;;
;;;;;; 本组结论：整组一元夺宝请求可以达到HPS300并保持系统性能稳定。
;;;;;; 
CPU占用：
;
;;;;;; 本组结论：整个打压过程中，cpu占用低于20%，符合预期
;;;;;; 
Mem占用：

 
从图中可以看出： 
;;;;;;;;1、 usedmem内存和php-fpm占用的内存在8小时内曲线平稳。没有内存泄露。 
;;;;;;;;2、 buff/cache内存在逐渐增长。属于正常缓存，并不是实实在在占用的物理内存。 

 
 
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.;;;; 向一元夺宝服务器发送请求，随机组合发送一元夺宝请求序列，验证返回结果正确性;
   

本文由职坐标整理并发布，希望对同学们有所帮助。了解更多详情请关注职坐标软件测试之测试技术频道！