这几天，我有幸接受并完成了人生中的第一次压测。从0到现在用了2.5天，心情比较复杂。这几天的收获。这篇文章我想在以下几点展开：接受压测任务时的状态进行压测的过程***对这次经历的小总结下一阶段想做的一件小事乱七八糟上周四下午刚接到任务的时候，项目组要求重测一个功能，并跟领导说了。我认为手动测试功能的瓶颈就足够了。结果快要下班的时候，领导让写个脚本把这个功能打压掉。其实从一开始踏入测试的大门，我就下定决心要学做压力测试，并且在写性能合同的时候就向领导表达了自己的意愿。可现在，突然接到领导这样的指示，只有两个字——乱七八糟。一直只知道loadrunner是做性能测试的，到现在还不知道怎么做。而且，它似乎有点复杂。什么样的场景设计，一看就让人摸不着头脑。后来有个同学推荐可以用jmeter，说好学好用，于是下载了一个jmeter。安装后发现也是第一个录制脚本的。你可以下载一个badboy来录制脚本。关联jmeter，可以把脚本导出到jmeter，也可以直接用jmeter记录。于是下载了jmeter，按照网上的教程安装，研究了怎么设置，怎么用，自己试着记录了一下，还是不是很清楚。后来同事说公司统一用LoadRunner，我立马又装了LR。幸运的是，安装成功了，而且是在我的本地机器上。于是LR***站开始了。在做压测的过程中，从书本和网上学习了LR脚本录制/脚本回放/控制器使用/如何设计场景，如何设计场景更适合我要做的压测现在。首先是在网上和书上看到了负载处理的案例。才明白领导说的是模拟不断的往系统里导入数据。其实更好或者更正确的描述应该是多个用户并发发送给系统进行限制数据导入操作。.所以我跟开发同事确认过，目前除了限制5个用户外，其他参数比如响应时间，用户没有提出任何要求，我们只是对用户做了一些限制。负载目的明确：5个用户同时向系统导入15*100*6*400这样的数据，看程序是否稳定运行/服务器是否稳定运行（资源占用）。1、在录制脚本的过程中，发现每个用户登录的时候都需要输入验证码，但是每次验证码都变了，所以借鉴了之前自动化测试的经验，让项目组的同事屏蔽或更改验证码。查看***的验证码。开始自己录制脚本、创建事务、插入集合点、检查点。第一次会有陌生和不确定，但大胆双面操作会更有底气。2.参数自动化在参数化书里已经提到了。这一步还是比较模糊的。刚开始接触压测的时候，我以为参数化就是定义参数和赋值。后来书上的内容太多了，就找同事了解参数化，完成参数化。3、脚本replay参数化完成后，再次replay，结果NOERRORDETECT。接下来就是愉快的进行了，这也是最乱的——场景设计。4.场景设计设计几个用户，如何初始化用户（比如几秒初始化一个），什么时候作为集合点，是让他们循环运行一段时间还是之后结束任务循环运行。其实确定了这些之后，场景设计就差不多完成了。5、使用controller执行脚本在这个过程中，经常会出现一些问题，比如找不到文件，或者文件是空文件，或者超时。关于找不到文件的问题，经过百度发现，录制的时候文件在哪里并不重要，重要的是在replay脚本或者controller中运行脚本的时候，文件一定要在脚本的目录。对于文件为空文件的问题，往往是因为录音问题。录制过程中必须保证文件正常导入和执行。对于函数中正常的报错，如果在脚本录制过程中出现，就会出现问题。只能重新录制。至于超时问题，就是http请求/响应的超时，服务器响应时间设置的大一些。第一次改成1000的时候发现可以，后来改成1500还是不行，只好改成10000😓。终于没事了6.Analyze应该是性能测试中最难的部分，如何评估和优化系统性能——我只能说我只是个菜鸟💔💔。只能请了一些有经验的公司同事帮我做性能测试。对于图表不合理的情况，我重新创建数据并再次运行脚本，最终与其他场景的结果达成了共识。终于可以报了，却发现忘记监控服务器资源使用情况了。.真是个悲剧！！！于是，网上查了一下如何用LR监控远程服务器。我发现有一个netuser命令，成功提示我53系统错误。按照网上搜索的方法找到服务器的lanmanserver打开，😄😄，打开服务器的管理服务，根本找不到这个东西，嗯，为了赶紧汇报，我先用肉眼观察cou的用法。.师傅告诉我，我现在最适合肉眼观察，使用LR远程监控对菜鸟来说还是有点要求的。当然，这也会成为我下一步必须克服的困难。小结关于这段经历，我有两点要说：***，遇到新的任务或问题，有压力，同时也是成长的时候，经常处在舒适区，很难有进步；第二，做事一定要有条理，有条不紊，有条不紊，细心周到。比如在测试的时候，不小心把文件名里的数字写错了。下一阶段我想做什么能够使用LR对服务器进行远程监控，b．熟练使用LR的analyze功能给项目带来性能优化
