性能测试推广手册

性能测试概述

性能测试主要内容

性能测试是经过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，二者能够结合进行。经过负载测试，肯定在各类工做负载下系统的性能，目标是测试当负载逐渐增长时，系统各项性能指标的变化状况。压力测试是经过肯定一个系统的瓶颈或者不能接收的性能点，来得到系统能提供的最大服务级别的测试。

性能测试在软件的质量保证中起着重要的做用，它包括的测试内容丰富多样。中国软件评测中心将性能测试归纳为三个方面：应用在客户端性能的测试、应用在网络上性能的测试和应用在服务器端性能的测试。一般状况下，三方面有效、合理的结合，能够达到对系统性能全面的分析和瓶颈的预测。

性能测试的目的

性能测试目的是验证软件系统是否可以达到用户提出的性能指标，同时发现软件系统中存在的性能瓶颈，优化软件，最后起到优化系统的目的。

　　包括如下几个方面

　　1．评估系统的能力，测试中获得的负荷和响应时间数据能够被用于验证所计划的模型的能力，并帮助作出决策。

　　2．识别体系中的弱点：受控的负荷能够被增长到一个极端的水平，并突破它，从而修复体系的瓶颈或薄弱的地方。

　　3．系统调优：重复运行测试，验证调整系统的活动获得了预期的结果，从而改进性能。

　　检测软件中的问题：长时间的测试执行可致使程序发生因为内存泄露引发的失败，揭示程序中的隐含的问题或冲突。

　　4．验证稳定性（resilience）可靠性（reliability）：在一个生产负荷下执行测试必定的时间是评估系统稳定性和可靠性是否知足要求的惟一方法。

性能

测试的方法

一、性能测试（performance testing）：它是一种咱们常见的一种方法，它是经过模拟生产运行的业务压力量和使用场景组合，测试系统的性能是否知足生产性能的要求。简单地说就是要在特定的运行条件下验证体系统的能力情况。

这种方法的主要特色有：

1） 这种方法的主要目的是验证系统是否有系统说明具备的能力

2） 这种方法须要事先了解被测试系统典型场景，并具备肯定的性能目标

3） 这种方法要求在已肯定的环境下运行

二、负载测试(load testing)：有时被叫作可量性测试，它主要是经过在被测系统上不断增长压力，直到性能达到预约目标或者资源达到饱和状态。它能够找到体系统的处理能力的极限，为系统调优提供数据。

它的主要特色有

1）它的主要目的是找到系统处理能力的极限

2） 须要在给定的测试环境下进行，也须要考虑被测试体系统的业务压力量和典型场景，使得测试结果具备业务上的意义

3） 通常用来了解系统的性能容量，或是配合性能调优来使用。

三、、 压力测试 (stress testing) ：这种方法测试系统在必定饱和状态下，系统可以处理的会话能力，以及体系学统是否会出现错误。

这种性能测试方法具备如下特色

1) 它的主要目的是检查系统处于压力状况下时，应用的表现

2) 通常经过模拟负载等方法，使得系统的资源使用达到较高的水平

3) 通常用于测试系统的稳定性

四、并发测试（concurrency testing）：经过模拟用户的并发访问，测试多用户并发访问同一个应用、同一模块或者数据记录时是否存在死锁或者其它性能的问题

1）主要目的是发现系统中可能隐藏的并发访问时的问题

2）主要关注系统可能存在的并发问题，例如系统中的内存泄漏、死锁等方面的问题

3）这种方法能够在开发的各个阶段使用，须要相关的测试工具的配合和支持

WEB性能测试目标

目标	说明
度量最终用户响应时间	完成一个业务流程须要多长时间
度量系统容量	在没有显著性能降低的前提下，系统可以处理多大的负载
肯定瓶颈	哪些因素会延长响应时间

注：据中国IT实验室调查，平均响应时间在2秒之内的网页吸引力是最大的；平均响应时间在5秒之内的为可接受；平均响应时间在10秒以上的为烦躁型（即用户不可接收型）。

性能测试流程

性能测试流程

第一，分析产品结构，明确性能测试的需求，包括并发、极限的性能要求。

第二，分析应用场景和用户数据，细分用户行为和相关的数据流，肯定测试点或测试接口，列示系统接口的可能瓶颈，通常是先主干接口再支线接口，并完成初步的测试用例设计。

第三，依据性能测试需求和肯定的测试点进行测试用例设计，并明确不一样测试方案的重要程度或优先级做为取舍评估的依据，必要时在前期产品设计中提出支持性能测试的可测试性设计方案和对测试工具的需求。

