性能测试
软件系统的性能是一个很大的概念,覆盖面非常广泛,对一个软件系统而言,包括执行效率、资源占用、系统稳定性、安全性、兼容性、可靠性、可扩展性等。性能测试是为描述测试对象与性能相关的特征并对其进行评价而实施和执行的一类测试。它主要通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。通常大家把负载测试、压力测试等统称为性能测试。
负载测试
通过逐步增加系统负载,测试系统性能的变化,并最终确定在满足系统的性能指标情况下,系统所能够承受的最大负载量。简而言之,负载测试是通过逐步加压的方式来确定系统的处理能力,确定系统能够承受的各项阀值。例如,逐步加压,从而得到“响应时间不超过10秒”, “服务器平均CPU利用率低于85%”等指标的阈值。
压力测试
通过逐步增加系统负载,测试系统性能的变化,并最终确定在什么负载条件下系统性能处于失效状态,并获得系统能提供的最大服务级别。压力测试是逐步增加负载,使系统某些资源达到饱和甚至失效的测试。
其他的性能测试分类为：
配置测试
主要是通过对被测试软件的软硬件配置的测试,找到系统各项资源的最优分配原则。
并发测试
测试多个用户同时访问同一个应用、同一个模块或者数据记录时是否存在死锁或者其他性能问题,几乎所有的性能测试都会涉及一些并发测试。
容量测试
测试系统能够处理的最大会话能力,确定系统可处理同时在线的最大用户数,通常和数据库有关。
可靠性测试
通过给系统加载一定的业务压力(如CPU资源在70%~90%的使用率)的情况下,运行一段时间,检查系统是否稳定。因为运行时间较长,通常可以测试出系统是否有内存泄漏等问题。
失败测试
对于有冗余备份和负载均衡的系统,通过这样的测试来检验如果系统局部发生故障,用户是否能够继续使用系统,用户受到多大的影响。如几台机器做均衡负载,测试一台或几台机器垮掉后,系统能够承受的压力。
响应时间
Response Time = 网络传输（请求）时间+服务器处理（一层或多层）时间+网络传输（响应）时间。
响应时间是指系统对请求作出响应的时间。直观上看，这个指标与人对软件性能的主观感受是非常一致的，因为它完整地记录了整个计算机系统处理请求的时间。由于一个系统通常会提供许多功能，而不同功能的处理逻辑也千差万别，因而不同功能的响应时间也不尽相同，甚至同一功能在不同输入数据的情况下响应时间也不相同。所以，在讨论一个系统的响应时间时，人们通常是指该系统所有功能的平均时间或者所有功能的最大响应时间。当然，往往也需要对每个或每组功能讨论其平均响应时间和最大响应时间。
对于单机的没有并发操作的应用系统而言，人们普遍认为响应时间是一个合理且准确的性能指标。需要指出的是，响应时间的绝对值并不能直接反映软件的性能的高低，软件性能的高低实际上取决于用户对该响应时间的接受程度。对于一个游戏软件来说，响应时间小于100毫秒应该是不错的，响应时间在1秒左右可能属于勉强可以接受，如果响应时间达到3秒就完全难以接受了。而对于编译系统来说，完整编译一个较大规模软件的源代码可能需要几十分钟甚至更长时间，但这些响应时间对于用户来说都是可以接受的。
258原则（没啥意义）：
所谓的“2-5-8原则”，简单说，就是当用户能够在2秒以内得到响应时，会感觉系统的响应很快；当用户在2-5秒之间得到响应时，会感觉系统的响应速度还可以；当用户在5-8秒以内得到响应时，会感觉系统的响应速度很慢，但是还可以接受；而当用户在超过8秒后仍然无法得到响应时，会感觉系统糟透了，或者认为系统已经失去响应，而选择离开这个Web站点，或者发起第二次请求。
事务响应时间（Transaction Reponse Time）
事务是指一组密切相关的操作组合。例如一次登录可能包含了多次HTTP请求，如：判断用户是否存在？密码是否正确？是否已登录？登录？等多个HTTP请求。
通过Loadrunner获取的事务响应时间，主要可以分解为：First Buffer +Receive + Client Time
1）First Buffer（建立Connection后，浏览器发送请求并成功接收第一个字节的时间）
2）Receive（浏览器接收到第一个字节到最后一个字节的时间）
3）Client Time（请求在客户端浏览器延迟的时间，基本可以忽略）
除了这三个时间，一般细分时间表里还包括DNS解析时间、FTP认证时间、SSL加密握手时间、Connection创建连接时间等。
各个时间段说明：
Stalled（阻塞）
浏览器对同一个主机域名的并发连接数有限制，因此如果当前的连接数已经超过上限，那么其余请求就会被阻塞，等待新的可用连接；此外脚本也会阻塞其他组件的下载；
优化措施：
1、将资源合理分布到多台主机上，可以提高并发数，但是增加并行下载数量也会增大开销，这取决于带宽和CPU速度，过多的并行下载会降低性能；
2、脚本置于页面底部；
DNS Lookup（域名解析）
请求某域名下的资源，浏览器需要先通过DNS解析器得到该域名服务器的IP地址。在DNS查找完成之前，浏览器不能从主机名那里下载到任何东西。
优化措施：
1、利用DNS缓存（设置TTL时间）；
2、利用Connection:keep-alive特性建立持久连接，可以在当前连接上进行多个请求，无需再进行域名解析；
Initial connection（初始化连接）
TCP建立连接的三次握手时间
SSL（包含于HTTPS连接中）
http是超文本传输协议，以明文方式发送内容，不提供任何方式的数据加密，如果被不法分子截取浏览器和服务器之间的传输报文，会获取其中的信息。
https 是安全套接字层超文本传输协议，就是在HTTP的基础上加入了SSL协议，SSL依靠证书来验证服务器的身份，并为浏览器和服务器之间的通信加密。
因此建立HTTPS连接的时间相当于三次握手的时间+SSL时间。
Request sent（发送请求）
发送HTTP请求的时间（从第一个bit到最后一个bit）
优化措施：
1、减少HTTP请求，可以使用CSS Sprites、内联图片、合并脚本和样式表等；
2、对不常变化的组件添加长久的Expires头（相当于设置久远的过期时间），在后续的页面浏览中可以避免不必要的HTTP请求；
Waiting（等待响应）
通常是耗费时间最长的。从发送请求到收到响应之间的空隙，会受到线路、服务器距离等因素的影响。
优化措施：
1、使用CDN，将用户的访问指向距离最近的工作正常的缓存服务器上，由缓存服务器直接响应用户请求，提高响应速度；
Content Download（下载）
下载HTTP响应的时间（包含头部和响应体）
优化措施：
1、通过条件Get请求，对比If-Modified-Since和Last-Modified时间，确定是否使用缓存中的组件，服务器会返回“304 Not Modified”状态码，减小响应的大小；
2、移除重复脚本，精简和压缩代码，如借助自动化构建工具grunt、gulp等；
3、压缩响应内容，服务器端启用gzip压缩，可以减少下载时间；
后面的请求就省去了连接的过程：
资源利用率
资源利用率是指服务器系统不同硬件资源被使用的程度，主要包括CPU 使用率、内存使用率、磁盘使用率、网络等。资源使用率=资源实际使用量/总的可用资源量。资源利用率表现当前服务器资源使用的情况，它是分析服务器出现瓶颈和对服务器进行调优的主要依据，在配置调优测试的过程中，通过比较配置调优前后系统资源的使用率来判断调优的效果。
资源利用率是否是越低越好呢？
大家普遍的理解无非是当前系统的资源占用率越低越好，但是这个理解有一个概念上的偏差。 所谓的低资源利用率是指在一个单位基数下的概念，例如100ms响应时间，500TPS并发的基数下，如果资源利用率越低，则说明系统越好。而今天我要讲的是，资源不使用就是浪费，就是可耻！
我们要做高资源利用率！让系统在高资源占用情况下工作，而不是在低资源利用率下工作。以前我们总是在用时间换空间，现在？资源绰绰有余， 我们应该考虑如何用空间换时间了。
对内存体系熟悉的朋友应该知道，当前系统的内存管理体系和以前是不同的，我们并不会当一个进程关闭后就释放其使用过的内存，而将其标记为备用，当新建一个进程的时候，会先去尝试使用可用内存，在可用内存不足时再去从备用内存中释放。这就是典型的提高资源利用率的做法，一个系统的性能好坏不光是简单的三大指标，而是如何在可控的范围内竟可能发挥所有剩余资源来将业务更好的完成。
从业务角度的做法就是化整为零，例如原本需要好几个小时的报表，利用资源空余的时间分段处理；杀毒扫描安排在系统空闲的时候；持续集成及性能测试安排在凌晨用户使用较少的时候；下载软件通过QOS来利用空余带宽而不影响基本视频和游戏应用。这些东西都利用了高资源利用率。
从技术角度的做法就是多线程，多进程，多实例化。一个进程如果不能使用足够多的资源，那么就做多线程；多线程不行了，就上多个进程；多个进程不行了就上多个实例；多个实例不行就上多个虚拟化甚至多个主机。这些东西也利用了高资源利用率。
如果我有一个小的房子，为了让房间整洁，我必须不断的打包，解包来将生活用品整理起来，并且非常完美的存储在各种储物柜中，确保空间的完美使用。但是当我有很大的房子的时候，为什么不把东西都放开，让查找和使用它们更加方便呢？所以平衡点在于根据整个存储空间资源的情况来合理把握如何打包和存放。
不要再炫耀当前系统性能怎么好，资源占用率怎么低了！如果这样浪费资源其实也是性能测试做的不好的证据！
提高资源占用率，复用资源，挖掘系统潜能，平整波峰，这才是性能测试团队奋斗的目标。
并发用户
并发用户数是指现实系统中操作业务的用户，在性能测试工具中，一般称为虚拟用户数(Virutal User)。并发用户数和注册用户数、在线用户数的概念不同，并发用户数是一定会对服务器产生压力的，而在线用户数只是 ”挂” 在系统上，对服务器不产生压力，注册用户数一般指的是数据库中存在的用户数。
一种是严格意义上的并发，即所有的用户在同一时间点做同一件事或操作，这种操作一般指做同一类型的业务。比如，所有用户同一时刻做并发登陆，同一时刻做表单提交。
另外一种并发是广义范围的并发，这种并发与前一种并发的区别是，尽管多个用户对系统发出了请求或者进行了操作，但是这些请求或都操作可以是相同的，也可以是不同的。比如，在同一时刻有用户在登录，有用户在提交表单。
前面的两种解释都是从用户业务的角度来解释并发的，因为我们平时所做的性能测试也是从用户端对业务层的操作来进行并发测试的。
如果考虑整个系统运行过程中服务器所承受的压力是这样的：在该系统的运行过程中，把整个运行过程划分为离散的时间点，在每个点上都有一个“同时向服务端发送请求的用户数”，这个就是所谓的服务器所承受的并发访问数。
从性能测试工具的角度来看，虽然，性能测试工具可以1秒模拟成千上万个请求，那么这些请求的产生同样分前后顺序。就算这些请求被真正的“同时”生产出来，通过网络传输到过服务器时，因为受网络带宽、延迟等影响，也无法真正的对服务器构成“同时”请求。
从服务器角度，当它接收到并发请求，在处理这些请求时同样需要分前后顺序，因为它处理每个请求的时间极短；每秒可以处理几千几万次请求；所以，我们说它的并发能力是每秒/次。
吞吐量
指在一次性能测试过程中网络上传输的数据量的总和。
对于交互式应用来说，吞吐量指标反映的是服务器承受的压力，在容量规划的测试中，吞吐量是一个重点关注的指标，因为它能够说明系统级别的负载能力，另外，在性能调优过程中，吞吐量指标也有重要的价值。
关于吞吐量，据悉：
1. 约发现的80%系统的性能瓶颈都由吞吐量制约；
2. 并发用户数和吞吐量瓶颈之间存在一定的关联；
3. 采用吞吐量测试可以更快速定位问题。
通过不断增加并发用户数和吞吐量观察系统的性能瓶颈。然后，从网络、数据库、应用服务器和代码本身4个环节确定系统的的性能瓶颈。
吞吐率
单位时间内网络上传输的数据量，也可以指单位时间内处理客户请求数量。它是衡量网络性能的重要指标，通常情况下，吞吐率用“字节数/秒”来衡量，当然，你可以用“请求数/秒”和“页面数/秒”来衡量。其实，不管是一个请求还是一个页面，它的本质都是在网络上传输的数据，那么来表示数据的单位就是字节数。
事务
就是用户某一步或几步操作的集合。不过，我们要保证它有一个完整意义。比如用户对某一个页面的一次请求，对某系统的一次登录，对商品的一次确认支付过程。这些我们都可以看作一个事务
TPS
每秒钟系统能够处理事务或交易的数量，它是衡量系统处理能力的重要指标。
点击率
每秒钟用户向Web服务器提交的HTTP请求数。这个指标是Web 应用特有的一个指标；Web应用是“请求---响应”模式，用户发一个申请，服务器就要处理一次，所以点击是Web应用能够处理的交易的最小单位。如果把每次点击定义为一个交易，点击率和TPS就是一个概念。容易看出，点击率越大。对服务器的压力也越大，点击率只是一个性能参考指标，重要的是分析点击时产生的影响。
需要注意的是，这里的点击不能简单的看作鼠标的一次“单击”操作，也许一次“单击”操作中，客户端可能向服务器发现多个HTTP请求。
点击率可以看做是TPS的一种特定情况。点击率更能体现用户端对服务器的压力。TPS更能体现服务器对客户请求的处理能力。
-------------------------------------------------------------------------------------------------------------------------------------------------
当cpu，内存等的追加成本过高，公司无法负担， 或者说系统的硬件资源堆不上去了，就该测试人员去做系统的性能测试了。
从业务优化，代码优化的角度去发现定位并解决系统的性能瓶颈问题。替公司省钱，提升用户体验。
关于258原则，这还是要取决于需求。2秒的响应时间现在来看还是比较长的，最好能做到0.5秒左右。
不能一味的追求响应时间的降低，要找一个平衡点，要在用户可接受的响应时间范围内去最大化吞吐量，提升TPS。
做一件事0.1秒，1秒做10件，则事务响应时间TRT为0.1，tps为10，这一秒的吞吐量为10；
若做一件事0.125秒，同时可以做两件事，则1秒做16件，事务响应时间TRT为0.125，tps为16，这一秒的吞吐量为16；
HTTP中的reponse头里面的Content-Encoding:gzip，压缩响应体，减少网络上传输的时间，花费的是服务端的压缩和客户端的解压时间，通常在cpu空闲的情况下后者花费的时间比前者要少。
电脑出了问题。。。