什么是软件性能

什么是软件性能

定义：软件的性能是软件的一种非功能特性，它关注的不是软件是否能够完成特定的功能，而是在完成该功能时展示出来的及时性。

由定义可知性能关注的是软件的非功能特性，所以一般来说性能测试介入的时机是在功能测试完成之后。另外，由定义中的及时性可知性能也是一种指标，可以用时间或其它指标来衡量，通常我们会使用某些工具或手段来检测软件的某些指标是否达到了要求，这就是性能测试。

性能测试定义：指通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。

不同群体眼中的性能

不同的人由于人生观、世界观、价值观以及教育背景、知识体系、人生阅历的不同，对于同一事物或问题的看法可能不同。对于软件性能也是如此，不同的人由于视角的不同，所关注的点也可能不同，下面来看看在不同的人群眼中性能分别是什么样的。

用户眼中的性能：

开发眼中的性能：

系统管理员眼中的性能：

测试眼中的性能是什么样的呢？

测试人员通常是做为软件质量控制的一个角色，不仅仅是找bug，需要对整个软件的质量负责，性能也属于质量的一部分，因此测试人员眼中的性能应该是全面的，考虑的东西也需要全面：

1、测试人员需要考虑全面的性能，包括用户、开发、管理员等各个视角的性能。

2、测试人员在做性能测试时除开要关注表面的现象如响应时间，也需要关注本质，比如用户看不到的服务器资料利用率，架构设计是否合理？代码是否合理等言方方面面。

性能测试之负载测试

系统在不同负载下的性能表现，通过负载测试能够测试出系统在各种负载下的性能变化曲线，发现系统的性能拐点，从而找出系统的最佳性能。

举例：用户并发测试（递增并发用户数，查看系统性能指标变化）。

性能测试之压力测试

系统在高强度负载下的性能表现，通过压力测试可以测试出系统能够承受的最大负载。

压测是一种寻求系统介于正常和不正常之间临界值的一种负载测试。压测不仅关注高负载下系统是否正常运行，同时关注负载减小后，系统是否能够恢复。

性能测试之基准测试

基准测试（benchmarking）是一种测量和评估软件性能指标的活动，在特定时期（系统稳定时）通过基准测试建立一个已知的性能水平（称为基准线），当系统的软硬件环境发生变化之后再进行一次基准测试以确定那些变化对性能的影响。

基准测试可以比较系统在版本迭代过程中，各个性能指标的变化，为系统的版本迭代优化提供参考。

性能测试之配单测试

也叫配置项测试，对被测系统的软硬件参数进行配置的测试。通过配单测试可以找出系统各项资源指标的最佳分配比。

性能测试之容量测试

通过容量测试预先分析出反映软件系统应用特征的某项指标的极限值（如最大并发用户数、数据库记录数等），系统在其极限状态下没有出现任何软件故障或还能保持主要功能正常运行。

软硬件固定的情况下，对系统进行一定规模的数据量操作，观察系统各项性能指标是否正常。举例：电子商务网站所能承受的、同时进行交易或结算的在线用户数。

性能测试之稳定性测试

通过对软件稳定性的测试可以观察在一个运行周期内、一定的压力条件下，软件的出错机率、性能劣化趋势等。

进而大大减少软件上线后的崩溃卡死等现象，为软件的逐步优化提供方向及验证。

在特定的负载下（正常或略高于正常的负载），在一段运行周期内，对被测系统进行一系列的正常操作，观察各个系统性能指标变化以及系统是否能够长期稳定运行。

性能测试之扩展性测试

基础设施不需要经常变更，应用之间较少依赖或耦合，可以对需求变更快速响应。架构设计会考虑到未来功能的可扩展性，所以当系统增加新功能时，不需要对现有系统的结构和代码进行修改。

系统集群的扩展性测试，观察系统在集群服务器增加时，整体性能是否稳步提升，集群中的每台服务器性能是否有额外损耗等。

性能测试应用场景

1、性能测试应用场景（领域）主要有：能力验证、规划能力、性能调优、缺陷发现、性能基准比较，下表简单介绍和对比了这几个场景的各自用途和特点： 

2、通常在某个性能场景（领域）中需要联合使用多种性能测试方法一起进行性能测试，下表为性能测试应用领域与测试方法关联：

性能测试业务场景

业务场景与设计要点

业务场景顾名思义就是系统真实运行环境的场景，模拟性能测试场景的宗旨是尽可能还原业务现场真实的软硬件环境。在一些入围项目中，就需要尽可能按照入围测试的软硬件配置模拟性能测试场景。

业务场景的划分

性能测试的业务场景可以按照业务的组成以及测试目的和手段两个维度进行划分。

按照业务场景划分可以划分为单业务场景以及混合业务场景（也可以叫多业务场景），顾名思义，单业务场景的性能测试就是针对单一业务的性能测试场景，比如交换机的接口带宽测试、网站的用户登陆测试、安防系统的视频取流测试等。

