1.性能测试理论

性能测试理论

1.性能测试基础知识

1.1 为什么要做性能测试

1.1.1.大型系统崩溃事件

1.北京奥运会售票系统崩溃
https://blog.csdn.net/zhangyunbo1116/article/details/1862322?utm_source=blogxgwz1

2.12306售票系统

3.淘宝双十一下单/秒杀系统

1.1.2.当系统崩溃产生影响

1.对于用户而言当响应时间长，系统崩溃不能访问，页面卡顿，没有响应时用户体验感差，可能会造成用户群体的丢失。

2.对于研发人员，可能要考虑系统架构，数据库架构是否合理，代码算法是否可以优化。

3.对于运维人员，服务器资源是否应用合理，系统是否支持可扩展，扩展的话系统软硬件成本是否可控

4.对于老板来说 经济损失客户流失 ——-> 员工扣工资 绩效 甚至开除背锅

5.对于投资者来说 经济损失严重 负面新闻 撤资 或者拒绝投资 ——>公司倒闭

1.1.3 为什么要做

如果我们不做性能测试 下面的需求能否得到一个肯定的回答？

• 应用程序能否很快响应用户的请求
• 应用程序能否让用户在使用过程中有一个舒服的体验
• 应用程序能否在处理预期用户的请求 还有一定的盈余能力
• 应用程序是否能够在用户负载下稳定运行

1.2 什么是性能测试

1.2.1 概念

观察系统在一个给定的环境和场景中的性能表现是否与预期目标一致验证系统是否存在性能缺陷,并根据测试结果识别性能瓶颈,改善系统性能的完整的过程。本质就是模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。目的是为了通过技术手段查找出多用户多并发时系统存在的性能问题，来提升用户体验。其实就是通过工具或者代码模拟大量用户实现对服务器的并发访问 来查找出系统可能存在的性能瓶颈

1.2.2 性能测试与功能测试 焦点

功能测试：验证软件系统操作功能是否符合产品功能需求规格，主要焦点在功能（正向、逆向）；强调测试的覆盖度

性能测试：验证软件系统是否满足业务需求场景，主要焦点是业务场景的满足(时间、空间)；强调高频业务是否满足需求

说明：
时间：软件的响应时间…
空间：服务器的磁盘使用率、CPU使用率、内存空闲率…

两者是相辅相成的缺一不可

1.2.3 性能测试的类别

• 基于协议级接口的性能测试 指的是通过模拟大量的客户端请求发送给服务器，来评估服务器端的负载处理能力，硬件资源的使用效率，网络传输过程的响应时间等指标是否满足应用系统的性能需求。或者通过压力测试，模拟在极端情况下服务器端系统的稳定性和可靠性等
• 基于代码级接口的性能测试 原理上与协议级接口类似，只是更加直接地调用客户端或服务器端的API接口，通过线程并发的方式向服务器端发起请求。这种情况通常适合进行白盒层面的性能测试，用于测试某个单元的性能情况
• 单机应用程序的性能测试 很多时候，我们也会测试一些单机的应用程序或者纯粹的客户端的性能。比如移动App应用对当前移动终端的资源消耗，如CPU，内存，流量，电量等资源的利用情况。通常这种情况下，我们下面所讲授的性能测试技术是不适用也不需要，我们只需要利用好资源监控工具即可完成对客户端性能的评估。但是，如果我们仍然基于一个移动App来测试其服务器端对应的性能，那么本章所有内容则全部适用，且针对移动App的服务器端性能测试，也不存在什么特别的方法，与基于PC端应用测试其服务端的性能的技术和方法都是一致的。

1.2.4 性能测试核心技术基本原理

1. 基于协议

我们通常所说的性能测试,一般是基于网络应用系统的测试而言,基于网络的应用系统要完成性能测试,必须要通过协议来完成,这样我们才不至于受限于前端界面的限制,同时能够更好地进行场景设计和运行,并且确保一定可以自动化运行。这一点通过前端界面的方式将有很多限制。常见的协议有：HTTP，HTTPS，websocket，HLS(流媒体音视频传输)。基于协议本质是为了提高效率避免很多限制

2. 基于多线程/多进程/协程

模拟多用户

3.模拟用户真实场景 (很重要)

