新人如何学习性能测试？在网络吞吐性能测试中 pipeline 构造批量请求模式除了“跑分”

软件测试火的①塌糊涂的时候，大家心里估计在颤抖。不就是点点系统嘛，能有什么大出息，软件测试做几年以后大家水平都差不多，如何才能不被快速取代，去做性能测试呀。

测试做久了就会知道，性能测试是测试人员的终极梦想，这是为什么呢？工资高呀。我有朋友做了③年功能测试，感觉太机械，然后报培训班学习性能测试，目前从事性能测试工作。

万事开头难，我从想做性能测试到现在⑤个年头过去了，现在把做性能测试过程中的迷茫、坚持、到后来的被认可写下来，纪念下那年的加班岁月。

我①直认为自己很幸运，在校期间就找了份实习工作，做金融方面的测试。银行系统涉及到钱，所以从公司到银行很重视测试。当然了现在互联网时代，性能测试就更重要了。

大③暑期实习时做了软件测试，培训老师说软件测试分为功能测试和性能测试，最牛逼的是做性能测试，那简直是受万人敬仰。

刚好学校开始选毕设课题，看到了loadrunner性能测试题目，带着想成为行业的大拿，受到膜拜的幻想，于是乎选择了这个课题，仿佛看到了未来做性能测试的样子。

由于在学校老师没教过这个，所以得自学，就连loadrunner工具也得自己在网上下载，loadrunner是大型商业软件，小公司用的大都是开源工具，公司做银行系统，所以性能测试是重中之重，正好有此软件。

第①次听培训老师讲性能，特别认真的带着本和笔坐第①排听。培训老师在公司待①⓪多年了，讲的很好。“⑧⓪%的交易是②⓪%的时间完成的、tps、tps拐点、脚本、并发用户数、最大并发用户数、单交易场景、混合交易场景等”听的云里雾里。

实习时在公司培训班待了①周，做了个小型银行系统，大概只有账户查询、开户、存款贷款等小模块。系统用于是乎我就在电脑里安装了这个系统做性能测试。

公司有配置库，文档包括各种类型，恰好有性能测试文档。由于公司有②人做性能测试，常年在客户现场出差，所以①切都得自学，带我毕设的老师也是没做过这方面的工作。

度娘里找答案，清①色全是loadrunner的工具使用，如何设置参数、如何录制脚本、脚本参数化等。到了这步就木有下文了，宝宝心里苦。

我最想看到的是录制脚本后脚本运行成功（数据库里有条成功数据）、如何设置场景、如何获取有用的数据、以及如何测出瓶颈、以及如何解决瓶颈、最后出份漂亮的性能测试报告。心理想着等我哪天做完性能测试①定和大家分享有用的知识。

现在回想起来，当初真是太可怜了，录制脚本后，回放录制的视频，界面①直显示登录超时，登陆脚本都无法登录系统，更别提之后的测试脚本了。

大④毕设做的很不好，没人指导，自己在瞎琢磨，没有写过测试脚本，毕设答辩内容很空洞，勉强通过。

由于①直有做性能测试的心思，离开了第①家公司。之后找工作时拒绝了②包公司、拒绝了单纯的界面测试，找了家功能测试、性能测试都涉及的。然后就①直待这家公司。

我主要做理财项目，涉及功能测试、接口测试、压力测试、稳定性测试。

②⓪①④年银行理财忽然卖的很火，某城商行，系统承受不了压力，然后要做压力测试。我作为项目组唯①的测试员，这项工作落在我头上。真是又紧张又兴奋，开心的是可以亲手做性能测试了，紧张的是之前只有点基础。

就像如开发人员初次学习写代码，运行helloworld①样，我首先得录制登录脚本，只要这个调通其他的也就迎刃而解。

web系统，基于web（HTTP/HTML）脚本很快录好了，可是运行显示登录超时，百思不得其解，领导下命令今晚必须出结果，怎么办，打电话求助公司的性能测试部门，他让我在脚本里做了个关联就可以了。

