八、性能测试期间遇到的问题和心得：
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，问题和风险，以及明天的计划。
最后非常非常感谢云帅，像老师一样，非常细心和耐心，教我很多很多，让我受益很多很多，更让我体会到了一个优秀的性能测工程师认真严谨的工作态度。
文章来源于领测软件测试网 https://www.ltesting.net/
