《软件性能测试过程详解与案例剖析》书评

用尽荒洪之力总结之Loadrunner性能测试

软件测试火的一塌糊涂的时候，大家心里估计在颤抖。不就是点点系统嘛，能有什么大出息，软件测试做几年以后大家水平都差不多，如何才能不被快速取代，去做性能测试呀。测试做久了就会知道，性能测试是测试人员的终极梦想，这是为什么呢？工资高呀。我有朋友做了3年功能测试，感觉太机械，然后报培训班学习性能测试，目前从事性能测试工作。万事开头难，我从想做性能测试到现在5个年头过去了，现在把做性能测试过程中的迷茫、坚持、到后来的被认可写下来，纪念下那年的加班岁月。我一直认为自己很幸运，在校期间就找了份实习工作，做金融方面的测试。银行系统涉及到钱，所以从公司到银行很重视测试。当然了现在互联网时代，性能测试就更重要了。大三暑期实习时做了软件测试，培训老师说软件测试分为功能测试和性能测试，最牛逼的是做性能测试，那简直是受万人敬仰。刚好学校开始选毕设课题，看到了loadrunner性能测试题目，带着想成为行业的大拿，受到膜拜的幻想，于是乎选择了这个课题，仿佛看到了未来做性能测试的样子。由于在学校老师没教过这个，所以得自学，就连loadrunner工具也得自己在网上下载，loadrunner是大型商业软件，小公司用的大都是开源工具，公司做银行系统，所以性能测试是重中之重，正好有此软件。第一次听培训老师讲性能，特别认真的带着本和笔坐第一排听。培训老师在公司待10多年了，讲的很好。“80%的交易是20%的时间完成的、tps、tps拐点、脚本、并发用户数、最大并发用户数、单交易场景、混合交易场景等”听的云里雾里。实习时在公司培训班待了一周，做了个小型银行系统，大概只有账户查询、开户、存款贷款等小模块。系统用于是乎我就在电脑里安装了这个系统做性能测试。公司有配置库，文档包括各种类型，恰好有性能测试文档。由于公司有2人做性能测试，常年在客户现场出差，所以一切都得自学，带我毕设的老师也是没做过这方面的工作。度娘里找答案，清一色全是loadrunner的工具使用，如何设置参数、如何录制脚本、脚本参数化等。到了这步就木有下文了，宝宝心里苦。我最想看到的是录制脚本后脚本运行成功（数据库里有条成功数据）、如何设置场景、如何获取有用的数据、以及如何测出瓶颈、以及如何解决瓶颈、最后出份漂亮的性能测试报告。心理想着等我哪天做完性能测试一定和大家分享有用的知识。现在回想起来，当初真是太可怜了，录制脚本后，回放录制的视频，界面一直显示登录超时，登陆脚本都无法登录系统，更别提之后的测试脚本了。大四毕设做的很不好，没人指导，自己在瞎琢磨，没有写过测试脚本，毕设答辩内容很空洞，勉强通过。由于一直有做性能测试的心思，离开了第一家公司。之后找工作时拒绝了二包公司、拒绝了单纯的界面测试，找了家功能测试、性能测试都涉及的。然后就一直待这家公司。我主要做理财项目，涉及功能测试、接口测试、压力测试、稳定性测试。2014年银行理财忽然卖的很火，某城商行，系统承受不了压力，然后要做压力测试。我作为项目组唯一的测试员，这项工作落在我头上。真是又紧张又兴奋，开心的是可以亲手做性能测试了，紧张的是之前只有点基础。就像如开发人员初次学习写代码，运行helloworld一样，我首先得录制登录脚本，只要这个调通其他的也就迎刃而解。web系统，基于web（HTTP/HTML）脚本很快录好了，可是运行显示登录超时，百思不得其解，领导下命令今晚必须出结果，怎么办，打电话求助公司的性能测试部门，他让我在脚本里做了个关联就可以了。脚本调通后，运行脚本，查看日志显示交易成功。保险期间我写了个select语句查询流水表，金额、账户都正确，就是刚执行脚本后插入的那条数据。终于成功了一把，最终熬到凌晨2点，设置了系统运行8小时，回家睡觉去了。第二天查询数据库，成功了10万多条没有报错，简直好惊喜。由于知识有限，第二天买了本性能测试书，那段时间，只要闲下来就会录制其他交易的脚本，学习到了脚本参数化、关联等。那年别的项目也做性能，所以我学习了web、socket、xml协议的脚本。测试脚本做性能测试第一步就是写测试脚本，一个完美的脚本是成功的一半。脚本分为2种模式：录制、手动编写。由于系统是web类型的，所以直接用工具录制，关键是当初也不会写啊。图片发自简书App脚本参数化：添加事务图片发自简书Apploadrunner11以上版本不添加事务，场景执行后tps无值。关联关联分为自动关联、手动关联，适合复核交易，通过流水号查询交易，适用于http协议。测试数据参数化图片发自简书App测试脚本中为了保证流水号的唯一性，添加时间数字+时间毫秒设置。日志设置f4设置log，选择参数等。图片发自简书Ap脚本运行后，日志框会显示交易状态，遇到有参数时写print语句，日志里可以看到参数取值是否正确。socket脚本模版xml脚本，保证发起报文和接收报文都是明文，接收端如果是密文，测试时先解密再测试。图片发自简书App发送报文，报文长度必须正确，接收报文内容可以为空，长度数字写大点，确保大于实际的报文长度。公司针对测试接口有模拟工具所以可以直接录制，也可以写脚本。首先明白接口用的是什么报文然后再写脚本。现在给大家一份性能测试报告1、测试背景首先确保功能测试覆盖率达到100%，缺陷通过率大于95%，其次做性能测试。银行理财产品有银行兜底，所以卖的很火，银行发产品后客户集中在一段时间抢购，导致系统压力，出现大量失败的交易，所以为了保证系统长期运行的稳定性，针对典型交易做性能测试。2、测试目标获取系统的处理性能指标，满足当前生产系统及未来3年的业务发展需要。发现性能瓶颈，协助开发人员进行性能调优。3、测试指标平均事物响应时间ART：响应时间遵循2、5、8s原则，本次测试响应时间小于等于8s；并发用户数：现在高峰日操作人数500人，20%的并发量计算，高峰日并发用户数大于等于100规划未来2年高峰操作达到600人，20%的并发量，并发用户数大于等于120规划未来三年操作人数达到700人，20%的并发量，用户数大于等于140。资源使用指标：cpu使用率小于等于80%内存使用率小于等于80%磁盘交换率小于等于80%tps值：每秒处理的业务笔数，80%的交易在20%的时间完成，每天交易量10万笔，一天8小时tps=80%*100000/（8*3600*20%）=13.89并发交易成功率：大于等于95%4、选取典型交易性能测试主要针对交易量大的交易，如购买、赎回、份额查询。5、测试工具loadrunner8.1nmon监测资源使用率，磁盘、cpu、内存等。6、测试类型基准测试单交易单用户测试，典型交易在无压力情况下获取单笔交易处理的耗时，为之后的并发测试提供一个数据参考，一个用户跑5分钟。验证测试脚本及测试参数的正确性。获取单笔交易的性能数据，主要是单笔交易平均响应时间、TPS。并发测试主要分为：单交易多用户测试和混合交易多用户测试，由于最后要跑稳定性，本次只做单交易多用户测试。每个典型交易通过单交易多用户迭代执行，获取性能指标，比如TPS、ART、系统资源使用情况，根据需要进行性能调优。tps出现拐点时，继续测2组数据，如果这2组数据tps明显下降，此时就测出了最大并发用户数。备注：交易数据库有当前流水表和历史流水表，所以每次跑场景前删除当前流水表的数据。稳定性测试多交易多用户的并发混合模式，对被测系统进行长时间的稳定测试，获取持续加压下的性能指标。考察是否会出现宕机、响应时间变长、交易成功率下降、资源使用率达99%的情况。选取单交易并发时的最大用户并发数取中间值跑稳定性。7、测试总结目前我遇到的瓶颈和解决方式1、磁盘交换率达到99%；2、内存使用率5%左右；加大系统进程数并增加并发用户数。3、内存使用率高达99%；经查看系统实时刷日志，原因是某个可有可无的参数没配置。4、单交易sql执行时间2s；增加索引。5、单交易执行时间过长；每次sum金额时，交易太多，执行时间过长，增加一张表每做一条交易sum一次，分担了压力。6、tps值明显在某个时间点降低，经查询当前流水表数据大于100万条；这个目前无解得对数据库进行调优。实践出真知，知识有限，就分享这么多了，写这篇文章已经用尽了我的荒洪之力。我做测试买的就是这本书，当初百度搜索的答案，很细适合初中级测试人员。

