【心得】阿达聊性能测试

上两周一直在准备考试，就没怎么写新的东西，本周开始，又会继续更新。

说到性能测试，我真的只能算个新手，写的不对的地方，希望大家狠狠的留言指教。

      我把性能测试单独列出来说了，其实，性能测试也是自动化测试的一种。

【第一次尝试】

      记得第一次做性能测试是给公司的一个安防系统做的，只做了并发登录。当时什么也不懂，只知道有个Loadrunner软件是做性能测试用的，就装了Loadrunner做性能。由于是CS结构，使用了Socket协议进行录制，录制完了，花了好长时间才学会给Socket脚本进行参数化。搜索都搜的头都炸了，才把一堆的稀奇古怪的错误给干掉了，设完场景，跑完，看看没报什么错，便交差了。连图表都看不懂，分析也没做，报告也没写，总之迷迷糊糊的做完了这第一次的性能测试，话说，也不知道是不是真的给服务器打上了压力，只是觉得，貌似结果有点太理想了。

当时对软件的性能要求也不是很高，所以也没怎么追究结果的真实性。只是很在脚本编辑的过程中，无意间发现了一个安全BUG。使用一个Guest账户登录，在脚本中居然录下所有用户名和密码的比对过程，密码居然还是明文的。只要随意登录一个账号，便能知道admin账户的密码，这个太意外了，于是便提了这样的BUG，算是意外的收获吧。一个用于公安、监狱的软件有这样的安全BUG，应该算是很严重了。结果，被老大直接挂了，据我所知，知道我离开公司，这个BUG都没有修改。

【出差做测试】

第二次做性能测试是比较正式且刺激的经历。这次是客户方提出了性能测试的需求，于是，便对性能测试重视了起来。

看了需求，2000并发量，有点不可思议，而且客户要求出差到客户现场做测试。不管了，现在大本营里调通脚本再说。

这次的系统是BS结构系统，选择了web协议。和往常一样，开始录制脚本，结果发现只录制下了登录和注销，中间的用户写文件的动作，一点脚本都没有录制下来。经过和开发人员讨论下来的结果，原来中间写文件的动作由于要实时上传和其他用户也能实时查看的功能，用了Socket连接等。于是改用Socket协议进行脚本的录制，发现录下来了一堆一堆的乱码。经过漫长的研究与痛苦的讨论，最后决定，由开发提供接口，登录和注销使用LR录制，中间的写文件操作则调用开发给的接口完成。

由于系统是使用Java开发，就使用了能写Java语句的Java Vuser协议。调脚本真是一个痛苦的过程，因为我本身并不会Java开发，所以更别说调用接口操作什么的。于是便安排了一个Java开发搭档，一起开发脚本。在开发的帮助下，安装完对应的JDK并配置好环境变量，新建了Java Vuser脚本后，直接运行，发现没有报错。简单写了个Hello World没有问题，便开始正式调试脚本。

然后找方法，由于Java Vuser没有录制，所以又找方法将录制下来的登录和注销动作C语言脚本，翻译成了Java语言。（后话：日志里有写方法，云层说可以用混合协议，这个我到没试过）

