前言
性能测试的目的是发现系统处理能力的瓶颈而系统调优才是最终的目的，如果能进一步提高各业务服务器、数据库服务器的调优技能，对性能测试工作来说是如虎添翼。

相信我们进行性能测试的时候，都遇到过这样的问题：
1、你的性能测试方案是什么样的？
2、我们现在系统整体性能状况如何？
3、为什么你会设计这样的方案（如并发、迭代、思考时间、各项指标）
4、你设计的这个方案假使过了，能保证生产环境不出问题吗？

准备阶段
必要性分析
分析是否有必要进行性能测试；

被测对象分析
确认被测对象，并根据被测对象性质确认测试方案；

测试技术准备
根据被测对象准备测试技术不同协议测试工具、测试重点及方案是有区别的，例如http接口、rpc、websocket、udp测试技术不同，应根据不同的测试对象准备不同的测试方案

目标评估
评估被测服务性能指标预期结果

峰值QPS
已上线的需求可以按目前线上状态评估，这样最准未上线的需求一种方式可以找类似其它功能，没有相似功能的话可以找类似其它产品无法参照的话可按全量工具评估总请求，平均到秒后再按“帕累托法则（八二法则）”乘以对应系数估算

QPS
大部分单一接口的QPS=HPS，一条请求就是一次query，有少部分需求可能一次Hit有多次Query，需了解具体业务实现

TPS
复杂业务评估指标可使用TPS（每秒处理事务数），常见的情况像一次转账业务可能包含查询、转账、核对等几个连续动作，这种连续动作可称为一次T，TPS经常用来评估逻辑处理的能力和用时；

响应时间
不同产品对响应时间的要求是不相同的，内存处理一般请求的响应时间应该在10ms以内，有数据库读写的情况可能稍长（redis一般是十毫秒级别，mongo稍长，mysql最长，但一般大小的数据也应该在百毫秒级别）超过百毫秒的情况需要确认具体需求，及这类情况占比，响应时间指标一般有下面几种级别；

平均响应时间
总时间/总请求数
TP50：所有请求中处理最快的前50%请求中的最长耗时
TP90：所有请求中处理最快的前90%请求中的最长耗时
TP95：所有请求中处理最快的前95%请求中的最长耗时
TP99：所有请求中处理最快的前99%请求中的最长耗时
TP999：所有请求中处理最快的前99.9%请求中的最长耗时

错误响应数占比
所有请求中非200返回码的请求数占比

超时率
所有请求中超时的请求数占比需在压测工具中定义一个超时时间

被测服务资源占用指标预期
服务器cpu预期
程序有大量运算的情况下cpu可能成为瓶颈，例如dsa加密、大量检索运算；

服务器内存预期
1、程序启动时需要load大量数据到内存；
2、程序运行时需要使用大量内存以增加处理速度（空间换时间）的情况；

存储预期
绝大多数的web服务存储开销都在log等功能需求上，且一般情况log文件会定时传走&清理，这里要注意清理过程是否会存在log积压；

带宽预期
一般过大的静态资源应放在专用的资源服务器上，带宽问题常见于大量数据资讯返回或流媒体服务中；

端口数预期
端口问题常见于长连接服务，和需要作为client端向子服务请求的需求；
常见问题：1、time_wait过多；2、服务阻塞导致端口无法释放；

磁盘io预期
磁盘io问题常见于写log的功能，业务逻辑中需要做磁盘io的需求已经不多了，因为数据在程序启动时会被加载到内存中以提升读写速度；

相关依赖预期评估
依赖后端子服务
处理一个请求时需要向一个或多个后端服务请求资源；

依赖后端DB
处理一个请求时需要做db读写操作；

依赖运行环境，例如K8S集群等
服务运行的环境可能导致性能不满足预期，例如当服务部署在虚机时，需要评估虚机处理能力；如果部署在k8s集群时，需评估宿主机和集群前端proxy处理能力；如请求流包含多个环节时，每个环节都有压力存在；

依赖外部资源，例如CDN服务等
场景：业务逻辑回返回cdn地址，客户端收到地址后直接去cdn获取数据；
这类场景需要对cdn服务的处理能力和带宽预期做评估；

依赖磁盘空间，例如log存储
评估服务日志量大小；

最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取