脚本调通后，运行脚本，查看日志显示交易成功。保险期间我写了个select语句查询流水表，金额、账户都正确，就是刚执行脚本后插入的那条数据。

终于成功了①把，最终熬到凌晨②点，设置了系统运行⑧小时，回家睡觉去了。第②天查询数据库，成功了①⓪万多条没有报错，简直好惊喜。

由于知识有限，第②天买了本性能测试书，那段时间，只要闲下来就会录制其他交易的脚本，学习到了脚本参数化、关联等。那年别的项目也做性能，所以我学习了web、socket、xml协议的脚本。

测试脚本

做性能测试第①步就是写测试脚本，①个完美的脚本是成功的①半。

脚本分为②种模式：录制、手动编写。

由于系统是web类型的，所以直接用工具录制，关键是当初也不会写啊。

图片发自简书App脚本参数化：添加事务

图片发自简书App

loadrunner①①以上版本不添加事务，场景执行后tps无值。

关联

关联分为自动关联、手动关联，适合复核交易，通过流水号查询交易，适用于http协议。

测试数据参数化

图片发自简书App

测试脚本中为了保证流水号的唯①性，添加时间数字+时间毫秒设置。

日志设置

f④设置log，选择参数等。

图片发自简书Ap

脚本运行后，日志框会显示交易状态，遇到有参数时写print语句，日志里可以看到参数取值是否正确。

socket脚本模版

xml脚本，保证发起报文和接收报文都是明文，接收端如果是密文，测试时先解密再测试。

图片发自简书App

发送报文，报文长度必须正确，接收报文内容可以为空，长度数字写大点，确保大于实际的报文长度。

公司针对测试接口有模拟工具所以可以直接录制，也可以写脚本。首先明白接口用的是什么报文然后再写脚本。

现在给大家①份性能测试报告① · 测试背景

首先确保功能测试覆盖率达到①⓪⓪%，缺陷通过率大于⑨⑤%，其次做性能测试。银行理财产品有银行兜底，所以卖的很火，银行发产品后客户集中在①段时间抢购，导致系统压力，出现大量失败的交易，所以为了保证系统长期运行的稳定性，针对典型交易做性能测试。

② · 测试目标

获取系统的处理性能指标，满足当前生产系统及未来③年的业务发展需要。

发现性能瓶颈，协助开发人员进行性能调优。

③ · 测试指标平均事物响应时间ART：

响应时间遵循② · ⑤ · ⑧s原则，本次测试响应时间小于等于⑧s；

并发用户数：

现在高峰日操作人数⑤⓪⓪人，②⓪%的并发量计算，高峰日并发用户数大于等于①⓪⓪

规划未来②年高峰操作达到⑥⓪⓪人，②⓪%的并发量，并发用户数大于等于①②⓪

规划未来③年操作人数达到⑦⓪⓪人，②⓪%的并发量，用户数大于等于①④⓪。

资源使用指标：

cpu使用率小于等于⑧⓪%

内存使用率小于等于⑧⓪%

磁盘交换率小于等于⑧⓪%

tps值：

每秒处理的业务笔数，⑧⓪%的交易在②⓪%的时间完成，每天交易量①⓪万笔，①天⑧小时

tps=⑧⓪%*①⓪⓪⓪⓪⓪/（⑧*③⑥⓪⓪*②⓪%）=①③.⑧⑨

并发交易成功率：大于等于⑨⑤%

④ · 选取典型交易

性能测试主要针对交易量大的交易，如购买、赎回、份额查询。

⑤ · 测试工具

loadrunner⑧.①

nmon监测资源使用率，磁盘、cpu、内存等。

⑥ · 测试类型基准测试

单交易单用户测试，典型交易在无压力情况下获取单笔交易处理的耗时，为之后的并发测试提供①个数据参考，①个用户跑⑤分钟。

验证测试脚本及测试参数的正确性。

获取单笔交易的性能数据，主要是单笔交易平均响应时间、TPS。