混合业务场景的性能测试则是对多个业务进行综合性能测试，主要考察整个系统或者多个模块在真实业务场景下是否能够满足性能要求。

性能测试基本概念

响应时间

a）定义：从用户发送一个请求到用户接收到服务器返回的响应数据这段时间就是响应时间

b) 关键路径：下图为一次http请求经过的路径，请求会经过网络发送到web服务器进行处理，如果需要操作DB，再由网络转发到数据库进行处理，然后返回值给web服务器，web服务器最后把结果数据通过网络返回给客户端。

c) 计算方法：Response time = (N1+N2+N3+N4)+ (A1+A2+a3)，即：（网络时间 + 应用程序处理时间）

d) 响应时间-负载对应关系：

图中拐点说明：

1、响应时间突然增加

2、意味着系统的一种或多种资源利用达到的极限

3、通常可以利用拐点来进行性能测试分析与定位

吞吐量

a）定义：单位时间内系统处理的客户端请求的数量

b）计算单位：一般使用请求数／秒做为吞吐量的单位，出可以使用 页面数／秒表表示。

另外，从业务角度来说也可以使用 访问人数 /天 或 页面访问量／天 做为单位。

c）计算方法：Throughput = (number of requests) / (total time).

d）吞吐量-负载对应关系：

图中拐点说明：

1、吞吐量逐渐达到饱和。

2、意味着系统的一种或多种资源利用达到的极限。

3、通常可以利用拐点来进行性能测试分析与定位。

并发数

并发用户数：某一物理时刻同时向系统提交请求的用户数，提交的请求可能是同一个场景或功能，也可以是不同场景或功能。

在线用户数：某段时间内访问系统的用户数，这些用户并不一定同时向系统提交请求

系统用户数：系统注册的总用户数据

三者之间的关系：系统用户数 >= 在线用户数 >= 并发用户数

资源利用率

a) 定义：指的是对不同系统资源的使用程度，通常以占用最大值的百分比来衡量

b) 通常需要关注的服务器资源如下：

1、CPU：就像人的大脑，主要负责相关事情的判断以及实际处理的机制

2、内存：大脑中的记忆块区，将眼睛，皮肤等收集到的信息记录起来的地方，以供cpu进行判断，但是是临时的，访问速度快，如果关机或断电这里的数据会消失。

3、磁盘IO：大脑中的记忆区块，将重要的数据保存起来（永久保存，关机或断电不会丢失，速度慢），以便将来再次使用这些数据。

4、网络：

c）资源利用-负载对应关系：

图中拐点说明：

1、服务器某荐资源使用逐渐达到饱和。

2、通常可以利用拐点来进行性能测试分析与定位。

其它常用概念

a) TPS：Transactions Per Second，每秒事务数

b)思考时间：用户每个操作后的暂停时间，或者叫操作之间的间隔时间，此时间内是不对服务器产生压力的

c) 点击数：每秒钟用户向WEB服务器提交的HTTP请求数。这个指标是WEB应用特有的一个指标:WEB应用是"请求-响应"模式,用户发出一次申请,服务器就要处理一次，所以点击是WEB应用能够处理的交易的最小单位。如果把每次点击定义为一个交易，点击率和TPS就是一个概念。容易看出，点击率越大，对服务器的压力越大。点击率只是一个性能参考指标，重要的是分析点击时产生的影响。需要注意的是，这里的点击并非指鼠标的一次单击操作，因为在一次单击操作中，客户端可能向服务器发出多个HTTP请求.

d）PV：访问一个URL，产生一个PV（Page View，页面访问量），每日每个网站的总PV量是形容一个 网站规模的重要指标。

UV：作为一个独立的用户，访问站点的所有页面均算作一个UV（Unique Visitor，用户访问）

性能测试理发店模型

相信大家都进过或见过理发店，一间或大或小的铺面，1个或几个理发师，几张理发用的椅子和供顾客等待的长条板凳，在我们的这个理发店中，我们事先做了如下的假设：

1、理发店共有3名理发师。

2、每位理发师剪一个发的时间都是1小时。

3、我们顾客们都是很有时间观念的人而且非常挑剔，他们对于每次光顾理发店时所能容忍的等待时间+剪发时间是3小时，而且等待时间越长，顾客的满意度越低。如果3个小时还不能剪完头发，我们的顾客会立马生气的走人。

通过上面的假设我们不难想象出下面的场景：

1、当理发店内只有1位顾客时，只需要有1名理发师为他提供服务，其他两名理发师可能继续等着，也可能会帮忙打打杂。1小时后，这位顾客剪完头发出门走了。那么在这1个小时里，整个理发店只服务了1位顾客，这位顾客花费在这次剪发的时间是1小时；

