一，性能瓶颈
1、网络瓶颈，如带宽，流量等形成的网络环境：
针对网络瓶颈，现在貌似很少，不过也不是没有，首先想一下如果有网络的阻塞，断网，带宽被其他资源占用，限速等情况，应用程序或系统会是什么情况，针对WEB，无非是超时，HTTP400，500之类的错，针对一些客户端程序，可能也是超时，掉线，服务器下发的，需要服务器返回的信息获取不到还有一种更明显的情况，应该就是事务提交慢，如果封装事务的代码再不完善，一般造成的错误，无非就是数据提交不完整，或者因为网终原因+代码缺陷造成重复性提交。如此综合下来，肯定是考虑网络有瓶颈，然后考虑网络有问题时，怎样去优化，是需要优化交互的一些代码，还是接口之类的
2、应用服务瓶颈，如中间件的基本配置，CACHE等：
应用服务的瓶颈的定位，比较复杂，学习中，不过网上有很多资料可以参考的。一般像tomcat，weblogic之类的，有默认的设置，也有经过架构和维护人员进行试验调试的一些值，这些值一般可以满足程序发布的需要，不必进行太多的设置，可能我们认识的最基本的就是JAVA_OPTS的设置，maxThreads，time_out之类的参数我们做借助LR，Jemeter或webload之类的工具，执行性能测试，尤其是对应用服务造成了压力，如果应用服务有瓶颈，一般我们设置的log4j.properties，日志都会记录下来。然后根据日志，去进一步确定应用服务的问题
3、系统瓶颈，这个比较常用：应用服务器，数据库服务器以及客户机的CPU，内存，硬盘等配置：
系统瓶颈，这个定位虽说比较复杂，但是有很多前辈的经验值参考，不作说明，相信用LR的同行，也可以从性能记数器中得出一些指标值，加上nagios，cacti，可以很明显的看出系统哪些资源够用，哪些资源明显不够用。不过，一般系统瓶颈的造成，是因为应用程序本身造成的。关于这点儿的分析和定位，就需要归入应用程序本身瓶颈分析和定位了
4、数据库瓶颈，以ORACLE为例，SYS中默认的一些参数设置：
5、应用程序本身瓶颈：
1）应用程序瓶颈，这个是测试过程中最需要去关注的，需要测试人员和开发人员配合执行，然后定位，我这儿做的大都是执行性的，比如会有脚本去运行，开发人员会结合jprofiler之类的工具，去看一下堆遍历，线程剖析的情况确定哪儿有问题。
2）大致是这样，没有实际操作过逐步细化分析，先可以监控一些常见衡量CPU，内存，磁盘的性能指标，进行综合分析，然后根据所测系统具体情况，进行初步问题定位，然后确定更详细的监控指标来分析。
二，测试场景，测试点
测试点：
1，响应时间
1）个人主观因素和客观响应时间
2）用户在大数据量查询时，我们可以将先提取出来的数据展示给用户，在用户看的过程中继续进行数据检索，这时用户并不知道我们后台在做什么。
2，出错率
1）连续工作状态下的出错信息
3，管理员
1）服务器资源使用情况是否合理
2）应用服务器和数据库资源使用是否合理
3）系统能否实现扩展
4）系统最多支持多少用户访问，系统最大业务处理量是多少
5）系统性能可能存在的瓶颈在哪里
6）更换哪些设备可以提高性能
7）系统能否支付7X24小时的业务访问
4，开发/设计人员
1）架构设计是否合理
2）数据库设计是否合理
3）代码是否存在性能方面的问题
4）系统中是否有不合理的内存使用方式
5）系统中是否存在不合理的线程同步方式
6）系统中是否存在不合理的资源竞争
5，测试
1）链接超时
2）崩溃
3）系统交互：电话/短信/低电量提醒/push提醒/USB数据线插拔提醒/充电提醒等
4）弱网情况
5）CPU使用问题：CPU频率设置过高时会导致过热,过热导致耗电更严重,CPU频率设置过低导致手机滞后,应用处理缓慢同样会导致耗电。
更多时候，用户解决CPU超载问题只能关闭甚至卸载App，App就被Kill了!
测试场景：
1，区间多用户循环操作
1）30个用户在10秒内，循环访问服务器10次，（平均响应时间在30ms内，错误率为0）
2）即N个用户在S秒内调用接口X次，查看，响应时间/错误率
2，高并发操作
1）100个用户同时访问，（平均响应时间在30ms内，错误率为0）（高并发）
2）即N个用户同时调用一个接口，查看，响应时间/错误率
3，高频率操作
1）模拟2个用户都以20QPS的频率访问服务器资料，持续10秒，要求平均响应时间在30ms内，且错误率为0
2）QPS每秒访问次数
4，特殊的活动并发测试
三，测试方法
1，根据不同的业务类型给出测试用例
1）跟踪记录服务器端的运行情况和返回给客户端的运行结果
2）可采用逐步加压和瞬间加压方式
2，测试数据准备
1）测试数据库需具备与真实环境成一定比例或基本一致的数据
3，场景案例
测试中，使用逐步加压的模式，测试运行场景安排如下：
1.每隔2秒增加1个用户连接，最多增加到100个用户，查看并记录运行情况
2.每隔2秒增加2个用户连接，最多增加到200个用户，查看并记录运行情况
3.每隔2秒增加1个用户连接，最多增加到300个用户，查看并记录运行情况
4.每隔3秒增加1个用户连接，最多增加到400个用户，查看并记录运行情况
每个场景都包括：用户登录-业务操作-业务完成-退出系统，所有用例都按以上场景进行测试，由于pc性能限制，
为了更准确模拟现场环境，将运行的所有脚本部署在8台LoadRunner终端上，主要目的就是检查在不同的压力的情况下，业务系统的性能表现。
四，指标分级
1，应用软件级别指标
1）CPU的利用率小于40%
2）内存占用小于80%
3）Processor queue length 小于2
4）Response time 小于 1s
5）吞吐量throughtput大于90%
6）业务执行的平均响应时间（期望值：<15s）
7）不同并发用户数的状况下的记录上述值
2，网络级别指标
1）吞吐量：单位时间内网络传输数据量
2）冲突率：在以太网上监测到的每秒冲突数
3，操作系统级别指标
1）进程/线程交换率：进程和线程之间每秒交换次数
2）CPU利用率：即CPU占用率（％）
3）系统CPU利用率：系统的CPU占用率（％）
4）用户CPU利用率：用户模式下的CPU占用率（％）
5）磁盘交换率：磁盘交换速率
6）中断速率：CPU每秒处理的中断数
4，数据库级别指标
1）数据库I/O的流量大小
2）数据库锁资源的使用数量
3）数据库的并发连接数：客户端的最大连接数
五，记录指标数据
1，运行状况记录
1）硬件环境资源
2）服务器操作系统参数
3）网络相关参数
4）数据库相关参数
2，记录结果/分析解决
1）APP服务器主机上的CPU利用率
2）在数据库（Oracle）服务器上主机上的CPU利用率
3）IO和CPU利用率对照表如下
4）APP服务器监控的网络流量
5）DB服务器上监控的网络流量
6）运行的并发用户数目
7）测试中完成各操作的平均响应时间：（单位：秒）
8）测试中每秒的点击率如下
9）交易的吞吐率（每秒处理数据量）
3，对应设计优化方案
六，补充发起频率概念
相同吞吐量下不同的发起频率
举个例子，一秒发起100笔报文，可以有不同的发起频率：
1） 每10毫秒发起1笔报文
2） 每100毫秒发起10笔报文
3） 每1000毫秒发起100笔报文
这三种发起频率下，系统的吞吐量都是每秒100笔报文，但是系统资源利用率、响应时间等指标会略有差异。
