性能测试概述
性能测试主要内容
性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。
性能测试在软件的质量保证中起着重要的作用，它包括的测试内容丰富多样。中国软件评测中心将性能测试概括为三个方面：应用在客户端性能的测试、应用在网络上性能的测试和应用在服务器端性能的测试。通常情况下，三方面有效、合理的结合，可以达到对系统性能全面的分析和瓶颈的预测。
性能测试的目的
性能测试目的是验证软件系统是否能够达到用户提出的性能指标，同时发现软件系统中存在的性能瓶颈，优化软件，最后起到优化系统的目的。
包括以下几个方面
1．评估系统的能力，测试中得到的负荷和响应时间数据可以被用于验证所计划的模型的能力，并帮助做出决策。
2．识别体系中的弱点：受控的负荷可以被增加到一个极端的水平，并突破它，从而修复体系的瓶颈或薄弱的地方。
3．系统调优：重复运行测试，验证调整系统的活动得到了预期的结果，从而改进性能。
检测软件中的问题：长时间的测试执行可导致程序发生由于内存泄露引起的失败，揭示程序中的隐含的问题或冲突。
4．验证稳定性（resilience）可靠性（reliability）：在一个生产负荷下执行测试一定的时间是评估系统稳定性和可靠性是否满足要求的唯一方法。
性能
测试的方法
1、性能测试（performance testing）：它是一种我们常见的一种方法，它是通过模拟生产运行的业务压力量和使用场景组合，测试系统的性能是否满足生产性能的要求。简单地说就是要在特定的运行条件下验证体系统的能力状况。
这种方法的主要特点有：
1） 这种方法的主要目的是验证系统是否有系统说明具有的能力
2） 这种方法需要事先了解被测试系统典型场景，并具有确定的性能目标
3） 这种方法要求在已确定的环境下运行
2、负载测试(load testing)：有时被叫做可量性测试，它主要是通过在被测系统上不断增加压力，直到性能达到预定目标或者资源达到饱和状态。它可以找到体系统的处理能力的极限，为系统调优提供数据。
它的主要特点有
1）它的主要目的是找到系统处理能力的极限
2） 需要在给定的测试环境下进行，也需要考虑被测试体系统的业务压力量和典型场景，使得测试结果具有业务上的意义
3） 一般用来了解系统的性能容量，或是配合性能调优来使用。
3、、 压力测试 (stress testing) ：这种方法测试系统在一定饱和状态下，系统能够处理的会话能力，以及体系学统是否会出现错误。
这种性能测试方法具有以下特点
1) 它的主要目的是检查系统处于压力情况下时，应用的表现
2) 一般通过模拟负载等方法，使得系统的资源使用达到较高的水平
3) 一般用于测试系统的稳定性
4、并发测试（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÷最高处理能力）））÷用户习惯操作频率
注：公式要注意各时间单位的不同和转换
