性能测试准备过程总结
准备阶段
必要性分析
分析是否有必要进行性能测试；
被测对象分析
确认被测对象，并根据被测对象性质确认测试方案；
测试技术准备
根据被测对象准备测试技术
不同协议测试工具、测试重点及方案是有区别的，例如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存储
评估服务日志量大小；
-
其它意想不到的依赖
场景：百度春晚红包需求，百度红包服务端性能符合预期，但整理逻辑中忽略了用户习惯（用户对百度的认知是搜索引擎而不是app，所以app的红包功能对百度网页搜索带来了非常大的并发流量）导致搜索引擎主站瘫痪；百度红包功能还对第三方app市场和appstore带来大量流量，导致其服务瘫痪；
测试方案
测试方案应包含以下内容
被测对象（即性能测试需求中的功能-子功能）
测试目标
有预期的情况：经评估的各个指标预期预期不明确的情况：说明情况，例如“此功能无法预估预期qps状态，上线后根据实际情况调整”
测试环境
说明测试所用机器各项配置；
依赖说明
说明被测服务依赖的服务及功能的状态或mock状态
实验分组及排期
每组的验证点及环境、时间安排；
测试工具
http接口工具
-
loadrunner
-
locust
-
jmeter
-
wrk
grpc工具
-
ghz
流量复制放大回放
-
goreplay
websocket长连接
-
websocket-bench
其它自定义协议等
-
自己编写压测脚本
可使用go语言或python gevent库等方案模拟大并发
测试用例
测试用例要覆盖所有逻辑，可以通过统计压测用例覆盖率的方法来确定是否有遗漏逻辑；需评估未覆盖的代码逻辑是否需要补充用例；
测试环境
测试环境要尽量与线上保持一致；不能保持一致的可选择性能比线上少低一点的机器；如果服务是第一次上线，建议在不影响线上其它服务的情况下（外围有线上proxy，或需要读写线上数据库等类似情况不能直接使用测试环境进行性能测试）直接只用线上环境进行性能测试；
子服务&测试配置准备
测试中台服务时需要准备与生产环境一致的子服务或微服务，没有条件准备时可使用mock服务替代；
风险预案
对重要的被测系统应该做planB，例如：一组服务为节省资源，使用8台服务器，评估可满足需求；但可能存在短时大并发的情况，所以，在上线之初或有运营活动之前，应准备一些备用机，当线上监控报出问题时，立刻扩容；
