感想一

进入性能测试虚拟小组后，有幸跟着悟石元壮参与了一次项目的实践，感觉做下来收获蛮多的，把它总结下来。

一、创建文件夹

1.在执行性能测试的服务器上创建项目的名称，如 D:\项目名称，下面创建四个文件夹，分别为data，image，result 和 script，分别用户存放性能数据，图像，脚本和执行结果。

这样做是便于归类查找浏览，通常一台服务器上会存放好多个项目的执行。

二、编写脚本

这个提出来我主要是想说明下这次项目的脚本是在FF下跑的，是由于在性能测试执行阶段还不支持ie下打开界面。

FF下录制脚本主要设置如下：

new一个脚本的时候主要设置application type和 programe auguments 选择win32 applications和 firefox.exe所在的目录，如D:\Program Files\Mozilla Firefox\firefox.exe

三、关注的参数

1、寻找并发用户数：

（1）首先通过递增用户找到load接近4，cpu接近75%时的压力下的并发用户数

（2）用这个并发用户数去执行1h/2h的性能测试

（3）用这个并发用户数去进行12h的稳定性测试

2、根据预期pv确定事务数：

每秒平均值 =( (总PV量*80%)/(24*60*60*40%))/服务器数量=pv/s，每秒的峰值为每秒平均值×1.6得出。（不过关于这个计算模型还有待改进的地方，并不是每条产品线的产品都是这么适用的）

pv/s等价转化到tps，得出需要满足的事务数

3、响应时间，需要小于0.5s

4、cpu：阀值为75%

5、load：阀值为4

6、内存：查看是否能正确释放内存，存在内存泄漏等。

四、安装监控工具

1、由于服务器上没有成功安装rstated工具，lr中就取不到load和cpu这些数据，所以替补的方法是安装record-load.sh脚本，来采集load和cpu数据。

数据都是存放在cpu_load.list文件中。由于这个脚本没有提供平均值的计算功能，执行完成后需要复制出来在excel中计算平均值，已经提建议给性能测试组他们会改进脚本。

2、安装jconsole监控java内存，稳定性测试需要开这监控。需要在服务器中配置一项：

在/home/admin/dianping/bin jbossctl文件中

JAVA_OPTS=”$JAVA_OPTS -Djava.awt.headless=true”

JAVA_OPTS=”$JAVA_OPTS -Dsun.net.client.defaultConnectTimeout=10000″

JAVA_OPTS=”$JAVA_OPTS -Dsun.net.client.defaultReadTimeout=30000″

之后添加JAVA_OPTS=”$JAVA_OPTS -Djava.awt.headless=true -Dcom.sun.management.jmxremote.port=1090 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -Djava.rmi.server.hostname=*.*.*.*”

就ok了。打开jconsole后，主要查看内存——对内存使用情况和内存池”ps old gen”中的情况。能否正常释放内存。

五、规范和模板

1、可以参照——性能测试脚本制作和场景设置规范.doc

2、脚本，测试结果，事务也有相应的命名规范，脚本命名为（应用名称+性能点名称），事务命名（性能点名称），

测试结果命名规则为（应用名称+性能点名称+执行脚本时间+并发用户数+运行时间）

3.模板——性能测试报告模板.doc和性能测试设计方案模板.doc

六、查看日志

1、查看debug日志（debug.log ）：查看是否有报错信息

2、查看超时日志（filter.log）：查看是否超时。这里超时的判断看是否大于200ms，超时的概率有个计算公式：超时的概率=超时日志中超时的数目/事务数

事务数可以在lr中的结果中有个查看总的事务数。超时的概率的阀值为10万分之1。大于这个概率的时候需要开发去查找超时的原因。

七、linux命令

1.我这次主要用到如下的linux命令：ls，cd ，cd .. ，su ，vi，tail -f ，ctrl+z。当然还有很多其他的命令，之后再去实践了。

八、性能测试期间遇到的问题和心得：

1、录制脚本碰到的疑惑：脚本中发表点评的内容显示成“?????????, ?????????”—— 这个就是输入的文字只是中文显示不出来，这样显示没有问题；

2、对性能测试的各个参数点及对应的标准需要非常熟悉，这样好比有了一个预期结果和一个参照标准，执行测试过程中可以很快查出某个点的性能问题；

3、shell脚本中建议增加一项LOAD和CPU的平均值的计算功能。

最后，还是要感谢下性能测试小组的同学给予的帮助，谢谢悟石和元壮，在这个项目中给我耐心的讲解和解释，让我了解很多性能测试知识。

感想二

最近有幸和云帅参与了新江湖的性能测试，这个项目中，由于测试时间紧，性能点多，我们从开发提交测试后就进行性能测试。提早介入测试导致我们后来遇到很多问题。我主要的工作是协助云帅，申请性能测试服务器，验证搭建好的性能测试环境和功能，准备性能测试数据，后期我参与了好友最近更新的相册这个性能点的执行，下面说下具体是怎么做上面的事情的：

1、申请性能测试服务器：