• 请求步骤 — 尽可能真实模拟用户场景中的操作步骤
• 请求数量 —— 尽可能真实的模拟用户的请求接口数量
• 请求大小 —— 尽量模拟用户提交数据的大小
• 思考时间 —— (固定和随机) 类似等待 模拟用户 行为
• 脚本参数化 —— 模拟不同用户（直接复制生产环境数据 或者 构建数据）
• 缓存 —— (硬盘 内存)
• 带宽 —— 可以通过工具或者路由器等网络设备进行设置或者直接测试云服务器服务(我们正常的性能测试执行都是在局域网内进行,而局域网内的带宽几乎不是问题,现在主流的局域网带宽都是1G。而真实的情况是,用户的带宽目前主流的最多也就100M,甚至还有2M,20M不等。我们的服务器在生产环境的对外出口带宽也不可能随意达到1个G,带宽费用是非常昂贵的。所以我们一定要特别注意模拟更加真实的带宽。通常情况下,在局域网内部,我们可以通过设置交换机或者路由器的限速策略来完成这过程)
• 并发用户数 —— 通过多线程 进程 协程 模拟 (在线用户数的20% 二八定律 https://www.cnblogs.com/brainchan/p/10978025.html)
• 数据库容量
• 测试环境(通常测试环境和正式环境的服务器配置是不一样的，所以如果直接测测试环境肯定会有巨大误差的)
  • 指标换算法（测试环境测试 不推荐 会存在偏差 并不能完全准确）
  • 偷梁换柱法（正式环境测试 不推荐 可能会影响到生产环境的数据 影响到用户体验 ）
  • 云服务器租赁法

1.2.5 性能测试的分类(按测试目的划分)

性能测试是个综合的概述，通常我们说的性能测试指的是测试一种分类或多种分类，任何一具体分类，都是性能测试

1.负载测试(Load Testing) 【重点】

说明：在一定的软件、硬件及网络环境下,通过改变系统负载方式、增加负载等来发现系统中所存在的性能问题。测试服务器的性能指标是否在用户的要求范围内,用于确定系统所能承载的最大用户数、最大有效用户数。关注不同用户数下的系统响应时间及服务器的资源利用率
通常通过逐步增加系统负载，测试系统性能的变化，并最终确定在满足系统的性能指标情况下，得到系统所能够承受的最大负载量。
目的：用来测试系统的容量（最大用户数，最佳用户数）定位系统的瓶颈
测试场景:拱形场景
提示:负载测试是通过逐步加压的方式来确定系统的处理能力、确定系统能够承受的各项阀值。例如：逐步加压，从而得到“响应时间不超过3秒”、“服务器平均CPU利用率低于80%”等指标的阀值。     
    负载：向服务器发送请求
    阀值：关注的某一具体数值(比如：登录小于3秒、用户数2000、业务成功率100%)
性能测试地铁模型分析  https://www.cnblogs.com/puresoul/p/5458734.html

2.压力测试(Stress Testing) 【重点】

说明：在一定的软件、硬件及网络环境下,通过模拟大量的虚拟用户向服务器产生负载,使服务器的资源处于极限状态下长时间连续运行,以测试服务器在高负载情况下是否能够稳定工作。
目的：检测服务器的稳定性 为了给项目上线之后可能出现的性能问题提前做好测试预案
测试场景：门型场景

3.并发测试(Concurrent Testing) 【重点】

说明：在一定的软硬件环境下 通过模拟多个用户 同时访问 同一个应用或接口或模块，用以检测服务器会不会出现性能缺陷
目的：检测服务器是否会出现线程死锁 资源抢占 内存泄漏等情况
提示：
    通常是为了测指定功能
    1. 并发测试需要配合【集合点】来使用
    专业术语：集合点：
    全部集合：先把数量放到一个集合点 然后统一释放/等待所有线程加载完毕，同时向服务器提交请求(秒杀系统)
    部分集合：先把数量放到一个集合点，到点释放/在超时时间内，将已加载好的线程发给服务器提交请求

4.配置测试(Configuration Testing)

说明：通过运行一种或多种业务在一定的并发用户数量情况下,获得不同配置的性能指标,用于选择最佳的设备及参数配置
目的：给项目部署环境提供最佳性能配置参照标准

5.容量测试(Volume Testing)

说明:在一定的软硬件及网络环境下,向数据库或硬盘中构造不同数量级别的数据记录,通过运行一种或多种业务在一定的虚拟用户数量情况下,获取不同数据级别的服务器性能指标
目的：验证数据库、硬盘数据存储的容量的最佳值

6.基准测试(Benchmark Testing)

说明：在一定的软硬件环境下，模拟少量的用户去请求服务器，用来检测服务器在少量用户访问时的基本性能情况
目的：为了后面的性能测试提供一个基准参考值，调试脚本验证脚本是否能正常通过

7.稳定性测试(Stability Testing)

说明：又叫极限测试 通过给系统加载一定的业务压力（如CPU资源在70%～90%的使用率）的情况下，运行一段时间(一星期 一月 一年)，
目的:   检查系统是否稳定。是否有异常表现(宕机，错误率飙升等)
提示：
    1. 通常稳定性测试，我们测试一段时间即可；
       (如：24小时、3×24小时或7×24小时来模拟长时间运行)

1.2.6 性能测试常用指标

1.响应时间(ResponseTime/RT)

用户响应时间：
说明：响应时间指用户从客户端发起一个请求开始，到客户端接收到从服务器端返回结果整个过程所耗费的时间
    2-5-8原则：响应时间在2秒以内认为速度是非常快的，2-5秒也能接受，超过5接受度没那么高，超过8秒用户是不能容忍的
    平均响应时间：多个用户操作的响应时间的平均值。
    90%的响应时间：90%的用户的响应时间都小于某个值，这个值我们称为90%的响应时间。有些公司称为90线，95%（95线），99%（99线）。
浏览器耗时分析：
    阻塞：排队等待的时间
    DNS解析：域名解析的耗时
    连接：建立tcp连接的耗时
    TLS/ssl：加密耗时
    发送：客户端给服务端发送请求的耗时
    等待：等待服务端处理，服务端处理请求的耗时
    接收：客户端接收服务端响应的耗时
接口响应时间：接口请求和获取响应的时间。这个不包括静态资源。一般都是毫秒级别的，不遵循2-5-8原则。200ms
与用户响应时间的区别：接口响应时间不包括静态资源（css，js，图片，html）的加载时间。
静态资源：对于所有用户或者所有请求拿到的响应都是一样的。
动态资源：不同的用户或者不同的请求参数获取到的响应是不一样的
跟负载的关系：随着负载的递增  响应时间逐渐递增

2.吞吐量(Throughput)

说明：吞吐量（Throughput）：指的是单位时间内处理的客户端请求数量，直接体现软件系统的性能承载能力。定位性能瓶颈。严格意义上的吞吐量指的是数据包传输的量
     通常情况下，吞吐量用“请求数/秒”或者“页面数/秒”来衡量。  其实就是吞吐率
提示：
    1. 从业务角度来看，吞吐量可以用“业务数/小时”、“业务数/天”、“访问人数/天”、“页面访问量/天”来衡量。
    2. 从网络角度来看，可以用“字节数/小时”、“字节数/天”等来衡量网络的流量。
跟负载的关系：初始阶段随着负载的递增  吞吐量逐渐递增
            中间阶段随着负载的递增  吞吐量逐渐平缓
            后期阶段随着负载的递增  吞吐量逐渐下降

3.事务处理能力(TPS/Transaction Per Second)

TPS是指每秒业务(事务)处理量,即单词"Transaction Per Second"的简写。笔数/秒，笔数/分，笔数/时。
事务: 把一系列按照特定逻辑来执行的操作，作为一个整体来计算。所有的请求要么全部执行要么都不执行
事务的四大特性：原子性 一致性 隔离性 持久性  
问:一个电商项目 每天的交易量达到1亿笔交易  求TPS
提示: 二八原则  
TPS = 1亿*80% / (24*3600)*20%

4.每秒点击数(HPS/Hits Per Second)

说明：点击数是衡量Web服务器处理能力的一个重要指标。它的统计是客户端向Web服务器发了多少次HTTP请求计算的。
提示：
    1. 点击数不是通常一般人认为的访问一个页面就是１次点击数，点击数是该页面包含的元素（如：图片、链接、框架等）向Web服务器发出的请求数数量。
    2. 通常我们也用每秒点击次数（Hits per Second）指标来衡量Web服务器的处理能力。
    3. 从客户端角度来衡量性能

5.每秒响应数(RPS/Response Per Second)

说明：每秒钟从服务器返回的响应数量
提示：从服务端角度来衡量性能

6.资源利用率

说明：是指系统各种资源的使用情况，一般用“资源的使用量/总的资源可用量×100%”形成资源利用率的数据。
提示：通常，没有特殊需求的话（不同公司要求不一样）  
      1). 建议CPU不高于80%；
      2). 内存不高于80%；
      3). 磁盘不高于90%；
