“苍蝇式的战斗精神”和“XX性能测试”
辛苦了一段时间的性能测试终于完成了，附上偶的总结，抛砖引玉，欢迎各位看官指点------------------------------------------------------------------------------------------
“苍蝇式的战斗精神”和“XX性能测试”
前言：XX 性能测试终于告一段落了，心情也轻松了许多，感觉一块大石
头落地了。从一开始的协助调优，到后来的天天熬性能，前前后后断
断续续好几个月的时间，总算媳妇熬成婆了。这么长的时间，咱不能
白忙活了呀，总得把学到的想到的听到的以后可能会用到的记录下
来，与天下人共享，这才叫“境界”，O(∩_∩)O 哈哈~。借用曹雪芹
老先生的话“满纸荒唐言，一把辛酸泪”，当然我这份资料可是绝对
滴“不荒唐”，反倒是“粉实在粉实在”。这可是第一手资料哦，值得
珍藏ing，(*^__^*) 嘻嘻……
不过“辛酸”的的确确是真实的，现在俺只能告诉各位看官“辛
酸”的滋味真滴不好受。曾经有那么一段时间，俺是真的失望了，对
整个性能的失望，甚至是对自己的绝望，特打击自信滴。俺就像一只
没头苍蝇，天天面对着LoadRunner 不停的乱试。那时候真的都不知
道自己还能做什么了，还会做什么了，曾经一度没有了方向，整个人
都要垮掉了，提不起精神，觉得自己特没用，这也许就是所谓的“挫
败感”吧。不知各位看官是否有过类似的感受，如有过那咱们先握个
手吧，兄弟，知己呀。如果没有，我向您致敬，您运气真好O(∩_∩)O~
还好，俺这“苍蝇式的战斗精神”总算感动了上天，本以为看不
到头了，没得救了，突然那么一天，上帝眷顾俺咧，怜悯俺咧，这么
好的一个娃儿，不能就让她这么废的老，让性能好起来吧，性能就真
的好啦O(∩_∩)O ~。哈哈，开个玩笑，It is just a story！其实
主要是想告诉大家，遇到任何事情都不要回避气馁，坚持一点，再坚
持一点，也许就会“柳暗花明又一村”咯。当然，我们性能的优化经
历了千辛万苦，与“苍蝇式的探索”和开发兄弟们的辛苦努力是分不
开滴。为了纪念“苍蝇”兄弟给俺的启发，特地以此命名。
正文：
言归正转，下面就把俺这段时间所学所想所感记录下来，让“苍
蝇精神”永垂千古(*^__^*) ……
（一）总体统筹
1、作为性能测试，挖掘用户需求是非常重要的。
对客户来讲，他可能只需要知道这个页面我要几秒钟就能看到，
不能低于几秒钟，超过几秒我就接受不了了。或者说我需要这个系统
能支持多少用户，以后公司发展了，还需要支持更多的用户使用等等。
这个时候我们就要进行需求的分析和细化，把这个几秒钟、多少
个用户具体的整理归纳成性能测试所需要的东西。有效的性能测试需
求分析才是整个性能测试过程中的重中之重。
2、性能需求固然重要，更重要的还要做好性能测试计划，测试计
划可以说是整个项目的总指挥。
这个计划不应该是泛泛而谈，为应付而应付的东西。它不仅仅应
该是测试计划，更应该是计划测试。计划测试就是要让测试活起来，
有生气，有内容。
经过实践，个人觉得性能测试计划最好使用Excel 表格，这样便
于及时的记录结果、修订内容，而且看起来会非常的清晰。性能测试
计划是跟测试用例整理到一起的，详见附件《XX 性能测试计划
.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 类型太麻烦了，特别是大数据量的时候，如果
不是必须用的话，建议选择其他的类型。比如说XX 项目中，对Server
的参数化就是选择在server0、server1 还是server2 上执行，先前
都是采用file 类型，因为最多要有1500 个用户并发，所以要在file
中准备1500 条数据，这样就是一个比较大的工作量，尽管用excel
拖曳一下也蛮方便的。事实上，我只需要对0、1、2 做参数化就行了，
所以使用Random Number 类型就更方便啦，而且通过压力测试发现，
这种参数处理方式可以使各台服务器的负载更加均衡。强调这一点并
不是说file 类型不好，而是说在进行参数化的时候要结合实际，做
最有效的处理。其实对于参数化已经讲了不止一次了，每次都有新的
内容，关键是要用，在用的过程中才能做到“融会贯通，游刃有余”。
（4）脚本关联方式。脚本的关联是在脚本处理过程中经常用到的，
他可以自动关联，也可以手动关联。可以参考鄙人以前写的《在
LoadRunner 中用web_reg_save_param()做关联.doc》，除了该文档中
编写的方法外，鄙人还发现一个查找关联点的方法，那就是在脚本回
放的时候选择打开浏览器Tools->General Options->Display->Show
browser during replay，这样就会将新一轮的回放结果显示在浏览
器中，很明了的就可以查看了。如果对系统比较熟悉，关联就会变得
非常简单了。
3、场景设计。场景设计是非常重要的，这个更多的依赖于性能需求，
想要什么样的结果就做什么样的设计。在此次的测试过程中发现，场
景开始执行时如果同时有100 个用户并发操作，就会出现大量的连接
超时，服务器无法响应，或者连接被过早的关闭等错误，这个时候就
需要寻求最佳的并发用户数量，因为有多台客户端，所以在设计场景
时就需要仔细计算每个客户端的并发用户数量，并且需要保证每次接
收和发送消息的并发用户数量是相同的。具体可参见附件《XX 性能
测试报告.pdf》中的场景设计图。
4、Run-time 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、结果文件的命名和保存。场景执行后势必会产生结果文件，结果
文件的命名需要规范易于分辨。如上第(6)点，如果选择Always send
messages，那么光日志文件就可能占据很大的空间，把结果文件制作
成HTML Report 的形式就会节省很大的空间。在Analysis 中整理好
所需要的结果图表，选择Analysis -> Reports -> HTML Report 即
可。
7、使用多台客户端作为Load Generators。为保证每台机器都能正
常连接，各客户端的LoadRunner Agent Process 都是开启的，然后
在场景开始之前需要先Connect 每台客户端。
多台客户端机器作为Load Generators 时，除了主控机，也就是
执行场景的机器，LoadRunner 会在各个客户端机器的临时文件夹中
生成很大的文件，有的多大10 几个G，文件的大小跟场景执行时间
成正比。因此场景开始之前，一定要保证各客户机的磁盘空间充足。
（三）结果分析
个人认为结果分析是一个长期的过程，更应该是一个集体合作的
结晶。由于个人知识结构的限制，分析的难免不到位，附上测试报告，
仅供分享。
（四）相关知识
性能测试真是一个考验所有相关人员，尤其是测试人员各方面能
力的活计。做好性能测试需要具备各方面的知识，不一定全部精通，
但至少都要懂一点。专业的测试技能、软件编程能力、网络知识、操
作系统、数据库、中间件、行业知识、个人素养等等。
在网络方面，测试人员应该掌握基本的网络协议以及网络工作原
理。尤其要掌握一些网络环境的配置知识，这些都是测试工作中经常
用到的知识。
尾声：
终于接近尾声了，希望这篇《“苍蝇式的战斗精神”和“XX 性能测
试”》能给大家带来一点点的帮助。
[ 本帖最后由 qicyt1812 于 2009-3-16 20:18 编辑 ]
哇!
:lol 运气很好,一来就碰到好贴写的不错，深有同感！
性能测试真的是很费力啊!分析的不错
写的蛮好 我目前还处在没有方向的状态哟，不晓得从哪着手，请指点哈 不错，好文，顶，收藏一下 顶下 下了看看，希望是好文 性能测试不只是你描述的这么简单，监控和调优方面都没有涉及到。 学习下 下载研究下 太感激了。。。。。:handshake 不错的文章，简单易懂 不错的文章 :hug:不错，好东西。。。 学习了，谢谢！ 文章好长啊，不过非常好，谢谢！:handshake 不错，感谢LZ，分析部分再多一些就更好了 写的太好了，可惜不知道怎么回事，我这下不下来:( 真的是好帖，尤其分享精神值得赞赏
