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/
