13. 服务端性能测试
说到服务端性能测试就不得不提到上述流程图，言简意赅的概括了性能测试中所需要做到的内容。上面是比较全的指标。但实际工作中的每一次性能测试可能都有一定的侧重点，比如在trace的测试中可能更看重的两个版本之间的性能对比；在redis的测试中更注重的单机的双写qps上限；在函数计算的测试过程中更注重在一定的qps压力系统的稳定性；而在discovery的压测过程中可能更注重的复现线上问题 以及 定位系统瓶颈。
压力测试的过程往往需要反复是比较耗时的过程，因此一定有每次压测的侧重点。而在目前大部分的场景测试中，可能事务的响应时间可能并不作为重点关注的事项。也有可能之前的测试业务在这点上并不关心。
性能指标
在服务端性能测试中通常我们需要关注的指标分为客户端的指标以及服务端指标；
1.客户端也就是我们产生压力的机器；
2.服务端就是我们的测试机器；
在服务端我们需要关注机器的：
1.cpu、mem负载情况；
2.网络链接数占用情况；
3.磁盘的读写；
4.网卡流量吞出等；
更进一步如果我们要做相应的性能分析和优化 可能需要关注 机器上的线程数；gc耗时等。
在性能指标这块，其实整个类别和我们在做移动端的测试情况大底相同。只不过这里的测试进程变成了一个可以对外提供http服务的进程，所以可能需要额外更加关注网络连接的使用；网卡流量的吞吐。
测试流程
测试开始前要确定：
1.梳理待测机器的规格，诸如服务器的cpu核数以及内存大小、缓存集群的大小、消息队列的容量限制
2.梳理压测接口的请求链路，确定链路上哪些是第三方应用，如果涉及第三方调用 可以先提前和第三方进行沟通 明确第三方资源ready；压力可以真实到达我们关注的待测服务。（一般会直接ip调用在内网，移除网关等依赖）
3.明确压测场景，场景中涉及的接口。准备相应的压测脚本以及测试数据。在压测过程中，一般来说测试数据是比较难准备的，尤其是对大QPS，需要百万级别的数据，因此造数也是在压测过程中的关键部分。
4.明确压测终止的条件：是客户端出错；还是某个资源达到60%；还是其他；
5.明确告警、日志等观测组件是否配置ok；便于在压测过程中分析相应的现场
测试过程：
1.从一个基准并发线程数开始压测并持续压测一段时间5-10分钟；观察服务端的请求qps以及系统资源使用情况；并且关注客户端的错误率 以及请求的处理时间tps；保证客户端无错误；
2.然后递增逐渐增
剩余60%内容，订阅专栏后可继续查看/也可单篇购买
本专栏专注于从零到1的接口自动化测试框架开发过程分享、Android端专项测试技术分享，服务端专项测试技术分享 以及 基于开源框架进行二次开发的经验分享
查看19道真题和解析