跟负载的关系：初始阶段随着负载的递增逐渐递增中后期随着负载递增逐渐达到饱和

7.事务失败率 /成功率

说明：错误率指系统在负载情况下，失败事务的概率。失败率＝(失败事务数/事务总数)*100%。
提示：
    1. 不同系统对失败率要求不同，但一般不超过千分之五；
    2. 稳定性较好的系统，其失败率应该由超时引起，即为超时率。

8.并发数

说明：并发（Concurrency）：它最简单的描述就是指多个同时发生的业务操作。
      （例如，100个用户同时单击登录页面的“登录”按钮操作。）
          又对服务器同时并发 及 对单个操作或者业务的并发(抢购 秒杀)
提示：并发性测试描述的是多个客户端同时向服务器发出请求，考察服务器端承受能力的一种性能测试方式
补充: 计算并发用户数的五种方法  https://blog.csdn.net/qq_23101033/article/details/74977874

9.每秒查询率(QPS/Query Per Second)

　每秒查询率QPS是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准，在因特网上，作为域名系统服务器的机器的性能经常用每秒查询率来衡量。对应fetches/sec，即每秒的响应请求数，也即是最大吞吐能力。 （看来是类似于TPS，只是应用于特定场景的吞吐量）

1.2.7 专业术语

1.事务

