“苍蝇式的战斗精神”和“XXX性能测试”
前言：
XXX性能测试终于告一段落了，心情也轻松了许多，感觉一块大石头落地了。从先前的协助调优，到之后的天天熬性能，前前后后断断续续几个月的时间，总算媳妇熬成婆了。这么长的时间，咱不能白忙活了呀，总得把学到的想到的听到的以后可能会用到的记录下来，与天下人共享，这才叫“境界”，O(∩_∩)O哈哈~。借用曹雪芹老先生的话“满纸荒唐言，一把辛酸泪”，当然我这份资料可是绝对滴“不荒唐”，反倒是“粉实在粉实在”。这可是第一手资料哦，值得珍藏ing，(*^__^*)嘻嘻……
不过“辛酸”的的确确是真实的，现在俺只能告诉各位看官“辛酸”的滋味真滴不好受。曾经有那么一段时间，俺是真的失望了，对整个性能的失望，甚至是对自己的绝望，特打击自信滴。俺就像一只没头苍蝇，天天面对着LoadRunner不停的乱试。那时候真的都不知道自己还能做什么了，还会做什么了，曾经一度没有了方向，整个人都要垮掉了，提不起精神，觉得自己特没用，这也许就是所谓的“挫败感”吧。不知各位看官是否有过类似的感受，如有过那咱们先握个手吧，兄弟，知己呀。如果没有，我向您致敬，您运气真好O(∩_∩)O~
还好，俺这“苍蝇式的战斗精神”总算感动了上天，本以为看不到头了，没得救了，突然那么一天，上帝眷顾俺咧，怜悯俺咧，这么好的一个娃儿，不能就让她这么废的老，让性能好起来吧，性能就真的好啦O(∩_∩)O ~。哈哈，开个玩笑，It is just a story！其实主要是想告诉大家，遇到任何事情都不要回避气馁，坚持一点，再坚持一点，也许就会“柳暗花明又一村”咯。当然，我们性能的优化经历了千辛万苦，与“苍蝇式的探索”和开发兄弟们的辛苦努力是分不开滴。为了纪念“苍蝇”兄弟给俺的启发，特地以此命名。
正文：
言归正转，下面就把俺这段时间所学所想所感记录下来，让“苍蝇精神”永垂千古(*^__^*)……
（一）总体统筹
1、作为性能测试，挖掘用户需求是非常重要的。
对客户来讲，他可能只需要知道这个页面我要几秒钟就能看到，不能低于几秒钟，超过几秒我就接受不了了。或者说我需要这个系统能支持多少用户，以后公司发展了，还需要支持更多的用户使用等等。
这个时候我们就要进行需求的分析和细化，把这个几秒钟、多少个用户具体的整理归纳成性能测试所需要的东西。有效的性能测试需求分析才是整个性能测试过程中的重中之重。
2、性能需求固然重要，更重要的还要做好性能测试计划，测试计划可以说是整个项目的总指挥。
这个计划不应该是泛泛而谈，为应付而应付的东西。它不仅仅应该是测试计划，更应该是计划测试。计划测试就是要让测试活起来，有生气，有内容。
经过XXX的测试，个人觉得性能测试计划最好使用Excel表格，这样便于及时的记录结果、修订内容，而且看起来会非常的清晰。XXX性能测试计划我是跟测试用例整理到一起的，详见附件《XXX性能测试计划.xls》，仅供参考。
3、一定要有测试用例，如果说测试计划是总指挥的话，测试用例就是总指挥手中的魔法棒，它指导着用户的操作过程。
因为性能测试比较繁琐，可能需要不停的反复，因此测试用例要做到及时更新，并且必须要及时的记录一些重点的测试结果。“好脑筋不如烂笔头”，记录下来就不容易忘记了，而且也能更好的做到有据可循。
众所周知，凡是有人的地方就会有矛盾，就会有责任的纷争和归属，如果有据可循，就避免了大量麻烦。其实这种事情我想每个做测试的兄弟姐妹们都应该遇到过，尤其是功能测试的时候。系统上线啦，咱们的辛劳没人太在意，一旦系统出了问题，得啦，好日子来啦，测试是怎么做的，这种问题怎么没有测到。嗳，这个时候如果有证据说明你确实做过了，而且是没有问题的，那自然就……当然，这也不能成为我们推卸责任的理由，出现问题了，还是需要积极的去面对，及时的去修正，不管是不是你的责任。
（二）细节把握
1、录制脚本前要先熟悉系统，这样才能做到“知己知彼，百战不殆”。其实不需要这么冠冕堂皇的理由，如果连系统都不熟悉，“丈二和尚摸不着头”的，谈何而来的脚本录制。
2、脚本要优化。脚本不是录制完就算完事了，就可以使用了，而是要根据需要进行优化，脚本分割、创建事务、参数化等等。我在实际过程中总结了下面几点：
（1）脚本删减。因为LoadRunner是模拟用户之间的通信过程的，不是所有的脚本都是必需的，事实上有些垃圾代码可能会影响性能测试结果的准确性。因此可以对脚本进行删减，只保留关键部分。删减的过程中需要注意的是如果你不确定，可以先把不需要的脚本注释掉，然后在VUGen中执行一遍，如果成功执行，这些被注释掉的脚本就可以删除了。
经过实践发现，脚本中的这些地方是可以删除的：web_add_cookie函数、一些非必须的web_url函数等等，还有每个函数EXTRARES之后LAST之前的部分。或者通过Tree View视图查看，没有Server Response返回值的，或者返回值中的内容对整个脚本无关紧要的，不需要用到它的返回值来做关联或者其他操作的，就都可以删掉。这是个很实用的技巧，屡试不爽。
有人可能会产生这样的困惑，哎呀，这么删来删去的，万一删错怎么办呢，还要重新录制脚本，岂不是很麻烦。不要着急，试试Regenerate Script…吧，VUGen-> Tools -> Regenerate Script…可以还原到初始脚本哦。
（2）脚本分割。LR的脚本分割具有更强的灵活性，如果有一段内容需要经常被使用到，那么就可以把他单独拎出来，放在一个函数，也就是在Script. View左边Action导航中Create New Action即可。这样就可以随用随调了。
脚本处理好以后在VUGen中回放时，默认是按照RunTime-Setting -> Run Logic -> Run下面的action顺序执行的，这个时候就会出现问题。比如Run下面有4个action：login()、start()、sendMsg()（调用start()）、logout()，其中只需要在sendMsg的时候调用一次start就可以了，按照目前的顺序回放的话，start()就被多执行了一次。要解决这个问题，只需要将start()从RunTime-Setting -> Run Logic -> Run中删除即可。回到Script. View左边Action导航可以看到start()的图标变成了半透明状，类似“只读”状态，事实上是可以编辑的。这又是一个行之有效的小窍门。
（3）脚本参数化。以前只拘泥于选择file文件类型对脚本进行参数化，后来发现file类型太麻烦了，特别是大数据量的时候，如果不是必须用的话，建议选择其他的类型。比如说XXX项目中，对Server的参数化就是选择在server0、server1还是server2上执行，先前都是采用file类型，因为最多要有1500个用户并发，所以要在file中准备1500条数据，这样就是一个比较大的工作量，尽管用excel拖曳一下也蛮方便的。事实上，我只需要对0、1、2做参数化就行了，所以使用Random Number类型就更方便啦，而且通过压力测试发现，这种参数处理方式可以使各台服务器的负载更加均衡。强调这一点并不是说file类型不好，而是说在进行参数化的时候要结合实际，做最有效的处理。其实对于参数化已经讲了不止一次了，每次都有新的内容，关键是要用，在用的过程中才能做到“融会贯通，游刃有余”。
（4）脚本关联方式。脚本的关联是在脚本处理过程中经常用到的，他可以自动关联，也可以手动关联。可以参考鄙人以前写的《在LoadRunner中用web_reg_save_param()做关联》，除了该文档中编写的方法外，鄙人还发现一个查找关联点的方法，那就是在脚本回放的时候选择打开浏览器Tools->General Options->Display->Show browser during replay，这样就会将新一轮的回放结果显示在浏览器中，很明了的就可以查看了。如果对系统比较熟悉，关联就会变得非常简单了。
3、场景设计。场景设计是非常重要的，这个更多的依赖于性能需求，想要什么样的结果就做什么样的设计。在此次的测试过程中发现，场景开始执行时如果同时有100个用户并发操作，就会出现大量的连接超时，服务器无法响应，或者连接被过早的关闭等错误，这个时候就需要寻求最佳的并发用户数量，因为有多台客户端，所以在设计场景时就需要仔细计算每个客户端的并发用户数量，并且需要保证每次接收和发送消息的并发用户数量是相同的。具体可参见附件《XXX性能测试报告.pdf》中的场景设计图。
4、Run-tXXXe Setting设置。因为要保证每个用户都必须成功登录，所以在登录脚本中做了条件判断，如果用户的ID和应用ID等不为空，就表示登录成功了，如果为空就重新登录，这个时候Miscellaneous的Continue on error选项就需要被勾选，这样就可以保证每个用户都能成功登录了。
Preferences -> Options里面，step timeout caused by resources is a warning设置为yes，这样资源下载失败了就会显示为一个警告，就不会在场景中出现大量的error。
Preferences -> Options里面，step download timeout (sec)可以设置的时间长一点，比如说300s，这样就保证了资源下载的时间，资源下载失败的现象也会减少。
同时需要在场景的Tools -> Options -> Timeout做一些超时时间限制的调整。
如果基本上知道结果输出可能的情况，就可以General->Log设置Send messages only when an errors occurs，也就是仅在错误时候输出日志。如果需要查看所有的日志输出，可以选择Always send messages。
5、场景定时运行。有时候可能并不需要场景设置好了马上就执行，而是希望在某个时间点开始。这个时候可以选择场景中的Edit Schedule -> Scenario Start Time，设置为At (HH:MM:SS) on (yyyy-mm-dd)执行。此时需要注意的是，一定要点Start Scenario
6、结果文件的命名和保存。场景执行后势必会产生结果文件，结果文件的命名需要规范易于分辨。如上第4点，如果选择Always send messages，那么光日志文件就可能占据很大的空间，把结果文件制作成HTML Report的形式就会节省很大的空间。在Analysis中整理好所需要的结果图表，选择Analysis -> Reports -> HTML Report即可。
7、使用多台客户端作为Load Generators。为保证每台机器都能正常连接，各客户端的LoadRunner Agent Process都是开启的，然后在场景开始之前需要先Connect每台客户端。
多台客户端机器作为Load Generators时，除了主控机，也就是执行场景的机器，LoadRunner会在各个客户端机器的临时文件夹中生成很大的文件，有的多大10几个G，文件的大小跟场景执行时间成正比。因此场景开始之前，一定要保证各客户机的磁盘空间充足。
（三）结果分析
个人认为结果分析是一个长期的过程，更应该是一个集体合作的结晶。由于个人知识结构的限制，分析的难免不到位，附上测试报告，仅供分享。
此次测试，主要关注了事务的响应时间、吞吐量和服务器的资源占用率等几个方面的指标。
1、事务正常运行的时候，如果响应时间曲线持续上升，点击率和吞吐量曲线都在下降，可能表明系统的处理能力在下降。引起该现象的原因可能有：（1）用户数连接未做限制，导致请求数不断上升，响应时间不断变长。（2）出现内存泄露。
2、CPU的使用率不断上升，内存的使用率也是不断上升，其他一切都很正常，表明系统中可能产生资源争用。
3、 所有的事务响应时间、cpu等指标都很正常，大量的业务失败，可能是由于数据库死锁造成的，也就是说，你在操作一张表或一条记录，别人就不能使用，即数据存在互斥性，当数据量大时，就会出现数据错乱的情况。
（四）相关知识
性能测试真是一个考验所有相关人员，尤其是测试人员各方面能力的活计。做好性能测试需要具备各方面的知识，不一定全部精通，但至少都要懂一点。专业的测试技能、软件编程能力、网络知识、操作系统、数据库、中间件、行业知识、个人素养等等。
在网络方面，测试人员应该掌握基本的网络协议以及网络工作原理。尤其要掌握一些网络环境的配置知识，这些都是测试工作中经常用到的知识。
操作系统和中间件方面，应该掌握基本的使用、安装及配置等技能。例如，很多应用系统都是基于Unix、Linux来运行的，这就要求测试人员掌握其基本的操作命令以及相关工具软件的使用。而WebLogic、Websphere等中间件的安装与配置方法也需要掌握一些。
数据库知识则是更应该掌握的基础知识。现在的应用系统几乎离不开数据库。因此，不但要掌握基本的安装、配置，还要掌握SQL。测试人员至少应该掌握Mysql、MS SqlServer、Oracle等常见数据库的使用。
作为一名优秀的测试工程师，首先要对测试工作有兴趣，因为测试工作在很多时候多少显得有些枯燥。因此，先要热爱测试工作，才能做好测试工作。在个人素养方面，除了具备必须的专业技能和行业知识外，测试人员还应该具有一些基本的品质：专心+细心+耐心+责任心+自信心 ，统称为“五心”。
如此看来，要真正的做好性能测试，还有很大一段距离，有差距才有动力，有动力才有进步的空间，加油！
尾声：
终于接近尾声了，希望这篇《“苍蝇式的战斗精神”和“XXX性能测试”》能给大家带来一点点的帮助。