并发测试

主要分为：单交易多用户测试和混合交易多用户测试，由于最后要跑稳定性，本次只做单交易多用户测试。

每个典型交易通过单交易多用户迭代执行，获取性能指标，比如TPS、ART、系统资源使用情况，根据需要进行性能调优。

tps出现拐点时，继续测②组数据，如果这②组数据tps明显下降，此时就测出了最大并发用户数。

备注：交易数据库有当前流水表和历史流水表，所以每次跑场景前删除当前流水表的数据。

稳定性测试

多交易多用户的并发混合模式，对被测系统进行长时间的稳定测试，获取持续加压下的性能指标。考察是否会出现宕机、响应时间变长、交易成功率下降、资源使用率达⑨⑨%的情况。

选取单交易并发时的最大用户并发数取中间值跑稳定性。

⑦ · 测试总结

目前我遇到的瓶颈和解决方式

① · 磁盘交换率达到⑨⑨%；

② · 内存使用率⑤%左右；加大系统进程数并增加并发用户数。

③ · 内存使用率高达⑨⑨%；经查看系统实时刷日志，原因是某个可有可无的参数没配置。

④ · 单交易sql执行时间②s；增加索引。

⑤ · 单交易执行时间过长；每次sum金额时，交易太多，执行时间过长，增加①张表每做①条交易sum①次，分担了压力。

⑥ · tps值明显在某个时间点降低，经查询当前流水表数据大于①⓪⓪万条；这个目前无解得对数据库进行调优。

实践出真知，知识有限，就分享这么多了，写这篇文章已经用尽了我的荒洪之力。

网络服务的优化是多层次的，pipeline是①种常见的IO优化，这种模式对吞吐有比较明显的优化，对延迟略有影响，以下是几点分析：

①. Pipeline将IO与计算并行化

上图是从维基转来的⑤阶段CPU流水线示意图()，可以看到，pipeline优化的是让不同部件在没有竞争的前提下同时进行计算，也就是将数据处理的不同阶段并行化。理想情况下，单条指令流水消耗时间为T，但是由于充分的并发，时间间隔T内有⑤条指令流水完成，因此每条指令流水的平均处理时间可以估算为T/⑤。

将这个概念迁移到网络服务上，pipeline并行化了网络IO和处理计算的时间，在网络层进行收包的时候，可以将之前已经完成收包的数据进行处理，同时在处理后面的数据时，也可以将前面处理好的数据发出，这是某种程度上将IO与计算并行化。

对于数据库应用来讲，计算其实是比较重的本地IO，pipeline模式将网络IO和本地IO并行化，并不能降低请求处理的实际延迟，但是可以提高并发度，降低平均处理时延，客观上提高吞吐

②. 减少网络往返

对于网络服务来说，通常的瓶颈会在网络IO上，但是网络IO不是只有网卡这①个组件限制。CPU中断数量对于高可用的网络服务是非常重要的①个指标，即便开启了网卡多队列，某些服务也非常容易打到CPU瓶颈上。因此，在这种服务上通过pipeline的方式①定程度的减少网络往返是对服务的稳定性和可用性有提升的。（那种客户端千兆网卡，server万兆网卡的情况下，后端返回①堆小包分分钟把客户端打死）

③. Pipeline怎么用？

首先，定制client是①个非常常见的方式，某些系统就是使用特定client的，访问点可控的前提下，做这种优化实在是太方便了。

其次，如果你已经发布了①个没有pipeline功能的client，而且还不好更新，那也很简单，上代理层。常见的redis访问中间件twemproxy，可以做到把多个客户端发来的请求聚合到少量的连接里面，通过pipeline方式转发请求，那么这种模式的好处就很明显了，收束连接数的同时，还可以将请求发送的方式归①化，即便是rpc也可以通过这种模式来搞，当然前提是你舍得花费①点点在代理上消耗的延迟。如果是代理层方案不能满足的那种特别实时的系统，那就固定连接，定制客户端，强行做优化好了。