性能测试总结---开篇（理想很丰满，工具很骨感）

接触性能测试有大半年了，总结一下自己对性能测试的认知（这里我们只说后端）。趟着石头过河，如果发现我哪里写错了，请留言指正。

之前被提醒性能测试不等于loadrunner、jmeter；但是从网上自学的最好途径也莫过于这两种工具了。。。。搞来搞去还是被套路了。模拟真实环境，录制和生成脚本，优化脚本并准备测试数据，设置和部署场景，产生并发用户和向系统施加持续的压力，监控承压服务。。。。。

性能测试的本质其实是：尽量模拟出批量真实用户的操作场景，对被测试系统实施负载测试，通过监视承压端在不同的压力场景下的性能表现来定位出潜在的性能瓶颈，提出瓶颈点并组织推动优化。选用压测工具确实能在很大程度上满足以上需求，且学习成本低，关键是能短时出测试结论。

先说一下以上工具是怎么实现压测的：

　　　拿我司的项目举例：真实的线上环境是很复杂的，全国各地的用户（ip）使用不同的设备（device）通过客户端（clinic）基于某种协议（如HTTP）发送不同数据格式（如POST GET）的请求，途径DNS解析到负载（Ngx）最后分发到服务端（server），服务端逻辑处理通过查询redis或数据库（DB）来给客户端返回数据。

一：首先环境部署，由于水平不高能力有限，我是这么部署的：跟运维要了一台服务器（与承压端处于同一局域网），安装windos桌面并部署压测工具及环境，将主要的后端程序（单台服务）隔离出来作为承压端，在不考虑外网，不考虑负载均衡，不考虑实际实际数据库体量。。。。（看到美团的全链路之后，笑到哭）

二：梳理脚本准备数据，尽量模拟用户真实操作：如对登录事务进行压力负载，首先要准备好登录事务所涉及到的接口请求，然后尽可能的将主要的请求参数参数化，如ip欺骗，设备型号，登录用户信息等（接口如果有token或currentime等实时参数的限制，需跟开发请教规则并自己在脚本中将其参数化）；其次按照你想要压测得目标值设定场景（你想要达到的性能需求来设置定时器，处理器及断言）

三：负载过程中监控承压服务：没有使用什么牛逼的监控手段，直接在服务后台top

四：分析结果并调优：讲真，没什么发言权。全凭开发运维去调优，搞性能测试本也不是测试一个人能搞清楚的，需要开发、运维去共同调试。 服务器硬件大小及参数配置、网络因素（DNS、带宽）、中间件的配置及数据库配置、应用程序里的逻辑处理 sql语句优化 等。随便一项往深挖就不是一两天能整明白的，个人觉得还是应该在测试自己的一亩三分地深耕的基础上尽量去拓宽自己的知识面。路漫漫、、、

我先大概写一下我做性能测试所涉及到的大概事项，之后慢慢将详细的细节梳理一遍，又快到年底了。。。。