2022-03-20 22:40 大数据开发工程师

关注

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

大家好，我是温大大。今天给大家带来了另一个读者故事，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