事务: 把一系列按照特定逻辑来执行的操作，作为一个整体来计算。所有的请求要么全部执行要么都不执行
事物的四大特性：原子性 一致性 隔离性 持久性

2.集合点

集合点就是用来统一管理用户并发数，当设置了某一个集合点之后，集合的用户数只要符合设置的集合点条件就开始执行请求

3.关联

就是上下接口之间存在联系，下一个接口的请求参数需要从上面某个接口的响应中获取
常用于接口测试 性能测试
jmeter  后置处理器 正则表达式提取器

4.检查点/断言

就是对我们性能测试脚本中的事务进行断言处理 用以统计事务的成功或失败的状态
只有添加了检查点之后，在做性能测试的时候才会统计事务成功率

5.用户数

• 最佳用户数

  就是我们服务器的各项指标都处于最佳状态，此时系统对应的并发用户就是最佳用户数

  1.通常情况下系统岀现性能问题由两个原因导致,一是系统长时间运行而并没有很好的资源回收机制导致系统处理能力降低,二是由于使用系统的用户数增加导致系统没有更多的软件硬件资源来处理相应请求。而最佳用户数表示系统在此负载下各方面情况良好,软件硬件资源不存在浪费,也不会负载过大而濒临崩溃。通常资源利用率在60%~80%之间算是比较好的一种情况
  

• 最大用户数

  就是服务器的某些性能指标处于超负荷运行状态 ，系统随时可能宕机崩溃。此时系统对应的并发用户数叫做最大用户数

  1.指系统能跟随的最大负载。通常在此情况下,系统将很容易岀现响应不及时,或者资源利用率过大,甚至开始岀现资源不够用的情况,但是不至于让系统崩溃,勉强能够维持运转,但是已经开始影响用户体验。比如带宽已经逼近最大带宽,或者是CPU使用率已经接近100%,CPU的队列开始出现等待的情况。通常如果超过最大用户数据的话系统就会出现无法处理负载,或者网络堵塞,甚至内存溢出,系统宕机,系统无响应等情况。所以最大用户数是一个系统是否能正常运转的临界值,在系统正常处理任务时
  2.建议不要试图挑战系统的最大用户数,而应该实时监控发现出现峰值的情况,一旦出现峰值情况，应该立即采取措施
  

• 在线用户数

  就是跟服务器保持会话连接的用户，可以根据在线用户数估算并发用户数(在线用户数的8%-12% 具体情况可能存在差异)

  1.所有正在访问系统用户(不一定正在作操作,而是说当前客户端与服务器端的
  2.Session会话仍然保持),在线用户数通常不能说明系统的负载,因为很有可能是在线的用户但是在Session会话期内并没有向系统发起多少请求。只有向系统发出请求,系统才会消耗服务器资源来处理该请求,也只有在这种情况下才能真正对系统产生负载。
  3.比如我们打开首页,实现登录的过程中,我们必须会有一段时间是在输入用户名和密码,而这段输入的过程,客户端是在线的会话也是处理连接状态,但是并没有向服务器端发起请求,只有当我们点击提交"按钮时,请求才会真正发送到服务器端进行处理,这个时候,服务器端才会有负载产生
  

