跑稳定性之前要检查的环境
1、压力机磁盘空间（因为跑稳定性过程中生成的result文件的数据不断增加，如果压力机磁盘空间不够就会导致压力停止）
2、清空服务器日志，日志改成error模式，检查服务器空间大小。定时任务需要定时删除日志
3、查看数据库表空间是否足够
4、清空gc日志（方便观察稳定性的 gc情况）
5、如果执行过程中会生成数据并且数据保存在磁盘上，则需要考虑写个定时任务定时删除数据（如果这些数据可删除的情况下）
6、稳定性测试目的：HPJmeter分析日志是否能正常回收，能的话说明不存在内存溢出问题。gc时间百分比和fullgc时间百分比不超过5%则是正常的
批处理
1、了解生产环境上的数据是怎么分布的，才能在测试环境更好的模拟
2、从数据库上验证结果，哪些表的哪些字段改变了，数据增加了还是减少了多少，这个值与预期的是否一致，用sql记录跑批前后的数据量，验证数据的流向是否符合业务逻辑
3、批处理的处理流程，数据先到哪个表，再到哪个表，表的数据要依赖哪个表
4、例如存储加工：也就是报表跑数，报表跑数需要原系统表里有数据才能跑报表跑数，报表卸数的话是要报表结果表里有数据才能卸数
5、数据不够怎么造数
6、批处理测试关注批处理时间、批处理效率、批处理总量
波动
1、稳定性运行过程中tps掉了一个坑，15分钟后恢复正常。检查波动那个时间段后台是否有在做批处理。如果是，这波动是正常的（批处理导致cpu增大，tps减少）
脚本报错
1、压力执行过程中刚开始没报错，后来持续报错
2、检查日志是否满了或者表空间满了
3、是否是数据太多，返回结果太多造成的
稳定性过程中有支交易的响应时间越跑越高
1、检查该交易的最高响应时间是否超时，如果超时则要优化，如果不超时，可否优化
2、单跑该交易，观察响应时间是否越跑越高
3、检查该交易是要处理数据还是查询数据，依赖哪些表，是不是依赖的表的数据增加才导致该交易响应时间增加的
4、重测场景，去掉会增加数据的交易，看该交易响应时间是否增加
5、如果能优化最好，如果不能优化，应该在测试报告中说明
6、通过分析得出该交易响应时间的增长是因为其他表的数据增长造成的，生产上每天凌晨都会清理一定的数据，所以该交易的响应时间增长不会造成生产超时的存在
脚本调试
1、根据脚本模板替换报文，到日志中去查找对应的报文
2、编译脚本看是否存在语法错误，如果有，检查语法和报文的格式
3、运行脚本看是否存在错误，如果有，查看应用服务器日志，具体是什么原因报的错日志都有显示
4、常见的错误是数据库里没有数据，这时需要根据错误提示去数据库修改数据（耗费时间也是最多的）
5、保证要测试交易数据库表里的数据足够（数据跟生产环境一致）
6、检查哪些字段需要参数化，找到该字段对应的表，从数据库里查询需要参数化的数据（耗费时间也很多，你需要知道字段对应的表和数据的流向才能正确的拼凑出对应的sql语句，表的关联很多）
负载测试超时
1、从最简单的地方开始分析：检查压力机、应用服务器、数据库服务器是否存在硬件瓶颈，是否存在网络瓶颈
2、检查该交易对应的表的数据是否过多，超时大部分是数据库原因造成的
3、重压超时的交易，启动awr监控（数据库）
4、分析awr报告，查看哪些表没有索引、全表扫描等。如果有索引，查看是否有的数据没走索引
5、如果走索引，检查该交易是否查询的字段太多（比如：业务要求一次性处理365条数据，操作比较大）
6、参数化数据太少了，数据库有行锁导致响应时间超时，加上足够的参数化数据即可
7、参数化数据太少了，引起对数据库表的挣用，造成死锁，所以报超时错误，加上足够的参数化数据即可
8、数据库表锁、行锁、锁等待、死锁都会造成超时（数据库的用对应的sql查询是否有这些问题存在）
交易处理能力下降
1、稳定性测试过程中，发现整体交易处理能力随着时间的推移呈逐步下降趋势。经过对测试结果中各交易进行排查，确定导致tps下降的交易只有一只，该交易在测试模型中占比达到45%，当该交易响应时间逐步增长后，其交易能力呈反比下降，最终导致整体处理能力下降
2、分析服务器日志，统计该交易在服务器端的时间基本都是稳定状态，并且没有发现堆内存溢出情况，由此可排除程序问题
3、使用jconsole进程监控，发现进程在运行过程中存在频繁加载、卸载类的情况
4、正常情况下Java进程是不应该频繁加载和卸载类的。由于测试脚本调用引用的Java框架使用了大量的类，当Java内存中的永久保持区过小时，就会导致经常被引用的类频繁加载和卸载。由于堆内存过小，频繁new对象时容易产生大量内存碎片，从而导致new对象时效率逐步降低
5、解决方法：扩大-XX:MaxPermSize值
6、重新执行测试，整个测试过程中该交易运行平稳，未出现响应时间增长，处理能力下降的情况
PS：堆内存大小到低需要配置多少并没有一个固定标准，并不一定越大越好，需要根据被测交易特性，并发数量以及压力机配置等进行不断测试分析后再进行相应的合理划分
Java占用内存分析
很多人误认为-Xmx和-Xms参数指定的大小就是程序占用的内存，实际只是Java堆对象将会占用的内存。堆只是影响Java程序占用内存大小的一个因素。要更好的理解你的Java程序会占用多大的内存需要先了解以下因素：
对象（objects）
类（classes）
线程（threads）
本地数据接口（native data structures）
本地代码（native code）
这些因素对内存的影响又会随着城乡、环境和平台的变化而变化。想要精确的计算总的内存大小并不是那么容易，因为你只能控制堆大小（-Xmx）、类占用的内存（-XX:MaxPermSize）、线程栈（-Xss控制每个线程占用的内存），但如果栈太小时会导致栈溢出。所以计算公式为：（-Xmx）+（-XX:MaxPermSize）+线程数*（-Xss）+其他内存
其他内存取决于本地代码占用内存，它大约占JVM内存的5%左右
线程池占满
1、监控tomcat中间件是为了监控线程池的使用情况，如果tomcat里还配置了数据库连接池也要监控数据库连接池的使用情况。假如配置了300个线程池，那么如果监控到这300个线程池都属于繁忙状态，那说明线程池不够用了，后面的请求都属于排队状态，排队需要等待，会导致响应时间增长。但如果配置的线程池太大，则会浪费资源。所以需要减少不必要的线程池的浪费
2、通过通过manager status监控tomcat，修改tomcat/conf里的tomcat-users.xml进行配置，配置角色、用户名、密码，重启tomcat
3、访问http://localhost:8080/manager/status进行监控
4、acceptCount="300"，指的是当线程数达到maxThreads后，后续请求会被放入一个等待队列，这个acceptCount是这个队列的大小，如果这个队列也满了就直接refuse connection
场景1：接受一个请求，此时tomcat启动的线程数还没有达到maxThreads，tomcat会启动一个线程来处理该请求
场景2：接受一个请求，此时tomcat启动的线程数已经达到了maxThreads，tomcat把该请求放入队列，等待空闲了再来处理
场景3：接受一个请求，此时tomcat启动的线程数已经达到了maxThreads，且acceptCount也达到了最大，此时tomcat会拒绝此次请求，返回refuse connection错误
5、调整tomcat最大连接数，可以增加maxThreads和acceptCount，并且使acceptCount大于等于maxThreads
6、maxTreads的值应该根据流量的大小，如果值过低，将没有足够的线程来处理所有的请求，请求将进入等待状态，只有当一个处理线程释放后才被处理；如果设置的太大，tomcat的启动将花费更多的时间。所以该值需要实际测试分析得出，可通过前面讲的managerstatus监控页面得到。切记不能一味的扩大该值，瓶颈无法突破时，可以使用tomcat集群来提升性能
系统负载总是很高
1、系统运行一段时间后发现服务器的负载总是很高，而且后台出现错误日志。临时解决方案：重启机器，但是过了一段时间之后发现负载还是很高
2、不压测时看系统负载高不高，如果还高那就是系统本身有压力，看是什么导致负载高
LoadRunner响应时间和用户体验时间不一致
1、测试过程中发现loadrunner测试响应时间和客户端实际的用户体验时间不一致的现象，客户体验时间远远超过loadrunner测试的响应时间
2、分析：用户通过浏览器访问web服务器时，时间包括用户感应时间、浏览器处理时间、网络传输延时和后台服务处理时间。而loadrunner测试响应时间不包括浏览器的JS文件解析执行、渲染、以及人眼识别时间，只包括网络延时和后台服务处理时间。因为loadrunner主要是用来测试后台服务器性能的
3、一般情况下loadrunner测试响应时间都会小于用户实际体验时间
如果测试目的要求获取用户体验时间，则需要在loadrunner测试时间的基础上，考虑添加误差因子
如果用户实际体验时间远大于loadrunner测试响应时间，则需要重点分析排查JS解析执行、渲染、布局等问题
如果loadrunner测试响应时间较长，则分析是什么原因导致超时