2、当理发店内同时有两位顾客时，就会同时有两名理发师在为顾客服务，另外1位发呆或者打杂帮忙。仍然是1小时后，两位顾客剪完头发出门。在这1小时里，理发店服务了两位顾客，这两位顾客花费在剪发的时间均为1小时；

3、很容易理解，当理发店内同时有三位顾客时，理发店可以在1小时内同时服务三位顾客，每位顾客花费在这次剪发的时间仍然是均为1小时；

从上面几个场景中我们可以发现，在理发店同时服务的顾客数量从1位增加到3位的过程中，随着顾客数量的增多，理发店的整体工作效率在提高，但是每位顾客在理发店内所呆的时间并未延长。

当然，我们可以假设当只有1位顾客和2位顾客时，空闲的理发师可以帮忙打杂，使得其他理发师的工作效率提高，并使每位顾客的剪发时间小于1小时。不过即使根据这个假设，虽然随着顾客数量的增多，每位顾客的服务时间有所延长，但是这个时间始终还被控制在顾客可接受的范围之内，并且顾客是不需要等待的。

不过随着理发店的生意越来越好，顾客也越来越多，新的场景出现了。

假设有一次顾客A、B、C刚进理发店准备剪发，外面一推门又进来了顾客D、E、F，因为A、B、C三位顾客先到，所以D、E、F三位只好坐在长板凳上等着，1小时后，A、B、C三位剪完头发走了，他们每个人这次剪发所花费的时间均为1小时，可是D、E、F三位就没有这么好运，因为他们要先等A、B、C三位剪完才能剪，所以他们每个人这次剪发所花费的时间均为2小时——包括等待1小时和剪发1小时。

通过上面这个场景我们可以发现，对于理发店来说，都是每小时服务三位顾客——第1个小时是A、B、C，第二个小时是D、E、F；但是对于顾客D、E、F来说，“响应时间”延长了。如果你可以理解上面的这些场景，就可以继续往下看了。

在新的场景中，我们假设这次理发店里一次来了9位顾客，根据我们上面的场景，相信你不难推断，这9位顾客中有3位的“响应时间”为1小时，有3位的“响应时间”为2小时（等待1小时+剪发1小时），还有3位的“响应时间”为3小时（等待2小时+剪发1小时）——已经到达用户所能忍受的极限。假如在把这个场景中的顾客数量改为10，那么我们已经可以断定，一定会有1位顾客因为“响应时间”过长而无法忍受，最终离开理发店走了。

性能测试地铁模型

和绝大部分人一样，小白每天都要乘坐地铁上下班，那么就拿地铁来分析，再次深刻理解下性能。早上乘坐地铁上班，最典型的就是北京地铁1、5、10、13号线等，人多得简直没法形容！为了方便理解分析，先做如下假设。

某地铁站进站只有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。

通过上面这个场景可以发现，每秒能使3名乘客进站，第1s是A、B、C，第2s是D、E、F，但是对于乘客D、E、F来说，“响应时间”延长了。

场景五：假设这次进站一次来了9名乘客，根据上面的场景，不难推断出，这9名乘客中有3名的“响应时间”为1s，有3名的“响应时间”为2s（等待1s+进站1s），还有3名的“响应时间”为3s（等待2s+进站1s）。

场景六：假设这次进站一次来了10名乘客，根据上面的推算，必然存在1名乘客的“响应时间”为4s，如果随着大量的人流涌入进站，可想而知就会达到乘客的忍耐极限。

场景七：如果地铁正好在火车站，例如，著名的北京西站、北京站。每名乘客都拿着大小不同的包，有的乘客拿的包太大导致卡在刷卡机那（堵塞），这样每名乘客的进站时间就会又不一样。

小白突然想到，貌似很多地铁进站的刷卡机有加宽的和正常宽度的两种类型，那么拿大包的乘客可以通过加宽的刷卡机快速进站（增加带宽），这样就能避免场景七中的现象。

场景八：进站的乘客越来越多，3台刷卡机已经无法满足需求，于是为了减少人流的积压，需要再多开几个刷卡机，增加进站的人流与速度（提升TPS、增大连接数）。

场景九：终于到了上班高峰时间了，乘客数量上升太快，现有的进站措施已经无法满足，越来越多的人开始抱怨、拥挤，情况越来越糟。单单增加刷卡机已经不行了，此时的乘客就相当于“请求”，乘客不是在地铁进站排队，就是在站台排队等车，已经造成严重的“堵塞”，那么增加发车频率（加快应用、数据库的处理速度）、增加车厢数量（增加内存、增大吞吐量）、增加线路（增加服务的线程）、限流、分流等多种措施便应需而生。

分析到这里，小白可以熟练地把性能指标与场景结合运用起来了，初步学习成果还是不错的。

做好性能测试需要掌握的知识

1、掌握一门编程语言

2、掌握计算机原理和操作系统知识

3、良好的网络基础

4、掌握数据库知识

5、中间件（apache,tomcat）

6、常用抓包工具

7、性能测试工具