开发写了一堆不知道什么东西的代码和Jar包，把jar包放在脚本根目录下，好不容易搞定后，用指定的参数进行调用，发现可以进行一次文档编写。只是问题又来了--参数。参数中，有几个重要的参数是需要通过实时获取的，如JSession，由于当时对Loadrunner的使用方法并不熟练，进过反复查找资料，终于知道了有“关联”这个概念，也查到了“web_reg_save_param ”函数，可能领悟的有点慢，搞了半天终于知道了这个函数是可以获取页面上右键“源代码”中的数据。 通过"LB"和"RB"定位到需要截取的数据的左边是什么，右边是什么。经过了多次尝试，终于成功获取了JSession，并运用到参数中。运行脚本没有问题。这时候时间也逼近了，就没有再深入。

      到了出差的日子，第一次出差，且只有我一个测试人员单枪匹马去客户环境，还有做我自己都不熟练的Loadrunner压力测试，那种紧张感，真是太难以形容了。就怕出各种各样的意外。果然天不随人愿啊，先是在虚拟出的测试机上装Loadrunner软件和Vgen调JDK和环境变量遇到了各种各样的奇怪问题；然后是Controller怎么都启动不了；还发现自己带的电脑根本不让接入他们内部网络（特殊环境嘛），脚本只能靠手输了；而且由于我公司其他项目组的某个项目超时完成了好几个月，所以客户方对我们的态度也不是很友善；不但如此，测试环境也很恶劣，在地下2层车库旁边的一个房间里，没有垃圾桶，没有水喝，电源不够用，出入大门都需要层层验证等等等等。一边是领导要求，想办法增加测试时间，因为系统的代码还需要一点点时间完成优化，需要给后方开发一点时间；一边是客户方要求，尽快完成压力测试，每天都会来查岗，检查进度。第一次出差的我似乎遇到了前所未有的压力。就在好不容易在安装了N次Loadrunner后，Controller能正常使用后，又发现了一个大问题：我使用了11台测试机，1台主控，10台负载机，结果发现只有主控机上的脚本可以通过，而所有负载生成器上的脚本都报Error: Compilation process failed。这是在“大本营“中测试时完全没有遇到过的。经过几次测试发现，是负载生成器调用Jar包时出现的问题，只要调用Jar包，就会报错，将调用Jar包的语句注释掉，便运行正常。百度谷歌了一天，试过了网上能搜索到的方法，发帖询问（当时不知道在大大小小各色论坛上发了多少贴，反正感觉有用的回复真的不多，这使得后来我决定，论坛上有人提问时，只要我能回答，都会尽力帮助），结果还是无法正常使用，一次次地报错，那感觉，真是太绝望了。

      想着暂且跳过Controller，单使用主控去跑脚本吧，至少要先调通一次啊。结果要命的Analysis居然也开始作对了，出现在“任务管理器”中有Analysis的进程，但是没有Analysis的界面的情况。网上提问、百度谷歌无果后，再次尝试不停重装，重设配置。老天有眼，终于Virtual User Generator、Controller、Analysis都能正常使用了，出去喝一杯庆祝一下…哈哈~

      最后只能重新分配虚拟机资源，将测试机变为1台主控机而解决了这个问题（后面会提一下Error :  Compilation process failed怎么解决）。环境和脚本稳定后后，终于可以开始正常的压力测试了。结果发现，并发数量在一定数量后，就开始各种报错，各种timeout，查看服务器日志时，发现由于突然出现的大量并发，负载均衡未能正确合理的分配用户，导致将大量用户分配至某两台服务器上了，结果，这两台服务器就玩挂了。打电话回“大本营”，调脚本，优化，上版本，几个来回后，问题解决。之后还出现了种种问题，在不停的打电话，调优，上版本，测试后，算是圆满完成了任务。

      记忆非常深刻的三周，测试软件一次次的出现问题，脚本一次次的出错，客户一次次质问（你要是知道了这些用户是谁，你肯定会觉得被他们质问是件非常不好玩的事），一次次被要求拖长时间。也经历了有史以来唯一的一次连续工作40个小时未睡觉的经历。来自个方面的压力。报告如何写。如何和客户解释等等，回来后突然感觉成长了好多，发现需要学的东西也还有好多好多。

附：

      后来那个Error: Compilation process failed的问题回来后又研究了好一段时间，还是无果，后因没有环境了，就没有继续研究下去，最近在一个网友的帮助下，找出了一些解决办法：

1） 远程运行java vuser协议的脚本的时候，需要安装完整的loadrunner，只安装generator不行；

2） 需要在负载机上loadrunner主目录下面的classes中保存完整的目录结果；

如果import时，调用的class文件，有路径，则放到classes时，也需要对应放置

如：import org.test.JAVATest;

那么，放到D:\Program Files\HP\LoadRunner\classes下的，也要为org\test\JAVATest.class

即，完整路径为：D:\Program Files\HP\LoadRunner\classes\org\test\JAVATest.class

3） 负载机中loadrunner/classes中目录中保存脚本相关的所有jar包；

4） 在controller机器中的loadrunner/classes中也要保存所有的jar包，但是相关的.class文件可以不用保存；

5） 一些项目使用的额外的jar包，即在Run-time Settings中，需要在Java Environment Settings-Java VM中特别指定的jar包；

6） 直接放到LoadRunner安装路径下的classes目录下，是没有用的，会提示找不到类；这些jar包，需要在负载机上，相同的路径下放置；

在这位网友的尝试下，他的问题解决了，没有再报Compilation process failed的错。

【新的挑战】

      自从上次出差回来后，又回到了自动化测试中，然后跳槽，进入了新的公司，然后又开始做Sap的性能测试。

      经过了上一次的出差经历，回来后又好好学习了一下LoadRunner使用，并尝试通过测试结果的图表分析出系统的瓶颈。

      这次是要做SAP系统下的一个登录、查询表单等功能的压力负载测试。这次做起来显然要比上一次要熟悉多了。只是还是问题不断，SAP脚本录制录制完成后，脚本无法回放，尝试关联后，关联了七八个参数，回放还是不行，最后发现加上Header才能回放成功，而Header中又有N多的加密语句，经过了长达一个月的尝试无果。最后尝试使用了TruClient协议。算是一种类似QTP的界面识别的工作原理再进行并发测试。只需要录制GUI界面操作就能完成脚本的编辑，简单是简单，但是用起来感觉很不爽，而且资源占用非常大，要不是是在脚本没办法正常使用，真不会使用这样的鸡肋协议。

      附：

       Loadrunner 11.5版本的TruClient的基本用法在日志中也写了。

【结束语】

      性能测试这块，我一直觉的我还只是个新手，有很多地方，还在不停的摸索这，接下来会把云层的《性能测试进阶指南-LoadRunner11实战》好好研读一番。

      如果哪位性能测试上的高人愿意收我为徒，必将感激不尽。

欢迎志同道合之人一同学习。

QQ：370464196

Email：cydblack@163.com

陈永达