大家好，我是温大大。 今天给大家带来了另一个读者故事，A君故事 ———— 点工逆袭成为性能专项测试工程师的故事。
「现状」
A君毕业于某专科，毕业后做过运维、做过销售，
目前在武汉一家电商公司从事功能测试，也是待了最久的一家待了3年了。
目前他所在测试团队由10到增长到30多人，
他自己虽然学到了一些测试经验，但他自己感觉所处在团队的中低层，升职加薪无望了，
最可怕的是毕业6年了目前薪水也只维持在12K左右，
但总感觉自己没有一技之长，他想跳出点工的圈子（功能测试），想要搞一搞性能专项测试，
自己也网上找了一些教学视频，但总感觉学不透也上不了手，所以他找到我，希望我能给他一些学习建议和性能测试方面的职业规划。
「建议」
我了解了他的情况后，建议他先「学习」性能测试技能，在「找机会」实操项目，最后「主动」出击。
- 1、先「学习」入手 ，掌握性能测试入门3把斧头：性能工具、需求分析、瓶颈定位。
- 2、再「找机会」实操，「识别」目前测试工作中哪些可能涉及性能测试，主动承担「额外」工作量，进行实操练手。
- 3、最后「主动」出击，「锁定」目标公司可能是专项性能测试 或 会接触性能测试的工种，「迈出」性能测试之路第一步
目前该同学面了3家公司的性能专项测试工程师，1家给出了offer 16K+，其余2家刚过1面，虽然offer 只涨了4K 但是他成功开启了另一段职业道路 ———— 性能专项测试工程师
同样的今天给大家讲讲：
- 1.需求分析
- 2.工具选择
- 3.场景设计
- 4.场景执行
- 5.瓶颈调优
- 6.如何找项目「实操」
需求分析
有的同学会说性能测试第一步就是先搭建1个环境吧，或者说来找个工具开始搞吧，不搞性能需求调研的测试就是耍流氓，所以我们第一步做调研，还是以1个项目开始，就拿温大大做过的wifi认证项目给大家分享吧：
【业务模型+数据流】
温大大以一个真实的项目为例进行说明，部分模块做了简化处理
概述：手机WiFi认证项目 业务：业务由推送+认证+广告展示组成 交互：
- 1、手机 与 wifi 建立 tcp 连接，并且给手机推送认证页面，用户输入用户名+密码进行认证
- 2、请求发送到 nginx进行负载
- 3、具体server接收到请求后，会先在查询radis查询密码是否匹配，不匹配则查询mysql查看密码是否匹配
- 4、最终结果http定向报文302会返回给前端
有的同学可能会问，直接访问url入口就能压测了，为啥还需要了解这些模块与数据流呢，温大大想说因为只有我们深入了解数据流交互才能思考：我们选取什么「压测工具」、采取什么「压测策略」、如何分层定位「瓶颈」
【qps估算方法】
- 1、有明确的指标，按照指标来
- 2、没有明确指标，通过线上log采集估算
先说有明确指标时，你可以直接按照规定指标来，例：推送2000、用户认证qps200、广告展示50。
再说没有明确指标时，你可以从已经部署环境中推算以上的指标，还是以上面wifi项目为例：
首先获取认证log，一般这样的log都是以流水记录的，并且离散分布在一天的24小时内，所以我们不能统计全部数据，得过滤一些无效或者非法的数据，因为是银行认证系统，所以客户真实的认证时间是早9点-晚5点，我们通过Python或shell脚本过滤出这个时间内总认证总条数（假设我们获取了100万条），但这些认证请求肯定不是平均分布在8小时内，肯定是有认证高峰与低峰，所以我们根据 业界通用2/8法则定义：假设用户高峰认证现象发生在营业总时间内的20%情况下，也就是1.6小时内（8*0.2=1.6）。 那么认证qps=总认证条数/总业务认证时间，即每秒认证180 条（ 100万/1.6/3600=180）
在得到认证qps后，根据日志分析得出：wifi推送了10次里面才有1次用户认证+1次广告展示， 所以我们也得到了：推送qps 1800（180*10)与广告展示qps 180
- 认证qps 180
- 推送qps 1800
- 广告qps 180
【未来qps推算】
再来推算未来扩展后的qps，假设现有规模是2000个网点，未来老板说我们计划扩张到2万个网点，那未来qps就是现在的10倍，那么未来业务qps： 推送：180010=1.8万 认证：18010=0.18万 广告：180*10=0.18万
点评：当然估算方法有很多也可以根据其他规则来，但必须建立在真实的数据上面来，具体你可以跟研发/项目负责人一起协商。
工具选择
前面第一章系统数据流分析得知： 我们压测对象是cs架构、通过http协议请求与WiFi硬件链接、再通过nginx负载、server接受访问数据库或radis缓存的一个系统结构。
所以我只需要选取一个压测工具支持http协议的即可，目前业界通用的有几种，都有各自的优缺点：
1.企业级压测工具 loadrunner
优点： 支持多种协议压测模拟，简单上手的录制调试机制，丰富化的参数函数库，提供多样的监控系统指标的窗口以及丰富完善的报告模板。
缺点： 重量级的压测工具，安装比较反锁，而且需付费，虽然网上有很多破解资料，但如果是你公司是大型企业一般会因为版权放弃此工具。
2.开源压测工具 jmeter
优点：基于java语言的开源压测工具，同时支持多种协议，灵活性较高可以通过对内置插件进行二次开发
缺点：对于复杂的协议需要自己实现脚本编写，学习成本较高
3.Apache 自带压测工具ab，又称Apache Benchmark，支持对web网站进行压测。
优点：轻量级压测工具，安装简单上手很快，直接通过参数+URL可以实现对网站的压测
缺点：只是支持web网站压测工具，不支持其他协议的压测，报告不支持ui图形界面
结论
基于上面场景通过http协议触发流程，所以我们可以任意一种工具进行压测，后续以loadrunner进行讲解
点评：结合实际情况来选，若被压测系统是一些标准的协议选LR，若项目只是轻量级的请求选AB，若项目需要对压测工具进行要求二次开发或需对dubbo服务压测选jmeter
场景设计
有了工具后，也先别急搞脚本，让我们设计下性能场景，性能场景设计主要为了定位性能问题，分为3步走：
- 1、基准场景，将整条链路拆解成单个模块，并对单模块做压测，确保每个模块达到预期qps。
- 2、组合场景，基准场景达标后，接着设计组合场景，这就是「真实」高峰并发的用户场景，一般是压测业务的入口接口。
- 3、疲劳场景，短时间的组合场景通过后，并不能证明长时间的场景不会出现「内存」泄露这样的一些问题，所以还需要让「疲劳」场景帮忙验证，但考虑到真实情况，并不是7*24小时都是「高峰」并发，所以我们取 60%的组合场景指标作为 疲劳场景的压力指标
点评：以上是通用的一些场景，有些性能压测中还会考虑部署层面内容：单机 与 集群，低配置 与 高配置，具体视情况而定
场景执行
通过工具模拟请求，这里通过loadrunner 模拟http请求，这里我们不详细展开，后续开个专题给大家讲解
- 1、录制脚本
- 2、调试脚本(关联获取cookies)
- 3、加强脚本(参数化)
- 4、并发脚本(设置集合点、并发数)
- 5、监控指标
- 6、报告解读
点评：若对 loadrunner/jmeter 实操感兴趣的朋友，可以留言或者分享此文章出去，若阅读量达到500，温大大在爆肝继续输出 loadrunner/jmeter 的实操指南，在此立1个flag
瓶颈调优
由于有了基准场景、组合场景、疲劳场景的设计，所以瓶颈调优工作变得并不是那么难。
在基准场景下，确保每个模块对应的qps都能达标，这样就排除了单模块瓶颈的问题。
在组合场景下，若出现性能瓶颈，多半是模块 与 模块之间请求、数据库访问、网络、硬件 本身的问题，
大致可以通过以下几个方向去排查：
- 1、网络层：压力机与后端服务器的带宽不存在瓶颈，通过nmon工具在压力机侧与后端服务器侧观察网络是否打满，若打满则需加大网络带宽。
- 2、中间层：上面这个场景中则指nginx负载是否存在瓶颈，是否有负载不均衡情况，或者负载本身算法不合理的情况。
- 3、系统层：cs结构的系统中，client端与server端建立tcp链接数、文件句柄数是否达到系统上限，需要ulimit、net.ipv4这样的配置去调优。系统的cpu、内存、io读写是否存在满负载的情况，这些需要通过nmon、iostat一类的工具去定位。
- 4、数据库层：数据的访问是否都命中了缓存、没有走缓存的查询sql是否存在慢查询、慢查询是否是因为没走索引照成的，这些是数据层需要定位、优化考虑的事情。
- 5、内部逻辑层：以上常规的优化手段都试过后，发现qps上去后跑几天后又降下来的情况，那么是否内部逻辑本身存在内存泄露的问题，我们需要将qps出现拐点时那时的主进程的镜像通过工具jamp dump下来，然后通过一些java 镜像分析工具去看进程中那些堆栈占用太多，例：eclipse memory analyze
点评：以上只是一些通用常规的一些排查手段，主要思想是将系统进行拆解，然后确保数据流每个环节都不存在瓶颈，你可以通过nmon、iostat、jdk工具去监控是否该环节是否存在瓶颈，然后对该环节的模块通过一些配置参数或者更换硬件配置去调优
如何找项目「实操」
当然你也许会说，我们项目没有给我提供这样的机会，
温大大想说：“朋友，有句名言：机会出了留给有准备的人，它的后半句是：你得给自己制造机会”
再说回A君，他所在项目也没有这样的机会。
再跟我交流后，我发现他们有web页面刷新缓慢情况，于是鼓励A君，让他自己主动提出「性能摸底」的要求，于是才有了后面他加薪的故事。
说到这里温大大再送你们几个场景，让你找到属于自己的「性能测试」之路：
1、收集系统槽点，找出页面加载缓慢、数据库查询缓慢、接口响应缓慢的地方。
2、系统都不存在以上的情况，那么我们看看系统的资源占有是否过高：cpu/内存/磁盘/tcp 连接。
3、还是没出现以上的情况，那也不代表它不存在「性能瓶颈」，你也可以提出「性能摸底」要求，双手属于自己，没人管的住你用它制造「财富」，所以少年跟我一起「加薪」吧。
点评：如果你还不知道如何开始，可以找到我，让我帮你分析分析，看看有没有适合你走的路，每个人都是独特的自己，有自己存在的价值
关注我，加我好友拉你进面试群，一起讨论面试干货 / 套路，大家一起升职加薪
点击链接：温大大
让我帮你规划下学习线路 & 职业规划线路，帮你升职加薪。
关注公众号：「测试猿温大大」