先找总的开发负责人给出本阶段性能点所需要信息，包括性能点，服务名，Hsf版本号，数据源，data-pool设置，jdk版本号，apache版本号，jboss版本号，jvm设置，代码库路径，压测页面链接，依赖系统和该性能点对应的开发负责人。收集完这些信息后我们可以向悟石他们申请机器啦。申请时除了上面最后三点，其他内容都需要提供。这样做是为了之后让scm参照上面的信息部署环境。

2、验证搭建的环境/功能：

1）验证jdk、apache、jboss的版本：可以通过拷贝文件valid-env，执行check.sh来快速验证jdk、apache、jboss的版本。或者通过如下的方法来依次验证。

a、jdk版本查看 先通过jbosscle文件查找到使用的JAVA_HOME地址，然后根据目录查找 /opt/taobao/java/bin/java -version 或者 /opt/taobao/java/bin/java1 -version；

b、apache版本查看 /opt/taobao/install/httpd/bin/httpd -version；

c、jboss版本查看 jboss启动日志jboss_stdout.log中有，只要看前面几行就能查找到。

2）证数据库配置：数据库的配置，一般存放在应用下的conf目录下，orcle-***-ds.xml/mysql-***-ds.xml文件里。检查它是否连接了正确的数据库schema，连接数是否正确。

3）查看apache的访问日志是否屏蔽掉。查看conf目录下，httpd.conf文件里——CustomLog这个配置项。

4）验证功能：需要确保所要测试的性能点的功能及相关功能正确。执行几个主流程查看或者跑一下接口是否通。

3、准备测试数据：

1）向DBA讨教了如何快速准备大量的性能测试数据。两种方法。写存储或者设置autoincrement。我这次主要用的是后者。将表的主键设置 autoincrement，这样可以通过insert into 表(字段1，字段2…) select value1，value2… from 表执行一次可以成倍增长当前的数据。这种方法简单快捷，如果只是为了纯粹增加表的数据流这个方法还是比较好的。当然除了数据库的方法还可以通过接口去插数据，在lr中执行下也是不错的选择。

2）性能测试环境下什么数据也没有，所以通过导入功能测试环境的数据来充当，mysql工具中有一个很好的功能：可以将功能测试数据库库的表结构和数据复制到性能测试数据库，如果性能测试数据库中已经存在该表，就drop掉该表，执行速度很快，大大方便我们准备数据。推荐大家用SQLyog Enterprise这个工具，真的不错。方法如下：打开mysql的数据库，连接到功能测试库上，点击File——New Conections，连接到性能测试库上，选择你要操作的表，右击选择第二项——Copy Table To Diffierent Host/Database，在界面中左边是源数据库，也就是我们的功能测试数据库，选择你要复制的表，支持多选，右边选择目标数据库，也就是我们的性能测试数据库及对应的用户，如果表已经存在，勾选选项：Drop table if exists in target ，具体要拷贝表结构和数据或者只是表结构都可以自己选择，最后点击copy，数据库表结构和数据很快可以复制完。

4、录制脚本：

淘江湖二期很多页面是采用了异步方式调用，所以录制完一个页面后，通过抽取每个请求作为一个脚本。接口测试这块采用http的方式去模拟测试，这样方式最大的好处是脚本准备比较方便。

5、测试执行：

1）一个页面通过加载该页面所有的异步请求，逐步增加各个脚本的并发用户数，调整并发用户数，查看是否满足预期的tps。

2）测试过程中时刻关注lr的运行情况，曲线有没有波动很大，几个日志信息，debug日志，超时日志和velocity日志，是否有大量日志出现。监控 java虚拟内存是否正常释放，曲线是否平稳，而不是往上的趋势。一般如果有问题的话，刚开始运行脚本就会出现频繁报错，这时需要马上停下来查看问题原因。排查原因有很多，由于我们介入较早，有一些是因为数据库表结构没有建索引，或者是应用的版本没更新导致（初期bug比较多，版本经常更新），所以经过这次测试，深刻体会到性能测试的前提需要在sql审核通过，索引加好，功能比较稳定的前提下进行，也就是功能测试第二阶段开始，此时功能相对稳定，表结构也不会怎么变化，会少走很多弯路。

3）由于这次页面性能测试依赖的应用比较多，最多有用到13台应用服务器，当测试某个性能点的时候，需要查看与该应用交互的应用的情况，可以用netstat -nal命令。查出来后，监控这些相关的服务器，cpu，load，日志情况等。

4）用lr监控cpu这些数据时发现有一台服务器监控到的cpu有问题，空闲状态cpu就已经达到60%了，具体原因也不清楚，所以换了方式采用我们这边的一个监控cpu和load的shell脚本来做。

6、关于性能测试计划：这次测试有11个性能点，6个接口和5个页面，计划中根据测试优先级高低分三个阶段进行，分阶段搭建测试环境和准备数据和脚本，先接口后页面的顺序执行。

7、关于性能测试日报：日报中主要记录目前所处的测试阶段，当天的测试工作，测试结果和结果分析，BugList，问题和风险，以及明天的计划。

最后非常非常感谢云帅，像老师一样，非常细心和耐心，教我很多很多，让我受益很多很多，更让我体会到了一个优秀的性能测工程师认真严谨的工作态度。