第四，完成性能测试用例设计、分类选择和依据用户行为分析设计测试规程，并准备好测试用例将用到的测试数据。

第五，肯定采用的测试工具。

第六，进行初验测试，根据测试结果分析性能瓶颈，经过迭代保证基本的指标等测试的环境。

第七，迭代进行全面的性能测试，完成计划中的性能测试用例的执行。

第八，完成性能测试评估报告。

性能测试结果的分析流程

具体问题具体分析（这是因为不一样的应用系统，不一样的测试目的，不一样的性能关注点）

• 查找瓶颈时按如下顺序，由易到难。

服务器硬件瓶颈-〉网络瓶颈（对局域网，能够不考虑）-〉服务器操做系统瓶颈（参数配置）-〉中间件瓶颈（参数配置，数据库，web服务器等）-〉应用瓶颈（SQL语句、数据库设计、业务逻辑、算法等）

注：以上过程并非每一个分析中都须要的，要根据测试目的和要求来肯定分析的深度。对一些要求低的，咱们分析到应用系统在未来大的负载压力（并发用户数、数据量）下，系统的瓶颈在哪儿就够了。

分析的信息来源：

•1 根据场景运行过程当中的错误提示信息

•2 根据测试结果收集到的监控指标数据

设计性能测试用例的原则

设计性能测试用例注意的原则：

能够知足预期性能指标测试用例要求的，就没有必要设计更多的内容，由于用例越多，执行的本也越高。

必定要服从总体性能测试策略，千万不能仅从技术角度来考虑设计“全面”的测试用例，“全面”应该以是否知足本身的测试要求做为标准。

只有根据实际项目的特色制定合理的性能测试策略、编写适当的性能测试用例，并在测试实施中灵活地变通才能够作好性能测试工做。

性能测试输出文档：

测试计划：主要包含测试范围、测试环境、测试方案简介、风险分析等，测试计划要进行评审后方可生效。

测试报告：主要包含测试过程记录、测试分析结果、系统调整建议等。

测试经验总结：不断总结工做经验是创建学习型团队的基础，实践－总结－再实践

参考文档

性能测试术语及缩写词

测试时间：一轮测试从开始到结束所使用的时间

并发线程数：测试时同时访问被测系统的线程数。注意，因为测试过程当中，每一个线程都是以尽量快的速度发请求，与实际用户的使用有极大差异，因此，此数据不等同于实际使用时的并发用户数。

每次时间间隔：测试线程发出一个请求，并获得被测系统的响应后，间隔多少时间发出下一次请求。

平均响应时间：测试线程向被测系统发请求，全部请求的响应时间的平均值。

处理能力：在某一特定环境下，系统处理请求的速度。

cache影响系数：测试数据未必如实际使用时分散，cache在测试过程当中会比实际使用时发挥更大做用，从而使测试出的最高处理能力偏高，考虑到这个因素而引入的系数。

用户习惯操做频率：根据用户使用习惯估算出来的，单个用户在一段时间内，使用此类功能的次数。一般以一天内某段固定的高峰使用时间来统计，若是一天内没有哪段时间是固定的高峰使用时间，则以一天的工做时间来统计。

预期平均响应时间：由用户提出的，但愿系统在多长时间内响应。注意，这个值并非某一次访问的时间，而是一段时间屡次访问后的平均值。

最大并发用户数：在给定的预期平均响应时间下，系统最多能支持多少个并发用户。这个数据就是实际能够同时使用系统的用户数。

并发：狭义的并发通常分两种状况。一种是严格意义上的并发，即全部用户在同一时刻作同一件事情或操做，这种操做通常针对同一类型的业务。另外一种并发是广义的并发。这种并发与狭义的并发的区别是尽管多个用户对系统发出了请求或进行了操做，可是这些请求或操做能够是相同的，也能够是不一样的。对总体系统而言，任然有不少用户同时对系统进行操做，所以，仍然属于并发的范畴。

能够看出，广义的并发是包含狭义的并发的，并且广义的并发更接近用户的实际使用状况，由于对大多数系统而言，只有数量不多的用户进行“严格意义上的并发”。对于性能测试而言，这两种并发通常都须要进行测试，一般的作法是先进行严格意义上的并发测试。严格意义上的并发通常发生在使用比较频繁的模块中，尽管发生的几率不是特别高，可是一旦发生性能问题，后果极可能是致命的。严格意义上的并发测试每每和功能测试关联起来，由于只要并发功能遇到异常一般都是程序的问题，这种测试也是健壮性和稳定性测试的一部分。

