软件性能测试的基本概念.docx
《软件性能测试的基本概念.docx》由会员分享，可在线阅读，更多相关《软件性能测试的基本概念.docx（28页珍藏版）》请在冰豆网上搜索。
软件性能测试的基本概念
第1章软件性能测试的基本概念
1.1什么是软件性能
提到软件性能测试，有一点是很明确的，即测试关注的重点是“性能”。
那么，究竟什么是“软件性能”？
一般来说，性能首先是一种指标，表明软件系统或构件对于其及时性要求的符合程度；其次是软件产品的一种特性，可以用时间来进行度量。
性能的及时性用响应时间或吞吐量来衡量。
响应时间是对请求做出响应所需要的时间。
对于单个事务，响应时间就是完成事务所需的时间；对于用户任务，响应时间体现为端到端的时间。
比如，“用户单击OK按钮后2秒内收到结果”就是一个对用户任务响应时间的描述，具体到该用户任务中，可能有多个具体的事务需要完成，每个事务都有其单独的响应时间。
对交互式的应用（如典型的Web应用）来说，一般以用户感受到的响应时间来描述系统的性能；而对非交互式应用（如嵌入式系统或银行等的业务处理系统）而言，响应时间是指系统对事件产生响应所需要的时间。
通常，对软件性能的关注是多个层面的。
用户、管理员和产品的开发人员都关注软件性能，那么这些不同的关注者所关注的“性能”的具体内容是不是完全相同呢？
如果不同，这些不同又在哪里？
而作为软件性能测试工程师，不同层面的软件性能都需要关注，在关注全部层面的性能体现的时候，又应该注意哪些内容呢？
下面从4个不同层面来对软件性能进行阐述。
1.1.1用户视角的软件性能
从用户的角度来说，软件性能就是软件对用户操作的响应时间。
说得更明确一点，对用户来说，从单击一个按钮、发出一条指令或是在Web页面上单击一个链接开始，到应用系统把本次操作的结果以用户能察觉的方式展示出来的过程所消耗的时间就是用户对软件性能的直观印象。
图1.1以一个Web系统为例，说明了用户的这种印象。
图1.1Web系统的响应
必须要说明的是，用户所体会到的响应时间既有客观的成分，也有主观的成分。
例如，用户执行了某个操作，该操作返回大量数据，从客观的角度来说，事务的结束应该是系统返回所有的数据，响应时间应该是从用户操作开始到所有数据返回完成的整个耗时；但从用户的主观感知来说，如果采用一种优化的数据呈现策略，当少部分数据返回之后就立刻将数据呈现在用户面前，则用户感受到的响应时间就会远远小于实际的事务响应时间（这是在C/S结构的管理系统中常用的一种技巧）。
1.1.2管理员视角的软件性能
从管理员的角度来看，软件系统的性能首先表现在系统的响应时间上，这与用户视角一致。
但管理员是一种特殊的用户，和一般用户相比，除了会关注一般用户的体验之外，还会关心和系统状态相关的信息。
例如，管理员已经知道在并发用户数为100时，A业务的响应时间为8秒，那么此时的系统状态如何？
服务器的CPU使用是否已经达到了最大值？
是否还有可用的内存？
应用服务器的状态如何？
设置的JVM可用内存是否足够？
数据库的状况如何？
是否还需要进行一些调整？
这些问题不在一般用户的体验范围之内，但对管理员来说，要保证系统的稳定运行和持续的良好性能，就必须关心这些问题。
另一方面，管理员还会想要知道系统具有多大的可扩展性、处理并发的能力如何、系统可能的最大容量是什么、系统可能的性能瓶颈在哪里、通过更换哪些设备或是进行哪些扩展能够提高系统性能等。
了解了这些情况，管理员才能根据系统的用户状况制定管理措施，在系统出现计划之外的用户增长等紧急情况时能够立即制定相应措施，进行迅速的处理。
此外，管理员可能还会关心系统在长时间的运行中是否足够稳定，是否能够不间断地提供业务服务等。
因此，从管理员的视角来看，软件性能不仅仅是应用的响应时间这么一个简单的问题。
管理员关注的部分性能相关问题，如表1-1所示。
表1-1管理员关注的部分性能相关问题
管理员关心的问题
软件性能描述
服务器的资源使用状况合理吗
资源利用率
应用服务器和数据库的资源使用状况合理吗
资源利用率
系统是否能够实现扩展
系统可扩展性
系统最多能支持多少用户的访问？
系统最大的业务处理量是多少
系统容量
系统性能可能的瓶颈在哪里
系统可扩展性
更换哪些设备能够提高系统性能
系统可扩展性
系统能否支持7×24小时的业务访问
系统稳定性
1.1.3开发视角的软件性能
从开发人员的角度来说，对软件性能的关注就更加深入了。
开发人员会关心主要的用户感受——响应时间，因为这是用户的直接体验；也会关心系统的扩展性等管理员关心的内容，因为这些也是产品需要面向的用户（特殊的用户）。
但对开发人员来说，其最想知道的是如何通过调整设计和代码实现、系统设置等方法提高软件的性能表现，以及如何发现并解决软件设计和开发过程中由于多用户访问引起的缺陷。
因此，其最关注的是使性能表现不佳的因素和由于大量用户访问引发的软件故障，也就是通常所说的性能瓶颈和系统中存在的在大量用户访问时表现出来的缺陷。
例如，对于一个没有达到预期性能规划的应用，开发人员最想要知道的是该性能的表现究竟是由于系统架构选择的不合理，还是由于代码实现的问题、数据库设计的问题，抑或是由于系统的运行环境引发的。
又如，对于一个即将发布到现场给用户使用的应用，开发人员可能会想要知道当大量用户访问该系统时，系统会不会出现某些故障，如是否存在由于资源竞争引起的挂起，是否存在由于内存处理等问题引起的系统故障等。
因此，对开发人员来说，单纯获知系统性能“好”或者“不好”的评价并没有太大的意义，他们更想知道的是哪些地方是引起不好的性能表现的根源，或是哪里可能存在故障发生的可能。
开发人员关注的部分软件性能问题如表1-2所示。
表1-2开发人员关注的部分性能问题
开发人员关心的问题
问题所属层次
架构设计是否合理
系统架构
数据库设计是否存在问题
数据库设计
代码是否存在性能方面的问题
代码
系统中是否有不合理的内存使用方式
代码
系统中是否存在不合理的线程同步方式
设计与代码
系统中是否存在不合理的资源竞争
设计与代码
1.1.4Web前端性能
前端性能，尤其是Web前端性能，已经成为目前Web应用性能主要被关注的部分之一。
随着Web应用开发技术的改变，Web应用响应时间的构成越来越复杂，Ajax等大量前端技术的应用使得服务端的响应时间在用户感受到的响应时间中所占的比例越来越小。
在这种情况下，Web前端性能越来越受到关注。
Web应用的前端响应时间指浏览器的页面加载时间。
一般而言，浏览器的页面加载时间包括对HTML的解析、对页面上的图片及CSS等文件的获取和加载、客户端脚本（JavaScript）的执行时间以及对页面进行展现所花费的时间，这部分性能体现就被称为前端性能。
与对应的服务端性能不同，前端性能的产生主要与浏览器的页面元素加载、客户端代码执行以及页面展现相关，与服务器本身并无太大的关系。
脚下留心：
Web前端响应时间主要是浏览器的展现和浏览器端脚本（如JavaScript脚本）执行所消耗的时间，严格上来说，这个时间并非与服务端的性能毫无关系。
例如，大多数Ajax应用都会使用JavaScript从服务器获取数据，获取数据所需要消耗的时间显然是依赖于服务端性能的。
然而，大多数情况下，由于Ajax本身的异步机制，这些时间消耗并不构成前端响应时间的主要部分，因此在讨论Web前端性能时，并不特别关注这部分时间。
与服务端性能不同，前端性能与并发用户量的大小并无非常直接的关系。
由于前端性能考察的主要是浏览器的展现和脚本执行时间，通常对前端性能的关注主要在浏览器展现页面的方式、浏览器各种机制的合理应用及脚本的合理性上。
概括来说，如何提高浏览器下载和执行资源的并发性，如何让浏览器尽快开始渲染页面，如何让浏览器尽可能充分地利用缓存等问题是前端性能关注的主要问题。
本书的第6章详细讨论了Web前端性能测试，包括Web前端性能的组成部分、提高Web前端性能的一般方法以及主要的用于前端性能分析的工具等，请读者参考。
1.1.5总结
以上介绍了4个不同层面上的软件性能关注点，由此可见，不同的对象对软件系统性能的关注是有着显著的差异的。
从项目管理的角度，以系统干系人来分析，大部分用户对性能的理解属于“用户视角”，项目的维护人员或用户方的项目经理一般会从“管理员视角”来看待软件性能的问题，而项目的创建者——开发人员（包括设计人员）自然就是从“开发视角”和“前端性能”来关注软件性能了。
因此，对软件性能测试来说，在不同的层面上要求我们关注不同的内容：
从直接体验的用户的角度来说，表现为软件系统对用户操作的响应时间；在系统或管理员的关注层面，还需要从软件的性能表现分析系统的可扩展性、并发能力等指标；从最贴近软件的创建者——开发人员的角度来说，还需要为软件性能问题进行定位，了解性能的制约因素和引起性能问题的关键原因。
本书的第2章描述了软件性能测试的应用领域和主要测试方法，通过这些方法和应用领域的描述，可以了解怎样将不同层面的性能关注点体现在软件性能测试的过程中。
1.2软件性能的几个主要术语
接触过软件性能测试的人，会经常听到这样一些词汇：
响应时间、并发用户数、吞吐量、性能计数器，在使用性能测试工具进行测试时，还会接触到“思考时间”（ThinkTime）的概念，那么，这些术语的确切含义究竟是什么呢？
本节重点介绍以上各个术语。
1.2.1响应时间
在1.1节和1.1.1节中都提到了“响应时间”的概念，响应时间是“对请求做出响应所需要的时间”，而且，我们把响应时间作为用户视角软件性能的主要体现。
如前所述，响应时间既有客观的成分，也有主观的成分。
例如，对一个Web应用来说，如果某页面的主要功能是向用户提供可“阅读”的内容，那么用户很可能会将“页面开始显示可阅读的内容”这个时间作为自己感受到的响应时间；而对一个主要功能是提供给用户“交互”的页面，只有当用户可以开始在页面上进行交互后，才会觉得页面“响应完成”。
我们将用户感受到的响应时间定义为“用户响应时间”，毫无疑问，“用户响应时间”是最直观地反映应用是否满足客户需求的指标，但由于该响应时间中包含主观性，很难被准确度量，因此，本书对响应时间的讨论主要基于呈现时间与服务端响应时间两方面。
如图1.1所示，将用户所感受到的软件性能（响应时间）划分为呈现时间和服务端响应时间两个部分。
其中，呈现时间取决于数据在被客户端收到后呈现给用户所消耗的时间，例如，对于一个Web应用，呈现时间就是浏览器接收到响应数据后呈现和执行页面上的脚本所消耗的时间；而服务端响应时间指应用系统从请求发出开始到客户端接收到数据所消耗的时间。
呈现时间的主要构成是前端响应时间，这部分时间主要取决于客户端而非服务端。
性能测试是否需要关注前端性能，主要取决于应用本身的特点和期望的运行环境。
例如，一台内存不足的客户端机器在处理复杂页面的时候，其呈现时间可能就很长，而这并不能说明整个系统的性能。
对于Web应用来说，即使使用同样配置的计算机，合理地使用前端技术也能极大地减少前端响应时间，因此有必要对前端响应时间进行深入的研究。
在后续的软件性能测试的讨论中，我们会经常在“前端响应时间”、“服务端响应时间”和“用户响应时间”中穿梭跳跃，为了叙述方便，除非在容易引起混淆的地方，否则，本文一概使用术语“响应时间”，请读者根据上下文自行判断。
指点迷津：
有些细心的读者可能已经注意到了，在这里把“服务端响应时间”定义为“应用系统从请求发出开始到客户端收到响应所消耗的时间”，而许多描述性能测试的书或者工具却把“响应时间”定义为“应用系统从请求发出开始到客户端接收到最后一个字节数据所消耗的时间”。
造成这种差异的原因我们认为是，对用户体验来说，可以采用一些技巧在数据尚未完全接收完成时进行呈现来减少用户感受到的响应时间。
当然，在后续的对性能测试的描述中，尤其是针对Web应用的测试（因为浏览器行为是既定的），我们仍然采用后一种定义方式来描述响应时间。
响应时间可以被进一步分解。
图1.2描述了一个Web应用的页面响应时间的构成。
从图中可以看到，页面的服务端响应时间可被分解为网络传输时间（N1+N2+N3+N4）和应用延迟时间（A1+A2+A3），而应用延迟时间又可以分解为数据库延迟时间（A2）和应用服务器延迟时间（A1+A3）。
之所以要对响应时间进行这些分解，主要目的是能够更容易地定位性能瓶颈。
在后续的实例讨论中，将会看到如何应用这些响应时间的分解进行性能问题的定位。
图1.2Web应用的页面响应时间分解
关于响应时间，要特别说明的一点是，对客户来说，该值是否能够被接受带有一定的用户主观色彩，也就是说，响应时间的“长”和“短”没有绝对的区别。
例如，对一个电子商务网站来说，在美国和欧洲，一个普遍被接受的响应时间标准为2/5/10秒，也就是说，在2秒之内给客户响应被用户认为是“非常有吸引力的”，在5秒之内响应客户被认为是“比较不错的”，而10秒是客户能接受的响应的上限。
但考虑一个税务报账系统，用户每月使用一次该系统，一次花费2小时以上进行数据的录入，当用户单击“提交”按钮后，即使系统在20分钟后才给出“处理成功”的消息，用户仍然不会认为该系统的响应时间不能接受——毕竟，相对于一个月才进行一次的操作来说，20分钟确实是一个可以接受
的等待时间。
因此，在进行性能测试时，合理的响应时间取决于实际的用户需求，而不能依据测试人员的设想来决定。
1.2.2并发用户数
在阐述“并发用户数”术语前，先来看看为什么在性能测试中需要关注并发用户数。
首先，如果性能测试的目标是验证当前系统能否支持现有用户的访问，最好的办法就是弄清楚会有多少用户会在同一个时间段内访问被测试的系统，如果使用性能测试工具模拟出与系统的访问用户数相同的用户，并模拟用户的行为，那得到的测试结果就能够真实反映实际用户访问时的系统性能表现，这样一来，就能够通过性能测试了解当系统处于实际用户访问下时，会具有怎样的性能表现。
这里提到的在同一个时间段内访问系统的用户数量，也就是我们说的并发用户数的一个概念，这种并发的概念通常在性能测试（PerformanceTesting）方法中使用，用于从业务的角度模拟真实的用户访问，体现的是业务并发用户数。
如果抛开业务的层面，仅从服务器端承受的压力来考虑，那么，对C/S或B/S结构的应用来说，系统的性能表现毫无疑问地主要由服务端决定。
在什么时候服务端会承受最大的压力，或者说，在什么时候服务端表现为最差的性能呢？
毫无疑问，肯定是在大量用户同时对这个系统进行访问的时候。
下面以
图1.3来说明这个“同时”。
图1.3用排球击打墙面
如图1.3所示，用排球击打墙面时，越多球同时击打到墙面，墙面承受的压力就越大。
如果把击打排球的人看成是系统的使用者，用墙壁代表服务端，显然，越多的用户同时使用系统，系统承受的压力越大，系统的性能表现也就越差，而且，很可能出现由于用户的同时访问导致的资源争用等问题。
在这里提到了“并发用户数”的另一个概念，该概念不从业务角度出发，而是从服务端承受的压力出发，描述的是同时向客户端发出请求的客户，该概念一般结合并发测试（ConcurrencyTesting）使用，体现的是服务端承受的最大并发访问数。
下面用一个更接近实际的例子来说明这两个“并发”概念之间的不同。
图1.4所示为实际应用系统。
图1.4实际应用系统
对服务端来说，每个用户和服务端的交互都是离散的。
如果仅考虑一个单独的用户对系统的使用，过程大致如下：
用户每隔一段时间向服务端发送一个请求或命令，服务端按照用户的要求执行某些操作，然后将结果返回给用户。
从用户的角度来看，在一个相当长的时间段内（如1天），都会有基本固定数量的使用者使用该系统，虽然每个使用者的行为不同，但从业务的角度来说，如果所有用户的操作都没有遇到性能障碍，则可以说该系统能够承受该数量的并发用户访问，这里的“并发”概念就是上面讨论的业务并发用户数。
然而，如果考虑整个系统运行过程中服务器所承受的压力，情况就会不同了：
在该系统的运行过程中，我们把整个运行过程划分为离散的时间点，在每个点上，都有一个同时向服务端发送请求的客户数，那服务端承受的最大并发访问数。
如果能找到运行过程中可能出现的最大可能的服务端承受的最大并发访问数，则在该用户数下，服务器承受的压力最大，资源承受的压力也最大，在这种状态下，可以考虑通过并发测试发现系统中存在的并发引起的资源争用等问题。
指点迷津：
上面提到的两个不同的“并发”概念之间最根本的不同是什么呢？
读者可以这样理解：
假如采用第一种“并发”的概念，同样是2000人规模的并发用户数，如果用户的操作方式不同（场景不同），服务器承受的压力是完全不同的（设想两种极端的情况：
在一种情况下，所有用户均平均每秒单击一次鼠标，发起一个业务，而在另一种情况下，所有用户平均5秒才单击一次鼠标，发起一个业务，则很明显，两种情况下服务器可能承受的最大压力是不同的），而在采用后一种“并发”的概念时，如果两种情况具有相同的最大并发用户数，则说明这两种情况下服务器承受的最大压力是相同的。
在实际的性能测试中，经常接触到的与并发用户数相关的概念还包括系统用户数和同时在线用户人数，下面用一个实际的例子来说明它们之间的差别。
假设有一个OA系统，该系统有2000个用户——这就是说，可能使用该OA系统的用户总数是2000名，这个概念就是“系统用户数”，该系统有一个“在线统计”功能（系统用一个全局变量计数所有已登录的用户），通过该功能可以得到，最高峰时有500人在线（这个500就是一般所说的“同时在线人数”），那么，系统的并发用户数是多少呢？
根据我们对业务并发用户数的定义，500即是整个系统使用时最大的业务并发用户数。
当然，500这个数值只是表明在最高峰时刻有500个用户登录了系统，并不表示服务器实际承受的压力。
因为服务器承受的压力还与具体的用户访问模式相关。
例如，在这500个同时使用系统的用户中，考察某一个时间点，假设其中40%用户在饶有兴致地看系统公告（注意，“看”这个动作是不会对服务端产生任何负担的），20%用户在填写复杂的表格（对用户填写的表格来说，只有在“提交”时才会向服务端发送请求，填写过程是不对服务端构成压力的），20%用户在发呆（也就是什么也没有做），剩下的20%用户在不停地从一个页面跳转到另一个页面——在这种场景下，可以说，只有20%的用户真正对服务器构成了压力。
因此，服务器实际承受的压力不只取决于业务并发用户数，还取决于用户的业务场景。
那么，该系统的服务端承受的最大并发访问数是多少呢？
这取决于业务并发用户数和业务场景，一般可以通过对服务器日志的分析得到。
多学两招：
究竟怎样确定一个实际系统的并发用户数呢？
在给出答案之前，读者不妨自己先思考一下。
还是以上面的例子来说，对这样一个系统，如果读者是测试的负责人员，该如何去设计测试呢？
我们前面已经说过，并发用户数决定于具体的业务场景，因此，在确定并发用户数之前，必须先对用户的业务进行分解，分析出其中的典型业务场景（也就是用户最常使用、最关注的业务操作），然后基于场景采用某些方法获得其并发用户数。
在实际的性能测试工作中，测试人员一般比较关心业务并发用户数，也就是从业务角度关注究竟应该设置多少个并发数比较合理，因此，在后面的讨论中，将主要针对业务并发用户数进行讨论，而且，为了方便，直接将业务并发用户数称为并发用户数。
那么，究竟应该如何获得测试人员关心的并发用户数的具体数值呢？
下面给出了一些用于估算并发用户数的公式：
（1-1）
（1-2）
在式（1-1）中，C是平均并发用户数，n是loginsession的数量；L是loginsession的平均长度；T指考察的时间段长度。
例如，对一个典型的OA应用，考察的时间段长度应该为8小时的工作时间。
式（2-2）则给出了并发用户数峰值的计算方式，其中，
指并发用户数的峰值；C是式（1-1）中得到的平均并发用户数。
该公式是假设用户的loginsession产生符合泊松分布而估算得到的。
下面根据书后参考文献[3]给出的方法进行实例计算。
实例：
假设有一个OA系统，该系统有3000个用户，平均每天大约有400个用户要访问该系统，对一个典型用户来说，一天只在8小时内使用该系统，且从登录到退出该系统的平均时间为4小时。
则根据式（1-1）和式（1-2），可以得到：
C=400
4/8=200
200+3
=242
书后参考文献[3]同时还给出根据并发用户数估算其他相关属性的方法。
例如，如果能够知道平均每个用户发出的请求数（假设为u），则系统的总的吞吐量就可估算为
。
当然，书后参考文献[3]给出的是一种可行的方法，但并不是唯一，甚至可以说不是最精确的方法，因为在公式中仍然需要估算平均用户数和loginsession的长度，而要精确估算这两个值并不容易。
另外，考虑到用户的业务操作存在一定的时间集中性（也就是说，用户对系统业务的访问往往不是平均分布在整个考察时间段内，而是相对集中地分布在某几个时间段内），采用式（1-1）和式（1-2）进行计算仍然存在一定的偏差。
基于书后参考文献提供的方法，我们给出一些使用该公式的建议，遵循这些建议，可以更精确地计算得到并发用户数。
（1）以更细的时间粒度进行考察。
例如，可以设定1个小时为考察时间的粒度，对一个典型的OA系统，将一天的上班时间划分为8个区间，这样可以解决业务操作存在的时间集中性的问题。
（2）考虑典型的业务模式。
不同的应用有不同的业务模式，例如，一个内部系统一般在上班后的30分钟至1小时集中出现用户的登录；一个账务系统在每月的结账日前几天比较繁忙；一个门户网站在重大消息发布的前后会有访问高峰；一个旅游网站在节假日前夕会有大量用户的访问……因此，在计算并发用户数时，可以结合应用的业务模式，多考虑一些可能发生的场景，基于这些场景进行估算。
除了书后参考文献[3]介绍的方法之外，对于企业内部使用的Web系统来说，一个更一般的（当然精度更差）经验公式是：
（1-3）
（1-4）
也就是说，用每天访问系统用户数的10%作为平均并发用户数，并发用户数的最大值由并发用户数乘以调整因子r得到，r的取值一般为2~3。
式（1-3）和式（1-4）可以在要求不太严格的性能测试，或是只有很少数据支持分析的性能测试中使用。
前面曾提到了日志分析方法。
所谓日志分析方法，是指通过对应用服务器的日志进行分析，从而了解系统用户的使用状态，从日志中计算得出服务器承受的最大并发用户访问数。
这种方式得到的数据准确度和可信度都比较高，对于Internet应用等无法估计用户数量和用户行为模式的应用，这种方式最为
可信。
日志分析方法需要日志分析工具的支持，这里推荐AWStats开源工具（Internet/Site_Management/Log_Analysis/Commercial/自行通过Google搜索loganalyzer关键字查找。
1.2.3吞吐量
吞吐量直接体现软件系统的性能承载能力，是指单位时间内系统处理的客户请求的数量。
一般来说，吞吐量用请求数/秒或页面数/秒来衡量，从业务的角度，吞吐量也可以用访问人数/天或处理的业务数/小时等单位来衡量。
当然，从网络的角度来说，也可以用字节数/天来考察网络流量。
例如，对一个Web应用系统来说，从系统的处理能力考虑，可以以页面数/秒作为吞吐量的标准；对一个银行的业务前台系统来说，可以以其处理的业务
数/小时作
升级会员 