基础概念
1、系统性能包括：执行效率、资源占用、系统稳定性、安全性、兼容性、可靠性、可扩展性。
2、性能测试八大类：性能测试、负载测试、压力测试、配置测试、并发测试、容量测试（数据库）、可靠性测试（系统稳定性），一般在功能测试结束了才开始。
负载测试：通过逐步加压来确定系统的处理能力和承受能力的各项阈值,单位时间高压
压力测试：通过逐步加压，测试系统性能的变化、验证被测对象是否达到性能指标
容量测试： 容量越大性能越好
3、性能测试也可以针对单元测试（面向对象测试的是类）、接口测试，接口输入参数（前端），输出参数（后端）均可进行性能测试所以性能测试不全是系统级别的，可以是单元级别，接口级别，前端小用户量可以用HTTPwatch来测试。
性能指标和有关计算公式
1、吞吐量（throughput）：单位时间内处理客户端请求数量，吞吐量越大，单位时间内处理的数据就越多，系统负载能力就越强，一般用来评估对比哪个服务器比较好,F=（并发虚拟用户数每个VU发出的请求数)/性能测试所用时间，其中在线用户数可通过插件http://www.51.la
还可以根据2-8原则计算。
如用户登录场景：早高峰时段，8：50—9：10，5000坐席上线登陆。业务量：5000个
时间：20x60=1200秒
吞吐量=80%x业务量/(20%时间)=4000/240=16.7/秒
而并非5000/1200=4.1/秒
2、并发数量（并发的虚拟用户数Vuser）concurrency计算公式：
（1） 计算平均的并发用户数： C = nL/T
（2） 并发用户数峰值： C’ ≈ C+3根号C
公式（1）中，C是平均的并发用户数；n是login session的数量平均有多少人访问系统；L是loginsession的平均长度平均在线多长时间；T指考察的时间段长度。
公式（2）则给出了并发用户数峰值的计算方式中，其中，C’指并发用户数的峰值，C就是公式（1）中得到的平均的并发用户数。该公式的得出是假设用户的loginsession产生符合泊松分布而估算得到的。
还有一个广泛用户并发数公式
C=n/10
C^=rC(通常r=2~3)
通常用访问系统的用户最大数量的10%作为平均并发用户数；
3、思考时间:
think time，在脚本中用lr_think_time()函数,模拟真实的情况可以加上，模拟极限情况可以去掉 思考时间完全取决于用户行为与服务器网络没关系
在线用户：保持在线会话 会占用内存资源
4、响应时间：是指用户从客户端发起一个请求开始，到客户端接收响应从服务器返回的结果的结束，结果信息展示在客户端的整个过程所耗费的时间。 响应时间=网络传输时间+web应用服务器处理延迟时间+数据库服务器处理延迟时间+客户端处理延迟时间 （从用户端来讲，差异在于网络传输，一般在局域网里面进行测试，要保证网络没有问题（LR可以设置模拟带宽）一般用的是平均响应时间
5、点击数（hits）：根据客户端向web服务器发送了多少次HTTP请求计算的通常使用每秒点击数(hits per second)这个指标来衡量服务器处理能力
6、性能计数器(counter)：描述相关服务器或操作系统中间件等性能的一些数据指标。
7、资源利用率：各种资源的使用情况 遵循短板效应原理。
8、网络吞吐量：网络工作正常的情况下，单位时间内通过网络的数据数量。当网络吞吐量达到网络设备或链路的最大传输能力时，需要考虑升级网络设备
9、错误率，一般不超过千分之五，一般较稳定的系统错误率是由超时引起的叫超时率。
10、系统稳定性：（如要求36524无故障运行需要进行该项测试 ） 是指系统在标准压力下（系统逾期日常压力），能够稳定运行的时间。（如内存泄漏就是在改类型测试中发现的），至少连续运行24小时以上
11、PV: 一个ip访问一次算一个PV 按PV算是不合理的，一般是按照IP算
脚本要素
1、集合点
同步虚拟用户，以便恰好在同一刻执行任务。lr_rendezvous(“事务名称”)
2、事务
事务是指服务器响应虚拟用户请求所用的时间，一个完整事务由事务开始、事务结束以及一个或者多个业务操作、任务构成。lr_start_transaction(“事务开始”)…lr_end_transaction(“事务结束”，LR_PASS) 事务结束必须包含事务状态： LR_PASS(Succeed)、LR_FAIL(FAIL）、LR_STOP(Stop)、LR_AUTO自动检测返回状态
思考时间不能放在事务里面，否则会被算进事务执行时间
3、检查点
http是无状态的，当客户端向服务器发送请求后，只要服务器响应了请求，他就认为是正确的。检查点是在回放脚本期间搜索特定的文字符串或者图片等内容，从而验证服务器响应内容的正确性。web_reg_find() 是注册函数（带reg)，必须放在响应页面之前设置检查点之后必须保证Preferences->Checks里面对应选项选项是选中的，否则不会生效。
web_reg_find: 从下一个回应的hTML页面中查找指定字段文本字符串
web_find: 从HTML页面查找指定文本字符串
web_image_check:从HTML页面中查找指定的图片
web_global_verification: 从所有后续HTTP交互中查找指定的文本字符串
4、关联
脚本与录制的完全相同的话回放时遇到比较智能的服务器就会失败。关联把脚本中写死的数据转变成动态的数据如：Session ID，也可以将冗长的数据参数化，可手动关联，自动关联和利用关联。
需求分析及业务场景
分析必要性、可行性、要非常熟悉系统功能：系统架构、业务流程、功能重点、网络部署
没有明确性能测试需求如何开展：1、用户频繁使用存在大量用户使用的（如登录、注册、查询个人信息）2、系统关键功能点，存在大量数据操作（如支付接口）3、与外部系统存在接口的，有相互调用关系，大量数据流转 4、可能存在风险的地方 （比如会在某个时候突然达到峰值的那种）
确定测试点后交给上级评审再进行测试
确定需求之后提取对应测试点开始测试（性能测试一般不做异常分析，因为异常一把比较少），性能测试要发现问题并定位问题。
例如：分析数据量（用户、交易数据、峰值、峰值并发数等等），分析测试点，确定对应指标
最好同一个性能测试用例执行三次，然后分析结果，只有结果相近才能证明是成功的
确定并发数
1、客户直接给出指标、或自己经验 2、查询系统日志 时间点峰值：用数据库查、可以是linux日志，网络流量等
响应时间：1、用户操作时间 2、服务器处理时间（2、5、8、10）
举例：系统要求5分钟内完成200次用户注册，响应时间不超过3秒，成功率100%，CPU及内存使用率不超过70%
首先录制算出 单次注册消耗时间10.86
560/10.86=27
200/27=8个Vuer
827=216个测试数据
216*1.2倍=260个数据 （准备充分，避免测试脚本运行因数据不够用导致错误)
系统资源耗用
1、CPU使用率 算法有问题使用率会很高，（序复杂，或调用API接口，死循环等）不能持续在某个峰值如90% 一般不超过70%,否则就视为会存在瓶颈
内存：与CPU持续使用率标准差不多 （内存泄漏，如定义太多全局变量没有释放等会使其过高）
2、网络带宽：不超过总带宽50%
3、磁盘
4、CPU队列长度，不超过CPU数量+1 超过说明堵塞
业务模型建立
约束条件：数据约束（参数化、造测试数据）、环境约束（关联）
业务流程分析
业务流程图