转自51testing 上的书评，写的比较中肯，感谢作者

这本书我看了有一段时间了，最近一直比较忙，就什么也没写。今天想来想去还是写写自己的感触：一直不太喜欢，有些没有任何的分析就夸书写的好，或者骂书写的不好之类的人。这本书我看了两遍的。为什么书我看了两遍才会想写点东西呢。我衔还苁裁词椋吹谝槐樽苁窃谑茏抛髡叩挠跋欤扛鲎髡咝词椋加凶约旱南敕ǎ谝淮谓哟ィ琳叩姆治霾⒉欢嗟摹＞拖褚盏男磐饺衔帐歉鍪ト耍盏募蚁缛酥蝗衔歉銎匠Ｈ艘谎?br /> 不说太多了。还是来聊聊书：整体上来讲，书的结构层次很清楚，并且有实践，有理论，给读者比较多的增长知识的机会。并且作者为读者想的也比较周到，在最后把几个难点问题写了些实例。做了说明。并附上LR的手册（虽说这一点我不是很赞同，下面我会说原因）。下面细说：1，前两章节，是理论的说明。在理论上，我一直觉得在性能这一块的名词解释很模糊。本书对这些名词做了一些分析，并且很详细，这一点很好。可是问题来了，分析完了，应该有一个定论。而这本书里，对名词的定论也同样是模糊的。我看了一下后，原来模糊的名词还是同样的模糊。即，作者在某些词句上的考究还不是很细致。性能测试的方法，这一段的分类是不错的，解释也是有一定道理。可是我觉得不足的是，侧重点不是很明确，其实作者要表达的意思是有侧重的，而文字中没有表达出来。这是我对前两章节的理解。2，分析方法。这里的分析方法，基本上网络上都有流传，不过作者加入了自己在实际工作中的经验，有些部分值得学习。我觉得这部分写的不错。因为有些我没有实际的遇到过，不能妄加评论。不过这一段如果加进更多的作者的经验，而少一些网络上已经流传的分析方法，我想会更好。总看到有些人在论坛上或者在群里问这个分析部分是怎么做的，并且有些人发一个图就让别人帮他分析。这是完全做不到的。分析是一个整体的过程。不是一个两个图就能看出来的。所以，分析是一个整体的过程，并且需要的相关知识也比较多，所以不能独立的来看问题。希望各网友分析的时候，先了解一下周边的知识。而不要对着LR的结果图大叫：看不懂，看不懂。3，我对实践篇的看法。这一部分，作者的实践经验体现的比较多。比如，对工具的引入的分析，对团队人员的结构分析，值得借鉴。作者对整体流程的说明还是比较详细的，比如，前期准备、工具引入、测试计划、场景描述等。可是看了之后，我觉得有一点不太清楚的是，对需求的分析。这一块并不是很多，并且在对结果分析的时候，没有对需求进行对应，而这一点应该是最重要的。作者在这一点上，多是一笔带过。而在对结果的分析上，讲的比较笼统。如果细分下去，并说明对某种应用应该用什么样的分析流程，这样我认为会比较好。4，附录。前面说了，对这一附录的不太赞同。因为从书名来看，应该是更关注工具之上的性能测试。而对本书的整体来看，还是认为作者对工具的关怀太多了。很多地方都太靠近工具。而书中也说了，性能测试并不是说会工具就会性能测试了的。那书里的某些部分，应该高于工具来分析说明。多关注一些对架构的分析，我认为会更好。之上所言，均是我自己的看法，各位读者的看法，还是要读者自己来定。希望我的话没有蒙蔽各位读者的明亮的眼睛。转自： http://www.51testing.com/?uid-17369-action-viewspace-itemid-3410