并发用户数量：关于并发用户数量，有两种常见的错误观点。一种错误观点是把并发用户数量理解为使用系统的所有用户的数量，理由是这些用户可能同时使用系统；还有一种比较接近正确的观点是把用户在线数量理解为并发用户数量。实际上，在线用户不必定会和其余用户发生并发，例如正在浏览网页信息的用户，对服务器是没有任何影响的。可是，用户在线数量是统计并发用户数量的主要依据之一。

并发主要针对服务器而言，是否并发的关键是看用户的操做是否对服务器产生了影响。所以，并发用户数量的正确理解是，在同一时刻与服务器进行交互的在线用户数量。这些用户的最大特征是和服务器发生了交互，这种交互既能够是单向传送数据的，也能够是双向传送数据的。

并发用户数量的统计方法目前尚未准确的公式，由于不一样的系统会有不一样的并发特色。例如OA系通通计并发用户的经验公式为：使用系统的用户数量*（5%~20%）。对于这个公式，没有必要拘泥于计算出的结果，由于为了保证系统的扩展空间，测试时的并发用户数量就会稍稍大一些，除非要测试系统能承受的最大并发用户数量。举例说明：若是一个OA系统的指望用户为1000个，只要测试出系统能支持200个并发用户就能够了。

请求响应时间：请求响应时间是指从客户端发出请求到获得响应的整个过程的时间。这个过程从客户端发出一个请求开始计时，到客户端接收到从服务器端返回的响应结果计时结束。在某些工具中，请求响应时间一般会被称为"TTLB"，即"Time to last byte"，意思是从发送一个请求开始，到客户端接收到最后一个字节的响应为止所耗费的时间。请求响应时间的单位通常为“秒”或“毫秒”。

事物响应时间：事物可能由一系列请求组成，事物的响应时间主要针对用户而言，属于宏观上的概念，是为了向用户说明业务响应时间而提出来的。例如：跨行取款食物的响应时间就是由一系列的请求组成的。事物响应时间和业务吞吐率都是直接衡量系统性能的参数。

吞吐量：指在一次性能测试过程当中网络上传输的数据量的总和。吞吐量/传输时间，就是吞吐率。

吞吐率（Throughput）：一般用来指单位时间内网络上传输的数据量，也能够指单位时间内处理的客户端请求数量。是衡量网络性能的重要指标。

可是从用户或业务角度来看，吞吐率也能够用“请求数/秒”或“页面数/秒”、“业务数/小时或天”、“访问人数/天”、“页面访问量/天”来衡量。例如在银行卡审批系统中，能够用“千件/每小时”来衡量系统的业务处理能力。

TPS（Transaction Per Second）：每秒钟系统可以处理的交易或事物的数量。它是衡量系统处理能力的重要指标。TPS是LoadRunner中重要的性能参数指标。

点击率（Hit Per Second）：秒钟用户向Web服务器提交的HTTP请求书。这个指标是Web应用特有的一个指标：Web应用是“请求-响应”模式，用户发出一次申请，服务器就要处理一次，因此“点击”是Web应用可以处理交易的最小单位。若是把每次点击定义为一次交易，点击率和TPS就是一个概念。不难看出，点击率越大，对服务器的压力也越大。点击率只是一个性能参考指标，重要的是分析点击时产生的影响。

须要注意的是，这里的点击不是指鼠标的一次“单击”操做，而是在一次“单击”操做中，客户端可能向服务器发出多个HTTP请求。

资源利用率：资源利用率指的是对不一样系统资源的使用程度，例如服务器的CPU利用率、磁盘利用率等。资源利用率是分析系统性能指标而改善性能的主要依据，所以，它是Web性能测试工做的重点。

资源利用率主要针对Web服务器、操做系统、数据库服务器、网络等，是测试和分析瓶颈的主要参数。在性能测试中，要根据需求采集具体的资源利用率参数来进行分析。

成功率＝成功次数÷（成功次数＋失败次数）

处理能力＝成功次数÷测试时间

最短平均响应时间＝MIN（平均响应时间）

最高处理能力＝MAX（处理能力）×（1－cache影响系数）

最大并发用户数＝（最高处理能力－1÷（预期平均响应时间－最短平均响应时间＋（1÷最高处理能力）））÷用户习惯操做频率

注：公式要注意各时间单位的不一样和转换