【面试 - 性能测试工程师】如何在项目中练手性能测试，莫慌

大家好，我是温大大。今天给大家带来了另一个读者故事，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、还是没出现以上的情况，那也不代表它不存在「性能瓶颈」，你也可以提出「性能摸底」要求，双手属于自己，没人管的住你用它制造「财富」，所以少年跟我一起「加薪」吧。

点评：如果你还不知道如何开始，可以找到我，让我帮你分析分析，看看有没有适合你走的路，每个人都是独特的自己，有自己存在的价值

加我好友拉你进面试群，一起讨论面试干货 / 套路，大家一起升职加薪

关注我，加我好友拉你进面试群，一起讨论面试干货 / 套路，大家一起升职加薪

点击链接：温大大

让我帮你规划下学习线路 & 职业规划线路，帮你升职加薪。

关注公众号：「测试猿温大大」