经验之谈（苍蝇式的战斗精神”和“XX性能测试”）

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

前言：XX 性能测试终于告一段落了，心情也轻松了许多，感觉一块大石头落地了。从一开始的协助调优，到后来的天天熬性能，前前后后断断续续好几个月的时间，总算媳妇熬成婆了。

（一）总体统筹 1、作为性能测试，挖掘用户需求是非常重要的。
     对客户来讲，他可能只需要知道这个页面我要几秒钟就能看到，不能低于几秒钟，超过几秒我就接受不了了。或者说我需要这个系统能支持多少用户，以后公司发展了，还需要支持更多的用户使用等等。这个时候我们就要进行需求的分析和细化，把这个几秒钟、多少个用户具体的整理归纳成性能测试所需要的东西。有效的性能测试需求分析才是整个性能测试过程中的重中之重。

2、性能需求固然重要，更重要的还要做好性能测试计划，测试计划可以说是整个项目的总指挥。
     这个计划不应该是泛泛而谈，为应付而应付的东西。它不仅仅应该是测试计划，更应该是计划测试。计划测试就是要让测试活起来，有生气，有内容。经过实践，个人觉得性能测试计划最好使用Excel 表格，这样便于及时的记录结果、修订内容，而且看起来会非常的清晰。。

3、一定要有测试用例，如果说测试计划是总指挥的话，测试用例就是总指挥手中的魔法棒，它指导着用户的操作过程。
    因为性能测试比较繁琐，可能需要不停的反复，因此测试用例要做到及时更新，并且必须要及时的记录一些重点的测试结果。“好脑筋不如烂笔头”，记录下来就不容易忘记了，而且也能更好的做到有据可循。众所周知，凡是有人的地方就会有矛盾，就会有责任的纷争和归属，如果有据可循，就避免了大量麻烦。其实这种事情我想每个做测试的兄弟姐妹们都应该遇到过，尤其是功能测试的时候。系统上线啦，咱们的辛劳没人太在意，一旦系统出了问题，得啦，好日子来啦，测试是怎么做的，这种问题怎么没有测到。嗳，这个时候如果有证据说明你确实做过了，而且是没有问题的，那自然就……当然，这也不能成为我们推卸责任的理由，出现问题了，还是需要积极的去面对，及时的去修正，不管是不是你的责任。

 

（二）细节把握

1、录制脚本前要先熟悉系统，这样才能做到“知己知彼，百战不殆”。

       其实不需要这么冠冕堂皇的理由，如果连系统都不熟悉，“丈二和尚摸不着头”的，谈何而来的脚本录制。

2、脚本要优化。

     脚本不是录制完就算完事了，就可以使用了，而是要根据需要进行优化，脚本分割、创建事务、参数化等等。我在实际过程中总结了下面几点：

（1）脚本删减。

   因为LoadRunner 是模拟用户之间的通信过程的，不是所有的脚本都是必需的，事实上有些垃圾代码可能会影响性能测试结果的准确性。因此可以对脚本进行删减，只保留关键部分。删减的过程中需要注意的是如果你不确定，可以先把不需要的脚本注释掉，然后在VUGen 中执行一遍，如果成功执行，这些被注释掉的脚本就可
以删除了。经过实践发现，脚本中的这些地方是可以删除的：web_add_cookie函数、一些非必须的web_url 函数等等，还有每个函数EXTRARES 之后LAST 之前的部分。或者通过Tree View 视图查看，没有ServerResponse 返回值的，或者返回值中的内容对整个脚本无关紧要的，不需要用到它的返回值来做关联或者其他操作的，就都可以删掉。这是个很实用的技巧，屡试不爽。有人可能会产生这样的困惑，哎呀，这么删来删去的，万一删错怎么办呢，还要重新录制脚本，岂不是很麻烦。不要着急，试试
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->Showbrowser during replay，这样就会将新一轮的回放结果显示在浏览器中，很明了的就可以查看了。如果对系统比较熟悉，关联就会变得非常简单了。

3、场景设计。

   场景设计是非常重要的，这个更多的依赖于性能需求，想要什么样的结果就做什么样的设计。在此次的测试过程中发现，场景开始执行时如果同时有100 个用户并发操作，就会出现大量的连接超时，服务器无法响应，或者连接被过早的关闭等错误，这个时候就需要寻求最佳的并发用户数量，因为有多台客户端，所以在设计场景时就需要仔细计算每个客户端的并发用户数量，并且需要保证每次接收和发送消息的并发用户数量是相同的

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、场景定时运行。

   有时候可能并不需要场景设置好了马上就执行，而是希望在某个时间点开始。这个时候可以选择场景中的EditSchedule -> 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，文件的大小跟场景执行时间成正比。因此场景开始之前，一定要保证各客户机的磁盘空间充足。

（三）结果分析
  个人认为结果分析是一个长期的过程，更应该是一个集体合作的结晶。由于个人知识结构的限制，分析的难免不到位。

四）相关知识
  性能测试真是一个考验所有相关人员，尤其是测试人员各方面能力的活计。做好性能测试需要具备各方面的知识，不一定全部精通，但至少都要懂一点。专业的测试技能、软件编程能力、网络知识、操作系统、数据库、中间件、行业知识、个人素养等等。在网络方面，测试人员应该掌握基本的网络协议以及网络工作原理。尤其要掌握一些网络环境的配置知识，这些都是测试工作中经常用到的知识。