• 并发用户数

  同时向服务器发送请求的用户数

  1.同时对服务器产生请求的用户总数。通常情况下对"同时”的理解是狭义的,就是只
  2.有在某特定时间段内向服务器发起请求都算作"同时,也就是"并发"。而严格意义上的”并发”或"同时″是指同一时刻,这通常很难做到,所以我们忽略这一严谨的定义,而采用"时间段″来理解并发
  

• 系统用户数

  系统设计出来之后给定的一个理论值`

  1.系统额定的用户数量(设计容量),这是理论值,而我们做性能测试的目的,其实就
  2.是为了验证系统用户数是否真正可行
  

• 注册用户数

  系统上线后 用户注册的数量

6.系统负载模型图

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-1NvSzN38-1669712457709)(https://woniumd.oss-cn-hangzhou.aliyuncs.com/test/zhangjing/20210125152310.png)]

拐点法：可以协助分析定位性能瓶颈，吞吐量持续上升，用户数量增加到极限时出现下滑趋势

7.PV(Page View)

1.访问量, 即页面浏览量或点击量，衡量网站用户访问的网页数量；在一定统计周期内用户每打开或刷新一个页面就记录1次，多次打开或刷新同一页面则浏览量累计。反应的是用户使用系统的一个情况
2.可以通过后台的pv波动图计算并发数

8.UV(Unique Visitor)

独立访客，统计1天内访问某站点的用户数(以cookie为依据);访问网站的一台电脑客户端为一个访客。可以理解成访问某网站的电脑的数量。网站判断来访电脑的身份是通过来访电脑的cookies实现的。如果更换了IP后但不清除cookies，再访问相同网站，该网站的统计中UV数是不变的。如果用户不保存cookies访问、清除了cookies或者更换设备访问，计数会加1。00:00-24:00内相同的客户端多次访问只计为1个访客。

9.IP(Internet Protocol)

1.独立IP数，是指1天内多少个独立的IP浏览了页面，即统计不同的IP浏览用户数量。同一IP不管访问了几个页面，独立IP数均为1；不同的IP浏览页面，计数会加1。 IP是基于用户广域网IP地址来区分不同的访问者的，所以，多个用户（多个局域网IP）在同一个路由器（同一个广域网IP）内上网，可能被记录为一个独立IP访问者。如果用户不断更换IP，则有可能被多次统计。
扩展资料
1.IP和PV之间的关系：
PV是和IP的数量是成正比的，因为页面被刷新一次那么PV就会被记录一次，所以IP越多，说明网站的PV数据也就随之增多。但是需要注意的是PV并不是网站的页面的访问者数量，而是网站被访问的页面数量。因为一个访问者可以多次刷新页面，增加PV数量。
2.IP和UV之间的关系：
在记录网站流量统计数据时，有时候网站的IP数据大于UV数据，有时候UV的数据也会大于IP数据。。比如，用同一个IP去访问我们的SEO网站，但是一个是用的台式的电脑，一个是用的笔记本，那么网站流量统计工具显示的数据就会是2个UV，1个IP。

1.3 怎么开展性能测试

1.3.1 什么时候开始性能测试

1.先确定需不需要做

• 客户有明确的性能需求
• 当没有明确需求时
  • 如果市场用户访问量不大，时间允许就做一个基准测试，时间不允许就不做
  • 市场用户量比较大，需要先跟产品，需求人员确定好性能需求，再去做对应的性能测试

2.什么时候开始做

• 未上线的新产品
  • 都是在功能，接口测试完成之后。系统趋于稳定在做性能测试
• 已经上线的产品
  • 系统更新(新增功能，改善功能)
  • 系统扩容(扩大用户访问量，提高业务处理能力)
  • 系统优化(随着时间推移，用户量增多，系统处理变慢)
  • 系统修复(系统上线出现问题，功能缺陷，性能缺陷)
• 什么时候介入
  • 都是在功能，接口测试完成之后。系统趋于稳定在做性能测试
• 一般测那些
  • 先跑一遍基准测试 看脚本是否能通然后再去做 负载测试 压力测试 并发测试 (其他测试根据情况在做补充)

1.3.2 性能测试关注点

性能测试本身不是目的,任何一种测试类型,其核心目的都是为了发现系统存在的问题并及时修复以确保系统能够稳定运行,能够正常处理业务,能够提供给用户一个更好的使用体验,能够让客户对系统产生信心,能够成功交付运行。所以,通常情况下,我们为系统进行性能测试,主要目的是评估以下一些关注点是否满足要求

1. 客户端响应时间是否满足要求?
2. 服务器资源使用情况是否合理?
3. 应用服务器和数据库资源使用是否合理?
4. 最大访问数,最大业务处理量是多少?
5. 系统可能存在的瓶颈在哪里?
6. 能否支持7*24小时的业务访问?
7. 架构和数据库设计是否合理?
8. 内存和线程资源是否能被正常回收?
9. 代码或者SQL语句是否存在性能问题?
10. 如果系统出现不稳定情况,其可恢复性如何?

1.3.3 性能测试流程

• 分析

  • 性能测试需求分析

    说明：需求分析就是把真正需求搞清楚；
    分析点：
        响应时间
        TPS
        并发用户数
        事务成功率
        资源利用率
    例如：
        1). 对所有的功能都进行性能测试;
        2). 系统用户登录响应时间小于3秒钟;
        3). 系统支持50万用户并发访问;    
        4). 系统的日PV能达到5000个以上。
        5).    对已经上线的系统，进行性能优化
    

• 设计

  • 性能测试方案/计划

    说明：
        1). 性能测试计划是对性能测试的重要过程。
        2). 在对需求文档经过认真分析后，作为性能测试管理人员，需要编写的第一份文档就是性能测试计划;
        3). 性能测试计划中，需要阐述产品、项目的背景，将前期的需要测试性能需求明确，并落实到文档中。
    例如：
        1). 交代项目背景
        2). 测试目的
        3). 测试范围
        4). 测试设计
        5). 测试方法
        6). 测试标准
        7). 测试环境
        8). 风险分析
        9). 测试结果
        10). 测试输出
    

• 实现

  • 构建测试数据

    说明：在进行性能测试之前，我们应该先构造假数据，尽可能的模拟真实场景
    提示：自动化构建数据，获取线上用户数据，数据脱敏处理
    

  • 设计性能测试用例

    说明：性能测试需求最终要体现在性能测试用例设计中，性能测试用例应结合用户应用系统的场景，设计出相应的性能测试用例，用例应能覆盖到测试需求
    提示：
        1). 明确那些业务功能使用频繁；
        2). 明确系统预期的用户规模、并发用户数、在线用户数；
        3). 明确系统业务的处理能力要求，如：TPS、响应时间、系统资源利用率等；TPS ：(Transaction per second)事务数/秒
    

    | 测试模块 | 测试场景 | 测试描述 | 脚本设计 | 预期性能需求 |
    | —————— | :—————————————————-: | :—————————————————————————————- | :—————————————————————————————- | :—————————————————————————- |
    | 登陆 | 100用户同时登录，然后访问登录后首页 | 不断增加用户数做负载测试，50用户起步，每次递增20个。制作压力曲线拐点模型，计算最佳并发数和最大并发数 | 1、请求登陆接口 2、请求main页面，加载静态资源。登录请求和main请求加到一个事务。3、登录请求设置同步定时器 | 错误率不超过0.5%；资源利用率小于80%；响应时间小于5秒 |
    | 学院信息查询 | 100用户登录，然后同时操作学员信息查询 | 对学员信息查询做压力测试，持续2000次或者半小时 | 1、用户登录。2、请求学员信息查询接口，接口的请求数据参数化，3、线程组设置持续时间1800s | 错误率不超过0.5%；资源利用率小于80%；响应时间小于5秒 |

• 设计性能测试场景

  说明：测试场景的设计一个重要的原则就是依据测试用例，把测试用例设计的场景展现出来。
  提示：
      1). 虚拟用户数量及启动虚拟用户方式
      2). 场景的相关设置(如：集合点)
      3). 脚本是否存在依赖关系(登录与注册)
      4). 思考时间 请求数 请求大小 是否缓存 带宽
      5).    拱形（负载测试）
          门型（压力测试）
          复杂(模拟真实服务器访问情况，不停的在Ramp Up，Duration，Ramp Down之间切换，场景运行图象类似于高低起伏不同的波浪线。这类场景的运用较少，因为需要大量的历史数据作为支撑，通常不适用于对未上线的系统进行设计)
          混合(利用上述各类场景，进而更好的模拟真实情况，比较理想的一种模型，实用价值不大。)
  

• 设计性能测试脚本

  说明：性能测试用例编写完成以后，接下来就需要结合用例的需要，进行测试脚本的编写工作。
  提示：
      1). 工具选型、代码实现
      2). 脚本保证其正确性，去除冗余代码;
      3). 注重编码的规范和代码的编写质量；
  

• 执行

  • 搭建测试环境

    说明： 偷梁换柱法，指标换算法，云平台租赁
    

  • 执行测试脚本

    说明：执行测试脚本是关系到测试结果是否准确的一个重要过程。
    注意事项：
        1). 负载的测试机不能够运行设定的虚拟用户数；
        2). 没有“预热”过程；
        3). 没有模拟用户的真实环境；
        4). 性能用例运行次数过少。
    

  • 监控收集性能指标

    说明：可以在场景运行时决定要监控那些数据，便于后期分析性能测试结果。
    提示：
        1). 应用性能测试工具的重要目的就是可以提取到本次测试关心的数据指标内容;
        2). 性能测试工具利用应用服务器取得在负载过程中相关计数器的性能指标。 (计数器：计算、统计性能指标的工具)
    注意：
        1). 负载机的时钟要一致，保证在监控过程中的数据是同步的；
        2). 尽量搜集与系统测试目标相关信息，无关内容不必进行监控；
        3). 要以管理员的身份登录后
    

• 分析

  • 分析性能测试数据 找到性能瓶颈

    说明：性能测试执行过程中，性能测试工具搜集相关性能测试数据，待执行完成后，这些数据会存储到数据表或者其他文件中,为了定位系统性能问题，我们需要系统分析这些性能测试结果。
    提示：
        1). 一般使用“拐点分析”方法，利用性能计数器曲线图上的拐点进行分析的方法。（基本思想就是性能产生瓶颈的主要原因就是因为某个资源的使用达到了极限，此时表现为随着压力的增大，系统性能却出现急剧下降，就产生了“拐点”现象。）
    

  • 性能优化回归测试

    说明：性能测试分析人员经过对结果的分析以后，有可能提出系统存在性能瓶颈。
    提示：
        1). 调优人员(开发人员、数据库管理员、系统管理员、网络管理员、性能测试分析人员)相关人员对系统进行调整; 
        2). 验证-性能测试人员继续进行第二轮、第三轮……的测试，与以前的测试结果进行对比，从而确定经过调整以后系统的性能是否有提升。
    注意:
        系统调优由易到难的先后顺序如下：
        1. 硬件问题；
        2. 网络问题；
        3. 应用服务器、数据库等配置问题；
        4. 源代码、数据库脚本问题；
        5. 系统架构问题。
    

  • 设计测试报告

    • 项目背景
    • 测试目的
    • 测试方法
    • 测试环境
    • 测试目标
    • 测试数据
    • 测试结论
    • 测试分析
    • 性能优化
    • 测试时间

• 提交测试产物

  • 测试方案

  • 测试用例

  • 测试脚本
    出现急剧下降，就产生了“拐点”现象。）

  • 性能优化回归测试

    说明：性能测试分析人员经过对结果的分析以后，有可能提出系统存在性能瓶颈。
    提示：
        1). 调优人员(开发人员、数据库管理员、系统管理员、网络管理员、性能测试分析人员)相关人员对系统进行调整; 
        2). 验证-性能测试人员继续进行第二轮、第三轮……的测试，与以前的测试结果进行对比，从而确定经过调整以后系统的性能是否有提升。
    注意:
        系统调优由易到难的先后顺序如下：
        1. 硬件问题；
        2. 网络问题；
        3. 应用服务器、数据库等配置问题；
        4. 源代码、数据库脚本问题；
        5. 系统架构问题。
    

  • 设计测试报告

    • 项目背景
    • 测试目的
    • 测试方法
    • 测试环境
    • 测试目标
    • 测试数据
    • 测试结论
    • 测试分析
    • 性能优化
    • 测试时间

• 提交测试产物

  • 测试方案
  • 测试用例
  • 测试脚本
  • 测试报告