1、查询服务器软硬件信息，主机软硬件信息
uname -a
dmidecode|grep "Name"
查看CPU型号 cat/proc/cpuinfo |grep "model name"|uniq
查看内存总数 cat/proc/meninfo |grep MemTotal
查看硬盘 fdisk -l |grep Disk
oracle 查看数据库版本（pl/sql中）：v$versionSQL>select * from v$version
查看操作系统版本 cat proc cpuinfo
2、因为是系统的升级，测试前需保证测试环境的数据量是旧系统的120%，并测得未进行性能测试前服务器的cpu及内存
3、录制脚本，该设置集合点的设置集合点，该设置事务的设置事务（这里需思考什么时候需设置集合点、什么时候需设置事务？？？）
插入集合点是为了衡量在加重负载的情况下服务器的性能情况。在测试计划中，可能会要求系统能够承受1000 人同时提交数据，在LoadRunner 中可以通过在提交数据操作前面加入集合点，这样当虚拟用户运行到提交数据的集合点时，LoadRunner 就会检查同时有多少用户运行到集合点，如果不到1000 人，LoadRunner 就会命令已经到集合点的用户在此等待，当在集合点等待的用户达到1000 人时，LoadRunner 命令1000 人同时去提交数据，从而达到测试计划中的需求。
说明：在脚本中设置了“集合点”后，当运行场景时可以对集合点进行设置，可以设置当百分之多少用户到达时，系统开始执行以下操作，详细的可以参考中文的用户手册
添加方法： 1、其中录制脚本script view中添加：lr_rendezvous(“XXX”);2、在录制脚本的tree view里添加：rendezvous-XXX;
并发用户：通俗意义上讲就是同时操作的用户，当然这个“同时”可以理解为同一时间段，还可以理解为同一时间点，当然如果说并发就是同一时间点上同时操作的用户，这样理解没有错误，但对于实际情况来讲，是没有严格意义上的并发执行的，就如同进程和线程关系一样，在某一个点严格上讲就只有一个人得到执行的权利。
集合点：用以同步虚拟用户，以便恰好在同一时刻执行任务。这个从概念上来讲，其实也是比较模糊，正因为模糊，使用才值得去深入探讨。对于LoadRunner来说，集合点只是一种策略，而这个策略也会有很多规则，因为实际情况中并非所有用户都会同时到达集合点，上面的那个结构图就能解释这个误解，因为从客户端发出到网络、中间件、应用层再到数据库，这其中的每一个环节都有延时，也就是说不可能所有的用户都能到达所谓的集合点，才开始同时执行操作。
从上面的两个概念的理解来讲，有人就会思考，并发用户和集合点到底有没有关系，这才是关键。当然这个就要看需求是什么了，所以说很多时候我们误用集合点和并发用户，其实根本原因在于对需求的理解，需求本身都没有搞清楚他想实现的场景，得到什么样的结果
4、场景设置：该系统的总人数是1000多人，但是平常用的数据量最多也就400个，所以最多算测400数据量
这里是100、200、400用户这样子测试
5、脚本运行得出结果：
这里分为两部分，一部分是单脚本运行，一部分是多脚本运行得出结果
无论是多和双都要有数据来源和数据分析
6、测试服务器cpu及内存，使用将场景运行的时间分段取时间点，但是这样子误差很大（找方法）
使用secureCRT连接服务器，将下面脚本写入文件
#!/bin/sh
NAME="/root/top_"$(date +%Y-%m-%d)
/usr/bin/top -b -d 1 -n 1 >> $NAME.txt
之后运行该文件：./myfile.txt
再进行分析，之后看到有可以用nmon进行分析（找个时间试试看）
本次性能测试反馈反思：
1、登录及部分功能，400用户的响应时间过长
原因：1、做性能测试的时候同时在功能测试，可能影响到了；
2、测的时候有过断网，网络不稳定；
3、跑的时间设置太短；
4、可能本来就不支持
2、各事务的响应时间变化趋势图没有加各个颜色代表的事务
（有考虑过，但是没有加，偷懒）
3、多脚本的数据，下面是单脚本的数据和分析
解决：1、增加多脚本的数据分析；2、增加单脚本的数据
（原先的思考是多脚本系统的测试，然后加单脚本模块的测试，但是没有考虑报告来源和分析的数据要一致，有来源就要有分析）