2.1认识性能测试
2.1.1认识软件性能
软件性能：软件的性能是软件的一种非功能特性，它关注的不是软件是否能够完成特定的功能，而是在完成该功能时展示出来的及时性。
性能关注的是软件的非功能性，所以一般来说性能测试介入的时机是在功能测试完成之后。
性能也是一种指标，可以用时间或其它指标来衡量，通常我们会使用某些工具或手段来检测软件的某些指标是否达到了要求，这就是性能测试。
2.1.2为什么要进行性能测试
多个客户端同时访问造成压力。
Web应用服务器、应用服务器、数据库、网络
2.1.3性能测试的概念
定义：软件系统的性能测试是一个很大的概念，覆盖面非常广泛。
①对软件系统而言，包括执行效率、资源占用、系统稳定性、安全性、兼容性、可靠性、可扩展性。
②性能测试是描述测试对象与性能相关的特征并对其进行评价而实施和执行的一类测试。
③主要通过自动化的测试工具模拟多种正常、峰值以及异常负载条件下来对系统的各项性能指标进行测试。
2.1.4不同群体眼中的性能
①用户眼中的性能
②开发眼中的性能
③系统管理员眼中的性能
2.1.5测试眼中的性能
①测试人员需要考虑全面的性能，包括用户、开发、管理员等各个视角的性能。
②测试人员在做性能测试时除了要关注表面的现象如响应时间，也需要关注本质，比如用户看不到的服务器资源利用率、架构设计是否合理、代码是否合理等方方面面。
2.2性能测试的重要性
2.2.1由性能引发的严重问题
eg1:2008年的奥运会票务系统，由于欧昂大的订票人数超出预期，奥运会票务系统“开工”后不久便陷入“瘫痪”状态，当时对外公布的是奥运会票务系统每小时能处理15万张门票的销售，以及承担每小时100万次以上的网上浏览量，但10月30日系统死机前每小时的网上浏览量达到800万，1小时售出的票也达到了20万张。由于预估工作的缺陷，导致很多人无法通过网络订到自己想要的票，影响了很多人的热情，也损坏了国家形象。
eg2:作为电商的代表，2009年11月22日，eBay网站出现死机，导致卖家至少损失了当日销售额的80%，原因是那年圣诞临近时，eBay网站上有超过2亿待售商品，这个数字比上一年同期多出33%，正式这激增的33%的待售商品导致eBay网站不堪重负而死机，80%的销售额对于eBay来说不可谓不严重。
2.2.2性能测试的重要性
①随着社会的发展，用户对产品的要求也越来越高，以前可能看重功能方面，现在正在逐步转变为性能方面。
②同时各大公司也加强了产品的性能测试，因为从曾经发生的种种事件来看，性能带来的严重问题以及损失不容忽视，而性能测试的重要性也不言而喻。
2.2.3性能测试的目的
①评估当前系统。
②寻找瓶颈，优化性能。
③预测未来性能。
2.3性能测试分类详解
2.3.1性能测试的种类
①负载测试。
②压力测试。
③容量测试。
④其他：配置测试、并发测试、可靠性测试、稳定性测试。
定义：
性能测试是确定或者有效验证了系统或者软件在测试环境下的速度、可伸缩以及（或者）稳定性等各种特性。
性能是指足以满足项目或者产品的性能目标的响应时间、吞吐量以及资源利用率等。
性能测试是一个总体的概念，其他的性格相关的测试都是性能测试的子范畴。
2.3.1.1负载测试
①侧重于确定当前测试中的系统或者应用软件在工作负载条件下，或者在实际运行阶段加载预期的容量时，系统或者应用软件所具备的相关性能特性。
②通过逐步证据系统负载，测试系统性能的变化，并最终确定在满足性能指标下，系统所能够承受的最大负载量。
③负载测试是通过逐步加压的方式来确定系统的处理能力，确定系统能够承受的各项阀值。
2.3.1.2压力测试
①确定当系统或者应用软件在某些超过实际运行所预期的条件下时所具备的性能特性。
②通过逐步增加系统负载，测试系统性能的变化，并最终确定在什么负载条件下系统性能处于失效状态，并获得系统能提供最大的服务基础。
③压力测试是逐步增加负载，是系统某些资源达到饱和甚至失效的测试。
2.3.3.1压力测试的目的
目的是发现在什么条件下系统的性能变得不可接受，并通过对应用程序施加越来越大的负载，直到发现应用程序性能下降的拐点。
2.3.1.3容量测试
①在满足性能目标的前提下，系统能够最大处理的最大会话能力，确定系统可处理同时在线的最大用户数。
②容量测试确定了服务器的极限失效点，同时监控在各种不同负载和流量模式水平下的性能结果。
2.3.1.4配置测试
通过对被测试软件的软硬件配置的测试，找到系统各项资源的最优分配原则。
2.3.1.5并发测试
测试多个用户同时访问同一个应用、同一个模块或者数据记录时是否存在死锁或者其他性能问题，几乎所有的性能测试都会涉及到一些并发测试。
2.3..1.6可靠性测试
①通过给系统加载一定的业务压力的情况下，运行一段时间，检查系统是否稳定。
②通常可以测试出系统是否有内存泄露等问题。
2.3.1.7稳定性测试
在复杂多变的环境下系统所能提供的总可靠性、健壮性、功能和数据完整性、有效性以及响应的连续性。
2.4性能测试应用场景
①能力验证。
②缺陷发现。
③规划能力。
④性能调优。
⑤性能基准比较。
2.4.1应用场景特点
2.5性能测试常用指标
2.5.1并发数
①并发用户数：某一物理时刻同时向系统提交请求的用户数，提交的请求可能是同一场景或功能，也可以是不同场景或功能。
②在线用户数：某段时间内访问系统的用户数，这些用户并不一定同时向系统提交请求。
③系统用户数：系统注册的总用户数据。
三者之间的关系：系统用户数≥在线用户数≥并发用户数
2.5.2响应时间
定义：
从用户发送一个请求到用户接受到服务器返回的响应数据这段时间就是响应时间。
响应时间的计算：
经典理论：响应时间=网络响应时间+应用程序响应时间
在没有缓存的情况下，一个请求发出去后，需要经过网络传输、DNS解析等步骤才能到达服务器，服务器处理完后，经由网络传输返回给客户端，而客户端接受到以后，要进行解析渲染展示给用户。
响应时间=网络传输（请求）时间+服务器处理（一层或多层）时间+网络传输（响应）时间+页面前端解析渲染时间
2.5.3吞吐量
定义：
单位时间内系统处理的客户端请求的数量。
计算单位：一般人请求数/秒作为吞吐量的单位。从业务角度来说也可使用 访问人数/天 或 页面访问量/天 作为单位（不常用）
计算方法：Throughput=(number of requests)/ (total time)
吞吐量-负载对应关系：
①吞吐量逐渐达到饱和。
②意味着系统的一种或多种资源利用达到的极限。
③通常可以利用拐点来进行性能测试分析与定位。
2.5.4资源利用率
定义：
指的是对不同系统资源的使用程度，通常以占用最大值的百分比来衡量。
2.5.5常用服务器资源指标
CPU：就像人的大脑，主要负责相关事情的判断以及实际处理的机制。
内存：大脑中的记忆块区，将眼睛，皮肤等收集到的信息记录起来的地方，以供CPU进行判断，但是是临时的，访问速度快，如果关机或断电，这里的数据会消失。
磁盘IO：大脑中的记忆区块，将重要的数据保存起来（永久保存，关机或断电不会丢失，速度慢），以遍将来再次使用这些资源。
网络：
2.5.6其他常用指标
TPS：每秒通过事务数，是直接反应系统性能的指标，该值大时，系统性能会比较好，当然每个系统都有它的上限，不可能无线大。将它与平均事务响应时间进行对比，可以分析事务数量对响应时间的影响。
思考时间：用户每个操作后的暂停时间，或者叫操作之间的间隔时间，此时间内是不对服务器产生压力的。
每秒点击数：每秒用户向WEB服务器提交的HTTP请求数。需要注意的是，这里的点击并非指鼠标的一次单击操作，因为在一次单击操作中，客户端可能向服务器发出多个HTTP请求。
PV：访问一个URL，产生一个PV（page view,页面访问量），每日每个网站的总PV量是形容一个网站规模的重要指标。
UV：作为一个独立的用户，访问站点的所有页面均算作一个UV（Unique Vsitor,用户访问）。
2.6性能测试模型
2.6.1地铁模型分析
eg:场景：某地铁站进站只有3个刷卡机。人少的情况下，每位乘客很快就可以刷卡进站，假设进站需要1s。乘客耐心有限，如果等待超过30min，就会暴躁、唠叨，甚至选择放弃。
场景一：只有1名乘客进站时，这名乘客可以在1s的时间内完成进站，且只利用一台刷卡机，剩余2台等待着。
场景二：只有2名乘客进站时，2名乘客仍都可以在1s的时间内完成进站，且利用了2台刷卡机，剩余1台等待着。
场景三：只有3名乘客进站时，3名乘客还能在1s的时间内完成进站，且利用了3台刷卡机，资源得到充分利用。
场景四：A、B、C三名乘客进站，同时D、E、F乘客也要进站，因为A、B、C先到，所以D、E、F乘客需要排队，等A、B、C三名乘客进站完成后才行。那么A、B、C乘客进站时间为1s，而D、E、F乘客必须等待1s，所以他们3位在进站的时间是2s。
场景五：假设这次进站一次来了9名乘客，根据上面的场景，不难推断出，这9名乘客中有3名的“响应时间”为1s，有三名的“响应时间”为2s（等待1s+进站1s），还有三名的“响应时间”为3s（等待2s+进站1s）。
场景六：假设这次进站一次来了10名乘客，根据上面的推算，必然存在1名乘客的“响应时间”为4s，如果随着大量的人流涌入进站，可想而知就会达到乘客的忍耐极限。
场景七：如果地铁正好在火车站，每名乘客都拿着大小不同的包，有的乘客拿的包太大导致在刷卡机那（堵塞），这样每名乘客的进站时间就会又不一样。
场景八：进站的乘客越来越多，3台刷卡机已经无法满足需求，于是为了减少人流的积压，需要再多开几个刷卡机，增加进站的人流与速度（提升TPS、增大连接数）。
场景九：终于到了上班高峰时间了，乘客数量上升太快，现有的进站措施已经无法满足，越来越多的人开始抱怨、拥挤，情况越来越糟。单单增加刷卡机已经不行了，此时的乘客就相当于“请求”，乘客不是在地铁进站排队，就是在站台排队等车，已经造成严重“堵塞”，那么增加发车频率（加快应用、数据库的处理速度）、增加车厢数量（增加内存、增大吞吐量）、增加线路（增加服务的线程）、限流、分流等多种措施便应需而生。
