在软件测试中和大家谈一下有关项目性能测试体验及实例
感想一
进入性能测试虚拟小组后，有幸跟着悟石元壮参与了一次项目的实践，感觉做下来收获蛮多的，把它总结下来。
一、创建文件夹
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，问题和风险，以及明天的计划。
最后非常非常感谢云帅，像老师一样，非常细心和耐心，教我很多很多，让我受益很多很多，更让我体会到了一个优秀的性能测工程师认真严谨的工作态度。
接下来我会以一个实例来更好的和大家了解一下性能测试这块的
月初曾经到X省做电力公司的性能测试项目,由于之前并无任何的测试经验以及性能测试项目经验.所以这
次的性能测试之行心中充满了太多的疑问以及不确定.
项目的背景：
电力公司的一个资产管理系统已经研发完毕,由于需要做推广工作,故此在推广之前需要做性能测
试,目的有三:
1、找出系统的性能瓶颈
2、对性能进行优化工作
3、确保系统在推广后的效果
项目人员组成：
项目经理： 负责项目的沟通协调。公司对外的接口。
测试小组： 负责所有测试工作的计划、执行及相关工作的安排分配。
平台小组： 协助测试小组工作。保证测试环境平台的适用性。
前两个属于性能测试的工作范畴；后一个属于和开发商以及客户一起共同努力产生的效果。
测试工作一共进行了两周，大部分的时间都用在了和客户沟通以及和开发商沟通上了。在项目初
期，由于经验上的缺乏，没有和客户就业务上问题用专人、专时来讨论，导致了在做需求的时候，我们
花费了大量人力、时间进行了重复的沟通，这导致了工作效率上降低。在第一周经常可以看见我们的测
试小组和平台小组的内部以及外部沟通经常会就一个业务问题进行反复的讨论。在项目后期，深刻的理
解了在进行专门的业务沟通会是十分必要的。
其实在整个项目中，之前自己一直认为在测试方面会花费较多的时间，后来才发现其实了解需求
、熟悉业务、了解应用、设计测试用例、做测试计划。。。这些才是真正消耗时间的地方。在这种地方
做项目，各方面都需要进行协调。不是你一来，你就可以顺顺利利的开展工作。包括系统的应用对象（
最终实际的客户），系统应用的主管（主管项目推广的领导），还有机房的管理人员（平常的工作很需
要他们的支持），软件开发商（由于软件的性能他们自己心中最清楚，所以性能测试的很关键的部分是
要获得软件开发商的支持），中国IT室验实内部小组的
沟通（平台小组和测试小组的沟通，两个小组为何成立，这里暂时不说）。
两个星期的工作，实际上是很辛苦的，由于本人并不是负责项目，所以并没有真正感受到项目经理的那种压力以及各方的工作的协调。
其实不管是软件项目还是开发项目，人在很大程度上是众要的，技术有时候并不能给你很大帮助，但是你必须得具备基本的技术能力。
看来在国内，至少很多项目的成功与否还是得靠人。靠外部和内部的人。
文章来源于领测软件测试网 https://www.ltesting.net/
