“苍蝇式的战斗精神”和“XX性能测试”

（一）总体统筹
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，文件的大小跟场景执行时间
成正比。因此场景开始之前，一定要保证各客户机的磁盘空间充足。
（三）结果分析
个人认为结果分析是一个长期的过程，更应该是一个集体合作的
结晶。由于个人知识结构的限制，分析的难免不到位，附上测试报告，
仅供分享。
（四）相关知识
性能测试真是一个考验所有相关人员，尤其是测试人员各方面能
力的活计。做好性能测试需要具备各方面的知识，不一定全部精通，
但至少都要懂一点。专业的测试技能、软件编程能力、网络知识、操
作系统、数据库、中间件、行业知识、个人素养等等。
在网络方面，测试人员应该掌握基本的网络协议以及网络工作原
理。尤其要掌握一些网络环境的配置知识，这些都是测试工作中经常
用到的知识。